Hi Zahed and Lars,
I think I mis-understood the comment.
I initially thought you were concerned that the server cannot specify
whatever port it wants. The current text was mostly saying "because DHCP
does not specify the port, the port needs to be defined by a standard. That
standard can be a document defining a default port for a transport protocol
or a document specifying the code point of the new Supported Transport.
>From the IESG telechat, I understand the concern is that if the client and
the server have agreed on another port - let's say out of band. They can
use that port.
If I understood correctly, I changed the following text:
OLD:
It is worth noticing that the Supported Transport field does not enable to
specify a por
t and the used port is defined by a standard.
In the case of DNS over TLS {{!RFC7858}}, the port is defined by
{{!RFC7858}} to be 853.
The need for such flexibility has been balanced with the difficulty of
handling a list o
f tuples ( transport, port ) as well as the possibility to use a dedicated
IP address fo
r the DM.
NEW:
It is worth noticing that the DHCP Option specifies the Supported
Transport without specifying any explicit port. Unless the HNA and the DM
have agreed on using a specific port - for example by configuration, or any
out of band mechanism -, the default port is used and must be specified.
The specification of such default port may be defined in the specification
of the designated Supported Transport or in any other document.
In the case of DNS over TLS {{!RFC7858}}, the default port is defined by
{{!RFC7858}} with the following value: 853.
The need to associate in the DHCP Option the port value to each Supported
Transport has been balanced with the difficulty of handling a list of
tuples ( transport, port ) as well as the possibility to use a dedicated IP
address for the DM in case the default port was already in use.
Yours,
Daniel
On Thu, Oct 20, 2022 at 9:37 AM Daniel Migault <mglt.i...@gmail.com> wrote:
> Hi Lars,
>
> Thanks for the comment. Please see my response inline below. The updates
> associated to your comments can be found below:
>
> https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/commit/3113e186f17ed36ee3ec635b1414bdc181e06484
>
> Yours,
> Daniel
>
>
> On Thu, Oct 20, 2022 at 8:21 AM Lars Eggert via Datatracker <
> nore...@ietf.org> wrote:
>
>> Lars Eggert has entered the following ballot position for
>> draft-ietf-homenet-naming-architecture-dhc-options-22: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to
>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> # GEN AD review of draft-ietf-homenet-naming-architecture-dhc-options-22
>>
>> CC @larseggert
>>
>> Thanks to Maria Ines Robles for the General Area Review Team (Gen-ART)
>> review
>> (
>> https://mailarchive.ietf.org/arch/msg/gen-art/uld2ipgAwbN-LgVg9X1VjFAPUYY
>> ).
>>
>> ## Discuss
>>
>> ### Section 4.2, paragraph 8
>> ```
>> It is worth noticing that the Supported Transport field does not
>> enable to specify a port and the used port is defined by a standard.
>> In the case of DNS over TLS [RFC7858], the port is defined by
>> [RFC7858] to be 853. The need for such flexibility has been balanced
>> with the difficulty of handling a list of tuples ( transport, port )
>> as well as the possibility to use a dedicated IP address for the DM.
>> ```
>> 7858 actually says
>>
>> By default, a DNS server that supports DNS over TLS MUST listen for
>> and accept TCP connections on port 853, unless it has mutual
>> agreement with its clients to use a port other than 853 for DNS over
>> TLS.
>>
>> So it is fully permissible for a DoT server to run on a different port
>> under
>> such a mutual agreement. In general, for other possible transports, just
>> because
>> a port is assigned for use does not mean a deployment is obligated to run
>> on it.
>>
>>
>> I agree. What we are trying to say is that we did not find it useful to
> enable the use of a non standard port. This is a restriction of the DHCP
> option - not the DNS over TLS.
>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> ## Comments
>>
>> ### IANA
>>
>> The IANA review of this document seems to not have concluded yet.
>>
>> I do see IANA Expert review OK on my side. I know we have had early
> review, but I cannot say it is completed. I do not expect issues though
> given the early reviews.
>
>
>> ### Inclusive language
>>
>> Found terminology that should be reviewed for inclusivity; see
>> https://www.rfc-editor.org/part2/#inclusive_language for background and
>> more
>> guidance:
>>
>> * Term `her`; alternatives might be `they`, `them`, `their`
>>
>> ## Nits
>>
>> All comments below are about very minor potential issues that you may
>> choose to
>> address in some way - or ignore - as you see fit. Some were flagged by
>> automated tools (via https://github.com/larseggert/ietf-reviewtool), so
>> there
>> will likely be some false positives. There is no need to let me know what
>> you
>> did with these suggestions.
>>
>> ### Typos
>>
>> #### Section 2, paragraph 3
>> ```
>> - to. ISPs may leverage such infrastructure and provide the homenet
>> + to. ISPs may leverage such infrastructure and provide the home
>> network
>> + +
>> ++++
>> ```
>>
>> changed
>
>> ### Outdated references
>>
>> Document references `draft-sury-dnsext-cname-dname-00`, but `-01` is the
>> latest
>> available revision.
>>
>> ### Grammar/style
>>
>> #### Paragraph 1
>> ```
>> s document defines DHCPv6 options so an Homenet Naming Authority (HNA)
>> can a
>> ^^
>> ```
>> Use "a" instead of "an" if the following word doesn't start with a vowel
>> sound,
>> e.g. "a sentence", "a university".
>>
>> fixed
>
>> #### Section 3, paragraph 4
>> ```
>> 6 options provide the necessary non optional parameters described in
>> Appendi
>> ^^^^^^^^^^^^
>> ```
>> This expression is usually spelled with a hyphen.
>>
>> #### Section 4.3, paragraph 2
>> ```
>> represents a supported transport, and a RDM MAY indicate the support of
>> multi
>> ^
>> ```
>> Use "an" instead of "a" if the following word starts with a vowel sound,
>> e.g.
>> "an article", "an hour".
>>
>> #### Section 4.3, paragraph 6
>> ```
>> FC8415] govern server operation in regards to option assignment. As a
>> conveni
>> ^^^^^^^^^^^^^
>> ```
>> Use "in regard to", "with regard to", or more simply "regarding".
>>
>> fixed
>
>> #### "A.3.", paragraph 4
>> ```
>> cribed in Appendix A.2, the HNA is expect to be able to handle multiple
>> Home
>> ^^^^^^
>> ```
>> Consider using either the past participle "expected" or the present
>> participle
>> "expecting" here.
>>
>>
>
>> ## Notes
>>
>> This review is in the ["IETF Comments" Markdown format][ICMF], You can
>> use the
>> [`ietf-comments` tool][ICT] to automatically convert this review into
>> individual GitHub issues. Review generated by the
>> [`ietf-reviewtool`][IRT].
>>
>> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
>> [ICT]: https://github.com/mnot/ietf-comments
>> [IRT]: https://github.com/larseggert/ietf-reviewtool
>>
>>
>>
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>>
>
>
> --
> Daniel Migault
> Ericsson
>
--
Daniel Migault
Ericsson
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
