Re: [Anima] Discovery of proxy/registrar insufficient (GRASP and more).

[Michael Richardson <[e-mail]>]

Toerless Eckert <[e-mail]> 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  [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-