Section 9 of https://datatracker.ietf.org/doc/draft-ietf-add-dnr/13/ does indeed request those assignments. And given that RFC-editor is working on converting this into an RFC, IANA must make the assignments for the RFC to be published.
- Bernie (from iPad) > On Feb 21, 2023, at 10:54 AM, mohamed.boucad...@orange.com wrote: > > Hi Robert, > > Thanks for the follow-up. > > Bernie has provided the context for 162/144 codes. > > For your second comment, a first attempt to tweak the text can be seen at: > https://tinyurl.com/opsawg-add-latest. This may be tweaked a little bit for > better readability. > > Cheers, > Med > >> -----Message d'origine----- >> De : last-call <last-call-boun...@ietf.org> De la part de Robert >> Sparks >> Envoyé : mardi 21 février 2023 15:49 >> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; >> gen-art@ietf.org >> Cc : draft-ietf-opsawg-add-encrypted-dns....@ietf.org; last- >> c...@ietf.org; ops...@ietf.org >> Objet : Re: [Last-Call] Genart last call review of draft-ietf- >> opsawg-add-encrypted-dns-09 >> >> >>> On 2/20/23 12:42 AM, mohamed.boucad...@orange.com wrote: >>> Hi Robert, >>> >>> Thank you for the review. >>> >>> Please see inline. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Robert Sparks via Datatracker <nore...@ietf.org> Envoyé : >>>> vendredi 17 février 2023 21:30 À : gen-art@ietf.org Cc : >>>> draft-ietf-opsawg-add-encrypted-dns....@ietf.org; last- >>>> c...@ietf.org; ops...@ietf.org Objet : Genart last call review >> of >>>> draft-ietf-opsawg-add- >>>> encrypted-dns-09 >>>> >>>> Reviewer: Robert Sparks >>>> Review result: Ready with Issues >>>> >>>> I am the assigned Gen-ART reviewer for this draft. The General >> Area >>>> Review Team (Gen-ART) reviews all IETF documents being >> processed by >>>> the IESG for the IETF Chair. Please treat these comments just >> like >>>> any other last call comments. >>>> >>>> For more information, please see the FAQ at >>>> >>>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. >>>> >>>> Document: draft-ietf-opsawg-add-encrypted-dns-09 >>>> Reviewer: Robert Sparks >>>> Review Date: 2023-02-17 >>>> IETF LC End Date: 2023-02-23 >>>> IESG Telechat date: Not scheduled for a telechat >>>> >>>> Summary: After addressing an issue, this will be ready for >>>> publication as a Proposed Standard RFC >>>> >>>> Issue: draft-ietf-add-dnr needs to be a normative reference, or >> some >>>> other mechanic needs to be used to ensure draft-ietf-add-dnr is >>>> published as an RFC before IANA follows the instructions in >> this >>>> document. >>>> >>> [Med] 142/166 are permanent assignments. The IANA registry is >> authoritative here. >> >> Ok, digging into the registries, I see 144 for OPTION_V6_DNR and >> 162 for OPTION_V4_DNR. Is that what you meant? If not, what are >> 142/166 pointing to? >> >> That these are already in the registries addresses the issue I >> raised, but please remind me how to find the artifacts that _put_ >> these points in the registry? I assume something triggered early >> permanent assignments for these? I wonder if those should be more >> transparently tracked. >> >>> >>> >>> Please note that we have the following to make sure that the >> registry is in sync vs. DHCP and have this note for IANA: >>> >>> The initial content of this sub-registry is listed in Table >> 4. The >>> Value and Description fields echo those of [DHCPv6]. >>> >>> Changes to the entry in the dhcp options registry will be >> automatically reflected in the registry defined by this document. >>> >>>> Nit: The discussion in paragraph 3 of section 3 and the note >> that >>>> follows are currently ambiguous. When it calls out that 2865 >> limits >>>> the size of DHCP options and that 7499 and 7930 relaxes the >> limit, is >>>> it only trying to inform where the recommendation of supporting >> 65535 >>>> bytes came from? Or is it trying to constrain the size of any >> DHCP >>>> option added to the the attributes defined here to 4096? >>>> >>> [Med] Alan already clarified this one. Please let us know if any >> text tweak is needed. >> Yes, I do think the document would be improved if it more directly >> stated what Alan said in his earlier response. >>> >>> >>> >> __________________________________________________________________ >> ____ >>> ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des >> informations >>> confidentielles ou privilegiees et ne doivent donc pas etre >> diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce >> message >>> par erreur, veuillez le signaler a l'expediteur et le detruire >> ainsi que les pieces jointes. Les messages electroniques etant >> susceptibles d'alteration, Orange decline toute responsabilite si >> ce message a ete altere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should >> not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the >> sender and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that >> have been modified, changed or falsified. >>> Thank you. >>> >> >> -- >> last-call mailing list >> last-c...@ietf.org >> https://www.ietf.org/mailman/listinfo/last-call > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
