EST by default runs on port 443 over TLS. It does not have any special port. Discovery is not defined in 7030. It is defined in BRSKI. And it based on GRASP or mDNS service discovery.
I think it is not necessary to define a default port. The default COAPS UDP 5684 suffices. Now if a server wants to advertise a different port then we would need the full URI with the port. From: Peter van der Stok [mailto:stokc...@bbhmail.nl] Sent: Monday, September 24, 2018 4:12 AM To: Esko Dijk <esko.d...@iotconsultancy.nl> Cc: Michael Richardson <mcr+i...@sandelman.ca>; Panos Kampanakis (pkampana) <pkamp...@cisco.com>; consulta...@vanderstok.org; ace@ietf.org Subject: Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI Hi, What do I read? when you do GET coap://example.com/.well-known/core The discovery is on port 5683. When you do GET coaps://example.com/.well-known/core the discovery port is 5684. I agree that we did not assign a port to coaps://example.com/est for that matter, and as such the example is incorrect. Will we make the port discoverable? RFC 7030 does not ask a port number from IANA. And a search through IANA port numbers on "est" does not yield anything. Any suggestions? or improve my knowledge. Peter Esko Dijk schreef op 2018-09-21 10:24: I've asked if discovery is always required, permitted, or encouraged. Normally it is always encouraged to use discovery in favour of fixed URIs at the server, to avoid specs squatting the URI namespace. But in our case the /.well-known/est space is already assigned (RFC 7030) so we have to support it also in coaps-est and no additional squatting takes place. Besides support for the well-known URI location, discovery by a client is permitted to find "ace.est" type resources at other places e.g. to get shorter URIs or to get 6lowpan-compressible port numbers, or both. I.e. - can the client avoid the round trip to do the discovery? - does the server have to provide the discovery? -- if not, what does a client do that performs the discovery and fails? I've been told it was required. - So it can't be required for the client, is my opinion. - The server must support it (being a good CoAP-citizen) in some way as in the previous email. - If it fails, the client might try another time using the /.well-known/est resource, or retry the discovery later on. (There could be various implementation-specific tactics here. Maybe the IP address of the EST server was configured wrongly; and the process that lead to this IP address can be redone by the client.) Esko _______________________________________________ Ace mailing list Ace@ietf.org<mailto:Ace@ietf.org> https://www.ietf.org/mailman/listinfo/ace
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
