Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI
> -Original Message- > From: Ace On Behalf Of Michael Richardson > Sent: Monday, September 24, 2018 9:27 AM > To: consulta...@vanderstok.org > Cc: Esko Dijk ; Panos Kampanakis (pkampana) > ; ace@ietf.org > Subject: Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI > > > Peter van der Stok wrote: > > 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. > > yes, the question is, when you ask: > > coap://example.com/.well-known/core?rt=ace.est > > do you expect to get back a pointer to: > >coaps://example.com/est > > > RFC 7030 does not ask a port number from IANA. And a search through > > IANA port numbers on "est" does not yield anything. > > It does not. > a) it doesn't do discovery, but just uses /.well-known directly. > b) it assumes https:// Is there any reason to assume that you need a different port from the default pair of coap ports? Knowing what the protocol and host name will point it to the correct location and you have the URI path to go to the correct resource on that server. Jim > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works| network architect [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails [ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI
Peter van der Stok wrote: > 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. yes, the question is, when you ask: coap://example.com/.well-known/core?rt=ace.est do you expect to get back a pointer to: coaps://example.com/est > RFC 7030 does not ask a port number from IANA. And a search through > IANA port numbers on "est" does not yield anything. It does not. a) it doesn't do discovery, but just uses /.well-known directly. b) it assumes https:// -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI
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 Cc: Michael Richardson ; Panos Kampanakis (pkampana) ; 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
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 > https://www.ietf.org/mailman/listinfo/ace___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI
> 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 https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI
Esko Dijk wrote: > @Michael: > Since the EST resource is always present on the fixed port 5684 on URI > /.well-known/est - if a fixed port is needed e.g. for a join proxy, use > 5684 and the well-known URI. No discovery needed. I've asked if discovery is always required, permitted, or encouraged. 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. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI
Esko Dijk wrote: > Indeed, and the ace-coap-est examples use port 61616 mostly. The > discovery Link Format is quite inefficient when returning results on > *different* endpoints. Example: > REQ: GET coap://[2001:db8::2:1]/.well-known/core?rt=ace.est > RES: 2.05 Content > ;rt="ace.est" I understand. > Although in above case the server could shorten the response payload by > returning its IP address ( [2001:db8::2:1]:61616/est>;rt="ace.est"). But still it’s a waste of > bytes. It could have multiple addresses!!! I've seen it just return , but I guess if you want to return the port number, you have to return the hostname... <:61616/est> won't do? > The current example in Section 5 of ace-coap-est is problematic, > because discovery is on port 5683 and the hosted EST endpoint is on the > secure port 5684. So the following won’t work according to RFC 7252 / So I've assumed that discovery happens on 5684, under DTLS. You are suggesting that we need to run an unencrypted CoAP to offer the discovery option as well. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI
Indeed, and the ace-coap-est examples use port 61616 mostly. The discovery Link Format is quite inefficient when returning results on *different* endpoints. Example: REQ: GET coap://[2001:db8::2:1]/.well-known/core?rt=ace.est RES: 2.05 Content ;rt="ace.est" Although in above case the server could shorten the response payload by returning its IP address ( ;rt="ace.est"). But still it’s a waste of bytes. The current example in Section 5 of ace-coap-est is problematic, because discovery is on port 5683 and the hosted EST endpoint is on the secure port 5684. So the following won’t work according to RFC 7252 / RFC 6690: REQ: GET coap://[2001:db8::2:1]/.well-known/core?rt=ace.est RES: 2.05 Content ;rt="ace.est" Because strictly speaking this tells the client that /est is hosted on port 5683 (no statement about 5684 hosting!) I see this as a design flaw in CoAP discovery; we would like to be able to use the above short syntax of course. @Michael: Since the EST resource is always present on the fixed port 5684 on URI /.well-known/est - if a fixed port is needed e.g. for a join proxy, use 5684 and the well-known URI. No discovery needed. Esko From: Peter van der Stok Sent: Thursday, September 20, 2018 16:56 To: Michael Richardson Cc: Esko Dijk ; Panos Kampanakis (pkampana) ; ace@ietf.org Subject: Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI Michael Richardson schreef op 2018-09-20 16:51: I didn't think that CoAP resource discovery supports port numbers, does it? It does; at least for the 3rd party registration, but also examples in the RD show return of port ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI
Michael Richardson schreef op 2018-09-20 16:51: > I didn't think that CoAP resource discovery supports port numbers, does it? > > It does; at least for the 3rd party registration, but also examples in the RD > show return of port___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI
Esko Dijk wrote: > To be fully complete the URIs that can be discovered should also > include a port number, as they could be hosted at 5684 or any available > UDP port - other than 5683. >coaps://www.example.com:// > coaps://www.example.com://ArbitraryLabel/ I didn't think that CoAP resource discovery supports port numbers, does it? There are some issues with this, specifically because it interacts poorly with the join proxy mechanism. (The proxy always forwards to a single port, and only listens on a single port) I supppose that's okay, for that usage can be banned for the zero-touch join mechanisms that use a join proxy. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI
Ok, thanks. To be fully complete the URIs that can be discovered should also include a port number, as they could be hosted at 5684 or any available UDP port - other than 5683. coaps://www.example.com:// coaps://www.example.com://ArbitraryLabel/ Esko -Original Message- From: Panos Kampanakis (pkampana) Sent: Monday, September 17, 2018 19:12 To: Esko Dijk ; ace@ietf.org Subject: RE: ace-coap-est: unclear definition of /.well-known/est URI Hi Esko, Good point. We made this change to ensure the text is clearer. You will see it in the next iteration. Thank you, Panos -Original Message- From: Esko Dijk [mailto:esko.d...@iotconsultancy.nl] Sent: Saturday, September 15, 2018 10:30 AM To: Panos Kampanakis (pkampana) ; ace@ietf.org Subject: RE: ace-coap-est: unclear definition of /.well-known/est URI Hello Panos, Thanks - it's clear now that the "ArbitraryLabel" needs to be supported for this use case. The unclarity in the current text comes from the fact that the default /.well-known/est/ is missing ; which should be supported also as in RFC 7030. Also the usage of the discoverable root URI is missing here. So we could update the text in Section 5 as follows: -- The individual EST-coaps well-known server URIs differ from the EST URI by replacing the scheme https by coaps and by specifying shorter resource path names: coaps://www.example.com/.well-known/est/ coaps://www.example.com/.well-known/est/ArbitraryLabel/ The ArbitraryLabel Path-Segment, if used, SHOULD be of the shortest length possible. The optional additional EST-coaps server URIs, obtained through discovery of the EST root resource(s), are of the form: coaps://www.example.com// coaps://www.example.com//ArbitraryLabel/ -- The suggestion by Peter to add references to the corresponding EST RFC 7030 sections is also good. Regards Esko From: Panos Kampanakis (pkampana) Sent: Wednesday, September 12, 2018 17:31 To: Esko Dijk ; ace@ietf.org Subject: RE: ace-coap-est: unclear definition of /.well-known/est URI Hi Esko, Thanks for the comment. Certificate authorities use the ArbitraryLabel in order to direct the CSR request and issue certificates based on a certain policy / cert profile. For example, if you are ClientX you get label ClientX198282 and when you hit the CA HTTP URI .well-known/est/ ClientX198282/sen the CA knows to use the policy for ClientX in order to issue a certificate. Of course, someone that has deployed an on-prem CA that has the same cert profile for all endpoints will not need an arbitrary label and the default EST namespace is enough. So, even though coaps://www.example..com/.well-known/est/ would work for many cases, we needed to keep the coaps://www.example..com/.well-known/est/ArbitraryLabel/ as well for cases where the client is getting a cert from a CA that serves more than on cert profiles. We may need to specify that the labl should be as short as possible, even though it is kind of self-explanatory. I hope it makes sense. Panos From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Esko Dijk Sent: Wednesday, September 12, 2018 11:10 AM To: mailto:ace@ietf.org Subject: [Ace] ace-coap-est: unclear definition of /.well-known/est URI Dear all/authors of ace-coap-est, Section 5 of ace-coap-est-05 indicates URI discovery is possible to find the EST functions entry point URI. Also a well-known URI is defined: coaps://www.example..com/.well-known/est/ArbitraryLabel/. This URI seems more complicated than needed? What if we simply define an always-available well-known URI, usable without any discovery: coaps://www.example..com/.well-known/est/ This re-uses the well-known EST namespace which is exactly defined to do EST functions. So using the short-est names within this namespace should be fine. It is important that a well-known URI is available that is usable without discovery, just like EST RFC 7030 defines it for https. The "ArbitraryLabel" only makes the URI longer. best regards Esko Dijk ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI
Hi Esko, Good point. We made this change to ensure the text is clearer. You will see it in the next iteration. Thank you, Panos -Original Message- From: Esko Dijk [mailto:esko.d...@iotconsultancy.nl] Sent: Saturday, September 15, 2018 10:30 AM To: Panos Kampanakis (pkampana) ; ace@ietf.org Subject: RE: ace-coap-est: unclear definition of /.well-known/est URI Hello Panos, Thanks - it's clear now that the "ArbitraryLabel" needs to be supported for this use case. The unclarity in the current text comes from the fact that the default /.well-known/est/ is missing ; which should be supported also as in RFC 7030. Also the usage of the discoverable root URI is missing here. So we could update the text in Section 5 as follows: -- The individual EST-coaps well-known server URIs differ from the EST URI by replacing the scheme https by coaps and by specifying shorter resource path names: coaps://www.example.com/.well-known/est/ coaps://www.example.com/.well-known/est/ArbitraryLabel/ The ArbitraryLabel Path-Segment, if used, SHOULD be of the shortest length possible. The optional additional EST-coaps server URIs, obtained through discovery of the EST root resource(s), are of the form: coaps://www.example.com// coaps://www.example.com//ArbitraryLabel/ -- The suggestion by Peter to add references to the corresponding EST RFC 7030 sections is also good. Regards Esko From: Panos Kampanakis (pkampana) Sent: Wednesday, September 12, 2018 17:31 To: Esko Dijk ; ace@ietf.org Subject: RE: ace-coap-est: unclear definition of /.well-known/est URI Hi Esko, Thanks for the comment. Certificate authorities use the ArbitraryLabel in order to direct the CSR request and issue certificates based on a certain policy / cert profile. For example, if you are ClientX you get label ClientX198282 and when you hit the CA HTTP URI .well-known/est/ ClientX198282/sen the CA knows to use the policy for ClientX in order to issue a certificate. Of course, someone that has deployed an on-prem CA that has the same cert profile for all endpoints will not need an arbitrary label and the default EST namespace is enough. So, even though coaps://www.example..com/.well-known/est/ would work for many cases, we needed to keep the coaps://www.example..com/.well-known/est/ArbitraryLabel/ as well for cases where the client is getting a cert from a CA that serves more than on cert profiles. We may need to specify that the labl should be as short as possible, even though it is kind of self-explanatory. I hope it makes sense. Panos From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Esko Dijk Sent: Wednesday, September 12, 2018 11:10 AM To: mailto:ace@ietf.org Subject: [Ace] ace-coap-est: unclear definition of /.well-known/est URI Dear all/authors of ace-coap-est, Section 5 of ace-coap-est-05 indicates URI discovery is possible to find the EST functions entry point URI. Also a well-known URI is defined: coaps://www.example..com/.well-known/est/ArbitraryLabel/. This URI seems more complicated than needed? What if we simply define an always-available well-known URI, usable without any discovery: coaps://www.example..com/.well-known/est/ This re-uses the well-known EST namespace which is exactly defined to do EST functions. So using the short-est names within this namespace should be fine. It is important that a well-known URI is available that is usable without discovery, just like EST RFC 7030 defines it for https. The "ArbitraryLabel" only makes the URI longer. best regards Esko Dijk ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI
Hello Panos, Thanks - it's clear now that the "ArbitraryLabel" needs to be supported for this use case. The unclarity in the current text comes from the fact that the default /.well-known/est/ is missing ; which should be supported also as in RFC 7030. Also the usage of the discoverable root URI is missing here. So we could update the text in Section 5 as follows: -- The individual EST-coaps well-known server URIs differ from the EST URI by replacing the scheme https by coaps and by specifying shorter resource path names: coaps://www.example.com/.well-known/est/ coaps://www.example.com/.well-known/est/ArbitraryLabel/ The ArbitraryLabel Path-Segment, if used, SHOULD be of the shortest length possible. The optional additional EST-coaps server URIs, obtained through discovery of the EST root resource(s), are of the form: coaps://www.example.com// coaps://www.example.com//ArbitraryLabel/ -- The suggestion by Peter to add references to the corresponding EST RFC 7030 sections is also good. Regards Esko From: Panos Kampanakis (pkampana) Sent: Wednesday, September 12, 2018 17:31 To: Esko Dijk ; ace@ietf.org Subject: RE: ace-coap-est: unclear definition of /.well-known/est URI Hi Esko, Thanks for the comment. Certificate authorities use the ArbitraryLabel in order to direct the CSR request and issue certificates based on a certain policy / cert profile. For example, if you are ClientX you get label ClientX198282 and when you hit the CA HTTP URI .well-known/est/ ClientX198282/sen the CA knows to use the policy for ClientX in order to issue a certificate. Of course, someone that has deployed an on-prem CA that has the same cert profile for all endpoints will not need an arbitrary label and the default EST namespace is enough. So, even though coaps://www.example..com/.well-known/est/ would work for many cases, we needed to keep the coaps://www.example..com/.well-known/est/ArbitraryLabel/ as well for cases where the client is getting a cert from a CA that serves more than on cert profiles. We may need to specify that the labl should be as short as possible, even though it is kind of self-explanatory. I hope it makes sense. Panos From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Esko Dijk Sent: Wednesday, September 12, 2018 11:10 AM To: mailto:ace@ietf.org Subject: [Ace] ace-coap-est: unclear definition of /.well-known/est URI Dear all/authors of ace-coap-est, Section 5 of ace-coap-est-05 indicates URI discovery is possible to find the EST functions entry point URI. Also a well-known URI is defined: coaps://www.example..com/.well-known/est/ArbitraryLabel/. This URI seems more complicated than needed? What if we simply define an always-available well-known URI, usable without any discovery: coaps://www.example..com/.well-known/est/ This re-uses the well-known EST namespace which is exactly defined to do EST functions. So using the short-est names within this namespace should be fine. It is important that a well-known URI is available that is usable without discovery, just like EST RFC 7030 defines it for https. The "ArbitraryLabel" only makes the URI longer. best regards Esko Dijk ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI
Hi esko, we can add a reference to sections 3.1 and 3.2.2. of RFC7030 Peter Panos Kampanakis (pkampana) schreef op 2018-09-12 17:31: > Hi Esko, > > Thanks for the comment.. > > Certificate authorities use the ArbitraryLabel in order to direct the CSR > request and issue certificates based on a certain policy / cert profile. For > example, if you are ClientX you get label ClientX198282 and when you hit the > CA HTTP URI .well-known/est/ ClientX198282/sen the CA knows to use the policy > for ClientX in order to issue a certificate. Of course, someone that has > deployed an on-prem CA that has the same cert profile for all endpoints will > not need an arbitrary label and the default EST namespace is enough. > > So, even though coaps://www.example..com/.well-known/est/ would > work for many cases, we needed to keep the > coaps://www.example..com/.well-known/est/ArbitraryLabel/ as well > for cases where the client is getting a cert from a CA that serves more than > on cert profiles. We may need to specify that the labl should be as short as > possible, even though it is kind of self-explanatory. > > I hope it makes sense. > > Panos > > FROM: Ace [mailto:ace-boun...@ietf.org] ON BEHALF OF Esko Dijk > SENT: Wednesday, September 12, 2018 11:10 AM > TO: ace@ietf.org > SUBJECT: [Ace] ace-coap-est: unclear definition of /.well-known/est URI > > Dear all/authors of ace-coap-est, > > Section 5 of ace-coap-est-05 indicates URI discovery is possible to find the > EST functions entry point URI.. Also a well-known URI is defined: > > coaps://www.example..com/.well-known/est/ArbitraryLabel/. > > This URI seems more complicated than needed? What if we simply define an > always-available well-known URI, usable without any discovery: > > coaps://www.example..com/.well-known/est/ > > This re-uses the well-known EST namespace which is exactly defined to do EST > functions. So using the short-est names within this namespace should be fine. > > It is important that a well-known URI is available that is usable without > discovery, just like EST RFC 7030 defines it for https. > > The "ArbitraryLabel" only makes the URI longer. > > best regards > > Esko Dijk > > ___ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
