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
