Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-08

[stephane.litkowski]

Thanks.

I will take care of your comments as part of the next revision.


-Original Message-
From: Dan Romascanu [mailto:droma...@gmail.com] 
Sent: Tuesday, December 11, 2018 15:29
To: gen-art@ietf.org
Cc: draft-ietf-rtgwg-spf-uloop-pb-statement@ietf.org; i...@ietf.org; 
rt...@ietf.org; droma...@gmail.com
Subject: Genart last call review of draft-ietf-rtgwg-spf-uloop-pb-statement-08

Reviewer: Dan Romascanu
Review result: Ready with Nits

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-rtgwg-spf-uloop-pb-statement-08
Reviewer: Dan Romascanu
Review Date: 2018-12-11
IETF LC End Date: 2018-12-18
IESG Telechat date: Not scheduled for a telechat

Summary:

Ready

This document analyzes the impact of using non-standardized IGP Link State
implementations resulting in non-consistent tuning of parameters in the network
and increased possibility of creating micro-loops. It can be viewed as a
problem statement for standardized solutions like RFC 8405.

The document is short and clear for implementers and operators familiar with
networks running this class of protocols. Diagrams and table help in reading
and understanding the material.

Major issues:

none

Minor issues:

none

Nits/editorial comments:

1. In the introduction:

> For non standardized timers, implementations are free to implement it
   in any way.

It is not obvious what 'it' means. I guess it's about different values of
timers resulting in the possibility of micro-loops creation, but it would be
better to clarify.

2. It would be useful to provide short explanations that make the figures more
clear. In fig. 1 - what do the nodes represent (routers implementing the
protocols), in fig. 2, and 3 - the abbreviations on the y axis



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

[Gen-art] Genart last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05

[Christer Holmberg]

Reviewer: Christer Holmberg
Review result: Ready

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-mpls-lsp-ping-lag-multipath-05
Reviewer: Christer Holmberg
Review Date: 2018-12-18
IETF LC End Date: 2018-12-11
IESG Telechat date: Not scheduled for a telechat

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

Major issues:None

Minor issues: None

Nits/editorial comments: None


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

Re: [Gen-art] Genart telechat review of draft-ietf-ntp-bcp-10

[Alissa Cooper]

Robert, thanks for your reviews of this document. I’ve flagged some of your 
specific comments in my ballot. I entered a DISCUSS ballot to ensure that RFC 
2119 and RFC 8174 get changed to normative references.

Thanks,
Alissa

> On Dec 13, 2018, at 6:12 PM, Robert Sparks  wrote:
> 
> Reviewer: Robert Sparks
> Review result: Ready with Nits
> 
> 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 wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-ntp-bcp-10
> Reviewer: Robert Sparks
> Review Date: 2018-12-13
> IETF LC End Date: 2018-10-08
> IESG Telechat date: 2018-12-20
> 
> Summary: Ready (but with nits that should be considered) for publication as a
> BCP RFC
> 
> Nits/editorial comments:
> 
> With a couple of exceptions, the changes between -07 and -10 are very helpful 
> -
> the document reads much more naturally.
> 
> One of the changes was to be more specific with actors - many uses of "you" or
> "your" were replaced with "the operator" for example. But this wasn't done
> throughout the document ("you" and "your" still appear frequently), and in at
> least one place the change caused a sentence to stop making sense: "If the 
> time
> on your network has to be correct close to 100% of the time, then even if you
> are using a satellite-based system, operators need to plan for those rare
> instances when the system is unavailable (or wrong!)."
> 
> I strongly encourage yet another pass focusing on removing "you" and "your" to
> the extent possible.
> 
> The changes also included using 2119 keywords much more often. Unfortunately
> many of the new uses are not appropriate. "Vendors MUST" and several instances
> of "It is RECOMMENDED" are particularly jarring. Moving 2119 to be an
> Informational reference is also incorrect if you are going to use those terms
> in this document.
> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
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-wilde-service-link-rel-06

[Alissa Cooper]

Peter, thanks for your review. Erik, thanks for the updates. I have entered a 
No Objection ballot.

Alissa

> On Nov 20, 2018, at 4:06 PM, Erik Wilde  wrote:
> 
> hello.
> 
> thanks, peter, for your review!
> 
> On 2018-11-20 17:21, Peter Yee wrote:
>> Page 8, Section 7: RFC 2223 requires you do more than provide an ellipsis 
>> here.
>>  You might want to consider what makes sense.  Perhaps a discussion of what
>> happens to a client that obtains a maliciously formatted service-desc or even
>> an errant service-desc.  While a human might be able to see through problems 
>> in
>> a "service-doc", it's quite possible that a machine will want to take
>> precautions about handling the received data and acting upon it.
> 
> thanks for the suggestion! 
> https://github.com/dret/I-D/commit/3f065e662ccd66419c92246a2bba9bd8c5127ade 
> adds security considerations.
> 
>> Nits/editorial comments:
>> Page 1, Note to Readers: Presumably this section will be removed prior to
>> publication.
> 
> done in 
> https://github.com/dret/I-D/commit/f5e8c10f4a9400d55a867d64b8aef9846ae4106b
> 
>> Page 3, 4th full paragraph, 1st sentence: Delete the comma after 
>> "consumption"
>> and delete the "for" following that.
>> Page 5, Section 3.3, 1st paragraph, 1st section: change "of" to "between".  
>> Put
>> the section references in parentheses.
>> Page 5, Section 3.3, 1st paragraph, 2nd sentence: insert "a" before "better".
> 
> addressed in 
> https://github.com/dret/I-D/commit/cc902371fff59b96d3185e643522fe8f1462d042
> 
> i think with these changes in the draft i have addressed the comments in this 
> review. i have posted a new version of the draft that includes the changes 
> mentioned here.
> 
> https://tools.ietf.org/html/draft-wilde-service-link-rel-07
> 
> thanks again and kind regards,
> 
> dret.
> 
> -- 
> erik wilde | mailto:erik.wi...@dret.net |
>   | http://dret.net/netdret|
>   | http://twitter.com/dret|
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

Re: [Gen-art] [mpls] Genart last call review of draft-ietf-mpls-rsvp-shared-labels-06

[Alissa Cooper]

Russ, thanks for your review. Vishnu, thanks for your responses. I entered a No 
Objection ballot.

Alissa

> On Dec 10, 2018, at 4:49 PM, Russ Housley  wrote:
> 
> Yes, those changes resolve my comments.
> 
> Russ
> 
> 
>> On Dec 10, 2018, at 12:57 AM, Vishnu Pavan Beeram > > wrote:
>> 
>> Russ, Hi!
>> 
>> Much Thanks for the review! We just posted a new rev (-07) to address your 
>> comments. Please do go through the diffs 
>> (https://tools.ietf.org/rfcdiff?url2=draft-ietf-mpls-rsvp-shared-labels-07.txt
>>  
>> )
>>  and let us know if the new version adequately addresses your concern. 
>> 
>> The term "loose hop" was introduced in RFC3209. So we just added a reference 
>> to it in the relevant sentence.
>> 
>> Regards,
>> -Pavan (on behalf of the authors)
>> 
>> On Fri, Nov 30, 2018 at 1:29 PM Russ Housley > > wrote:
>> Reviewer: Russ Housley
>> Review result: Ready
>> 
>> 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-mpls-rsvp-shared-labels-06
>> Reviewer: Russ Housley
>> Review Date: 2018-11-30
>> IETF LC End Date: 2018-12-11 
>> IESG Telechat date: unknown
>> 
>> Summary: Ready
>> 
>> 
>> Major Concerns:
>> 
>> None
>> 
>> 
>> Minor Concerns:
>> 
>> Section 5.3: To understand this section, I had to learn about "loose
>> hops" from other sources.  Please consider adding this term to the ones
>> that are defined in Section 2.
>> 
>> 
>> Nits:
>> 
>> Throughout document: s/hop by hop/hop-by-hop/
>> 
>> Section 5.3.1: s/The net result is that by/As a result, by/
>> 
>> ___
>> mpls mailing list
>> m...@ietf.org 
>> https://www.ietf.org/mailman/listinfo/mpls 
>> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
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-wilde-sunset-header-07

[Alissa Cooper]

Jari, thank you for your review. Erik, thanks for the updates. I entered a No 
Objection ballot.

Alissa

> On Nov 30, 2018, at 1:17 AM, Jari Arkko  wrote:
> 
> Sounds good. Thanks.
> 
> Jari
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

Re: [Gen-art] [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

Mohmad to comment.

Dino

> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern  wrote:
> 
> That is the other fix he offered.  Just remove the updates tag.
> I will leav eit to you and the the authors to determine which is correct.
> Yours,
> Joel
> 
> On 12/18/18 11:43 PM, Dino Farinacci wrote:
>> 8113bis should say that is it *extending* the type field so we can have more 
>> types. The word “update” I always had a problem with because it can be 
>> interpreted as “replacing". Replacing something to fix a problem.
>> 8113 is simply asking for one of the type value codepoint, so there can be 
>> another format to have more types.
>> Dino
>>> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern  wrote:
>>> 
>>> Authors: that sounds like a reasonable addition to me?
>>> 
>>> Yours,
>>> Joel
>>> 
>>> On 12/18/18 10:48 PM, Brian E Carpenter wrote:
 On 2018-12-19 15:46, Joel M. Halpern wrote:
> This is part of the package to move the coherent set of base LISP specs
> to PS.
> 
> The reason we did this rather than folding it into 6830bis / 6833bis is
> that we had originally simply cited 8113, and then realized that needed
> to move to PS along with everything else.  It seemed (and is) simpler to
> do it separately rather than to further modify 6830bis / 6933bis.
> 
> As for why it updates 6833bis, that is because one of the cahnges in
> moving the set to PS was to improve the split as to which information
> belonged in which document.
 OK, but I still don't find it logical The text doesn't explain which part 
 of
 6833bis is impacted, and normally these days we require such an 
 explanation.
 And if there is an impact, you're missing the opportunity of fixing the 
 error
 or gap in 6833bis, so the reader of 6833bis will be none the wiser unless
 you insert a reference to 8113bis.
 On the other hand, if there is no error or gap, you don't need "Updates:"
 at all. (Unfortunately, we don't have an "Extends:" header.)
Brian
> 
> Yours,
> Joel
> 
> On 12/18/18 9:25 PM, Brian Carpenter wrote:
>> Reviewer: Brian Carpenter
>> Review result: Ready with Issues
>> 
>> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01
>> 
>> 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-rfc8113bis-01.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2018-12-19
>> IETF LC End Date: 2018-12-27
>> IESG Telechat date:
>> 
>> Summary: Ready with issues
>> 
>> 
>> Comments:
>> -
>> 
>> I note that this is being raised from Experimental to the standards 
>> track.
>> Presumably that depends on the base LISP spec becoming PS.
>> 
>> Minor issues:
>> -
>> 
>> "This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
>> explain which text is updated. This is in contrast to RFC8113, which
>> explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
>> this draft claim to update rfc6830bis? I'm going to assume that
>> is an error.
>> 
>> In fact, why wasn't the definition of the LISP Packet Types registry
>> moved into the base spec (rfc6830bis)? That is where it belongs.
>> 
>> Since rfc6830bis (and rfc6833bis) are still under IESG review, anything
>> in them that needs updating should be updated! The fact is that 
>> rfc8113bis
>> extends rfc6830bis, which is not the same thing as "updates".
>> If the WG thinks that implementers of 6830bis need to read 8113bis,
>> there should be a normative reference in 6830bis to 8113bis.
>> 
>> 
> 
>>> 
>>> ___
>>> lisp mailing list
>>> l...@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp

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

Re: [Gen-art] [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

8113bis should say that is it *extending* the type field so we can have more 
types. The word “update” I always had a problem with because it can be 
interpreted as “replacing". Replacing something to fix a problem. 

8113 is simply asking for one of the type value codepoint, so there can be 
another format to have more types.

Dino

> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern  wrote:
> 
> Authors: that sounds like a reasonable addition to me?
> 
> Yours,
> Joel
> 
> On 12/18/18 10:48 PM, Brian E Carpenter wrote:
>> On 2018-12-19 15:46, Joel M. Halpern wrote:
>>> This is part of the package to move the coherent set of base LISP specs
>>> to PS.
>>> 
>>> The reason we did this rather than folding it into 6830bis / 6833bis is
>>> that we had originally simply cited 8113, and then realized that needed
>>> to move to PS along with everything else.  It seemed (and is) simpler to
>>> do it separately rather than to further modify 6830bis / 6933bis.
>>> 
>>> As for why it updates 6833bis, that is because one of the cahnges in
>>> moving the set to PS was to improve the split as to which information
>>> belonged in which document.
>> OK, but I still don't find it logical The text doesn't explain which part of
>> 6833bis is impacted, and normally these days we require such an explanation.
>> And if there is an impact, you're missing the opportunity of fixing the error
>> or gap in 6833bis, so the reader of 6833bis will be none the wiser unless
>> you insert a reference to 8113bis.
>> On the other hand, if there is no error or gap, you don't need "Updates:"
>> at all. (Unfortunately, we don't have an "Extends:" header.)
>>Brian
>>> 
>>> Yours,
>>> Joel
>>> 
>>> On 12/18/18 9:25 PM, Brian Carpenter wrote:
 Reviewer: Brian Carpenter
 Review result: Ready with Issues
 
 Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01
 
 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-rfc8113bis-01.txt
 Reviewer: Brian Carpenter
 Review Date: 2018-12-19
 IETF LC End Date: 2018-12-27
 IESG Telechat date:
 
 Summary: Ready with issues
 
 
 Comments:
 -
 
 I note that this is being raised from Experimental to the standards track.
 Presumably that depends on the base LISP spec becoming PS.
 
 Minor issues:
 -
 
 "This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
 explain which text is updated. This is in contrast to RFC8113, which
 explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
 this draft claim to update rfc6830bis? I'm going to assume that
 is an error.
 
 In fact, why wasn't the definition of the LISP Packet Types registry
 moved into the base spec (rfc6830bis)? That is where it belongs.
 
 Since rfc6830bis (and rfc6833bis) are still under IESG review, anything
 in them that needs updating should be updated! The fact is that rfc8113bis
 extends rfc6830bis, which is not the same thing as "updates".
 If the WG thinks that implementers of 6830bis need to read 8113bis,
 there should be a normative reference in 6830bis to 8113bis.
 
 
>>> 
> 
> ___
> lisp mailing list
> l...@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

___
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-rfc8113bis-01

[Joel M. Halpern]

Authors: that sounds like a reasonable addition to me?

Yours,
Joel

On 12/18/18 10:48 PM, Brian E Carpenter wrote:

On 2018-12-19 15:46, Joel M. Halpern wrote:

This is part of the package to move the coherent set of base LISP specs
to PS.

The reason we did this rather than folding it into 6830bis / 6833bis is
that we had originally simply cited 8113, and then realized that needed
to move to PS along with everything else.  It seemed (and is) simpler to
do it separately rather than to further modify 6830bis / 6933bis.

As for why it updates 6833bis, that is because one of the cahnges in
moving the set to PS was to improve the split as to which information
belonged in which document.


OK, but I still don't find it logical The text doesn't explain which part of
6833bis is impacted, and normally these days we require such an explanation.
And if there is an impact, you're missing the opportunity of fixing the error
or gap in 6833bis, so the reader of 6833bis will be none the wiser unless
you insert a reference to 8113bis.

On the other hand, if there is no error or gap, you don't need "Updates:"
at all. (Unfortunately, we don't have an "Extends:" header.)

Brian



Yours,
Joel

On 12/18/18 9:25 PM, Brian Carpenter wrote:

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01

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-rfc8113bis-01.txt
Reviewer: Brian Carpenter
Review Date: 2018-12-19
IETF LC End Date: 2018-12-27
IESG Telechat date:

Summary: Ready with issues


Comments:
-

I note that this is being raised from Experimental to the standards track.
Presumably that depends on the base LISP spec becoming PS.

Minor issues:
-

"This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
explain which text is updated. This is in contrast to RFC8113, which
explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
this draft claim to update rfc6830bis? I'm going to assume that
is an error.

In fact, why wasn't the definition of the LISP Packet Types registry
moved into the base spec (rfc6830bis)? That is where it belongs.

Since rfc6830bis (and rfc6833bis) are still under IESG review, anything
in them that needs updating should be updated! The fact is that rfc8113bis
extends rfc6830bis, which is not the same thing as "updates".
If the WG thinks that implementers of 6830bis need to read 8113bis,
there should be a normative reference in 6830bis to 8113bis.








___
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-rfc8113bis-01

[Joel M. Halpern]

This is part of the package to move the coherent set of base LISP specs 
to PS.


The reason we did this rather than folding it into 6830bis / 6833bis is 
that we had originally simply cited 8113, and then realized that needed 
to move to PS along with everything else.  It seemed (and is) simpler to 
do it separately rather than to further modify 6830bis / 6933bis.


As for why it updates 6833bis, that is because one of the cahnges in 
moving the set to PS was to improve the split as to which information 
belonged in which document.


Yours,
Joel

On 12/18/18 9:25 PM, Brian Carpenter wrote:

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01

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-rfc8113bis-01.txt
Reviewer: Brian Carpenter
Review Date: 2018-12-19
IETF LC End Date: 2018-12-27
IESG Telechat date:

Summary: Ready with issues


Comments:
-

I note that this is being raised from Experimental to the standards track.
Presumably that depends on the base LISP spec becoming PS.

Minor issues:
-

"This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
explain which text is updated. This is in contrast to RFC8113, which
explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
this draft claim to update rfc6830bis? I'm going to assume that
is an error.

In fact, why wasn't the definition of the LISP Packet Types registry
moved into the base spec (rfc6830bis)? That is where it belongs.

Since rfc6830bis (and rfc6833bis) are still under IESG review, anything
in them that needs updating should be updated! The fact is that rfc8113bis
extends rfc6830bis, which is not the same thing as "updates".
If the WG thinks that implementers of 6830bis need to read 8113bis,
there should be a normative reference in 6830bis to 8113bis.




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

[Gen-art] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Brian Carpenter]

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01

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-rfc8113bis-01.txt
Reviewer: Brian Carpenter
Review Date: 2018-12-19
IETF LC End Date: 2018-12-27
IESG Telechat date: 

Summary: Ready with issues


Comments: 
-

I note that this is being raised from Experimental to the standards track. 
Presumably that depends on the base LISP spec becoming PS.

Minor issues:
-

"This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
explain which text is updated. This is in contrast to RFC8113, which
explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
this draft claim to update rfc6830bis? I'm going to assume that
is an error.

In fact, why wasn't the definition of the LISP Packet Types registry
moved into the base spec (rfc6830bis)? That is where it belongs.

Since rfc6830bis (and rfc6833bis) are still under IESG review, anything
in them that needs updating should be updated! The fact is that rfc8113bis
extends rfc6830bis, which is not the same thing as "updates".
If the WG thinks that implementers of 6830bis need to read 8113bis,
there should be a normative reference in 6830bis to 8113bis.

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

Re: [Gen-art] [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Joel M. Halpern]

That is the other fix he offered.  Just remove the updates tag.
I will leav eit to you and the the authors to determine which is correct.
Yours,
Joel

On 12/18/18 11:43 PM, Dino Farinacci wrote:

8113bis should say that is it *extending* the type field so we can have more types. 
The word “update” I always had a problem with because it can be interpreted as 
“replacing". Replacing something to fix a problem.

8113 is simply asking for one of the type value codepoint, so there can be 
another format to have more types.

Dino


On Dec 18, 2018, at 9:24 PM, Joel M. Halpern  wrote:

Authors: that sounds like a reasonable addition to me?

Yours,
Joel

On 12/18/18 10:48 PM, Brian E Carpenter wrote:

On 2018-12-19 15:46, Joel M. Halpern wrote:

This is part of the package to move the coherent set of base LISP specs
to PS.

The reason we did this rather than folding it into 6830bis / 6833bis is
that we had originally simply cited 8113, and then realized that needed
to move to PS along with everything else.  It seemed (and is) simpler to
do it separately rather than to further modify 6830bis / 6933bis.

As for why it updates 6833bis, that is because one of the cahnges in
moving the set to PS was to improve the split as to which information
belonged in which document.

OK, but I still don't find it logical The text doesn't explain which part of
6833bis is impacted, and normally these days we require such an explanation.
And if there is an impact, you're missing the opportunity of fixing the error
or gap in 6833bis, so the reader of 6833bis will be none the wiser unless
you insert a reference to 8113bis.
On the other hand, if there is no error or gap, you don't need "Updates:"
at all. (Unfortunately, we don't have an "Extends:" header.)
Brian


Yours,
Joel

On 12/18/18 9:25 PM, Brian Carpenter wrote:

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01

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-rfc8113bis-01.txt
Reviewer: Brian Carpenter
Review Date: 2018-12-19
IETF LC End Date: 2018-12-27
IESG Telechat date:

Summary: Ready with issues


Comments:
-

I note that this is being raised from Experimental to the standards track.
Presumably that depends on the base LISP spec becoming PS.

Minor issues:
-

"This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
explain which text is updated. This is in contrast to RFC8113, which
explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
this draft claim to update rfc6830bis? I'm going to assume that
is an error.

In fact, why wasn't the definition of the LISP Packet Types registry
moved into the base spec (rfc6830bis)? That is where it belongs.

Since rfc6830bis (and rfc6833bis) are still under IESG review, anything
in them that needs updating should be updated! The fact is that rfc8113bis
extends rfc6830bis, which is not the same thing as "updates".
If the WG thinks that implementers of 6830bis need to read 8113bis,
there should be a normative reference in 6830bis to 8113bis.






___
lisp mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lisp




___
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-rfc8113bis-01

[Brian E Carpenter]

On 2018-12-19 15:46, Joel M. Halpern wrote:
> This is part of the package to move the coherent set of base LISP specs 
> to PS.
> 
> The reason we did this rather than folding it into 6830bis / 6833bis is 
> that we had originally simply cited 8113, and then realized that needed 
> to move to PS along with everything else.  It seemed (and is) simpler to 
> do it separately rather than to further modify 6830bis / 6933bis.
> 
> As for why it updates 6833bis, that is because one of the cahnges in 
> moving the set to PS was to improve the split as to which information 
> belonged in which document.

OK, but I still don't find it logical The text doesn't explain which part of
6833bis is impacted, and normally these days we require such an explanation.
And if there is an impact, you're missing the opportunity of fixing the error
or gap in 6833bis, so the reader of 6833bis will be none the wiser unless
you insert a reference to 8113bis.

On the other hand, if there is no error or gap, you don't need "Updates:"
at all. (Unfortunately, we don't have an "Extends:" header.)

   Brian

> 
> Yours,
> Joel
> 
> On 12/18/18 9:25 PM, Brian Carpenter wrote:
>> Reviewer: Brian Carpenter
>> Review result: Ready with Issues
>>
>> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01
>>
>> 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-rfc8113bis-01.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2018-12-19
>> IETF LC End Date: 2018-12-27
>> IESG Telechat date:
>>
>> Summary: Ready with issues
>> 
>>
>> Comments:
>> -
>>
>> I note that this is being raised from Experimental to the standards track.
>> Presumably that depends on the base LISP spec becoming PS.
>>
>> Minor issues:
>> -
>>
>> "This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
>> explain which text is updated. This is in contrast to RFC8113, which
>> explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
>> this draft claim to update rfc6830bis? I'm going to assume that
>> is an error.
>>
>> In fact, why wasn't the definition of the LISP Packet Types registry
>> moved into the base spec (rfc6830bis)? That is where it belongs.
>>
>> Since rfc6830bis (and rfc6833bis) are still under IESG review, anything
>> in them that needs updating should be updated! The fact is that rfc8113bis
>> extends rfc6830bis, which is not the same thing as "updates".
>> If the WG thinks that implementers of 6830bis need to read 8113bis,
>> there should be a normative reference in 6830bis to 8113bis.
>>
>>
> 

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