Please ignore Sorry for the noise, but the tools-team pointed me to a mailman3 setting that might be causing my CC’s being removed. CC-ing Rob again as a test.
K. > On Jul 30, 2024, at 1:08 PM, Kent Watsen <[email protected]> wrote: > > [CC-ing Rob] > > >> On Jul 30, 2024, at 1:02 PM, Kent Watsen <[email protected]> wrote: >> >> Hi Juergen, >> >> During the IETF 120 NETMOD session, there was a discussion regarding the >> status of this document. The chairs asked if anyone would be willing to >> help get it over the line. Both Rob and Joseph (CC-ed) volunteered. >> >> Is there a repo that you were working out of? >> >> Kent // as shepherd >> >> >>> On Apr 6, 2024, at 2:23 AM, Jürgen Schönwälder >>> <[email protected]> wrote: >>> >>> Hi Mahesh, >>> >>> I stopped working on this document since the AD indicated that he will >>> refuse any non-backwards compatible changes (regardless whether they >>> can be considered bug fixes). And I am personally also not happy about >>> some of the new naming conventions (which this message/thread was >>> about). If we are now taking a fresh look at things, I can produce a >>> new version, but this really only makes sense if we are willing to >>> actually publish this update. >>> >>> /js >>> >>> On 06.04.24 06:04, Mahesh Jethanandani wrote: >>>> Hi Juergen, >>>> Reviving this thread to identify next steps for the document. Where are we >>>> with publishing a -16 version of the draft? >>>> I do not see objections to most of your suggestions on the changes you >>>> recommend. For milli vs micro part of the discussion, could we have both? >>>> Separately, on the other thread on for changes to IPv6 zone definition, >>>> which I will respond to, can you summarize what the consensus is, so we >>>> can try to close on the thread. >>>> Thanks >>>>> On Mar 23, 2023, at 11:29 AM, Andy Bierman <[email protected]> wrote: >>>>> >>>>> >>>>> >>>>> On Thu, Mar 23, 2023 at 5:11 AM tom petch <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> From: netmod <[email protected] <mailto:[email protected]>> >>>>> on behalf of Jürgen Schönwälder <[email protected]> >>>>> Sent: 23 March 2023 11:13 >>>>> >>>>> On Wed, Mar 22, 2023 at 01:31:43PM +0000, Rob Wilton (rwilton) wrote: >>>>>> Hi Jürgen, >>>>>> >>>>>> Thanks for the draft. Please see my AD review comments below, except >>>>>> for a couple of comments related to the change to ipv6-address >>>>>> definition that I've spun into a separate thread so that I can include >>>>>> the interested parties of draft-ietf-6man-rfc6874bis into the discussion. >>>>> >>>>> Thanks for your review. See responses inline. >>>>> >>>>>> Moderate level comments: >>>>>> >>>>>> (1) p 13, sec 3. Core YANG Types >>>>>> >>>>>> typedef date-with-zone-offset { >>>>>> >>>>>> Why don't we just call this 'date' rather than 'date-with-zone-offset', >>>>>> particularly because the zone information is optional? Intuitively, >>>>>> from the name of this type, I would have expected that zone information >>>>>> as being required rather than being optional. >>>>>> >>>>>> I also note that the current naming convention of this type seems >>>>>> somewhat inconsistent from "date-no-zone", since one of them includes >>>>>> "offset" and the other does not. >>>>>> >>>>>> This same comment also applies to 'time-with-zone-offset'. >>>>> >>>>> Earlier versions had just 'date' and 'time' and both included a zone >>>>> offset. We then also got 'date-no-zone' and 'time-no-zone' and all was >>>>> kind of nice and consistent. Then the IP address debate kicked in and >>>>> finally some people made the point that we should be always explicit >>>>> (but then you can't encode all semantics in a name anyway). So this is >>>>> how we got to the names we have now. For me personally, 'date' and >>>>> 'date-no-zone' and 'time' and 'time-no-zone' was just fine. The >>>>> '-offset' came in as a way to future proof definitions since in some >>>>> contexts you may want to indicate the timezone not with a fixed offset >>>>> but with a timezone name like 'Europe/Berlin' that is then resolved >>>>> using more complex rules to a specific offset. >>>>> >>>>> I personally would be happy to change date-with-zone-offset back to >>>>> date and time-with-zone-offset back to time and to deal with the >>>>> future in the future... >>>>> >>>>> <tp> >>>>> >>>>> Me too. I think that the fashion for incorporating ever more semantics >>>>> into an identifier is a misunderstanding of what an identifier is for ie >>>>> to identify. >>>>> >>>>> >>>>> Me three. >>>>> IMO simple names like 'date' and 'time' and 'date-and-time' are easier to >>>>> understand. >>>>> Optional fields are different than mandatory fields. >>>>> If a data type has some mandatory field, then it may need to have its own >>>>> typedef and name. >>>>> >>>>> >>>>> >>>>> Tom Petch >>>>> >>>>> Andy >>>>> >>>>>> (2) p 27, sec 4. Internet Protocol Suite Types >>>>>> >>>>>> I've moved this comment to a separate thread. >>>>>> >>>>>> >>>>>> (3) p 28, sec 4. Internet Protocol Suite Types >>>>>> >>>>>> I've moved this comment to a separate thread. >>>>>> >>>>>> >>>>>> Minor level comments: >>>>>> >>>>>> (4) p 13, sec 3. Core YANG Types >>>>>> >>>>>> description >>>>>> "The date type represents a time-interval of the length >>>>>> of a day, i.e., 24 hours. >>>>>> >>>>>> I think that it might be helpful if the first part of the description >>>>>> stated that the type optionally includes the zone offset, particularly >>>>>> to differentiate from the type that excludes it. >>>>> >>>>> I am happy to add. "It includes and optional time zone offset." so >>>>> that it says: >>>>> >>>>> "The date type represents a time-interval of the length >>>>> of a day, i.e., 24 hours. It includes and optional time >>>>> zone offset. >>>>> >>>>> With the current naming scheme, we would have to >>>>> s/date/date-with-zone-offset/ everywhere in the description. >>>>> That will look pretty ugly. [sarcasm on] Perhaps we should >>>>> call it 'date-with-optional-zone-offset' and then the additional >>>>> sentence is not needed anymore. [sarcasm off] >>>>> >>>>>> This same comment also applies to 'time-with-zone-offset'. >>>>> >>>>> Yes. >>>>> >>>>>> (5) p 14, sec 3. Core YANG Types >>>>>> >>>>>> type date-with-zone-offset { >>>>>> pattern '[0-9]{4}-(1[0-2]|0[1-9])-(0[1-9]|[1-2][0-9]|3[0-1])'; >>>>>> } >>>>>> >>>>>> Although I can understand why it is modelled this way, i.e., to make the >>>>>> relationship between the types clear, there is likely to be a small >>>>>> performance overhead of modelling it this way, where this regex for this >>>>>> type is a strict subset of date-with-zone-offset. I wonder whether it >>>>>> would be cleaner to just define this type as an equivalent top-level >>>>>> type to date-with-zone-offset, both in the definition and description >>>>>> rather than as a derived type? >>>>>> >>>>>> This same comment also applies to 'time-no-zone'. >>>>> >>>>> This would require to copy quite some text and then this cloned text >>>>> needs to be kept consistent in the future. I do not think this is a >>>>> good idea. Implementations can take shortcuts if this is found to be >>>>> time critical (but that might also be very implementation specific). >>>>> My preference is to not change this. >>>>> >>>>>> (6) p 15, sec 3. Core YANG Types >>>>>> >>>>>> The maximum time period that can be expressed is in the >>>>>> range [-89478485 days 08:00:00 to 89478485 days 07:00:00]. >>>>>> >>>>>> I found this notation slightly confusing. When I originally saw it, I >>>>>> assumed that it is talking about time zones, and it only really made >>>>>> sense when comparing it to the other periods. >>>>>> >>>>>> I wasn't sure whether the specific details are that important, and >>>>>> whether defining it as -89478485 days to 89478485 days, might be both >>>>>> sufficient and easier to read. >>>>>> >>>>>> E.g., >>>>>> The maximum time period that can be expressed is in the >>>>>> range [-89478485to 89478485] days . >>>>>> >>>>>> If changed, this same comment applies to the other period types as well. >>>>> >>>>> For time periods with lower resolution, the details start to matter, >>>>> (see microseconds32 on the extreme end) and so I ended up using the >>>>> same notation and precision for all types. I think this is generally >>>>> the right thing to do, being always precise is better than arbitrarily >>>>> dropping precision. If someone has ideas for a better notation, I am >>>>> open for that. Perhaps adding ", where hh:mm:ss stands for hours, >>>>> minutes and seconds" would already do it?: >>>>> >>>>> The maximum time period that can be expressed is in the >>>>> range [-89478485 days 08:00:00 to 89478485 days 07:00:00], >>>>> where hh:mm:ss stands for hours, minutes and seconds." >>>>> >>>>>> (7) p 15, sec 3. Core YANG Types >>>>>> >>>>>> This type should be range restricted in situations >>>>>> where only non-negative time periods are desirable, >>>>>> (i.e., range '0..max')."; >>>>>> >>>>>> Isn't this going to be the common mainline case for network >>>>>> configuration? I.e., I presume that most cases where periods are >>>>>> intervals are going to be reported will be positive. Hence, it might be >>>>>> helpful to have a separate set of types defined for the positive only >>>>>> cases. >>>>>> >>>>>> This same comment applies to the other period types. >>>>> >>>>> I ones had unsigned versions of these types. If we also add unsigned >>>>> types, we end up with nine additional types, we would get something >>>>> like: >>>>> >>>>> hours-int32 >>>>> hours-uint32 >>>>> minutes-int32 >>>>> minutes-uint32 >>>>> seconds-int32 >>>>> seconds-uint32 >>>>> ... >>>>> nanoseconds-int64 >>>>> nanoseconds-uint64 >>>>> >>>>> Well, perhaps this is the right thing to do, people can then pick what >>>>> is most appropriate for their use case. >>>>> >>>>>> (8) p 16, sec 3. Core YANG Types >>>>>> >>>>>> typedef milliseconds32 { >>>>>> >>>>>> I was slightly surprised that we don't have a milliseconds64, e.g., the >>>>>> default timestamp in Java is given as an int64 in milliseconds. >>>>>> >>>>> >>>>> So far nobody asked for it. On POSIX systems (I think POSIX.1-2001 and >>>>> later), you usually have system APIs that can go into microsecond >>>>> resolution: >>>>> >>>>> struct timeval { >>>>> time_t tv_sec; /* seconds */ >>>>> suseconds_t tv_usec; /* microseconds */ >>>>> }; >>>>> >>>>> But if there is a use case for milliseconds64, I can easily add it. >>>>> well milliseconds-int64 and milliseconds-uint64, depending on the >>>>> resolution of your previous point. >>>>> >>>>>> Nit level comments: >>>>>> >>>>>> (9) p 21, sec 3. Core YANG Types >>>>>> >>>>>> 7950. An earlier version of this definition did exclude >>>>>> >>>>>> I suggest 'did exclude' -> 'excluded' >>>>> >>>>> Changed. >>>>> >>>>> /js >>>>> >>>>> -- >>>>> Jürgen Schönwälder Constructor University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>>> Fax: +49 421 200 3103 <https://constructor.university/ >>>>> <https://constructor.university/>> >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> <https://www.ietf.org/mailman/listinfo/netmod> >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> <https://www.ietf.org/mailman/listinfo/netmod> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> <https://www.ietf.org/mailman/listinfo/netmod> >>>> Mahesh Jethanandani >>>> [email protected] >>> >>> -- >>> Jürgen Schönwälder Constructor University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> >>> _______________________________________________ >>> netmod mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> netmod mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > > _______________________________________________ > netmod mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
