Subject: [Anima] AD review for draft-ietf-anima-constrained-join-proxy-06

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 18 Mar 2022 14:44:23 +0000

Hi,

This is my AD review for draft-ietf-anima-constrained-join-proxy-06.

Thanks for this document.  I found it pleasant to read and only had minor comments.

1. 
   Abstract:

   This intermediary node is known as a
   "constrained Join Proxy".  An enrolled Pledge can act as a Join
   Proxy.

Is a constrained Join Proxy and Join Proxy the same thing, or is one a subtype of the other?  I.e., would it be clearer to say that an enrolled Pledge can act as a constrained Join Proxy?

2. Sec 2.
   The term
   "installation IP_address" refers to the set of addresses which are
   routable over the whole installation network.
   
Is it referring to the set of addresses, or just one out of the set of addresses?

3.  Sec 4.
    in an LLN mesh can be
 
LLN doesn't seem to be defined anywhere.

4.  Sec 5.1, figure 2.

   IP_P:p_P = Link-local IP address and port of Pledge (DTLS Client)
   IP_R:5684 = Routable IP address and coaps port of Registrar
   IP_Ja:P_J = Link-local IP address and join-port of Join Proxy
   IP_Jb:p_Rb = Routable IP address and client port of Join Proxy

Really just a nit, but I assume that this is a naming scheme here, but I didn't find it that intuitive, specifically for differentiating between a link-local and routable IP address for the Join Proxy.  E.g., I was wondering if IP_Jl: and IP_Jr might be clearer., but I'll leave this entirely to the authors discretion.

5. Sec 5.3.

  The
   Registrar replaces the 5th "content" element with the DTLS payload of
   the response message and leaves all other array elements unchanged.
   
Possibly you could be more explicit that the message is sent back?

6. Sec 5.3

   When additions are added to the array in later versions of this
   protocol, any additional array elements (i.e., not specified by
   current document) MUST be ignored by a receiver if it doesn't know
   these elements.  This approach allows evolution of the protocol while
   maintaining backwards-compatibility.  A version number isn't needed;
   that number is defined by the length of the array.
   
 So, presumably new elements can be added, but never removed again afterwards?

 7. Sec 6.
 
   | Ports       | Join Proxy needs           |Join Proxy and Registrar|
   |             | discoverable join-port     |need discoverable       |
   |             |                            | join-ports             |
   +-------------+----------------------------+------------------------+

At the point that I read this, I didn't understand why discoverable ports are needed for both the Join Proxy and Registrar for the stateless mode.  I think that led me to the separate question as to whether it wouldn't make more sense to have the section on Discovery before the comparison section.

8. Sec 7.

   Three discovery cases are discussed: Join Proxy discovers Registrar,
   Pledge discovers Registrar, and Pledge discovers Join Proxy.  Each
   discovery case considers three alternatives: CoAP discovery, GRASP
   discovery, and 6tisch discovery.

When reading this, it wasn't entirely clear to me under what circumstances the different discovery mechanisms would be used.  Is it also possible that for some networks multiple discovery mechanisms may be available, or would it always be the case that only one would be deployed?

Finally, given the way that the options fall out, I did wonder if the document might be more readable if the 2-dimensional array of options was described the other way.  I.e., grouped primarily by whether CoAP or GRASP or 6tisch discovery is being used?

9. Sec 8.

   Another possibility is to use level 2 protection between Registrar
   and Join Proxy.
   
I don't understand what is meant by this.

---

Minor spelling and grammar warnings from an automated tool.

Spellings:
    aplication,
    neighbour,
    neighbouring,

Obviously neighbour isn't a spelling mistake, but flagging in case the intent is to be using American English :-)

Grammar Warnings:
Section: 7.1.2, draft text:
Autonomic Network Join Proxies MUST support GRASP discovery of Registrar as described in section 4.3 of [RFC8995] .
Warning:  Don't put a space before the full stop.
Suggested change:  "."

Section: 7.2.1, draft text:
The discovery of the coaps Registrar, using coap discovery, by the Pledge follows sections 6.3 and 6.5.1 of [I-D.ietf-anima-constrained-voucher]..
Warning:  Two consecutive dots
Suggested change:  "."

Section: 7.3.1, draft text:
Port numbers are assumed to be the default numbers 5683 and 5684 for coap and coaps respectively (sections 12.6 and 12.7 of [RFC7252] when not shown in the response. 
Warning:  Unpaired symbol: ')' seems to be missing

Section: 8, draft text:
All of the concerns in [RFC8995] section 4.1 apply. 
Warning:  Consider using all the.
Suggested change:  "All the"

Regards,
Rob

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 18 Mar 2022 16:19:51 +0100

> LLN doesn't seem to be defined anywhere.

It is “defined” in RFC 7102.

(I would not use this term.
It has the definitional sharpness of Labskaus.)

The term “LLN mesh” is definitely not defined.
The authors of RFCs 8505 8931 9030 9032 seem to like using it, anyway.

Grüße, Carsten

---

From: Peter van der Stok <[email-masked]>
Date: Mon, 21 Mar 2022 10:24:51 +0100

Hi Rob,

thanks for the review and the encouragements.
Below my reactions on your points.

When you agree with the proposed changes, and nobody else complains, I 
will submit the new I-D at the end of this week.

Greetings,

Peter

Rob Wilton (rwilton) schreef op 2022-03-18 15:44:

> Is a constrained Join Proxy and Join Proxy the same thing, or is one a 
> subtype of the other?  I.e., would it be clearer to say that an 
> enrolled Pledge can act as a constrained Join Proxy?
> 
> pvds =>
> Agree with your suggestion. Terminology reduction is always good.
> ==>
> 
> 2. Sec 2.
> The term
> NEW ==>
> The term "installation IP_address" refers to an address out of the set 
> of addresses which are routable over the whole installation network.
> ==>
> 
> 3.  Sec 4.
> in an LLN mesh can be
> 
> NEW==>
> the Pledge (P), in a Low-Power and Lossy Network (LLN) mesh
> {{RFC7102}} can be more than one hop away from the Registrar (R)
> ==>
> 
> Ignoring Carsten's remark about being badly defined.
> 
> 4.  Sec 5.1, figure 2.
> 
> Really just a nit, but I assume that this is a naming scheme here, but 
> I didn't find it that intuitive, specifically for differentiating 
> between a link-local and routable IP address for the Join Proxy.  E.g., 
> I was wondering if IP_Jl: and IP_Jr might be clearer., but I'll leave 
> this entirely to the authors discretion.
> 
> pvds==>
> Thanks, is clearer; changed as suggested in both figures
> ==>
> 
> 5. Sec 5.3.
> 
> The
> NEW==>
> After replacing the 5th "content" element with the DTLS payload of the 
> response message and leaving all other array elements unchanged, the 
> Registrar returns the response message.
> ==>
> 
> 6. Sec 5.3
> 
> pvds==>
> Yes, I addedd:
> NEW==>
> However, this means that message elements are consistently added to 
> earlier defined elements to avoid ambiguities.
> ==>
> ==>
> 
> 7. Sec 6.
> 
> At the point that I read this, I didn't understand why discoverable 
> ports are needed for both the Join Proxy and Registrar for the 
> stateless mode.  I think that led me to the separate question as to 
> whether it wouldn't make more sense to have the section on Discovery 
> before the comparison section.
> 
> pvds==>
> I see your point and put discovery section before comparison section
> ==>
> 
> 8. Sec 7.
> 
> When reading this, it wasn't entirely clear to me under what 
> circumstances the different discovery mechanisms would be used.  Is it 
> also possible that for some networks multiple discovery mechanisms may 
> be available, or would it always be the case that only one would be 
> deployed?
> 
> NEW==>
> discovery, and 6tisch discovery. It depends on the type of installation 
> which discovery mechanisms are offered. It can be imagined that 
> manufacturers provide the pledge/join-proxy with more than one 
> discovery mechanism. The pledge/join-proxy can try one after the other 
> mechanism untill success is reached. Alternatively, at installation a 
> switch is set to determine the discovery mechanism.
> ==>
> 
> Finally, given the way that the options fall out, I did wonder if the 
> document might be more readable if the 2-dimensional array of options 
> was described the other way.  I.e., grouped primarily by whether CoAP 
> or GRASP or 6tisch discovery is being used?
> 
> pvds==>
> This section has seen several structures, where this last structure 
> seemed to give the best results to generate readable text
> ==>
> 
> 9. Sec 8.
> 
> NEW==>
> In some installations, level 2 protection is provided between all 
> member pairs of the mesh. In such an enviroment encryption of the CBOR 
> array is unnecessay because the level 2 protection already provides it.
> ==>
> 
> ---
> 
> Obviously neighbour isn't a spelling mistake, but flagging in case the 
> intent is to be using American English :-)
> 
> pvds==>
> changed to american spelling convention
> ==>
> 
> Grammar Warnings:
> Autonomic Network Join Proxies MUST support GRASP discovery of 
> Registrar as described in section 4.3 of [RFC8995] .
> pvds==>
> thanks, done
> ==>
> The discovery of the coaps Registrar, using coap discovery, by the 
> Pledge follows sections 6.3 and 6.5.1 of 
> [I-D.ietf-anima-constrained-voucher]..
> pvds==>
> done
> ==>
> Port numbers are assumed to be the default numbers 5683 and 5684 for 
> coap and coaps respectively (sections 12.6 and 12.7 of [RFC7252] when 
> not shown in the response.
> pvds==>
> corrected
> ==>
> pvds==>
> also removed
> ==>
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Esko Dijk <[email-masked]>
Date: Thu, 24 Mar 2022 19:39:30 +0000

Hi Peter,

Sounds good –could I reverse the order, i.e. look at the diffs in the new I-D first and then complain? (I may skip the complaining part if everything looks ok ;-) )

Esko

From: Anima <[email-masked]> On Behalf Of Peter van der Stok
Sent: Monday, March 21, 2022 10:25
To: Rob Wilton (rwilton) <rwilton=[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Anima] AD review for draft-ietf-anima-constrained-join-proxy-06

Hi Rob,

When you agree with the proposed changes, and nobody else complains, I will submit the new I-D at the end of this week.

Greetings,

Peter

1.
   Abstract:

pvds =>

2. Sec 2.
   The term

NEW ==>
The term "installation IP_address" refers to an address out of the set of addresses which are routable over the whole installation network.
==>

3.  Sec 4.
    in an LLN mesh can be

NEW==>

4.  Sec 5.1, figure 2.

pvds==>

5. Sec 5.3.

  The

NEW==>
After replacing the 5th "content" element with the DTLS payload of the response message and leaving all other array elements unchanged, the Registrar returns the response message.
==>

6. Sec 5.3

pvds==>
Yes, I addedd:
NEW==>
 However, this means that message elements are consistently added to earlier defined elements to avoid ambiguities.
==>
==>

 7. Sec 6.

pvds==>

8. Sec 7.

NEW==>
Three discovery cases are discussed: Join Proxy discovers Registrar, Pledge discovers Registrar, and Pledge discovers Join Proxy. Each discovery case considers three alternatives: CoAP discovery, GRASP discovery, and 6tisch discovery. It depends on the type of installation which discovery mechanisms are offered. It can be imagined that manufacturers provide the pledge/join-proxy with more than one discovery mechanism. The pledge/join-proxy can try one after the other mechanism untill success is reached. Alternatively, at installation a switch is set to determine the discovery mechanism.
==>

pvds==>
This section has seen several structures, where this last structure seemed to give the best results to generate readable text
==>

9. Sec 8.

NEW==>
In some installations, level 2 protection is provided between all member pairs of the mesh. In such an enviroment encryption of the CBOR array is unnecessay because the level 2 protection already provides it.
==>

---

Spellings:
    aplication,
    neighbour,
    neighbouring,

pvds==>

Grammar Warnings:

pvds==>
thanks, done
==>

pvds==>
done
==>

pvds==>
corrected
==>

Section: 8, draft text:

Regards,
Rob

_______________________________________________
Anima mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/anima