Re: [auth48] [AD]* AUTH48: RFC-to-be 9562 <draft-ietf-uuidrev-rfc4122bis-14> for your review

[Orie Steele <[e-mail]>]

Murray, I think this is one of mine now.

[Err1957], - https://www.rfc-editor.org/verify_errata_select.php?eid=1957
(held for document update)
[Err3546], - https://www.rfc-editor.org/verify_errata_select.php?eid=3546
(held for document update)
[Err4975], - https://www.rfc-editor.org/verify_errata_select.php?eid=4975 (not
verified! .... should it be verified or held for document update?)
[Err4976], - https://www.rfc-editor.org/verify_errata_select.php?eid=4976
(held for document update)
[Err5560], - https://www.rfc-editor.org/verify_errata_select.php?eid=5560
(not verified! ... should it be verified or held for document update?)

Please let me know what to do about the 2 unverified errata.

I approve the reference to IEEE802.11bh.

OS, ART AD


On Thu, Apr 18, 2024 at 4:49 PM Sarah Tarrant <[e-mail]> wrote:

> Hello Kyzer, Michael, Brad, and *Murray,
>
> *Murray - Please review the addition of erratum IDs to the following
> sentence:
>
>    Further, [RFC4122] itself was in need of an overhaul to address a
> number of
>    topics such as, but not limited to, the following:
>     1. Implementation of miscellaneous errata reports. Mostly around
>         bit-layout clarifications, which lead to inconsistent
> implementations
>         [Err1957], [Err3546], [Err4975], [Err4976], [Err5560], etc.
>
> Also, please review the addition of the following reference to the
> following text:
>
> Reference:
>    [IEEE802.11bh]
>               IEEE, "IEEE Draft Standard for Information technology--
>               Telecommunications and information exchange between
>               systems Local and metropolitan area networks--Specific
>               requirements - Part 11: Wireless LAN Medium Access Control
>               (MAC) and Physical Layer (PHY) Specifications Amendment:
>               Enhancements for Extremely High Throughput (EHT)",
>               Electronic ISBN 978-1-5044-9520-2, March 2023,
>               <https://standards.ieee.org/ieee/802.11bh/10525/>.
>
> Current text:
>    Implementations MAY leverage MAC address randomization techniques
>    [IEEE802.11bh] as an alternative to the pseudorandom logic provided
>    in this section.
>
> Kyzer, Michael, and Brad - Thank you for your replies. We have updated the
> document accordingly.
>
> We have a few followup questions/comments.
>
> A) FYI - Regarding:
>
> >> 2) <!--[rfced] We have the following questions/comments about this text
> >>    in the Abstract and Introduction:
> .....
> > KD: I think we should revise like so:
> > Old Text:
> > This specification defines a Uniform Resource Name namespace for
> Universally Unique IDentifiers (UUIDs) (also known as Globally Unique
> IDentifiers (GUIDs)).
> >
> > New Text:
> > This specification defines UUIDs (Universally Unique IDentifiers) (also
> known as Globally Unique IDentifiers (GUIDs)) and a Uniform Resource Name
> namespace for Universally Unique IDentifiers (UUIDs).
>
> To avoid defining/expanding the term "Universally Unique IDentifiers
> (UUIDs)" twice, we updated to the following. Please let us know if there is
> any objection:
>
> Current:
>    This specification defines UUIDs (Universally Unique IDentifiers)
>    (also known as Globally Unique IDentifiers (GUIDs)) and a Uniform
>    Resource Name namespace for UUIDs.
>
>
> B) Regarding:
> >
> >
> > 20) <!-- [rfced] RFC 1738 has been obsoleted by RFC 4248.  We have
> updated
> >    to cite the latter.  Please let us know any objections.
> >
> > Original:
> >  [RFC1738]  Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
> >             Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738,
> >             December 1994, <https://www.rfc-editor.org/info/rfc1738>.
> >
> > Current:
> >  [RFC4248]  Hoffman, P., "The telnet URI Scheme", RFC 4248, DOI
> >             10.17487/RFC4248, October 2005,
> >      <https://www.rfc-editor.org/info/rfc4248>.
> > -->
> > KD:
> > RFC4248 does not replace RFC1738 in the context of this doc.
> > RFC3986 is better if we must swap one for the other.
> > Though for context I believe RFC1738 is still the best reference.
>
> We have reverted back to referencing RFC 1738. Would you like us to update
> the first instance to "[RFC1738] (obsoleted by [RFC4248])"?
>
> Original:
>    For [RFC1738] uniform
>       resource locators (URLs), one could provide a fully-qualified
>       domain-name (FQDN) with or without the protocol identifier
>       (www.example.com) or (https://www.example.com).
>
> Perhaps:
>    For Uniform Resource Locators (URLs) [RFC1738] (obsoleted
>       by [RFC4248]), one could provide a fully-qualified
>       domain-name (FQDN) with or without the protocol identifier
>       (www.example.com) or (https://www.example.com).
>
>
> C) Regarding:
> >
> >
> > 31) <!-- [rfced] Terminology: Please review the following terminology
> >    questions/comments and let us know how you'd like to proceed.
> >
> > f) Please let us know if the slashes in the following terms can be
> updated to "and", "or", or "and/or" for clarity.
> >
> >  application/language
> >  format/components
> >  formatting/encoding
> >  sub-typing/versioning mechanisms
> >  unicast/multicast
> >
> > KD:
> > AND/OR
> >  application/language
> >
> > AND
> >  format/components
> >  formatting/encoding
> >
> > OR
> >  sub-typing/versioning mechanisms
> >  unicast/multicast
> > -->
>
> How would you like us to proceed with this question?
>
>
> D) Regarding:
> > 32) <!-- [rfced] Sourcecode / Artwork
> >
> > b) In addition, please review each artwork element. Specifically, should
> any artwork element be tagged as sourcecode or another element?
> > -->
> >
> > KD:
> > A: That is fine
> > B: for the "<artwork>" tags I guess we can tag Figure 16 through 30 as
> "pseudocode" as well. The others do not need a tag.
>
> This type does not exist for the artwork element. We can update to
> sourcecode type="vector". Is that acceptable for Figures 16-30? More
> information is here:
> https://authors.ietf.org/en/rfcxml-vocabulary#sourcecode and
> https://authors.ietf.org/en/rfcxml-vocabulary#type-2
>
>
> The updated files have been posted here (please refresh):
> https://www.rfc-editor.org/authors/rfc9562.txt
> https://www.rfc-editor.org/authors/rfc9562.pdf
> https://www.rfc-editor.org/authors/rfc9562.html
> https://www.rfc-editor.org/authors/rfc9562.xml
>
> The relevant diff files have been posted here (please refresh):
> https://www.rfc-editor.org/authors/rfc9562-diff.html (comprehensive diff)
> https://www.rfc-editor.org/authors/rfc9562-auth48diff.html (AUTH48
> changes only)
>
> Note that it may be necessary for you to refresh your browser to view the
> most recent version.
>
> For the AUTH48 status of this document, please see:
>  https://www.rfc-editor.org/auth48/rfc9562
>
> Thank you,
> RFC Editor/st
>
> > On Apr 17, 2024, at 5:04 PM, Brad Peabody <[e-mail]> wrote:
> >
> > I concur with all of Kyzer’s answers, no objection from me.  (One minor
> typo is probably obvious but will mention “Var/Var” was intended to mean
> “Ver/Var” on point 26.)
> >
> > Best, Brad
> >
> >
> >> On Apr 17, 2024, at 7:10 AM, Kyzer Davis (kydavis) <[e-mail]>
> wrote:
> >>
> >> I knew I would miss one.
> >>
> >> For 17:
> >> Perhaps A works.
> >>
> >> -----Original Message-----
> >> From: Michael Richardson <[e-mail]>
> >> Sent: Wednesday, April 17, 2024 9:58 AM
> >> To: Kyzer Davis (kydavis) <[e-mail]>
> >> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> >> Subject: Re: AUTH48: RFC-to-be 9562 <draft-ietf-uuidrev-rfc4122bis-14>
> for your review
> >>
> >>
> >> Kyzer Davis (kydavis) <[e-mail]> wrote:
> >>> 17) <!--[rfced] In the following text, which meaning is correct?
> >>
> >>> Original:
> >>
> >>> After generating the 48 bit fully randomized node value,
> implementations MUST set the least significant bit of the first octet of
> the node ID set to 1.
> >>
> >>> Perhaps A (the least significant bit is set to 1):
> >>
> >>> After generating the 48-bit fully randomized node value,
> implementations MUST set the least significant bit of the first octet of
> the node ID to 1.
> >>
> >>> Perhaps B (the least significant bit is set to some value for the
> first octet of the node ID that is set to 1):
> >>
> >>> After generating the 48-bit fully randomized node value,
> implementations MUST set the least significant bit of the first octet of
> the node ID set to 1.
> >>   -->
> >>
> >> I can't see which choice you have made.
> >>
> >>
> >> --
> >> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT
> consulting )
> >>          Sandelman Software Works Inc, Ottawa and Worldwide
> >>
> >>
> >>
> >>
> >
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>