> 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 <mailto: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/ > <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/ > > <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 <mailto:homenet@ietf.org> > https://www.ietf.org/mailman/listinfo/homenet > <https://www.ietf.org/mailman/listinfo/homenet> > > > -- > Daniel Migault > Ericsson > > > -- > Daniel Migault > Ericsson
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
