Re: [Gen-art] [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-10.txt

[Peter van der Stok]

 Dear reviewers,

Can you verify that the recently published version 10 of the 
constrained-join-proxy draft correctly addresses your reviews as 
discussed on the mailing list?


many thanks,
greetings,

Peter
Peter van der Stok schreef op 2022-04-14 09:28:

This version 10 includes the results from SECDIR, OPSDIR, IANA, and 
GENART reviews.


Peter
internet-dra...@ietf.org schreef op 2022-04-14 09:25:

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Autonomic Networking Integrated Model 
and Approach WG of the IETF.


Title   : Constrained Join Proxy for Bootstrapping Protocols
Authors : Michael Richardson
Peter van der Stok
Panos Kampanakis
Filename: draft-ietf-anima-constrained-join-proxy-10.txt
Pages   : 24
Date: 2022-04-14

Abstract:
This document extends the work of Bootstrapping Remote Secure Key
Infrastructures (BRSKI) by replacing the Circuit-proxy between Pledge
and Registrar by a stateless/stateful constrained Join Proxy.  The
constrained Join Proxy is a mesh neighbor of the Pledge and can relay
a DTLS session originating from a Pledge with only link-local
addresses to a Registrar which is not a mesh neighbor of the Pledge.

This document defines a protocol to securely assign a Pledge to a
domain, represented by a Registrar, using an intermediary node
between Pledge and Registrar.  This intermediary node is known as a
"constrained Join Proxy".  An enrolled Pledge can act as a
constrained Join Proxy.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-join-proxy/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-join-proxy-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-constrained-join-proxy-10

Internet-Drafts are also available by rsync at 
rsync.ietf.org::internet-drafts


___
Anima mailing list
an...@ietf.org
https://www.ietf.org/mailman/listinfo/anima


___
Anima mailing list
an...@ietf.org
https://www.ietf.org/mailman/listinfo/anima___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Peter van der Stok]

 Hi Michael,

I liked the reference to RFC6550 because it shows that other RFCs 
provide the same modes; and it was argued to standardize only one mode.


Peter
Michael Richardson schreef op 2022-04-11 20:04:


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.


While what you write is not false: once enrolled, a node can take on 
the role

of join proxy.
But, it makes it sound like the purpose of enrollment is to become a 
join
proxy.  The purpose of enrollment is to carry out the revenue 
generating
portion of the network...   becoming a join proxy is a burden, it's 
about

"paying it forward"  https://en.wikipedia.org/wiki/Pay_it_forward


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


Mostly they are two terms for almost the same thing.
Properly implemented, they are indistinguishable from outside.
Internally, a circuit proxy involves two actual sockets, with an 
application
space loop to copy A->B and B->A.  For TCP, there are some complexities 
if

you chose to implement TCP urgent alerts.
A stateful xxx proxy would be NAT44, occuring at the network rather 
than

application layer.


 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?


I think that this is a bit of a Ines-specific answer.
I'm not sure that making allusions to RFC6550 here is helpful for the 
general

reader.

Maybe:
The stateful and stateless modes differ in the way that they store
the state required to forward the return packet to the pledge.
Similar to the difference between storing and non_storing Modes of
Operations (MOP) in RPL {{RFC6550}}. In the stateful method, the
return forward state is stored in the join proxy.  In the stateless
method, the return forward state is stored in the network.___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Peter van der Stok]

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 

Re: [Gen-art] Gen-ART review of draft-ietf-core-etch-02

[peter van der Stok]

Hi Christer,

Thanks for your suggestions and comments.
A bit late reaction due to holidays.

See my answers below. It is not excluded that my co-author may refine 
(improve) my answers.


Peter

Christer Holmberg schreef op 2016-09-20 13:34:

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


Document:   draft-ietf-core-etch-02
Reviewer:   Christer Holmberg

Review Date:20 September 2016
IETF LC End Date:7 September 2016
IETF Telechat Date: 13 October 2016


Summary:

The document is well written, and is almost ready for publication as
standards track RFC. However,
I have a number of editorial issues that I¹d like the authors to 
address.


Major Issues:   None

Minor Issues:   None

Editorial Issues:


Q1 (Abstract):

The Abstract says:

  "The existing Constrained Application Protocol (CoAP) methods
only allow access to a
   complete resource, not to parts of a resource.²

I suggest to say ³The CoAP methods  defined in RFC 7252 only
allowŠ²Because as possible new CoAP methods
are defined in the future, the ³existing methods² statement may no 
longer

be true. This also makes it clear
that, when the document was written, RFC 7252 was the only spec you 
used

as input for existing methods.


 True 



Q2 (Abstract):

In general, I think the Abstract contains too much detail. Wouldn¹t it 
be

enough to keep the 1st paragraph, and
add the first paragraph of section 1?

Something like:

  "The Constrained Application Protocol (CoAP) methods defined 
in

RFC 7252 only
   allow access to a complete resource, not to parts of a
resource.  In
   case of resources with larger or complex data, or in 
situations

where
   a resource continuity is required, replacing or requesting 
the

whole
   resource is undesirable.  Several applications using CoAP 
will

need
   to perform partial resource accesses.

   This specification defines the new Constrained Application
Protocol (CoAP)
   methods, FETCH, PATCH and iPATCH, which are used to access 
and

update parts
   of a resource.²

The rest of the Abstract text belongs e.g., in the Introduction 
section,

in my opinion.


IMO, you are right, and your suggestion is an improvement




Q3 (Introduction):

I think you need more background text before you start talking about 
the

methods. As suggested in Q2, move some
text from the Abstract to the Introduction.


will do, but I like to keep the fetch and patch introductions separate 
as they are.





Q4 (Section 2):

The text says: "Implementations MAY use a request body of any content 
type

with the FETCH method;²

First, I am not sure whether ³MAY² (uppercase) is appropriate here. 
What

about saying ³can² och ³may² (lowercase)?


We mean "MAY" as we can envisage different content formats for the 
future (e.g. one including query specifications) and we have a concrete 
case today.




Second, would it be better to say ³attach a body² instead of ³use a 
body²?

 I have no opinion on this, may be Carsten? 


Third, I think it would be good to add text about "safe and idempotent²
also to the Security Considerations section.


That would go to section 1 before section 1.1; to provide the 
background.





Q5 (Section 2.2.2):

Please add reference for Content-Format option.

 section 5.10.3 to be added



Q6 (Section 2.5):

Is there a reason this text is not in Section 4?


section 2.5 is about FETCH, while section 4 is about having 3 methods.
Renaming section 4 to "CoAP method set" may help?




Q7 (Section 2.6):

First, why not simply calling the section ³Example² or ³FETCH Example²?
The same comment apply to
section 3.1 for PATCH/iPATCH examples.


The examples are really simple, and we did not want to raise too high 
expectations.

May be I am over sensitive on this point.
Just " example" will do as well.



Second, is the first paragraph really Example text? Isn¹t it normative
text that should be somewhere else?


I like the suggestion to put it before section 2.1 or generate a 
separate subsection.




Third, is a reference for JSON needed on first occurrence?


Agree; good catch



Fourth, I don¹t think you need to say ³might² in the "JSON document 
that

might be returned by GET² sentence. It¹s
an example, so simply say "JSON document returned by GET².


agree




Q8 (Section 2 general):

Is there a reason there is no ³Error Handling² subsection for FETCH?


section 2.1 is sufficient in this case, because there are no issues that 
we are aware of.





Q9 (Section 3):

As far as I know, HTTP (and CoAP, I assume) method names are case
insensitive. Even though it sounds cool and trendy, so
you really need to say ³iPATCH², and not ³IPATCH²? Implementers may not
thing that one MUST use lowercase ³i², which I
assume is not correct, and I am not aware of any other 

Re: [Gen-art] Gen-ART review of draft-ietf-roll-applicability-ami-12

[peter van der Stok]

Hi Christer,

thanks for the review.
Do you propose to change the standards track objective to informational?

Peter

Christer Holmberg schreef op 2016-04-29 11:48:

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


Document: draft-ietf-roll-applicability-ami-12


Reviewer:   Christer Holmberg

Review Date: 29 April 2016

IETF LC End Date: 12 April 2016

IETF Telechat Date:  5 May 2016

Summary:  The document is well written,
and ready for publication is informational RFC.

Major Issues:None

Minor Issues:None

Editorial Issues:None

Links:
--
[1] http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-roll-applicability-home-building-08

[peter van der Stok]

HI Meral,

Thanks for the suggestions.
I have no problem with any of them. I think they are quite justified. 
Thank you very much for pointing them out.

Concerning scene and group control. I may suppress the word scene.
About [occuswitch] I have to look for a valid alternative. However, 
these links are maintained by a company, which changes information 
frequently.
Sorry for missing out some of the acronyms. I thought I caught them out 
all.


Greetings,

Peter


Meral Shirazipour schreef op 2015-03-22 21:28:

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-roll-applicability-home-building-08
Reviewer: Meral Shirazipour
Review Date: 2015-03-21
IETF LC End Date:  2015-03-23
IESG Telechat date: NA


Summary:
This draft is ready to be published as Standards Track RFC but I have
some comments.

Major issues:

Minor issues:

Nits/editorial comments:
-[Page 1], RPL first used in title/abstract, Would be good to spell 
it out.

-[Page 5], Section 2, Monitoring of functional correctness is at
least as important.. As important as what? (not clear)
-[Page 5], Section 2, Devices typically communicate their status
regularly and send alarm messages notifying a malfunction of equipment
or network.
Not clear what equipment is? network node is an equipment?
-[Page 6], Section 2.1, for large installation---for a large 
installation

-[Page 8], Section 2.2.2, fire detectors and the smoke dampers need
to be put in place to meet the stringent delay requirements.
Where can we find a value for the delay requirement of fire detectors?
A value or reference would be good.
-[Page 9], Section 2.2.4,advanced scene and group control. Not clear
what scene means.
-[Page 13], Section 4.1, assumes the role as
authoritative---assumes the role of authoritative
-[Page 16], section 4.1.8, please spell out first use CBC-MAC (Cipher
Block Chaining Message Authentication Code)
-[Page 16], section 4.1.10, it would be good to give the RFCs.
-[Page 16], section 4.2.4, MLE to spell out at first use mesh link
establishment
-[Page 22], CoAp first used in section 7.4, but spelled out in 
section 8.

-[Page 18], section 5.1.1., to throw away too late messages, how are
too late messages identified?
-[Page 27], [I-D.ietf-6lo-lowpanz] to be replaced by RFC7428
-[Page 28], link to [occuswitch] to be verified.
-Through the document both ms and msec are used. Selecting one for
consistency would be better.

Best Regards,
Meral
---
Meral Shirazipour
Ericsson
Research
www.ericsson.com


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-roll-applicability-home-building-08

[peter van der Stok]

Hi Adrian,

good news. I try to do the update this week.

Greetings, thanks,

Peter

Adrian Farrel schreef op 2015-03-23 20:12:

Hi Peter,

This all looks good.
The changes are small, but it would be worth catching them in a new 
revision.

Please post it when you have it, no need to check with me.

Once you've done that, we'll hand it over to Alvaro as the incoming AD, 
and he

can put it on an IESG telechat.

Cheers,
Adrian



-Original Message-
From: peter van der Stok [mailto:stokc...@xs4all.nl]
Sent: 23 March 2015 14:49
To: Meral Shirazipour
Cc: draft-ietf-roll-applicability-home-building@tools.ietf.org;

gen-art@ietf.org
Subject: Re: Gen-ART Last Call review of 
draft-ietf-roll-applicability-home-

building-08

HI Meral,

Thanks for the suggestions.
I have no problem with any of them. I think they are quite justified.
Thank you very much for pointing them out.
Concerning scene and group control. I may suppress the word scene.
About [occuswitch] I have to look for a valid alternative. However,
these links are maintained by a company, which changes information
frequently.
Sorry for missing out some of the acronyms. I thought I caught them 
out

all.

Greetings,

Peter


Meral Shirazipour schreef op 2015-03-22 21:28:
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 Please resolve these comments along with any other Last Call comments
 you may receive.

 Document: draft-ietf-roll-applicability-home-building-08
 Reviewer: Meral Shirazipour
 Review Date: 2015-03-21
 IETF LC End Date:  2015-03-23
 IESG Telechat date: NA


 Summary:
 This draft is ready to be published as Standards Track RFC but I have
 some comments.

 Major issues:

 Minor issues:

 Nits/editorial comments:
 -[Page 1], RPL first used in title/abstract, Would be good to spell
 it out.
 -[Page 5], Section 2, Monitoring of functional correctness is at
 least as important.. As important as what? (not clear)
 -[Page 5], Section 2, Devices typically communicate their status
 regularly and send alarm messages notifying a malfunction of equipment
 or network.
 Not clear what equipment is? network node is an equipment?
 -[Page 6], Section 2.1, for large installation---for a large
 installation
 -[Page 8], Section 2.2.2, fire detectors and the smoke dampers need
 to be put in place to meet the stringent delay requirements.
 Where can we find a value for the delay requirement of fire detectors?
 A value or reference would be good.
 -[Page 9], Section 2.2.4,advanced scene and group control. Not clear
 what scene means.
 -[Page 13], Section 4.1, assumes the role as
 authoritative---assumes the role of authoritative
 -[Page 16], section 4.1.8, please spell out first use CBC-MAC (Cipher
 Block Chaining Message Authentication Code)
 -[Page 16], section 4.1.10, it would be good to give the RFCs.
 -[Page 16], section 4.2.4, MLE to spell out at first use mesh link
 establishment
 -[Page 22], CoAp first used in section 7.4, but spelled out in
 section 8.
 -[Page 18], section 5.1.1., to throw away too late messages, how are
 too late messages identified?
 -[Page 27], [I-D.ietf-6lo-lowpanz] to be replaced by RFC7428
 -[Page 28], link to [occuswitch] to be verified.
 -Through the document both ms and msec are used. Selecting one for
 consistency would be better.

 Best Regards,
 Meral
 ---
 Meral Shirazipour
 Ericsson
 Research
 www.ericsson.com


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art