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]
