On 01-Dec-21 22:13, Peter van der Stok wrote:
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.
Well, I would like to hear that from Toerless, who wrote the DNS-SD draft. I
agree that it seems to be orthogonal, but I'd like to be certain.
I agree with Esko's comments about the format. Lower case seems to be the
de facto rule at https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=iesg&page=2
Brian
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: esko.d...@iotconsultancy.nl <mailto:esko.d...@iotconsultancy.nl> <mailto:esko.d...@iotconsultancy.nl <mailto:esko.d...@iotconsultancy.nl>> |
+31 6 2385 8339
_______________________________________________
Anima mailing list
Anima@ietf.org <mailto:Anima@ietf.org>
https://www.ietf.org/mailman/listinfo/anima
<https://www.ietf.org/mailman/listinfo/anima>
_______________________________________________
Anima mailing list
Anima@ietf.org <mailto:Anima@ietf.org>
https://www.ietf.org/mailman/listinfo/anima
<https://www.ietf.org/mailman/listinfo/anima>
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima