Re: [Anima] constrained handling of endpoint path names (from BRSKI-AE discussion today)

[Esko Dijk <[e-mail]>]

I added some comments on below questions on Github https://github.com/anima-wg/constrained-voucher/issues/51 .

In summary, you can ask for both resources of type ace.est and ace.brski by doing a wildcard query:
GET /.well-known/core?rt=ace.*

However this not only returns the two (intended?) resources ace.est and ace.brski, but also all the subtypes of these which is: 
ace.est.rv, ace.est.vs, ace.est.es, ace.est.ra

Note that the '/' in the rt name is not permitted by RFC 6690, it should be a '.' to indicate the hierarchy here. Created issues #54 for this.

Alternatively one can discover two times:
GET /.well-known/core?rt=ace.est
GET /.well-known/core?rt=ace.brski

This gets exactly the main resources but not the sub-resources below it separately. From the main resources the sub-resources are automatically inferred (i.e. the standard names 'rv', 'vs', 'es', and 'ra'.)
Doing this will reduce the amount of data transferred over the constrained network but adds an extra message roundtrip.

Section 9.1 needs to be extended to a proper IANA registration, and it should include these types:
ace.est
ace.est.rv
ace.est.vs
ace.est.es
ace.est.ra
(or the equivalent types 'ace.brski.*' in case we decide to change namespace est to brski  . Or maybe consider 'anima.brski.*'  or just 'brski.*' as the root rt namespace because BRSKI originated not in ACE WG scope but in ANIMA WG! )

Note that in my opinion all this discovery adds unnecessary complexity and overhead in the constrained node/network, so I created a proposal to also allow the .well-known resources that BRSKI is already using.  Why make something less efficient than the unconstrained protocol and force clients to use it ... ?
See issue #53  https://github.com/anima-wg/constrained-voucher/issues/53 
Note that ACE-coap-EST also supports the .well-known resources.

Esko

-----Original Message-----
From: Michael Richardson <[e-mail]> 
Sent: Friday, September 18, 2020 22:00
To: Esko Dijk <[e-mail]>; Werner, Thomas <[e-mail]>; [e-mail]; [e-mail]
Subject: constrained handling of endpoint path names (from BRSKI-AE discussion today)


Esko Dijk <[e-mail]> wrote:
    > I created a Github issue for constrained-voucher to capture the outcome
    > of this discussion:
    > https://github.com/anima-wg/constrained-voucher/issues/51

Thank you.

    > (Reminder: There are also a couple of more open issues. I can work on
    > these too and have already contacted Peter about these.)

I think that we can finally start digging these items out of the ditch
created by ACP and BRSKI stalling up the process.

In constrained-voucher/brski, there is a CoAP RD call:

     REQ: GET /.well-known/core?rt=ace.est*

     RES: 2.05 Content
     </est>; rt="ace.est"
     </est/rv>; rt="ace.est/rv";ct=TBD2 TBD3
     </est/vs>; rt="ace.est/vs";ct=50 60
     </est/es>; rt="ace.est/es";ct=50 60
     </est/ra>; rt="ace.est/ra";ct=TBD2 TBD3

I don't really know how to ask for multiple things.
  Clearly, we should be asking for "ace.brski" now?
  Do we have to change our allocation somewhere?
  I don't see any IANA activity around rt=ace.est/rv, unless it's section 9.1?
  which regisgters things, but I don't understand why it asks for ranges,
  because I have no idea where those *numbers* would go.
  I probably just don't know enough about this stuff.

I think that RFC6690 should probably be a normative reference.

I guess that we would have gotten all of the end points associated with
draft-ietf-ace-coaps-est when we above asked for ace.est.

RFC6690, section 4.1 [
   https://www.rfc-editor.org/rfc/rfc6690.html#section-4.1 ]

does not seem to permit two or three things to be returned, just wildcards.
What would happen if, when asked for rt=anima.brski, that it returned the
entries for ace.est and/or blah.cmp?

Is it late enough that we could just switch to CoRAL?
Do I even understand what means.

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