Re: [Gen-art] Genart last call review of draft-ietf-lisp-vendor-lcaf-09

[Christer Holmberg]

Hi,

Thanks for addressing my comments, and for explaining the reason for 
Experimental :)

Regards,

Christer

-Original Message-
From: Luigi Iannone  
Sent: tiistai 12. huhtikuuta 2022 10.14
To: Christer Holmberg 
Cc: gen-art@ietf.org; draft-ietf-lisp-vendor-lcaf@ietf.org; 
last-c...@ietf.org; l...@ietf.org
Subject: Re: Genart last call review of draft-ietf-lisp-vendor-lcaf-09

Hi Christer,

Thanks for the review.

As a shepherd I have a couple of comments inline.

> On 11 Apr 2022, at 22:35, Christer Holmberg via Datatracker 
>  wrote:
> 
> Reviewer: Christer Holmberg
> Review result: Ready with Issues
> 
> 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
> 
> .
> 
> Document: draft-ietf-lisp-vendor-lcaf-09
> Reviewer: Christer Holmberg
> Review Date: 2022-04-11
> IETF LC End Date: 2022-04-12
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> The document is well written, and easy to read and understand. 
> However, I do have a couple of issues.
> 
> Major issues:
> 
> Q1:
> 
> I do wonder why the document is published as Experimental, however, 
> due to the following reasons:

It is experimental because is an update to RFC 8060, which is experimental.
So unless we move that one to standard track I would say that is the right type 
of RFC.


> 
>   a)
> 
>   The document defines usage of the Type value 255.
> 
>   b)
> 
>   Section 3 says:
> 
>  "If a LISP device receives a LISP message containing a Vendor Specific
>   LCAF with an OUI that it does not understand, it MUST drop the
>   message and it SHOULD create a log message."
> 
>   This sounds like an update to LISP.
> 

Excellent point. Actually this document updates RFC 8060, and this should be 
stated in the document.


>   c)
> 
>   Section 3 defines new header fields.
> 
> Minor issues:
> 
> N/A
> 
> Nits/editorial comments:
> 
> Q2:
> 
> Section 1 says:
> 
>   “The Vendor Specific LCAF allows organizations to create
>   LCAF addresses to be used only internally on particular LISP
>   deployments.”
> 
> Is “allows” the best wording? Where organizations previously 
> disallowed to do this?
> 
> Would it be more correct to say “defines how organizations can create…”?

Yes, this wording is more correct.

Ciao

L.




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

Re: [Gen-art] Genart last call review of draft-ietf-lisp-vendor-lcaf-09

[Alberto Rodriguez-Natal (natal)]

Hi Christer, Luigi,

Thanks for the review Christer. I agree with your comments and with Luigi’s 
suggestions. We’ll edit the draft to include the feedback in the next iteration.

Thanks!
Alberto

From: Luigi Iannone 
Date: Tuesday, April 12, 2022 at 9:15 AM
To: Christer Holmberg 
Cc: gen-art@ietf.org , 
draft-ietf-lisp-vendor-lcaf@ietf.org 
, last-c...@ietf.org 
, l...@ietf.org 
Subject: Re: Genart last call review of draft-ietf-lisp-vendor-lcaf-09
Hi Christer,

Thanks for the review.

As a shepherd I have a couple of comments inline.

> On 11 Apr 2022, at 22:35, Christer Holmberg via Datatracker 
>  wrote:
>
> Reviewer: Christer Holmberg
> Review result: Ready with Issues
>
> 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
>
> .
>
> Document: draft-ietf-lisp-vendor-lcaf-09
> Reviewer: Christer Holmberg
> Review Date: 2022-04-11
> IETF LC End Date: 2022-04-12
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
>
> The document is well written, and easy to read and understand. However, I do
> have a couple of issues.
>
> Major issues:
>
> Q1:
>
> I do wonder why the document is published as Experimental, however, due to the
> following reasons:

It is experimental because is an update to RFC 8060, which is experimental.
So unless we move that one to standard track I would say that is the right type 
of RFC.


>
>   a)
>
>   The document defines usage of the Type value 255.
>
>   b)
>
>   Section 3 says:
>
>  "If a LISP device receives a LISP message containing a Vendor Specific
>   LCAF with an OUI that it does not understand, it MUST drop the
>   message and it SHOULD create a log message."
>
>   This sounds like an update to LISP.
>

Excellent point. Actually this document updates RFC 8060, and this should be 
stated in the document.


>   c)
>
>   Section 3 defines new header fields.
>
> Minor issues:
>
> N/A
>
> Nits/editorial comments:
>
> Q2:
>
> Section 1 says:
>
>   “The Vendor Specific LCAF allows organizations to create
>   LCAF addresses to be used only internally on particular LISP
>   deployments.”
>
> Is “allows” the best wording? Where organizations previously disallowed to do
> this?
>
> Would it be more correct to say “defines how organizations can create…”?

Yes, this wording is more correct.

Ciao

L.




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

Re: [Gen-art] Genart last call review of draft-ietf-lisp-vendor-lcaf-09

[Luigi Iannone]

Hi Christer,

Thanks for the review.

As a shepherd I have a couple of comments inline.

> On 11 Apr 2022, at 22:35, Christer Holmberg via Datatracker 
>  wrote:
> 
> Reviewer: Christer Holmberg
> Review result: Ready with Issues
> 
> 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
> 
> .
> 
> Document: draft-ietf-lisp-vendor-lcaf-09
> Reviewer: Christer Holmberg
> Review Date: 2022-04-11
> IETF LC End Date: 2022-04-12
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> The document is well written, and easy to read and understand. However, I do
> have a couple of issues.
> 
> Major issues:
> 
> Q1:
> 
> I do wonder why the document is published as Experimental, however, due to the
> following reasons:

It is experimental because is an update to RFC 8060, which is experimental.
So unless we move that one to standard track I would say that is the right type 
of RFC.


> 
>   a)
> 
>   The document defines usage of the Type value 255.
> 
>   b)
> 
>   Section 3 says:
> 
>  "If a LISP device receives a LISP message containing a Vendor Specific
>   LCAF with an OUI that it does not understand, it MUST drop the
>   message and it SHOULD create a log message."
> 
>   This sounds like an update to LISP.
> 

Excellent point. Actually this document updates RFC 8060, and this should be 
stated in the document.


>   c)
> 
>   Section 3 defines new header fields.
> 
> Minor issues:
> 
> N/A
> 
> Nits/editorial comments:
> 
> Q2:
> 
> Section 1 says:
> 
>   “The Vendor Specific LCAF allows organizations to create
>   LCAF addresses to be used only internally on particular LISP
>   deployments.”
> 
> Is “allows” the best wording? Where organizations previously disallowed to do
> this?
> 
> Would it be more correct to say “defines how organizations can create…”?

Yes, this wording is more correct.

Ciao

L.




> 
> 
> 

___
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