Re: [Anima] Genart last call review of draft-ietf-anima-constrained-join-proxy-09

Hi Ines,

Many thanks for your review.

Please see inline comments below.

Greetings,

Peter

Reviewer: Ines Robles
Review result: On the Right Track

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

https://trac.ietf.org/trac/gen/wiki/GenArtfaq.

Document: draft-ietf-anima-constrained-join-proxy-09
Reviewer: Ines Robles
Review Date: 2022-04-08
IETF LC End Date: 2022-04-08
IESG Telechat date: Not scheduled for a telechat

Summary:

The document defines a mechanism to assign a Device (Pledge) to a 
(anima)
domain, represented by a Registrar, using an intermediate node (e.g. 
6LR)
called constrained Joint Proxy. Once that the Pledge is enrolled to the
network, it can take the role of a Joint Proxy.

I understand that the document is going currently under modifications, 
new text
is being proposed into the Mailing List (e.g. updates on section 4, 
etc.), and
the open issues are being tracked into github
[https://github.com/anima-wg/constrained-join-proxy/issues/]

Pvds==>

Thanks for taking into account the github contents

==>

Additional Comments/Questions:

	* Which are the differences between a "Circuit-proxy" and a "stateful
constrained join Proxy"? I understand that both are stateful join proxy
entities, right? (Maybe the difference is in the constrained level?). In 
the
abstract states that they replace each other. Maybe a better description 
could
be: "instead of having only stateful join proxy (Circuit-proxy) mode, 
this spec
also include the stateless join proxy mode", is this correct?

Pvds ==>

At the end of section 2

  NEW

This document standardizes the CoAP/DTLS (method 4). The specified 
constrained Join Proxy extends the circuit proxy by using coaps DTLS 
ports, by choosing the DTLS destination address and by specifying a 
stateful and a stateless mode. The stateful and stateless modes have the 
same purpose as the storing and non_storing Modes of Operations (MOP) of 
RPL {{RFC6550}}.

Is this OK?

==>

2- Terminology Section:

2.1- It mentions JCR, but in the text is used "Registrar", thus, it 
could be
mentioned here that both refers to the same.

Pvds==>

NEW

In this document, the term "Registrar" is used throughout instead of 
"Join Registrar/Coordinator (JRC)".

==>

2.2- Other terms such as TOFU,
MASA and imprint are never used through the document [Maybe it should be
described (in SEC. section?) how these terms are related in this 
document (if
applicable)].

Pvds==>

Right, very good. They are removed

==>

2.3- Additionally, it would be nice to include the definition of
the: a) "constrained Joint Proxy" [smth similar what RFC9030 defines?];

pvds==>

NEW

The "Constrained Join Proxy" enables a pledge that is multiple hops away 
from the Registrar, to securely execute the BRSKI protocol {{RFC8995}} 
over a secure channel.

==>

b)
"Stateful and Stateless mode" (the text from the introduction could be 
moved to
this section);

  	* c) circuit-proxy (refer to RFC8995?)

pvds==>

see text end of section 2

==>

	* What happens when a joint-proxy restart in a stateful mode during a 
joining
message flow?

Pvds==>

That is a new aspect for me; see below

==>

	* Just for better understanding: E.g. If a Pledge participates in two
different use cases, meaning two different domains, then is it possible 
that
the Pledge become Stateful and Stateless Join Proxy (in different 
domains)?. I
understand that this is possible, but not useful, since the device will 
include
the specification complexity of both modes. Thus, I could think that it 
is
recommended to select the same mode for all the domains that a device 
join?
This could be a decision point whether to become or not a joint proxy?
(Although, at the end of the day it could be defined by the use case
requirements/available network resources).

	* Section 5, Page 6: "..A Join Proxy MAY implement both, with an 
unspecified
mechanism to switch between the two modes." I understand that it refers 
to one
single domain, I do not understand the meaning of "unspecified 
mechanism".
Maybe it should read: "the mechanism to switch between modes is not in 
the
scope of this document" ?

Pvds==>

NEW

A Join Proxy MAY implement both. A mechanism to switch between modes is 
out of scope of this document. It is recommended that a Join Proxy uses 
only one of these modes at any given moment during an installation 
lifetime.

==>

	* Section 5.1, Page 6: "...The Join Proxy maintains a 4-tuple array to
translate the DTLS messages received from the Registrar and forwards it 
back to
the
.." Translate the DTLS message to what? Please clarify.

pvds==>

NEW

The Join Proxy stores the 4-tuple array of the messages received from 
the Registrar and copies it back to the header of the message returned 
to the Pledge.

==>

	* Page 11: I understand that when the Pledge is one hop from the 
Registrar, it
does not need the join proxy, right?

Pvds==>

Correct, I hope this is clearer form the new text at the end of section 
4

==>

Nit (Pag. 11): "...Step 2 in implementation dependent..." -> "...Step 2 
is
implementation dependent..."

pvds==>

thanks

==>

Thanks for this document,

Ines.
Ines Robles via Datatracker schreef op 2022-04-08 21:01:

> Reviewer: Ines Robles
> Review result: On the Right Track
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-anima-constrained-join-proxy-09
> Reviewer: Ines Robles
> Review Date: 2022-04-08
> IETF LC End Date: 2022-04-08
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> The document defines a mechanism to assign a Device (Pledge) to a 
> (anima)
> domain, represented by a Registrar, using an intermediate node (e.g. 
> 6LR)
> called constrained Joint Proxy.  Once that the Pledge is enrolled to 
> the
> network, it can take the role of a Joint Proxy.
> 
> I understand that the document is going currently under modifications, 
> new text
> is being proposed into the Mailing List (e.g. updates on section 4, 
> etc.), and
> the open issues are being tracked into github
> [https://github.com/anima-wg/constrained-join-proxy/issues/]
> 
> Additional Comments/Questions:
> 
> 1- Which are the differences between a "Circuit-proxy" and a "stateful
> constrained join Proxy"? I understand that both are stateful join proxy
> entities, right? (Maybe the difference is in the constrained level?). 
> In the
> abstract states that they replace each other. Maybe a better 
> description could
> be: "instead of having only stateful join proxy (Circuit-proxy) mode, 
> this spec
> also include the stateless join proxy mode", is this correct?
> 
> 2- Terminology Section:
> 
> 2.1- It mentions JCR, but in the text is used "Registrar", thus, it 
> could be
> mentioned here that both refers to the same. 2.2- Other terms such as 
> TOFU,
> MASA and imprint  are never used through the document [Maybe it should 
> be
> described (in SEC. section?) how these terms are related in this 
> document (if
> applicable)]. 2.3- Additionally, it would be nice to include the 
> definition of
> the: a) "constrained Joint Proxy" [smth similar what RFC9030 defines?]; 
> b)
> "Stateful and Stateless mode" (the text from the introduction could be 
> moved to
> this section); c) circuit-proxy (refer to RFC8995?)
> 
> 3- What happens when a joint-proxy restart in a stateful mode during a 
> joining
> message flow?
> 
> 4- Just for better understanding: E.g. If a Pledge participates in two
> different use cases, meaning two different domains, then is it possible 
> that
> the Pledge become Stateful and Stateless Join Proxy (in different 
> domains)?. I
> understand that this is possible, but not useful, since the device will 
> include
> the specification complexity of both modes. Thus, I could think that it 
> is
> recommended to select the same mode for all the domains that a device 
> join?
> This could be a decision point whether to become or not a joint proxy?
> (Although, at the end of the day it could be defined by the use case
> requirements/available network resources).
> 
> 5- Section 5, Page 6: "..A Join Proxy MAY implement both, with an 
> unspecified
> mechanism to switch between the two modes." I understand that it refers 
> to one
> single domain, I do not understand the meaning of "unspecified 
> mechanism".
> Maybe it should read: "the mechanism to switch between modes is not in 
> the
> scope of this document" ?
> 
> 6- Section 5.1, Page 6: "...The Join Proxy maintains a 4-tuple array to
> translate the DTLS messages received from the Registrar and forwards it 
> back to
> the
> Pledge..."  Translate the DTLS message to what? Please clarify.
> 
> 7- Page 11: I understand that when the Pledge is one hop from the 
> Registrar, it
> does not need the join proxy, right?
> 
> Nit (Pag. 11): "...Step 2 in implementation dependent..." -> "...Step 2 
> is
> implementation dependent..."
> 
> Thanks for this document,
> 
> Ines.
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima