Hi, I am not sure you responded to my latest email. Having the policy for TLV type 1 here is not enough in my view since I only look at RFC4379 and create a new TLV type I will not know that I have to register it also for the type 21 if it will not be mentioned As for the vendor specific see my other email Roni > -----Original Message----- > From: Mach Chen [mailto:mach.chen@xxxxxxxxxx] > Sent: 29 August, 2013 11:33 AM > To: Roni Even; draft-ietf-mpls-return-path-specified-lsp- > ping.all@xxxxxxxxxxxxxx > Cc: ietf@xxxxxxxx; gen-art@xxxxxxxx > Subject: RE: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp- > ping-12 > > Hi Roni, > > Thanks for your detailed review and comments! > > Please see my reply inline... > > > From: Roni Even [mailto:ron.even.tlv@xxxxxxxxx] > > Sent: Wednesday, August 28, 2013 9:06 PM > > To: draft-ietf-mpls-return-path-specified-lsp-ping.all@xxxxxxxxxxxxxx > > Cc: ietf@xxxxxxxx; gen-art@xxxxxxxx > > 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