Hi Tatuya,
Thank you for the follow-up. Much appreciated.
> If you're saying that this is just an example and its
> applicability doesn't matter much, then I'd be happier if it were
> clearer that the content of this section is a mere example.
The introduction says the following:
A sample deployment usage of the DHCPv6-Options and DHCPv4-Options
RADIUS attributes is described in Section 5.
To further insist this is about an example, I made the following change:
OLD:
5. Applicability to Encrypted DNS Provisioning
NEW:
5: An Example: Applicability to Encrypted DNS Provisioning
This change together with the current text is much more clear this is an example to illustrate the use of
==
Typical deployment scenarios are similar to those described, for
^^^^^^
instance, in Section 2 of [RFC6911]. For illustration purposes,
^^^^^^^^^^^^^^^^^^^^^^^^^^
Figure 1 shows an example where a Customer Premises Equipment (CPE)
is provided with an encrypted DNS resolver. This example assumes
^^^^^^^^^^^^
that the Network Access Server (NAS) embeds both RADIUS client and
DHCPv6 server capabilities.
==
Hope this is better.
Cheers,
Med
> -----Message d'origine-----
> De : JINMEI Tatuya / 神明達哉 <jinmei@xxxxxxxxxx>
> Envoyé : mercredi 15 mars 2023 00:54
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>
> Cc : int-dir@xxxxxxxx; draft-ietf-opsawg-add-encrypted-
> dns.all@xxxxxxxx; last-call@xxxxxxxx; opsawg@xxxxxxxx
> Objet : Re: [dhcwg] Intdir telechat review of draft-ietf-opsawg-
> add-encrypted-dns-10
>
> >> I'm fine with deferring such a discussion to draft-ietf-add-
> dnr; I'm
> >> also fine with just removing any reference to Reconfigure from
> this
> >> draft (and maybe stating that's an out- of-scope topic).
>
> > [Med] I don't understand this position as what we are discussing
> here
> > is ** an example ** (not a reco or a new feature) to illustrate
> the
> > use of the attributes with CoA. That example wouldn’t be
> complete if
> > the DHCP leg is not exemplified as well. Issues with reconfigure
> are
> > well-known and adequate references for readers who want to learn
> more
> > are now provided in the document.
>
> One main concern of mine is that it's not so clear whether it's
> just an example or not. I actually also thought this section is
> intended just as an example. But it's one of the body of this
> document (not in an appendix), and while the RADIUS part of the
> protocol is generic, it's obvious the primary motivation is to use
> it for ietf-add-dnr. So I also thought the applicability of this
> section may have to be discussed in more detail, either in this
> doc or in ietf-add-dnr.
>
> If you're saying that this is just an example and its
> applicability doesn't matter much, then I'd be happier if it were
> clearer that the content of this section is a mere example. One
> clear way for that is to move this section to an appendix.
> Another would be to add a sentence or two clarifying that intent
> at the top of that section.
>
> If you're not willing to do either, I think we should agree to
> disagree here. In that case please feel free to dismiss my point.
> I'd also suggest removing the reference to RFC6977, since it was
> added to address my comment but it doesn't address it anyway.
>
> --
> jinmei
_________________________________________________________________________________________________________________________
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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
