Hi Kent,
Please see inline …
From: Kent Watsen <kent+i...@watsen.net>
Date: Thursday, 8 May 2025 at 23:19
To: netmod@ietf.org <netmod@ietf.org>
Subject: [netmod] please help close open issues on rfc6991-bis
Attention NETMOD WG,
This email begins a two-week poll confirming the WG consensus for fourvopen
issues DISCUSS items related to rfc6991-bis. If no objections are received by
May 22, the positions will be confirmed.
Background: During NETMOD 122, Mahesh presented open DISCUSS issues on the
rfc6991-bis document. Unfortunately, the discussion was incomplete. so this
email presents the open DISCUSS issues again, with a default position for each.
There are four open DISCUSS issues. One from Erik and three from Orie.
1. Erik's DISCUSS (regarding the "mac-address" typedef)
2. Orie's DISCUSS #1( Time)
3. Orie's DISCUSS #2 (URI Normalization)
4. Orie's DISCUSS #3 (Did you mean A-Labels?)
Each of these DISCUSS issues are presented below.
1) Erik's DISCUSS (regarding the "mac-address" typedef)
Issues:
Regex used in ‘typedef mac-address’ is incorrect
- it's an overloaded term
- mac-address can vary from 16 to 64 bits (802.15.4), not just 48 bits
Possible Solutions:
a) Fix the regex to accommodate 16 and 64-bit
- But there is a ‘phys-address’
b) Clarify that ‘mac-address’ as defined applies to IEEE 802.3 and 802.11
- Currently, we reference IEEE 802 (without any qualifiers)
The poll conducted regarding option (b)
Can You Accept If We Just Clarify The Description Statement For Mac-Address?
The results were:
Good participation with majority Yes responses
Any objections?
No objection. Keeping the existing 6 byte format pragmatically makes the most
sense.
2) Orie's DISCUSS #1( Time)
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.
Any objections?
I think that this is okay.
My reading of this is that you use the new commonly accepted format (Z), or the
historical YANG one. I think that we should plan to remove support for
“-00:00” in future. Should we give any forward guidance to that effect?
3) Orie's DISCUSS #2 (regarding URI Normalization)
There are two issues.
Issue #1:
The URI Normalization section says:
All unnecessary
percent-encoding is removed, and all case-insensitive
characters are set to lowercase except for hexadecimal
digits within a percent-encoded triplet, which are
normalized to uppercase as described in Section 6.2.2.1
of RFC 3986.
Orie asks:
What is “unnecessary percent encoding”?
The poll conducted:
Can You Accept Removing The Unnecessary Encoding Text?
Note: should say "Percent Encoding" (not just "Encoding")
The results were:
Reasonable participation. Approximate ratio of responses 2:1:5 NA:No:Yes.
- so mostly "yes"
Any objections?
I may have been the ‘no’ vote.
My understanding of URIs is that some characters MUST be percent encoded, but
also that some other characters that don’t need to be percent encoded may be
percent encoded. E.g., “Reserved characters that have no reserved purpose in a
particular context may also be percent-encoded but are not semantically
different from those that are not.” From
https://en.wikipedia.org/wiki/Percent-encoding
Hence, I interpret this text is that for normalization purposes, if the
character can be represented without using percent encoding then it MUST use
the non percent encoded form. As such, I think that the exist text, or
something like it, it probably useful and should be retained.
Issue #2:
Orie writes:
The URI Normalization section also says:
The purpose of this normalization is to help provide
unique URIs. Note that this normalization is not
sufficient to provide uniqueness. Two URIs that are
textually distinct after this normalization may still be
equivalent.
Orie asks:
Also what is the value of producing unique URIs,
if not for comparison / equivalence checks?
Current position: no update to text.
Any objections?
No objections. I think that we are just doing the best that we can, even if we
cannot get to a perfect solution.
4) Orie's DISCUSS #3 (Did you mean A-Labels?)
Orie quotes text from the document:
```
The domain part may use both A-labels and U-labels
(see RFC 5890). The canonical format of the domain part
uses lowercase characters and U-labels (RFC 5890) where
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)
```
Current position: no update to text.
Any objections?
I don’t really have sufficient background knowledge here, but the existing text
in the document seems right. I.e., I can’t see why we want to normalize email
address domains to the A-label form.
Kind regards,
Rob
Kent as chair (and Mahesh as AD)
_______________________________________________
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
