Re: [homenet] AD review of draft-ietf-homenet-naming-architecture-dhc-options-16
Just posted the 19 - usually I have one line per sentence... but not in that case ;-) I suspect we did not address all your concerns for the draft-ietf-homenet-front-end-naming-delegation but we are waiting for your feedbacks to see what else needs to be addressed. Thank you for the follow up! Yours, Daniel On Tue, Sep 20, 2022 at 9:30 AM Eric Vyncke (evyncke) wrote: > Merci Daniel, > > > > By looking at the diff -17-18, you have addressed all my concerns > > > > It would be ready for IETF Last Call, but you were too energetic when > removing the last sentence of section 6.2, you have actually removed the > whole paragraph and the IANA registry must have a registration policy. > So, we need to keep > > > > "Future code points are assigned under RFC Required as per [RFC8126]." > > > > Regards > > > > -éric-waiting-for-19 ;-) > > > > Also waiting for the revision of > draft-ietf-homenet-front-end-naming-delegation-17 as my plan is to group > the two I-D for the last call > > > > *From: *Daniel Migault > *Date: *Tuesday, 20 September 2022 at 15:05 > *To: *Eric Vyncke > *Cc: *"ralf.we...@akamai.com" , " > tomasz.mrugal...@gmail.com" , Stephen Farrell > , "homenet@ietf.org" > *Subject: *Re: [homenet] AD review of > draft-ietf-homenet-naming-architecture-dhc-options-16 > > > > Hi, > > > > I just submitted version 18. All comments have been addressed except > moving the appendices to a companion document. I would be a bit hesitant to > start a full process of adoption, last call while this can be shipped in an > appendix. If that is not the case and there is a strong incentive toward > having a companion document we can easily publish such a document. > > > > Yours, > > Daniel > > > > On Tue, Sep 20, 2022 at 8:17 AM Eric Vyncke (evyncke) > wrote: > > Daniel, Ralf, Tomek, > > > > Thank you for posting the -17 revision. > > > > Before requesting the IETF Last Call, I kindly request one small changes > in -17 in the IANA section + a couple of minor suggestions that can be > ignored, see below for EV> > > > > Stephen, as the doc shepherd, would you mind explaining why "PS" is the > right intended status? > > > > We can aim to request the Last Call still this week if this I-D and the > architecture revised I-Ds are quickly posted. > > > > Regards > > > > -éric > > > > > > *From: *homenet on behalf of Daniel Migault < > mglt.i...@gmail.com> > *Date: *Friday, 12 August 2022 at 02:04 > *To: *"Eric Vyncke (evyncke)" > *Cc: *"homenet@ietf.org" > *Subject: *Re: [homenet] AD review of > draft-ietf-homenet-naming-architecture-dhc-options-16 > > > > Hi Eric, > > > > Thank you for the review. Please find inline how we addressed your > comments. > > > > You can also find the change on github on the link below: > > > https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/pull/1/commits/088c8f783279a4506f55345b6dcc99b9f1555662 > > > > I will also send the IANA section for additional review to the IANA. > > > > Yours, > Daniel > > > > On Mon, Aug 8, 2022 at 10:44 AM Eric Vyncke (evyncke) 40cisco@dmarc.ietf.org> wrote: > > As usual, I do my own review before requesting the IETF Last Call for all > documents. The intent is to give another polishing pass on the I-D. > > > > For this review, the MD format is used. > > > > Hope this helps > > > > Regards > > > > -éric > > > > > > # Éric Vyncke, INT AD, comments for > draft-ietf-homenet-naming-architecture-dhc-options-16 > > > > CC @evyncke > > > > Thank you for the work put into this document. > > > > Please find below some blocking DISCUSS points, some non-blocking COMMENT > points (but replies would be appreciated even if only for my own education). > > > > Special thanks to Stephen Farrel for the shepherd's detailed write-up > including the WG consensus, *but* it lacks the justification of the > intended status (and the WGLC was extended to the DHC WG). > > > > I hope that this review helps to improve the document, > > > > Regards, > > > > -éric > > > > > > ## DISCUSS > > > > ### Section 4.2 port ? > > > > The DHCP option does not allow to run DoT over a non-standard port. Or if > another transport is defined without an associated default port, then there > is no way to specify a port. > > > > That is correct, the rationale was to min
Re: [homenet] AD review of draft-ietf-homenet-naming-architecture-dhc-options-16
Merci Daniel, By looking at the diff -17-18, you have addressed all my concerns It would be ready for IETF Last Call, but you were too energetic when removing the last sentence of section 6.2, you have actually removed the whole paragraph and the IANA registry must have a registration policy. So, we need to keep "Future code points are assigned under RFC Required as per [RFC8126]." Regards -éric-waiting-for-19 ;-) Also waiting for the revision of draft-ietf-homenet-front-end-naming-delegation-17 as my plan is to group the two I-D for the last call From: Daniel Migault Date: Tuesday, 20 September 2022 at 15:05 To: Eric Vyncke Cc: "ralf.we...@akamai.com" , "tomasz.mrugal...@gmail.com" , Stephen Farrell , "homenet@ietf.org" Subject: Re: [homenet] AD review of draft-ietf-homenet-naming-architecture-dhc-options-16 Hi, I just submitted version 18. All comments have been addressed except moving the appendices to a companion document. I would be a bit hesitant to start a full process of adoption, last call while this can be shipped in an appendix. If that is not the case and there is a strong incentive toward having a companion document we can easily publish such a document. Yours, Daniel On Tue, Sep 20, 2022 at 8:17 AM Eric Vyncke (evyncke) mailto:evyn...@cisco.com>> wrote: Daniel, Ralf, Tomek, Thank you for posting the -17 revision. Before requesting the IETF Last Call, I kindly request one small changes in -17 in the IANA section + a couple of minor suggestions that can be ignored, see below for EV> Stephen, as the doc shepherd, would you mind explaining why "PS" is the right intended status? We can aim to request the Last Call still this week if this I-D and the architecture revised I-Ds are quickly posted. Regards -éric From: homenet mailto:homenet-boun...@ietf.org>> on behalf of Daniel Migault mailto:mglt.i...@gmail.com>> Date: Friday, 12 August 2022 at 02:04 To: "Eric Vyncke (evyncke)" mailto:40cisco@dmarc.ietf.org>> Cc: "homenet@ietf.org<mailto:homenet@ietf.org>" mailto:homenet@ietf.org>> Subject: Re: [homenet] AD review of draft-ietf-homenet-naming-architecture-dhc-options-16 Hi Eric, Thank you for the review. Please find inline how we addressed your comments. You can also find the change on github on the link below: https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/pull/1/commits/088c8f783279a4506f55345b6dcc99b9f1555662 I will also send the IANA section for additional review to the IANA. Yours, Daniel On Mon, Aug 8, 2022 at 10:44 AM Eric Vyncke (evyncke) mailto:40cisco@dmarc.ietf.org>> wrote: As usual, I do my own review before requesting the IETF Last Call for all documents. The intent is to give another polishing pass on the I-D. For this review, the MD format is used. Hope this helps Regards -éric # Éric Vyncke, INT AD, comments for draft-ietf-homenet-naming-architecture-dhc-options-16 CC @evyncke Thank you for the work put into this document. Please find below some blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Stephen Farrel for the shepherd's detailed write-up including the WG consensus, *but* it lacks the justification of the intended status (and the WGLC was extended to the DHC WG). I hope that this review helps to improve the document, Regards, -éric ## DISCUSS ### Section 4.2 port ? The DHCP option does not allow to run DoT over a non-standard port. Or if another transport is defined without an associated default port, then there is no way to specify a port. That is correct, the rationale was to minimize the number of arguments and reduce the complexity of handling the DHCP Option. If we would consider adding ports, these should be added to every supported transport. This would move the Supported Transport field being a list of ( transport, port ). While not technically infeasible, that seemed to introduce too much complexity with regard to using a dedicated IP address for the DM. If the DM really needs to use another port one may think of storing such information in the DNS. EV> it would have been nice to have some text explaining this reasoning. Up to the authors to decide whether it is worth adding it. ### Section 6 registry s/IANA is requested to maintain a new number space/IANA is requested to create a new registry/ done Also follow RFC 8126 section 1.3 (and others) by notably adding a description, the parent grouping (DHC I guess) The sub section has been updated as follows: ## Supported Transport parameter IANA is requested to maintain a new registry of Supported Transport parameter in the Distributed Manager Option (OPTION_DIST_MANAGER) or the Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER). The different parameters are defi
Re: [homenet] AD review of draft-ietf-homenet-naming-architecture-dhc-options-16
Hi,
I just submitted version 18. All comments have been addressed except moving
the appendices to a companion document. I would be a bit hesitant to start
a full process of adoption, last call while this can be shipped in an
appendix. If that is not the case and there is a strong incentive toward
having a companion document we can easily publish such a document.
Yours,
Daniel
On Tue, Sep 20, 2022 at 8:17 AM Eric Vyncke (evyncke)
wrote:
> Daniel, Ralf, Tomek,
>
>
>
> Thank you for posting the -17 revision.
>
>
>
> Before requesting the IETF Last Call, I kindly request one small changes
> in -17 in the IANA section + a couple of minor suggestions that can be
> ignored, see below for EV>
>
>
>
> Stephen, as the doc shepherd, would you mind explaining why "PS" is the
> right intended status?
>
>
>
> We can aim to request the Last Call still this week if this I-D and the
> architecture revised I-Ds are quickly posted.
>
>
>
> Regards
>
>
>
> -éric
>
>
>
>
>
> *From: *homenet on behalf of Daniel Migault <
> mglt.i...@gmail.com>
> *Date: *Friday, 12 August 2022 at 02:04
> *To: *"Eric Vyncke (evyncke)"
> *Cc: *"homenet@ietf.org"
> *Subject: *Re: [homenet] AD review of
> draft-ietf-homenet-naming-architecture-dhc-options-16
>
>
>
> Hi Eric,
>
>
>
> Thank you for the review. Please find inline how we addressed your
> comments.
>
>
>
> You can also find the change on github on the link below:
>
>
> https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/pull/1/commits/088c8f783279a4506f55345b6dcc99b9f1555662
>
>
>
> I will also send the IANA section for additional review to the IANA.
>
>
>
> Yours,
> Daniel
>
>
>
> On Mon, Aug 8, 2022 at 10:44 AM Eric Vyncke (evyncke) 40cisco@dmarc.ietf.org> wrote:
>
> As usual, I do my own review before requesting the IETF Last Call for all
> documents. The intent is to give another polishing pass on the I-D.
>
>
>
> For this review, the MD format is used.
>
>
>
> Hope this helps
>
>
>
> Regards
>
>
>
> -éric
>
>
>
>
>
> # Éric Vyncke, INT AD, comments for
> draft-ietf-homenet-naming-architecture-dhc-options-16
>
>
>
> CC @evyncke
>
>
>
> Thank you for the work put into this document.
>
>
>
> Please find below some blocking DISCUSS points, some non-blocking COMMENT
> points (but replies would be appreciated even if only for my own education).
>
>
>
> Special thanks to Stephen Farrel for the shepherd's detailed write-up
> including the WG consensus, *but* it lacks the justification of the
> intended status (and the WGLC was extended to the DHC WG).
>
>
>
> I hope that this review helps to improve the document,
>
>
>
> Regards,
>
>
>
> -éric
>
>
>
>
>
> ## DISCUSS
>
>
>
> ### Section 4.2 port ?
>
>
>
> The DHCP option does not allow to run DoT over a non-standard port. Or if
> another transport is defined without an associated default port, then there
> is no way to specify a port.
>
>
>
> That is correct, the rationale was to minimize the number of arguments and
> reduce the complexity of handling the DHCP Option. If we would consider
> adding ports, these should be added to every supported transport. This
> would move the Supported Transport field being a list of ( transport, port
> ). While not technically infeasible, that seemed to introduce too much
> complexity with regard to using a dedicated IP address for the DM.
>
> If the DM really needs to use another port one may think of storing such
> information in the DNS.
>
>
>
> EV> it would have been nice to have some text explaining this reasoning.
> Up to the authors to decide whether it is worth adding it.
>
> ### Section 6 registry
>
>
>
> s/IANA is requested to maintain a new number space/IANA is requested to
> create a new registry/
>
>
>
> done
>
> Also follow RFC 8126 section 1.3 (and others) by notably adding a
> description, the parent grouping (DHC I guess)
>
>
>
> The sub section has been updated as follows:
>
>
> ## Supported Transport parameter
>
> IANA is requested to maintain a new registry of Supported Transport
> parameter in the Distributed Manager Option (OPTION_DIST_MANAGER) or the
> Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER). The
> different parameters are defined in {{tab-st}} in {{sec-st}}.
>
> The Name of the registry is: Supported Transport parameter
>
> The registry description is: The Supported Transport field of the DHCPv6
> option i
Re: [homenet] AD review of draft-ietf-homenet-naming-architecture-dhc-options-16
Daniel, Ralf, Tomek,
Thank you for posting the -17 revision.
Before requesting the IETF Last Call, I kindly request one small changes in -17
in the IANA section + a couple of minor suggestions that can be ignored, see
below for EV>
Stephen, as the doc shepherd, would you mind explaining why "PS" is the right
intended status?
We can aim to request the Last Call still this week if this I-D and the
architecture revised I-Ds are quickly posted.
Regards
-éric
From: homenet on behalf of Daniel Migault
Date: Friday, 12 August 2022 at 02:04
To: "Eric Vyncke (evyncke)"
Cc: "homenet@ietf.org"
Subject: Re: [homenet] AD review of
draft-ietf-homenet-naming-architecture-dhc-options-16
Hi Eric,
Thank you for the review. Please find inline how we addressed your comments.
You can also find the change on github on the link below:
https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/pull/1/commits/088c8f783279a4506f55345b6dcc99b9f1555662
I will also send the IANA section for additional review to the IANA.
Yours,
Daniel
On Mon, Aug 8, 2022 at 10:44 AM Eric Vyncke (evyncke)
mailto:40cisco@dmarc.ietf.org>> wrote:
As usual, I do my own review before requesting the IETF Last Call for all
documents. The intent is to give another polishing pass on the I-D.
For this review, the MD format is used.
Hope this helps
Regards
-éric
# Éric Vyncke, INT AD, comments for
draft-ietf-homenet-naming-architecture-dhc-options-16
CC @evyncke
Thank you for the work put into this document.
Please find below some blocking DISCUSS points, some non-blocking COMMENT
points (but replies would be appreciated even if only for my own education).
Special thanks to Stephen Farrel for the shepherd's detailed write-up including
the WG consensus, *but* it lacks the justification of the intended status (and
the WGLC was extended to the DHC WG).
I hope that this review helps to improve the document,
Regards,
-éric
## DISCUSS
### Section 4.2 port ?
The DHCP option does not allow to run DoT over a non-standard port. Or if
another transport is defined without an associated default port, then there is
no way to specify a port.
That is correct, the rationale was to minimize the number of arguments and
reduce the complexity of handling the DHCP Option. If we would consider adding
ports, these should be added to every supported transport. This would move the
Supported Transport field being a list of ( transport, port ). While not
technically infeasible, that seemed to introduce too much complexity with
regard to using a dedicated IP address for the DM.
If the DM really needs to use another port one may think of storing such
information in the DNS.
EV> it would have been nice to have some text explaining this reasoning. Up to
the authors to decide whether it is worth adding it.
### Section 6 registry
s/IANA is requested to maintain a new number space/IANA is requested to create
a new registry/
done
Also follow RFC 8126 section 1.3 (and others) by notably adding a description,
the parent grouping (DHC I guess)
The sub section has been updated as follows:
## Supported Transport parameter
IANA is requested to maintain a new registry of Supported Transport parameter
in the Distributed Manager Option (OPTION_DIST_MANAGER) or the Reverse
Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER). The different
parameters are defined in {{tab-st}} in {{sec-st}}.
The Name of the registry is: Supported Transport parameter
The registry description is: The Supported Transport field of the DHCPv6
option is a tow byte field that indicates the supported transport protocols.
Each bit represents a specific transport mechanism.
The parent grouping is Dynamic Host Configuration Protocol for IPv6 (DHCPv6) at
https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2.
New entry MUST specify the bit position, the Transport Protocol Description a
Mnemonic and a Reference as defined in {{tab-iana}}.
The initial registry is as specified in {{tab-iana}}.
Changes of the format or policies of the registry is left to the IETF via the
IESG.
Future code points are assigned under Specification Required as per
{{!RFC8126}}. The expert is expected to be familiar with DHCP.
EV> -17 has 'RFC required' (which is better -- see my previous point), but
there is no expert for RFC/Spec required policies. So, remove the last sentence
:)
~~~
Bit Position | Transport Protocol Description | Mnemonic | Reference
-++---+---
0 | DNS over TLS | DoT | This-RFC
1-15| unallocated| -| -
~~~
{:#tab-iana title="Supported Transport" }
## COMMENTS
### Shepherd's review, intended status
Stephen, as noted above, please include some justification for the intended PS
status.
### Section 4
Re: [homenet] AD review of draft-ietf-homenet-naming-architecture-dhc-options-16
Hi Eric,
Thank you for the review. Please find inline how we addressed your
comments.
You can also find the change on github on the link below:
https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/pull/1/commits/088c8f783279a4506f55345b6dcc99b9f1555662
I will also send the IANA section for additional review to the IANA.
Yours,
Daniel
On Mon, Aug 8, 2022 at 10:44 AM Eric Vyncke (evyncke) wrote:
> As usual, I do my own review before requesting the IETF Last Call for all
> documents. The intent is to give another polishing pass on the I-D.
>
>
>
> For this review, the MD format is used.
>
>
>
> Hope this helps
>
>
>
> Regards
>
>
>
> -éric
>
>
>
>
>
> # Éric Vyncke, INT AD, comments for
> draft-ietf-homenet-naming-architecture-dhc-options-16
>
>
>
> CC @evyncke
>
>
>
> Thank you for the work put into this document.
>
>
>
> Please find below some blocking DISCUSS points, some non-blocking COMMENT
> points (but replies would be appreciated even if only for my own education).
>
>
>
> Special thanks to Stephen Farrel for the shepherd's detailed write-up
> including the WG consensus, *but* it lacks the justification of the
> intended status (and the WGLC was extended to the DHC WG).
>
>
>
> I hope that this review helps to improve the document,
>
>
>
> Regards,
>
>
>
> -éric
>
>
>
>
>
> ## DISCUSS
>
>
>
> ### Section 4.2 port ?
>
>
>
> The DHCP option does not allow to run DoT over a non-standard port. Or if
> another transport is defined without an associated default port, then there
> is no way to specify a port.
>
>
That is correct, the rationale was to minimize the number of arguments and
reduce the complexity of handling the DHCP Option. If we would consider
adding ports, these should be added to every supported transport. This
would move the Supported Transport field being a list of ( transport, port
). While not technically infeasible, that seemed to introduce too much
complexity with regard to using a dedicated IP address for the DM.
If the DM really needs to use another port one may think of storing such
information in the DNS.
>
>
> ### Section 6 sub-sections
>
>
>
> As there are two IANA requests, please use 2 sub-sections, one per request.
>
done
>
>
> ### Section 6 reference
>
>
>
> For the request about option codes, in the table add the obvious 'this
> document' in the to-be-added column 'Reference' + the relevant section
> number.
>
done
>
>
> ### Section 6 registry
>
>
>
> s/IANA is requested to maintain a new number space/IANA is requested to
> create a new registry/
>
>
>
done
> Also follow RFC 8126 section 1.3 (and others) by notably adding a
> description, the parent grouping (DHC I guess)
>
>
>
The sub section has been updated as follows:
## Supported Transport parameter
IANA is requested to maintain a new registry of Supported Transport
parameter in the Distributed Manager Option (OPTION_DIST_MANAGER) or the
Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER). The
different parameters are defined in {{tab-st}} in {{sec-st}}.
The Name of the registry is: Supported Transport parameter
The registry description is: The Supported Transport field of the DHCPv6
option is a tow byte field that indicates the supported transport protocols.
Each bit represents a specific transport mechanism.
The parent grouping is Dynamic Host Configuration Protocol for IPv6
(DHCPv6) at
https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2
.
New entry MUST specify the bit position, the Transport Protocol Description
a Mnemonic and a Reference as defined in {{tab-iana}}.
The initial registry is as specified in {{tab-iana}}.
Changes of the format or policies of the registry is left to the IETF via
the IESG.
Future code points are assigned under Specification Required as per
{{!RFC8126}}. The expert is expected to be familiar with DHCP.
~~~
Bit Position | Transport Protocol Description | Mnemonic | Reference
-++---+---
0 | DNS over TLS | DoT | This-RFC
1-15| unallocated| -| -
~~~
{:#tab-iana title="Supported Transport" }
> ### Appendix B and its sub-sections
>
>
>
> Please use foo.example to stick to the example TLDs.
>
>
>
changed
> ## COMMENTS
>
>
>
> ### Shepherd's review, intended status
>
> Stephen, as noted above, please include some justification for the
> intended PS status.
>
>
>
> ### Abstract
>
>
>
> An 'agnostic' HNA is only defined in the appendix of the main document and
> is unclear without this context. Suggest to remove this word.
>
>
>
removed
>
>
> ### Section 2 DOI
>
>
>
> Isn't it 'DNS Outsourcing Infrastructure' ?
>
correct and changed
>
>
> ### Section 2 DOI or DM ?
>
>
>
> ```
>
>This document describes how a network can provision the HNA with a
>
>specific DOI.
>
> ```
>
> Is it DOI or DM?
>
Both can be used. The DM is a specific entity while DOI is a
