Toerless Eckert <t...@cs.fau.de> wrote:
> This is insufficient. Section 4.3 only describes the GRASP objective
> for EST-TLS, which uses the objective-value "EST-TLS". For the
> constrained join proxy, you need to specify the objective to use a new
> appropriate objective. For example, you could specify to continue to
> use AN_join_registrar, but use an objective-value of "EST-COAPS". That
> would IMHO be in the spirit of how we defined the RFC8995 GRASP
> objective. And astoundingly (;-)) it wouldn't require a new IANA
> registration (i think, Brian ?).Yes, you are right, we need to have a new objective to announce. I guess that we don't really think about the constrained-join-proxy really being used in an ACP context, but we really should that right. https://github.com/anima-wg/constrained-join-proxy/issues/17 > Note that it is not sufficient to delta RFC8995 and mention > "EST-COAPS", because the GRASP objective also needs to indicate UDP > instead of TCP. Even though it is longer, it would IMHO be prudent to > copy the whole GRASP objectives and examples from RFC8995 and > accordingly modify them, so that the constrained-proxy draft is > "standalone" in this respect (even if a page longer). I think you are asking us to show an example that advertises both RFC8995, and the constrained version, correct? > Isn't there the thought that some other variations of BRSKI will use > protocol variations, such as not CBOR+JSON ? some other "CMP" encoding > ? We decided that Registrars will be responsible for interoperation, and will support all protocols the operator expects to use. If you buy a Registrar that does not do X and a pledge that only does X, then it fails, and you were stupid. > I am asking, because it seems to me we need to be aware, that the > constrained-proxy is logically "just" a DTLS proxy, but once we have > more than one DTLS BRSKI variation, we still need to be able for > pledges to connect to registrar(s) that talk the BRSKI variation that > the pledge supports. What we define here initially is effectively > proxy/registrar for EST-COAPS. So let's assume, we get another > protocol, OTHER1-DTLS. The constrained proxy continues to work, but it > would now need to discover the OTHER1-DTLS Registrar, allocate a new > UDP port number on which to offer proxy services for OTHER1-DTLS and > announce that to pledges. You aren't wrong, but you also aren't right. Pledges are expected to try all options (possibly concurrently if they have CPU/ram) until they find one that works. There is no reason the join proxy needs to know the details of the Registrar supports, only that they support a way to talk to it. > I wonder if the names choosen for est-coaps discovery, brski.jp and > brski.rjp are ideal indicative of the fact that we're rather defining > brski-est-coaps.jp and brski-est-coaps.rjp. I guess beauty/explicitness Fair point. > 3. 6tisch discovery > [I-D.ietf-6tisch-enrollment-enhanced-beacon] is now RFC9032, please > update draft accordingly. > Upon quick browse of RFC9032 i fail to see how/where RFC9032 would be > able to deal with more than one discovery protocol. E.g.: How would we > discover BRSKI-EST-COAPS-REGISTRAR BRSKI-EST-COAPS-PROXY > OTHER1-DTLS-REGISTRAR OTHER1-DTLS-PROXY Yes, are you right. RFC9032 does not support DTLS at all. It supports RFC9031 only. Perhaps we should simply indicate that we don't support 6TISCH. > 4. Stateful vs. stateless proxy discovery > How do i know as a customer of equipment know that all my > pledges/proxies/registrars will interoperate in the face of those > devices seemingly being able to freely pick stateful and/or stateless > mode of operations ? Because, we defined the proxy to have a standard interface. (Except for CoAP/OSCORE vs CoAPS above) How the join proxy keeps state (in memory or in the network) is a private matter between the JP and the Registrar, and does not concern the pledge. -- ] 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 [ -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
