Subject: Re: [Anima] checking on advancing draft-ietf-anima-constrained-join-proxy / 'rt' naming

From: Esko Dijk <[email-masked]>
Date: Wed, 24 Nov 2021 11:32:03 +0000

Hello Sheng, all

I checked the new version against my review comments; and the following comment is still open – this is where Peter and me disagree.

> 9.1: the registered resource types (rt) would typically use some
> hierarchy in naming with dots to denote hierarchy. See the current
> entries in the registry:
> https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#rt-link-target-att-value
> For constrained-BRSKI we have defined "brski", "brski.vs", "brski.rv",
> etc.
>
> So to stay with existing conventions we could use such names.  One
> observation is that the Join Proxy in fact offers *all* BRSKI functions
> that the Registrar offers, but then proxied.
>
> -> PvdS Here follows my rant.
> There is no such thing as a convention for rt values.

My point on above is that the convention is that which has been used so far and is not written down in any other RFC, draft, document, or policy apart from the mere convention – what people register into the CoRE parameters registry ‘rt’ attributes.
All rt values so far have used the hierarchy

core.*  - CoRE WG types
ace.* - ACE WG types
brski.* - ANIMA WG types for BRSKI – not yet in the registry but specified in draft-constrained-voucher.
oic.* - any types specified by OCF/OIC
fa.* - any types specified by Fairhair Alliance

Hence my request to comply to this convention, however undocumented it is today. Any system architect would agree to that seeing the current list.

For the current draft it may be solved by choosing e.g.
rt=brski.jp     -   for the Join Proxy’s resource type  (to advertise join proxy support to Pledge)
rt=brski.rjp   -   for the Registrar’s Join Proxy port (to advertise Registrar’s support for stateless join proxy protocol messages)

I was hoping anyone else in the WG could also comment here to avoid a yes/no type discussion.

I’ll also look at the other open comments soon.

best regards
Esko

From: Anima <[email-masked]> On Behalf Of Sheng Jiang
Sent: Tuesday, November 16, 2021 11:19
To: [email-masked]
Cc: [email-masked]
Subject: [Anima] checking on advancing draft-ietf-anima-constrained-join-proxy

Hi, all,

This is a checking email to the WG collect the opinion whether draft-ietf-anima-constrained-join-proxy-05. Following our WGLC on -04 version, we asked the IoT directory review. Russ Housley provided it and the authors have reported that they addressed the received comments. If anyone has further comments, please feel free to raise with details and suggestions. I will start my duty as document shepherd next week.

Cheers,

Sheng

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Nov 2021 12:48:56 -0500

Esko Dijk <[email-masked]> wrote:
    > I checked the new version against my review comments; and the following
    > comment is still open – this is where Peter and me disagree.

understood.
I have no real opinion.

    > Hence my request to comply to this convention, however undocumented it
    > is today. Any system architect would agree to that seeing the current
    > list.

Can we ask core@ to review and comment then?

original message: https://mailarchive.ietf.org/arch/msg/anima/s9yU6LPnV8pE17Ws2xjH2f0mrO0/

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Esko Dijk <[email-masked]>
Date: Mon, 29 Nov 2021 10:17:12 +0000

Apart from the discussion whether the (current) hierarchical naming convention is to be used, or any names without hierarchy (because it is allowed for rt), there is an additional consideration to make.

If a Pledge wants to use CoAP discovery to discover one of a Constrained Join Proxy or Registrar on the link, because typically it would be able to contact both (DTLS connection & messages are identical), it would help very much if it only has to do a single discovery action for both. And not 2 separate discovery actions.

If the Pledge discovers for resources with rt=brski* , this is useful as it will find resource "rt=brski" indicating a Registrar and also resources "rt=brski.jp" indicating a Constrained Join Proxy. I can pick either one it finds. If both are found it may prefer the Registrar directly (rt=brski). 

In my view this naming choice (brski.*) thus makes things more efficient and consistent; it is more than just a name.

Regards
Esko

-----Original Message-----
From: Michael Richardson <[email-masked]> 
Sent: Wednesday, November 24, 2021 18:49
To: Esko Dijk <[email-masked]>; [email-masked]
Cc: Sheng Jiang <[email-masked]>; [email-masked]; Peter van der Stok <[email-masked]>
Subject: Re: [Anima] checking on advancing draft-ietf-anima-constrained-join-proxy / 'rt' naming

understood.
I have no real opinion.

---

From: Peter van der Stok <[email-masked]>
Date: Tue, 30 Nov 2021 11:21:51 +0100

HI Esko,

The PR of MCR has been applied to main,
meaning that we now use the rt-values brski.jp and brski.rjp.

Greetings,

Peter
Esko Dijk schreef op 2021-11-29 11:17:

> Apart from the discussion whether the (current) hierarchical naming 
> convention is to be used, or any names without hierarchy (because it is 
> allowed for rt), there is an additional consideration to make.
> 
> If a Pledge wants to use CoAP discovery to discover one of a 
> Constrained Join Proxy or Registrar on the link, because typically it 
> would be able to contact both (DTLS connection & messages are 
> identical), it would help very much if it only has to do a single 
> discovery action for both. And not 2 separate discovery actions.
> 
> If the Pledge discovers for resources with rt=brski* , this is useful 
> as it will find resource "rt=brski" indicating a Registrar and also 
> resources "rt=brski.jp" indicating a Constrained Join Proxy. I can pick 
> either one it finds. If both are found it may prefer the Registrar 
> directly (rt=brski).
> 
> In my view this naming choice (brski.*) thus makes things more 
> efficient and consistent; it is more than just a name.
> 
> Regards
> Esko
> 
> Subject: Re: [Anima] checking on advancing 
> draft-ietf-anima-constrained-join-proxy / 'rt' naming
> 
>> comment is still open - this is where Peter and me disagree.
> 
> understood.
> I have no real opinion.
> 
>> core.* - CoRE WG types
>> ace.* - ACE WG types
>> brski.* - ANIMA WG types for BRSKI - not yet in the registry but 
>> specified in
>> draft-constrained-voucher.
> original message: 
> https://mailarchive.ietf.org/arch/msg/anima/s9yU6LPnV8pE17Ws2xjH2f0mrO0/
> 
> --
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Peter van der Stok <[email-masked]>
Date: Tue, 30 Nov 2021 12:13:37 +0100

HI all,

All the suggestions by Michael and Esko have been introduced into the 
document stored in github.

I think that this concludes the WGLC, unless I forgot some items.
Once they agree, a new vesrion -06 will be submitted to anima.

many thanks for their input,

Greetings,

Peter

Esko Dijk schreef op 2021-11-24 12:32:

>> [1]
> My point on above is that the convention is that which has been used so 
> far and is not written down in any other RFC, draft, document, or 
> policy apart from the mere convention - what people register into the 
> CoRE parameters registry 'rt' attributes.
> 
> specified in draft-constrained-voucher.
> 
> rt=brski.jp     -   for the Join Proxy's resource type  (to advertise 
> join proxy support to Pledge)
> 
> rt=brski.rjp   -   for the Registrar's Join Proxy port (to advertise 
> Registrar's support for stateless join proxy protocol messages)
> 
> I'll also look at the other open comments soon.
> 
> best regards
> 
> Esko
> 
> This is a checking email to the WG collect the opinion whether 
> draft-ietf-anima-constrained-join-proxy-05. Following our WGLC on -04 
> version, we asked the IoT directory review. Russ Housley provided it 
> and the authors have reported that they addressed the received 
> comments. If anyone has further comments, please feel free to raise 
> with details and suggestions. I will start my duty as document shepherd 
> next week.
> 
> Cheers,
> 
> Sheng

Links:
------
[1]