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

["Murray S. Kucherawy" <[e-mail]>]

Given the text that's being added around the erratum IDs, I'd assume the
document editors considered them valid reports, so really either status
would be defensible.

I propose suggesting to the UUIDREV list that you plan to mark them as
verified and approve the references, and the WG has N (for some small N,
say 5 or 7) days to stop you.

-MSK

On Thu, Apr 18, 2024 at 3:14 PM Orie Steele <[e-mail]>
wrote:

> 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>
>