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.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Orie Steele, ART AD, comments for draft-ietf-netmod-rfc6991-bis-17 CC @OR13 * line numbers: - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-netmod-rfc6991-bis-17.txt&submitcheck=True * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Discuss Thanks to Bron Gondwana for the ARTART Review. I see: https://mailarchive.ietf.org/arch/msg/netmod/nXYnXH3oBBADXyW8YmWGMQnPb1M/ """ 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: https://mailarchive.ietf.org/arch/msg/netmod/PePGt7_5e-R9xMDIebRt1edDTBs/ ``` 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: https://datatracker.ietf.org/doc/html/rfc9557#section-2.2 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. ### 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? It seems wise to comment on unicode directly here, as you have for A-Labels regarding IDNA. Also what is the value of producing unique URIs if not for comparison / equivalence checks? ### 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? https://datatracker.ietf.org/doc/html/rfc5890#section-4.2 Consider just lifting the text for this section directly from: https://datatracker.ietf.org/doc/html/rfc6531#section-3.2 ``` 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. ---------------------------------------------------------------------- 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. ### 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. ``` - https://www.w3.org/TR/xmlschema11-2/#d-t-values - https://www.rfc-editor.org/rfc/rfc3339#appendix-D ### 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: - https://datatracker.ietf.org/doc/html/rfc3339#section-7 - https://datatracker.ietf.org/doc/html/rfc3986#section-7.2 - https://datatracker.ietf.org/doc/html/rfc5890#section-4.2 _______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
