RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12

[Mach Chen <[e-mail]>]

Hi Roni,

Thanks for your detailed review and comments!

Please see my reply inline...

> From: Roni Even [mailto:[e-mail]]
> Sent: Wednesday, August 28, 2013 9:06 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Gen-ART LC review of 
> draft-ietf-mpls-return-path-specified-lsp-ping-12
> 
> 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-mpls-return-path-specified-lsp-ping-12
> Reviewer: Roni Even
> Review Date:2013-8-28
> IETF LC End Date: 2013-9-4
> IESG Telechat date:
> 
> Summary: This draft is almost ready for publication as a standard track RFC.
> 
> 
> Major issues:
> Minor issues:
> I am not clear on the sub-TLV in section 6.2 1. If a new sub-TLV is 
> defined for TLV type 1 do they need also to be added to TLV type 21. 
> This should be clear, and if there is some relation I think it should 
> be reflected in the IANA registry for TLV type 1

Yes, type 21 TLV intends to reuse existing and future defined sub-TLVs for type TLV 1. And in Section 3.3, it has already stated this, it says:

"The Target FEC sub-TLVs defined in [RFC4379] provide a good way to
   identify a specific return path.  The Reply Path TLV can carry any
   sub-TLV defined for use in the Target FEC Stack TLV that can be
   registered."

So, for Section 6.2, to make it cleaner and more explicit, how about this change:

Old:

" No assignments of sub-TLVs in the range of 0-16383 and 32768-49161
   are made directly for TLV Type 21, sub-TLVs in these ranges are
   copied from the assignments made for TLV Type 1. Assignments of sub-..."

New:

" No assignments of sub-TLVs in the range of 0-16383 and 32768-49161
   are made directly for TLV Type 21, sub-TLVs in these ranges are
   copied from the assignments (including existing and future allocations)
   made for TLV Type 1. Assignments of sub-..."


> 2. For the vendor or private use why a difference policy than the rest 
> of the sub-TLV registry

This document does not make any changes to the "Vendor and Private use" definition, range and policy as defined in RFC4379. In RFC4379, it's policy is defined different from other ranges. 

> 
> Nits/editorial comments:
> 1. In section 3.4 I assume that "TC" is traffic class. It will be good 
> to expand and have reference.

OK, will fix it when all last call comments received.

Best regards,
Mach