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 10:11 AM Daniel Migault <[email protected]> wrote:
> Thanks I will adresse this in a couple of hours.
> Yours,
> Daniel
>
> On Thu, Oct 20, 2022 at 9:59 AM Zaheduzzaman Sarker <
> [email protected]> wrote:
>
>>
>>
>> On 20 Oct 2022, at 15:47, Daniel Migault <[email protected]> wrote:
>>
>> -- I clicked send to early.
>> Hi Zahed,
>>
>> Thanks for the review. Please find my response inline as well as the
>> updated text below:
>>
>> https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/commit/c29b4ca2b6e2af4de82ba20a975f3540fc93c458
>> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-5f6c20e934f2ca0b&q=1&e=92ddb335-b817-49fd-9afc-6a7f2862d9c8&u=https%3A%2F%2Fgithub.com%2Fietf-homenet-wg%2Ffront-end-naming-delegation-dhc-options%2Fcommit%2Fc29b4ca2b6e2af4de82ba20a975f3540fc93c458>
>>
>> I hope it addresses your concerns.
>>
>> Yours,
>> Daniel
>>
>>>
>>>
>>> On Thu, Oct 20, 2022 at 8:39 AM Zaheduzzaman Sarker via Datatracker <
>>> [email protected]> wrote:
>>>
>>>> Zaheduzzaman Sarker has entered the following ballot position for
>>>> draft-ietf-homenet-naming-architecture-dhc-options-22: No Objection
>>>>
>>>> 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/
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>>
>>>> Thanks for working on this document. I am supporting Lars's discuss to
>>>> clarify
>>>> the implication of a non standard port usage.
>>>>
>>>> We only chose to use the standard port. The reason we mentioned this is
>>> that when other transport modes will be used, a standard port will be
>>> defined. Either in the document defining the transport or in a document
>>> specifying the code point for the Supported Transport.
>>>
>>
>> What you wrote here is much clear than what is written in the document.
>> But then I would like to see normative language to use only the standard
>> port and not allow other ports that RFC7858 allows to use.
>>
>>
>>>
>>>> I also think this paragraph
>>>>
>>>> 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.
>>>>
>>>> should be moved to section 4.4 if this consideration is also true for
>>>> section
>>>> 4.3.
>>>>
>>>> correct. I just copied the lines.
>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> homenet mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/homenet
>>>>
>>>
>>>
>>> --
>>> Daniel Migault
>>> Ericsson
>>>
>>
>>
>> --
>> Daniel Migault
>> Ericsson
>>
>>
>>
>
> --
> Daniel Migault
> Ericsson
>
--
Daniel Migault
Ericsson
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
