Hi, Thanks for addressing my comments.
Mahesh, the 2 discuss-points are roughly "safe / interoperable / standards conformant" processing of datetimes and unicode strings. If you feel that the current document is clear enough on this, feel free to tell me so : ) Inline replies for the rest: On Tue, Jan 28, 2025 at 6:34 PM Mahesh Jethanandani <mjethanand...@gmail.com> wrote: > Hi Orie, > > Do the responses from Jürgen help? If not, could you respond? Thanks. > > > On Dec 18, 2024, at 10:47 AM, Jürgen Schönwälder > <jschoenwaelder@constructor.university> wrote: > > > > On Mon, Dec 16, 2024 at 01:59:46PM -0800, Orie Steele via Datatracker > wrote: > >> Orie Steele has entered the following ballot position for > >> draft-ietf-netmod-rfc6991-bis-17: Discuss > >> > >> When responding, please keep the subject line intact and reply to all > >> email addresses included in the To and CC lines. (Feel free to cut this > >> introductory paragraph, however.) > >> > >> > >> ## Discuss > >> > >> Thanks to Bron Gondwana for the ARTART Review. > > > > [...] > > > >> > >> """ > >> The decision on whether it's more important to try to align everything > we can > >> to the more sensible handling of 'Z' and -00:00, or leave things how > they are, > >> is beyond my pay grade! I'll leave it for the IESG to weight the pros > and > >> cons. """ > >> > >> ### Time > >> > >> And the relevant comments from the authors: > > > > [...] > > > >> > >> ``` > >> unfortunate. I will update the definitions of 'date' and 'time' to > >> follow RFC 9557 but I will not touch 'date-and-time' for now unless > >> lets say the IESG decides that alignment with RFC 9557 is more > >> important than our concerns about compliance of existing > >> implementations generating canonical representations. > >> ``` > >> > >> The text in -17: > >> > >> ``` > >> 639 (b) The time-offset -00:00 indicates that the > date-and-time > >> 640 value is reported in UTC and that the local time > zone > >> 641 reference point is unknown. The time-offsets > +00:00 and Z > >> 642 both indicate that the date-and-time value is > reported in > >> 643 UTC and that the local time reference point is UTC > (see RFC > >> 644 3339 section 4.3). > >> ``` > >> > >> In contrast to the section which Bron encouraged the authors to cite > which > >> states: > >> > >> ``` > >> If the time in UTC is known, but the offset to local time is unknown, > this can > >> be represented with an offset of "Z". (The original version of this > >> specification provided -00:00 for this purpose, which is not allowed by > >> [ISO8601:2000] and therefore is less interoperable; Section 3.3 of > [RFC5322] > >> describes a related convention for email, which does not have this > problem). > >> This differs semantically from an offset of +00:00, which implies that > UTC is > >> the preferred reference point for the specified time. ``` > >> > >> and > >> > >> ``` > >> Also note that the fact that [ISO8601:2000] and later do not allow > -00:00 as a > >> local offset reduces the level of interoperability that can be achieved > in > >> using this feature; however, the present specification does not formally > >> deprecate this syntax. With the update to [RFC3339], the local offset Z > should > >> now be used in its place. ``` > >> > >> See the full details at: > > > > [...] > > > >> > >> I think you should make it clearer that 'date-and-time' is not > compliant with > >> RFC9557 but 'date' and 'time' are. > >> > >> There is currently no text in the document which comments on this. > >> > >> I could not find a reference in RFC6020 to support the comment on the > list > >> "Note that RFC6020 picked -00:00 as the canonical representation for > values in > >> UTC with an unknown local time-offset." I assume you mean RFC6021, > which has > >> the following text: > >> > >> ``` > >> > >> The date-and-time type is compatible with the dateTime XML > >> schema type with the following notable exceptions: > >> > >> (a) The date-and-time type does not allow negative years. > >> > >> (b) The date-and-time time-offset -00:00 indicates an unknown > >> time zone (see RFC 3339) while -00:00 and +00:00 and Z all > >> represent the same time zone in dateTime. > >> > >> (c) The canonical format (see below) of data-and-time values > >> differs from the canonical format used by the dateTime XML > >> schema type, which requires all times to be in UTC using the > >> time-offset 'Z'. > >> ``` > >> > >> I suggest something like: > >> > >> RFC6021 defined the canonical format for date-and-time in a way that is > not > >> directly compatible with dateTime XML Schema type, or the guidance > provided in > >> RFC 9557 which updated RFC 3339. If the time in UTC is known, but the > offset to > >> local time is unknown, this SHOULD be represented with an offset of > "Z", and > >> MAY be represented using "-00:00" for backwards compatibility. Note > that "Z" > >> and "-00:00" are semantically different from an offset of +00:00, which > implies > >> that UTC is the preferred reference point for the specified time. > > > > Existing compliant implementations report -00:00 as this was the > > canonical format picked back when RFC 6021 was written: > > > > [...] The canonical format for > > date-and-time values with an unknown time zone (usually referring > > to the notion of local time) uses the time-offset -00:00. > > > > The canonical format is there to enable predictable comparisons, > > diffs, and filters. If we move to a should be Z but may be -00:00, we > > create a problem. If the IESG believes that creating this problem is > > worth in order to align with RFC 9557, so be it. But then the move > > should be clear, i.e., the decision then is to change the canonical > > format of a 15 year old type from using -00:00 to using Z. There is > > only one canonical format, it can't be Z or -00:00. > > > > My personal take is that we should not break deployed systems. Instead > > I suggested to the working group to that a new YANG module, lets call > > it ietf-chrono-types, should be written that provides revised date and > > time related data types and also covers the new formats defined in RFC > > 9557 (supporting among other things time zone names). Once such a > > module is in place, we can go and deprecate the date and time related > > definitions in ietf-yang-types. Authors of modules using these types > > can then update their definitions as they find necessary. > > I was not trying to encourage the WG to break existing deployments, I was encouraging the deviation from RFC 9557 to be called out more directly. The abstract of RFC 9557 states: ``` It updates RFC 3339 in the specific interpretation of the local offset Z, which is no longer understood to "imply that UTC is the preferred reference point for the specified time". ``` I suggest you simply note that the canonical format used by this yang module predates the guidance in RFC 9557. Consider saying that here: ``` 639 (b) The time-offset -00:00 indicates that the date-and-time 640 value is reported in UTC and that the local time zone 641 reference point is unknown. The time-offsets +00:00 and Z 642 both indicate that the date-and-time value is reported in 643 UTC and that the local time reference point is UTC (see RFC 644 3339 section 4.3). ``` Compare with: https://datatracker.ietf.org/doc/html/rfc9557#section-2.2 ``` Also note that the fact that [ISO8601:2000] and later do not allow -00:00 as a local offset reduces the level of interoperability that can be achieved in using this feature; however, the present specification does not formally deprecate this syntax. With the update to [RFC3339], the local offset Z should now be used in its place. ``` In plain english, the yang module reads to me as conforming to the guidance in RFC 9557, but when I read RFC 9557, it's clear that the module deviates to preserve compatibility / interoperability with existing deployments, this could be made clearer. > >> ### URI Normalization > >> > >> ``` > >> 1675 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary > >> 1676 percent-encoding is removed, and all case-insensitive > >> 1677 characters are set to lowercase except for hexadecimal > >> 1678 digits within a percent-encoded triplet, which are > >> 1679 normalized to uppercase as described in Section 6.2.2.1 > >> 1680 of RFC 3986. > >> > >> 1682 The purpose of this normalization is to help provide > >> 1683 unique URIs. Note that this normalization is not > >> 1684 sufficient to provide uniqueness. Two URIs that are > >> 1685 textually distinct after this normalization may still > be > >> 1686 equivalent. > >> ``` > >> > >> What is unnecessary percent-encoding? > > > > I assume this refers to percent encodings that are not necessary, > > e.g., %41 which can be represented as A. > A more interoperable solution to this would be to cite a specific comparison / equivalence checking procedure, for example: https://url.spec.whatwg.org/#url-equivalence (just as an example) It was not obvious to me reading this, which percent encodings would be removed by implementations, consider this example: https://stackoverflow.com/questions/2742852/unicode-characters-in-urls > > > >> It seems wise to comment on unicode directly here, as you have for > A-Labels > >> regarding IDNA. > > > > Not sure I understand. > https://url.spec.whatwg.org/#example-host-parsing (just as an example) > > > >> Also what is the value of producing unique URIs if not for comparison / > >> equivalence checks? > > > > I guess this is about some form of textual equivalence of URIs and > > some form of equivalence as "do two URIs refer to the same resource". > > We care about textual equivalence. > > > >> ### Did you mean A-Labels? > >> > >> ``` > >> 1723 The domain part may use both A-labels and U-labels > >> 1724 (see RFC 5890). The canonical format of the domain part > >> 1725 uses lowercase characters and U-labels (RFC 5890) where > >> 1726 applicable."; > >> ``` > >> > >> Seems strange to suggest U-Labels in a canonical format. > >> > >> Also, is there a relevant length restriction here? > > > > YANG strings are not length restricted. > I'm not familiar with yang, but I believe hostnames do have limits, perhaps this difference / lack of constraint is not a problem. > > > >> Consider just lifting the text for this section directly from: > >> > >> ``` > >> When doing lookups, the SMTPUTF8-aware SMTP client or > >> server MUST either use a Unicode-aware DNS library, or transform the > >> internationalized domain name to A-label form (i.e., a fully- > >> qualified domain name that contains one or more A-labels but no > >> U-labels) > >> ``` > >> > >> I believe this was Bron's comment as well. > > > > I do not see how this matches to our requirements. The canonical > > format is consumed by generic (text) processing tools or filters. Also > > note that the uri definition is 10+ years old. Changing the canonical > > format now means to introduce a new definition, deprecating the old > > one, then having YANG module authors pick up the new definition as > > they see necessary. > Without being a yang expert, I can't tell if these unicode issues will lead to implementation differences that would have a negative impact. If it's the position of the group / responsible AD that these discussion-points are not a problem for YANG implementations, I'm happy to clear my DISCUSS. > > > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> ## Comments > >> > >> ### SHOULD NOT use counter32 when ... > >> > >> Should this be normative guidance? It seems like normative guidance to > me. > >> > >> ``` > >> 13 description of a schema node using this type. If such > >> 414 other times can occur, for example, the instantiation > of > >> 415 a schema node of type counter32 at times other than > >> 416 re-initialization, then a corresponding schema node > >> 417 should be defined, with an appropriate type, to > indicate > >> 418 the last discontinuity. > >> ``` > >> > >> ### SHOULD NOT use default statement > >> > >> ``` > >> 477 The counter64 type should not be used for configuration > >> 478 schema nodes. A default statement SHOULD NOT be used > in > >> 479 combination with the type counter64. > >> ``` > >> > >> I wonder under which circumstances can this advice be ignored. > >> It seems like it is natural for any type that has no defined initial > value, > >> that a default statement MUST NOT be used. > > > > Some of this text predates YANG, see for example RFC 2578 (1999) and > > its predecessors. I am reluctant to make changes. But when it comes to > > proper use of RFC 2119 language, I am always happy to follow the > > guidance of those who understand its proper use. > This was a comment, I leave it to Mahesh to determine what is best here, I'm not an expert on YANG. > > > >> ### What about leap seconds? > >> > >> Not sure if leap seconds matter for YANG, iirc, they can sometimes be > relevant > >> for GPS systems. > >> > >> ``` > >> 634 The date-and-time type is compatible with the dateTime > XML > >> 635 schema dateTime type with the following notable > exceptions: > >> ``` > >> > >> ``` > >> Because the dateTime type and other date- and time-related types > defined in > >> this specification do not support leap seconds, there are portions of > the ·UTC· > >> timeline which cannot be represented by values of these types. Users > whose > >> applications require that leap seconds be represented and that date/time > >> arithmetic take historically occurring leap seconds into account will > wish to > >> make appropriate adjustments at the application level, or to use other > types. > >> ``` > > > > The date-and-time type (which also goes back to SMIv2 RFC 2579 and its > > history) does not do leap seconds nor does it handle years larger than > > 9999. I think it can represent YYYY-MM-DDT23:59:59.9999999 (for some > > number of 9s). That said, allowing 60 seconds for leap seconds would > > technically be possible as this would enlarge the value space of the > > type, which according to section 11 of RFC 7950 third bullet is > > allowed. So we could update the pattern to allow for leap seconds. > This was a comment, I leave it to Mahesh to determine what is best here, I'm not an expert on YANG. > > > >> ### Securing Considerations > >> > >> ``` > >> 1759 This document defines common data types using the YANG data > modeling > >> 1760 language. The definitions themselves have no security > impact on the > >> 1761 Internet, but the usage of these definitions in concrete > YANG modules > >> 1762 might have. The security considerations spelled out in the > YANG > >> 1763 specification [RFC7950] apply for this document as well. > >> ``` > >> > >> This document incorporates URI normalization, datetimes, and > internationalized > >> email addresses and domain names by reference. > >> > >> You should repeat security considerations for at least a few of these > topics > >> here. > >> > >> For example: > >> > > > > [...] > > > > Not sure about "repeating" security considerations. Perhaps what you > > suggest is that there should be statement saying: > > > > If an author uses one of the types defined in these modules, then > > the author should consult the security considerations contained in > > the references associated with the definition of the type. > > > > I prefer a generic solution rather then copying material and then the > > next update of this collection of definitions will get even more > > complicated. Also note that authors of YANG modules published as RFCs > > have to provide security considerations for the actual leafs and > > operations. > This is related to the discuss-points, and it was just a comment. I leave it to Mahesh to determine what is best here, I'm not an expert on YANG. > > > > /js > > > > -- > > Jürgen Schönwälder Constructor University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > _______________________________________________ > > netmod mailing list -- netmod@ietf.org > > To unsubscribe send an email to netmod-le...@ietf.org > > Mahesh Jethanandani > mjethanand...@gmail.com > > > >
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
