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

Reply via email to