Re: [OPSAWG] [Last-Call] Genart last call review of draft-ietf-opsawg-add-encrypted-dns-09

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.boucadair@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-bounces@ietf.org> De la part de Robert
>> Sparks
>> Envoyé : mardi 21 février 2023 15:49
>> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>;
>> gen-art@ietf.org
>> Cc : draft-ietf-opsawg-add-encrypted-dns.all@ietf.org; last-
>> call@ietf.org; opsawg@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.boucadair@orange.com wrote:
>>> Hi Robert,
>>> 
>>> Thank you for the review.
>>> 
>>> Please see inline.
>>> 
>>> Cheers,
>>> Med
>>> 
>>>> -----Message d'origine-----
>>>> De : Robert Sparks via Datatracker <noreply@ietf.org> Envoyé :
>>>> vendredi 17 février 2023 21:30 À : gen-art@ietf.org Cc :
>>>> draft-ietf-opsawg-add-encrypted-dns.all@ietf.org; last-
>>>> call@ietf.org; opsawg@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-call@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.
> 