NETMOD, We're past the confirmation period for this poll.
One response came in - thanks Rob! The good news is that his response didn't object to most (all but one) DISCUSS positions, which I think means (per the message below) that the others positions are now confirmed. This leaves open only the one DISCUSS item that Rob objected to the position for. Can folks please chime in on this thread so we can finally put this document behind us? Thank you! Kent > On May 8, 2025, at 6:17 PM, Kent Watsen <[email protected]> wrote: > > 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. > > Erik's DISCUSS (regarding the "mac-address" typedef) > Orie's DISCUSS #1( Time) > Orie's DISCUSS #2 (URI Normalization) > 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? > > > > > > 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? > > > > > > > 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? > > > 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? > > > > > > > 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? > > > > > Kent as chair (and Mahesh as AD) > > > _______________________________________________ > netmod mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
