Re: [Gen-art] Post-Telechat update (was Re: Gen-art LC review of draft-ietf-mpls-rfc4379bis-07)

[BRUNGARD, DEBORAH A]

Hi Elwyn,

Much thanks for all you help with this document!
All the best-
Deborah


From: Elwyn Davies [mailto:elw...@dial.pipex.com]
Sent: Sunday, October 30, 2016 8:10 PM
To: Carlos Pignataro (cpignata) <cpign...@cisco.com>
Cc: General area reviewing team <gen-art@ietf.org>; 
draft-ietf-mpls-rfc4379bis@ietf.org; BRUNGARD, DEBORAH A <db3...@att.com>
Subject: Re: Post-Telechat update (was Re: Gen-art LC review of 
draft-ietf-mpls-rfc4379bis-07)

Hi Carlos.

So I think we are done here. Thanks for doing the last couple of changes.

I won't press you any further on the SHOULD front if everybody else is happy.

As a matter of general principle, I (and my fellow gen-arters) tend to be 
fairly heavy on SHOULDs and MAYs.  Personally, I always ask myself several 
questions when I see a SHOULD (NOT) or MAY (NOT) (thinking primarily as a 
potential implementer):
- How do I test if the code ought to take the path other then specified in the 
SHOULD/MAY?
- If I do take the decision to go the other way, is it consistent with other 
things being done in the same message?
- Will I be able to correctly process the message at the receiver?
- Can I make an unambiguous deduction about the reason that the other path was 
taken when the message is received at the other end?

Clearly the code at the receiving end has to be able to accept both cases for 
interoperability, but the implementation needs to understand what meaning is 
associated with each of the cases.  I am uneasy about saying that a relaxed 
approach to SHOULDs etc. might cover 'unforeseen circumstances' because the 
receiving end may not understand what is being said since the circumstances 
were unforeseen.. that way lie hard to diagnose bugs I fear.
But If all parties are prepared to go with -09, then so be it.

Best wishes
Elwyn

BTW My 'weekends' are rather less well defined these days, being mostly 
retired.  Time to do what I(we) want occurs when I make it/want it!  But thanks 
for thinking of the precious weekend.  Oh, and many years ago, I had a job 
where the weekends were Thursday and Friday - had its advantages.  OTOH most 
Saturdays finished about 3am on Sunday. ;-)

/E

On 29/10/2016 04:26, Carlos Pignataro (cpignata) wrote:
Hi Elwyn,

Thanks! Please see inline.

Hi Jari, Deborah,

All major, minor, and nits/editorials (including these extra additional points) 
are now addressed.

On Oct 28, 2016, at 6:29 PM, Elwyn Davies 
<elw...@dial.pipex.com<mailto:elw...@dial.pipex.com>> wrote:

Hi Carlos,

:-)
Thanks for addressing the comments.  I have looked through -08 and there are a 
couple of extra points that I noticed - the s3.4 issue was effectively 
mentioned wrt s4.5 in my previous notes.

Anytime!

We addressed the major and the two minor issues, as that was the priority and 
what Jari recorded in the datatracker. We also did address the very vast 
majority of nits and editorials (a couple escaped), including some additional 
ones I found in editing.


Generally things are in good shape but there are some items that haven't been 
addressed or there is a quibble.

All addressed now — though “addressing” resulted in a no-change disposition in 
a couple instances.

Quibble fixed! :-)


If there is another version over the weekend I'll do my very best to check it 
before Monday.

I submitted a new revision -09, but *please* do not waste your precious weekend 
time on this. All issues are addressed, but if there is something we missed, it 
is within the mini-nit category. I don’t believe there’s any (naturally) but if 
there were, it can be addressed by the RFC Editor.

Enjoy your weekend!

More inline.


Regards,
Elwyn

Extra Points:
===

I Forgot to mention that there is lack of consistency in capitalisation of the 
message names: Personally I would go with Echo Request and Echo Reply 
throughout to make it clear that these are message names.

We’ll leave this capitalization one for the RFC Editor.


s3,4, para 1:


If the

   replying router is the destination (Label Edge Router) of the FEC,

   then a Downstream Detailed Mapping TLV SHOULD NOT be included in the

   MPLS echo reply.  Otherwise, the replying router SHOULD include a

   Downstream Detailed Mapping object for each interface over which this

   FEC could be forwarded.
I suspect that the SHOULD NOT ought to be MUST NOT.  Otherwise it needs an 
explanation of the circumstances in which the DDMAP TLV could be included.  
Similarly, the SHOULD needs to explain in what circumstances you wouldn't 
include one or more DDMAP TLVs.

If you ask me, personally, I’d say: use MUST / MUST NOT as sparingly as 
possible, only when interop is affected. Additionally, not every SHOULD / 
SHOULD NOT needs to explain the exceptional case.

It is perfectly OK to say that the SHOULD (NOT) is to cover for unforeseen 
circumstances, for future ideas, etc.

Consequently, no change regarding this.



s6.2.3: The Unassigned row should have a blank reference.

Re: [Gen-art] Post-Telechat update (was Re: Gen-art LC review of draft-ietf-mpls-rfc4379bis-07)

[Carlos Pignataro (cpignata)]

Hi Elwyn,

Thanks! Please see inline.

Hi Jari, Deborah,

All major, minor, and nits/editorials (including these extra additional points) 
are now addressed.

On Oct 28, 2016, at 6:29 PM, Elwyn Davies 
> wrote:

Hi Carlos,

:-)
Thanks for addressing the comments.  I have looked through -08 and there are a 
couple of extra points that I noticed - the s3.4 issue was effectively 
mentioned wrt s4.5 in my previous notes.


Anytime!

We addressed the major and the two minor issues, as that was the priority and 
what Jari recorded in the datatracker. We also did address the very vast 
majority of nits and editorials (a couple escaped), including some additional 
ones I found in editing.

Generally things are in good shape but there are some items that haven't been 
addressed or there is a quibble.


All addressed now — though “addressing” resulted in a no-change disposition in 
a couple instances.

Quibble fixed! :-)

If there is another version over the weekend I'll do my very best to check it 
before Monday.


I submitted a new revision -09, but *please* do not waste your precious weekend 
time on this. All issues are addressed, but if there is something we missed, it 
is within the mini-nit category. I don’t believe there’s any (naturally) but if 
there were, it can be addressed by the RFC Editor.

Enjoy your weekend!

More inline.

Regards,
Elwyn

Extra Points:
===

I Forgot to mention that there is lack of consistency in capitalisation of the 
message names: Personally I would go with Echo Request and Echo Reply 
throughout to make it clear that these are message names.


We’ll leave this capitalization one for the RFC Editor.

s3,4, para 1:

If the
   replying router is the destination (Label Edge Router) of the FEC,
   then a Downstream Detailed Mapping TLV SHOULD NOT be included in the
   MPLS echo reply.  Otherwise, the replying router SHOULD include a
   Downstream Detailed Mapping object for each interface over which this
   FEC could be forwarded.

I suspect that the SHOULD NOT ought to be MUST NOT.  Otherwise it needs an 
explanation of the circumstances in which the DDMAP TLV could be included.  
Similarly, the SHOULD needs to explain in what circumstances you wouldn't 
include one or more DDMAP TLVs.

If you ask me, personally, I’d say: use MUST / MUST NOT as sparingly as 
possible, only when interop is affected. Additionally, not every SHOULD / 
SHOULD NOT needs to explain the exceptional case.

It is perfectly OK to say that the SHOULD (NOT) is to cover for unforeseen 
circumstances, for future ideas, etc.

Consequently, no change regarding this.


s6.2.3: The Unassigned row should have a blank reference.


No. Because “Unassigned” comes with an Assignment criteria which is given in 
this document. Left as-is, as with all other Unassigned.

On 28/10/2016 02:29, Carlos Pignataro (cpignata) wrote:
Deal Elwyn,

Many thanks for a great review!

I just finished addressing all your comments: the major issue (easy to address, 
editorial fix, but with important implications), the minors, and all the nits. 
Surprisingly, I found a few small additional editorials, which I fixed as well.

Rev -08 would address all outstanding issues, from this review, Mirja, and a 
couple others.

Please see inline for a line-by-line set of responses.

On Oct 20, 2016, at 4:42 PM, Elwyn Davies 
> wrote:

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-rfc4379bis-07.txt
Reviewer: Elwyn Davies
Review Date: 2016/10/21
IETF LC End Date: 2016/10/18
IESG Telechat date: (if known) -

Summary: Not ready.  There is one major issue (already notified to authors and 
agreed as an issue) and a considerable number of minor and editorial issues. I 
have worked through the various RFCs and errata that are subsumed into the new 
version and almost everything has been correctly translated AFAICS.  A couple 
of minor points are covered in the comments.

Major issues:

s3.4: A number of items that are used in the normative Downstream Detailed 
Mapping TLV were originally defined in s3.3 (Downstream Mapping TLV format) but 
have been shifted to Appendix A.2.  This appendix is marked as non-normative.  
Thus there are now no normative definitions for the various TLVs used in s3.4 
that are defined in A.2.  I fear that these need to be returned to the 
normative part of the specification.


This is an excellent catch. Thank you. The fix is simple and purely editorial 
but the implication is clear.

I finished addressing this, which you will see posted as 

[Gen-art] Post-Telechat update (was Re: Gen-art LC review of draft-ietf-mpls-rfc4379bis-07)

[Elwyn Davies]

Hi Carlos,

:-)
Thanks for addressing the comments.  I have looked through -08 and there 
are a couple of extra points that I noticed - the s3.4 issue was 
effectively mentioned wrt s4.5 in my previous notes.


Generally things are in good shape but there are some items that haven't 
been addressed or there is a quibble.


If there is another version over the weekend I'll do my very best to 
check it before Monday.


Regards,
Elwyn

Extra Points:
===

I Forgot to mention that there is lack of consistency in capitalisation 
of the message names: Personally I would go with Echo Request and Echo 
Reply throughout to make it clear that these are message names.


s3,4, para 1:

If the
replying router is the destination (Label Edge Router) of the FEC,
then a Downstream Detailed Mapping TLV SHOULD NOT be included in the
MPLS echo reply.  Otherwise, the replying router SHOULD include a
Downstream Detailed Mapping object for each interface over which this
FEC could be forwarded.
I suspect that the SHOULD NOT ought to be MUST NOT.  Otherwise it needs 
an explanation of the circumstances in which the DDMAP TLV could be 
included.  Similarly, the SHOULD needs to explain in what circumstances 
you wouldn't include one or more DDMAP TLVs.


s6.2.3: The Unassigned row should have a blank reference.

On 28/10/2016 02:29, Carlos Pignataro (cpignata) wrote:

Deal Elwyn,

Many thanks for a great review!

I just finished addressing all your comments: the major issue (easy to 
address, editorial fix, but with important implications), the minors, 
and all the nits. Surprisingly, I found a few small additional 
editorials, which I fixed as well.


Rev -08 would address all outstanding issues, from this review, Mirja, 
and a couple others.


Please see inline for a line-by-line set of responses.

On Oct 20, 2016, at 4:42 PM, Elwyn Davies > wrote:


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-rfc4379bis-07.txt
Reviewer: Elwyn Davies
Review Date: 2016/10/21
IETF LC End Date: 2016/10/18
IESG Telechat date: (if known) -

Summary: Not ready.  There is one major issue (already notified to 
authors and agreed as an issue) and a considerable number of minor 
and editorial issues. I have worked through the various RFCs and 
errata that are subsumed into the new version and almost everything 
has been correctly translated AFAICS.  A couple of minor points are 
covered in the comments.


Major issues:

s3.4: A number of items that are used in the normative Downstream 
Detailed Mapping TLV were originally defined in s3.3 (Downstream 
Mapping TLV format) but have been shifted to Appendix A.2.  This 
appendix is marked as non-normative.  Thus there are now no normative 
definitions for the various TLVs used in s3.4 that are defined in 
A.2.  I fear that these need to be returned to the normative part of 
the specification.




This is an excellent catch. Thank you. The fix is simple and purely 
editorial but the implication is clear.


I finished addressing this, which you will see posted as the new 
revision. I am super happy with the outcome.

Looks good to me!


[I think it would be simplest and least error prone to swap the text 
that was in s3.3 of RFC 4379 back out of A.2 and put backward 
references to the new s3.4 into A.2 as necessary.]


Minor issues:

Sender/receiver terminology: The document can be somewhat confusing 
to a naive reader.  Sender and receiver are used in multiple 
contexts.  Where the context appears to relate to LSP ping, both 
senders and receivers are involved in sending LSP ping packets.  In 
general, sender and receiver appear to imply sending and receiving of 
Echo Request messages with their roles reversed with respect to Echo 
Responses, with the receiver stimulated to send an Echo Response by 
receiving an Echo Request.  It would help if this terminology and 
usage was explicitly set out early in the document. Additionally, 
some instances would be made more comprehensible by making the 
function explicit in the text e.g., in the operation of return codes.


Re-reading after fixing all the nits below, which include some sender 
clarifications, looks good.
There is one place (s3.1, para 1) where I think it could be made 
clearer.  Adding a few words to that section will help overall as well 
as just in that section.




s1.4/s3/s6.2.3: The R (Global) flag is defined in RFC 6426.  
Unfortunately it isn't in the IANA considerations there as was 
spotted in RFC Erratum 4012.  Might be worth mentioning the erratum 
(probably in s1.4?)  Alternatively this document can be made to 
provide the