Hi Peter, For me ok to include as well. (If registration is not included, we shouldn’t mention DNS-SD discovery, otherwise.)
You can take a look into https://datatracker.ietf.org/doc/html/rfc8995#section-8.6 which is a good template how the section should be formatted. (E.g. use lowercase, don’t include any optional fields, assignee and contact is IESG, etc.) Esko From: Anima <[email protected]> On Behalf Of Peter van der Stok Sent: Wednesday, December 1, 2021 10:14 To: Brian E Carpenter <[email protected]> Cc: [email protected] Subject: Re: [Anima] Constrained-join-proxy: use of DNS-SD discovery of a Join Proxy HI Brian, thanks, your remark is understood. However, Esko made the right suggestion that a service name must be allocated for DNS-SD. I think that is independent of your protocol draft. This draft seems the best place to allocate the service names. My intention is to write a phrase like: For later discovery of Join Proxy and Registrar server to Join Proxy, using DNS-SD or mdns the service names are allocated in section x.x section x.x Service Name: BRSKI-JP Transport Protocol(s): UDP Assignee: Peter van der Stok Contact: Peter van der Stok Description: service name of Join Proxy Reference [this document] Port Number: to be discovered. Known Unauthorized: Uses BRSKI porotocol Service Name: BRSKI-RJP Transport Protocol(s): UDP Assignee: Peter van der Stok Contact: Peter van der Stok Description: service name of Registrar server to Join Proxy Reference [this document] Port Number: to be discovered. Known Unauthorized: Uses BRSKI porotocol Agreed? greetings, Peter Brian E Carpenter schreef op 2021-11-30 20:42: On 01-Dec-21 01:55, Esko Dijk wrote: While reviewing latest updates; one other issue came up: the draft (re latest in Github) currently mentions DNS-SD as a means for a Pledge to discover a Join Proxy. But for DNS-SD discovery I believe a service name is needed; see RFC 6763 Section 7. But there’s no service name yet defined for a Join Proxy. Easiest solution would be to remove the entire DNS-SD sentence and reference. I.e. defer this to a future document. I think there's another reason for deferring it. We have a pending proposal in draft-eckert-anima-grasp-dnssd for how DNS-SD will integrate in an autonomic environment. It seems wise to have more clarity about that before defining how DNS-SD works for a Join Proxy. The two things may be completely orthogonal, but that requires a little thought. Brian If not removed, we probably need to add a service name registration for Constrained Join Proxy such that it can advertise its service and port over DNS-SD/mDNS correctly. (Note: the above is unrelated to my earlier remark on requiring a service name for the Registrar’s JPY protocol support. This could also be discovered over DNS-SD/mDNS but would need a separate service name.) Best regards Esko *IoTconsultancy.nl* | Email/Teams: [email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:[email protected]>> | +31 6 2385 8339 _______________________________________________ Anima mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/anima
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
