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. > >> ### 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. > >> It seems wise to comment on unicode directly here, as you have for A-Labels >> regarding IDNA. > > Not sure I understand. > >> 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. > >> 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. > >> ---------------------------------------------------------------------- >> 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. > >> ### 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. > >> ### 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. > > /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
