From nobody Tue Feb 21 09:47:43 2023 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9FE8C15C528; Tue, 21 Feb 2023 09:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.605 X-Spam-Level: X-Spam-Status: No, score=0.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FSL_HAS_TINYURL=2.699, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FOkP_J-mxLG; Tue, 21 Feb 2023 09:47:36 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02CE9C14F727; Tue, 21 Feb 2023 09:47:35 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id h19so2385989qtk.7; Tue, 21 Feb 2023 09:47:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=DgKGAGffWvFVlc9DnECDLNLMcYadRODQ2CibB1ZHhck=; b=noL0FMVIsUtoXoCLhrfgHpxbpWbDu3pScAs/aQvDIazyLucdCaOhPaTXplYqrCp9y/ pqmq0j/XHd4/usv8gXLAdcTECMGKcr0bbkGpOvvLB1+5RW5E1KIjinPClmk8SEdc3zyw GFjLAP05KQoQUZ/uQcRKCzoYRWN/4IczU1tkHe3IgA+RXUw7RYGzq0t5TVB3kfXeNnci S2sKtuyi+BNIJ1xCk/hXSwOQmX3m2lh3L23VVqgzLOtc8bUFG/VkpQ4VDprEvN7nsXfZ 6Dbmi/ahLyrp8CegaYauDjgVo81hmYIlKJMl0vD7irAHC7Rc87/V7tF51POdtjEMDPMR ogZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DgKGAGffWvFVlc9DnECDLNLMcYadRODQ2CibB1ZHhck=; b=aLVRj6gFWrsmo0kv7nrbnQEpg9GZ5U8SbephhoJ3nCMvVs1SZ3SSGJDWXX7jrGHrzY mfy4HaOUCF7CV/YSOuwkZtyPKLFLPteDHoZkpV/Z6FORvZz1NQiYvLLoZsAhLe3LnHVH MhA54f5JuObpHpH3Ih7WE6aZDQfmRWG7OrgXxFZMw+Qsamo+rLdronwIds5K/bP41Ss1 Pu2RHj5RhtdZ7Z3jcJn8C0cTRdUmFm9rbCq2aILFzsouO9ZPkr3K/t0jVrDx1NbG9bG5 oxVIiGWDnzJyEYWoMkCsVS2t68+trhUpEuiVSPDlUHXHjYbafz4SDYnrowYXZtinIiIY P0RA== X-Gm-Message-State: AO0yUKWzk346jaRuxC54LaW5HbglY+lD8ro9B1GCRUZds44TihZQgbm+ e5ggavG1PvUFA5Zr7nit4sEubsrE6w== X-Google-Smtp-Source: AK7set+jV2M9dY59ZvfYLD6wrqNqQVQ/45HGGbIy3Ulg3NlZIMbOBDuI6pqV5ZWna4UM1JZJghcANw== X-Received: by 2002:a05:622a:15c8:b0:3bd:a7a:3479 with SMTP id d8-20020a05622a15c800b003bd0a7a3479mr10622499qty.34.1677001654477; Tue, 21 Feb 2023 09:47:34 -0800 (PST) Received: from smtpclient.apple (d-24-233-121-124.nh.cpe.atlanticbb.net. [24.233.121.124]) by smtp.gmail.com with ESMTPSA id l127-20020a378985000000b0073d7f163f2fsm6535909qkd.86.2023.02.21.09.47.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Feb 2023 09:47:34 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-0EC99084-88C1-4A42-A496-15BD8F19F4A3 Content-Transfer-Encoding: 7bit From: Bernie Volz Mime-Version: 1.0 (1.0) Date: Tue, 21 Feb 2023 12:47:23 -0500 Message-Id: <0063E16F-A41D-4117-86B8-5E6E5B9141F7@gmail.com> References: <12310_1676994811_63F4E8FB_12310_110_1_1cab895283f242a4bbb006816a4f2c66@orange.com> Cc: Robert Sparks , gen-art@ietf.org, draft-ietf-opsawg-add-encrypted-dns.all@ietf.org, last-call@ietf.org, opsawg@ietf.org In-Reply-To: <12310_1676994811_63F4E8FB_12310_110_1_1cab895283f242a4bbb006816a4f2c66@orange.com> To: mohamed.boucadair@orange.com X-Mailer: iPad Mail (20D47) Archived-At: Subject: Re: [OPSAWG] [Last-Call] Genart last call review of draft-ietf-opsawg-add-encrypted-dns-09 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2023 17:47:39 -0000 --Apple-Mail-0EC99084-88C1-4A42-A496-15BD8F19F4A3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Section 9 of https://datatracker.ietf.org/doc/draft-ietf-add-dnr/13/ does in= deed request those assignments. And given that RFC-editor is working on conv= erting this into an RFC, IANA must make the assignments for the RFC to be pu= blished. - Bernie (from iPad) > On Feb 21, 2023, at 10:54 AM, mohamed.boucadair@orange.com wrote: >=20 > =EF=BB=BFHi Robert,=20 >=20 > Thanks for the follow-up.=20 >=20 > Bernie has provided the context for 162/144 codes.=20 >=20 > 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.=20 >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : last-call De la part de Robert >> Sparks >> Envoy=C3=A9 : mardi 21 f=C3=A9vrier 2023 15:49 >> =C3=80 : BOUCADAIR Mohamed INNOV/NET ; >> 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 >>=20 >>=20 >>> On 2/20/23 12:42 AM, mohamed.boucadair@orange.com wrote: >>> Hi Robert, >>>=20 >>> Thank you for the review. >>>=20 >>> Please see inline. >>>=20 >>> Cheers, >>> Med >>>=20 >>>> -----Message d'origine----- >>>> De : Robert Sparks via Datatracker Envoy=C3=A9 : >>>> vendredi 17 f=C3=A9vrier 2023 21:30 =C3=80 : 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 >>>>=20 >>>> Reviewer: Robert Sparks >>>> Review result: Ready with Issues >>>>=20 >>>> 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. >>>>=20 >>>> For more information, please see the FAQ at >>>>=20 >>>> . >>>>=20 >>>> 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 >>>>=20 >>>> Summary: After addressing an issue, this will be ready for >>>> publication as a Proposed Standard RFC >>>>=20 >>>> 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. >>>>=20 >>> [Med] 142/166 are permanent assignments. The IANA registry is >> authoritative here. >>=20 >> 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? >>=20 >> 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. >>=20 >>>=20 >>>=20 >>> Please note that we have the following to make sure that the >> registry is in sync vs. DHCP and have this note for IANA: >>>=20 >>> The initial content of this sub-registry is listed in Table >> 4. The >>> Value and Description fields echo those of [DHCPv6]. >>>=20 >>> Changes to the entry in the dhcp options registry will be >> automatically reflected in the registry defined by this document. >>>=20 >>>> 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? >>>>=20 >>> [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. >>>=20 >>>=20 >>>=20 >> __________________________________________________________________ >> ____ >>> ___________________________________________________ >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>=20 >> -- >> last-call mailing list >> last-call@ietf.org >> https://www.ietf.org/mailman/listinfo/last-call >=20 > __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confide= ntielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez rec= u ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages e= lectroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou= falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged in= formation 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 del= ete 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. >=20 --Apple-Mail-0EC99084-88C1-4A42-A496-15BD8F19F4A3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Section 9 of https://datatracker.ietf.org/doc/= draft-ietf-add-dnr/13/ does indeed request those assignments. And g= iven that RFC-editor is working on converting this into an RFC, IANA must ma= ke the assignments for the RFC to be published.

- Be= rnie (from iPad)

On Feb 2= 1, 2023, at 10:54 AM, mohamed.boucadair@orange.com wrote:

=EF=BB=BFHi Robert,=

Thanks for the follow-up.

Bernie has provided the context for 162/144 codes.

For your second comment, a first attempt to twea= k the text can be seen at: https://tinyurl.com/opsawg-add-latest. This may b= e tweaked a little bit for better readability.

<= span>Cheers,
Med

-----Message d'origine-----
De : last-call <last-call-bounces@ietf.org>= ; De la part de Robert
Sparks
Envoy=C3=A9&= nbsp;: mardi 21 f=C3=A9vrier 2023 15:49
=C3=80 : BOUCADAIR Mohamed INNOV/NET <mohamed.bou= cadair@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
<= blockquote type=3D"cite">

On 2/20/2= 3 12:42 AM, mohamed.boucadair@orange.com wrote:
Hi Robert,
=
Thank you for the review.
=
Please see inline.

Cheers,<= /span>
Med

=
-----Message d'origine-----
De : Robert Sparks via Datatracker <noreply@ietf.or= g> Envoy=C3=A9 :
= vendredi 17 f=C3=A9vrier 2023 21:30 =C3=80 : gen-art@ietf.org Cc&= nbsp;:
draft-ietf-o= psawg-add-encrypted-dns.all@ietf.org; last-
call@ietf.org; opsawg@ietf.org Objet : Genart l= ast call review
of
draft-ietf-opsawg-add= -
encrypted-dns-09<= /span>
<= blockquote type=3D"cite">

Reviewer: Robert Sparks
Review result: Ready with Issues=
=

I am the assigned Gen-ART reviewer fo= r this draft. The General
<= blockquote type=3D"cite">Area
Review Team= (Gen-ART) reviews all IETF documents being
processed by
the IESG for the IETF Chair.  Please treat these comme= nts just
like
any other last call comment= s.

For more information, please see t= he FAQ at

=
<https://trac.ietf.org/tra= c/gen/wiki/GenArtfaq>.
<= blockquote type=3D"cite">

Document: d= raft-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
<= /blockquote>

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_V= 4_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 m= e how to find the artifacts that _put_
these points in the registry? I assume something triggered= early
permanent assi= gnments for these? I wonder if those should be more
<= blockquote type=3D"cite">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
=
&nbs= p;  Value and Description fields echo those of [DHCPv6].

Changes to the entry in the dhcp options registr= y 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 a= re currently ambiguous. When it calls out that 2865
<= /blockquote>
limits
the size of DHCP options and that 7499 and 7930 relaxes t= he
limit, is
it only trying to inform wh= ere the recommendation of supporting
65535
bytes came from? Or is it trying to constrain the size of any
<= /blockquote>
DHCP
option added to the the attributes defined her= e to 4096?
<= br>
[Med] Alan already clarified this one. Please let us= know if any
<= span>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 a= vez recu ce
message
par erreur, veuillez le signaler a l'expediteur et le detru= ire
ains= i que les pieces jointes. Les messages electroniques etant
susceptibles d'alteration, Orange decl= ine toute responsabilite si
ce message a ete altere, deforme ou falsifie. Merci.

=
This message and its attachments may contain confidential or<= br>
privileged information that may be protected by law; they should<= /span>
not be d= istributed, used or copied without authorisation.
If you have received t= his email in error, please notify the
sender and delete this message and its attachm= ents.
As emails may be altered, Orange is not liable for messages that<= /span>
have bee= n modified, changed or falsified.
Thank you.
<= br>

--
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 doi= vent donc
pas etre diffuses, exploites ou copies sans autori= sation. Si vous avez recu ce message par erreur, veuillez le signaler=
a l'expediteur et le detruire ainsi que les pieces jointes. Les me= ssages electroniques etant susceptibles d'alteration,
Orange= decline toute responsabilite si ce message a ete altere, deforme ou falsifi= e. Merci.

This message and its attachments m= ay contain confidential or privileged information that may be protected by l= aw;
they should not be distributed, used or copied without a= uthorisation.
If you have received this email in error, plea= se notify the sender and delete this message and its attachments.
= As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified.
Thank you.

= --Apple-Mail-0EC99084-88C1-4A42-A496-15BD8F19F4A3--