Thanks I will adresse this in a couple of hours. Yours, Daniel On Thu, Oct 20, 2022 at 9:59 AM Zaheduzzaman Sarker < zaheduzzaman.sar...@ericsson.com> wrote:
> > > On 20 Oct 2022, at 15:47, Daniel Migault <mglt.i...@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 < >> nore...@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
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
