Re: [homenet] Zaheduzzaman Sarker's No Objection on draft-ietf-homenet-naming-architecture-dhc-options-22: (with COMMENT)

Thanks I will adresse this in a couple of hours.
Yours,
Daniel

On Thu, Oct 20, 2022 at 9:59 AM Zaheduzzaman Sarker <
zaheduzzaman.sarker@ericsson.com> wrote:

>
>
> On 20 Oct 2022, at 15:47, Daniel Migault <mglt.ietf@gmail.com> 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 <
>> noreply@ietf.org> 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
>>> homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet
>>>
>>
>>
>> --
>> Daniel Migault
>> Ericsson
>>
>
>
> --
> Daniel Migault
> Ericsson
>
>
>

-- 
Daniel Migault
Ericsson