Toerless Eckert <[email protected]> wrote: > We have started to put together a combined draft describing discovery > across the different BRSKI variations because after trying, it did > become more and more convoluted to try to describe these aspects > repeatedly across the different drafts individually.
It seems like a good document, can we please adopt it? * It is odd to have terminology as section 1, but I guess maybe people want to use the terminology in the Overview/Introduction. Probably plan to add a term-free short Introduction. * Section 2 says When an initiator such as a proxy or pledge uses a mechanism such as _Section 1_ which is probably intended to be a reference to a specific term, but that didn't work. I was looking at: https://datatracker.ietf.org/doc/html/draft-eckert-anima-brski-discovery in case the html version has rendered differently. } Upon discovery of the available sockets, the initiator selects one, whose } supported variation(s) best match the expectations of the initiator, } including performance, security or other preferences. } Selection may also include attempting to establish a connection to the } responder socket, and upon connection failure to attempt connecting to the } next best responder socket. I wonder if this initial attempt, which is something a proxy perhaps ought to do, shouldn't actually do some kind of request to the Registrar. Perhaps one to establish and/or confirm that the Registrar supports the desired mode, or to exhaustively list all the modes it does support. It might be that the /.well-known/core?rt=brski.jp call is the right thing for CoAP connections, but could we do the same/similiar thing for HTTPS? > [ RFC editor. Please remove the following sentence. Note: This section > contains three tables according to the specifications of this document. If > it is not possible to introduce more than one table per section, then we > will modify the request accordingly for three sections, but given how the > three tables are tightly linked, that would be unfortunate. ] Just email [email protected], and ask them. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
