Hi, This is OK . I have no concerns Roni > -----Original Message----- > From: Loa Andersson [mailto:loa@xxxxx] > Sent: 29 August, 2013 2:46 PM > To: Roni Even > Cc: 'Mach Chen'; draft-ietf-mpls-return-path-specified-lsp- > ping.all@xxxxxxxxxxxxxx; gen-art@xxxxxxxx; ietf@xxxxxxxx > Subject: Re: Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp- > ping-12 > > Roni, > > tnx - the authors should add words in the IANA section requesting that IANA > add this the pointed in the registry; they normally do anyway, but writing it > down should not be a problem. > > As for "Vendor Private" RFC 4379 says: > > "Values from "Vendor Private" ranges MUST NOT be registered with IANA; > however, the message MUST contain an enterprise code as registered > with the IANA SMI Private Network Management Private Enterprise > Numbers. For each name space that has a Vendor Private range, it > must be specified where exactly the SMI Private Enterprise Number > resides; see below for examples. In this way, several enterprises > (vendors) can use the same code point without fear of collision." > > The way I read this is that the paragraph does two things (1) defines the > allocation policy (in this case that "vendor private" won't be assigned by > IANA) and (2) put a restriction on the "vendor private" > (sub-)TLVs; they must contain a "private enterprise number". > > Up to now I've thought the restriction on the format was global for all > "vendor private" sub-TLVs that are used by TLV for LSP Ping. > However we put words to the same effect in e.g. 6424, wo there is no reason > not to do it here also. A pointer to RFC4379 should be enough > e.g.: > > "For the vendor private sub-TLVs defined for this document, the same > allocation policies and requirement on the sub-TLV format that is specified > for vendor private sub-TLVs in RFC4379 [RFC4379] appliacable." > > Would that cover you concern? > > /Loa > > > > On 2013-08-29 12:24, Roni Even wrote: > > Hi, > > This text is OK if one wants to implement this draft. > > My concern was about the consistency of the IANA registration so that > > if someone defines a new TLV type 1 based on RFC4379, IANA will know > > that it must update also the registry for TLV type 21. If you see no > > such problem, I have no concerns Roni > > > >> -----Original Message----- > >> From: Mach Chen [mailto:mach.chen@xxxxxxxxxx] > >> Sent: 29 August, 2013 1:05 PM > >> 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, > >> > >> How about this: > >> > >> " 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 and kept the same > >> as that for TLV Type 1. All sub-TLVs in these ranges (include existing > >> and future defined) defined for TLV Type 1 apply to TLV Type 21. > >> Assignments of sub-..." > >> > >> Best regards, > >> Mach > >> > >>> -----Original Message----- > >>> From: Roni Even [mailto:ron.even.tlv@xxxxxxxxx] > >>> Sent: Thursday, August 29, 2013 5:21 PM > >>> To: Mach Chen; > >>> 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, > >>> 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 > > > > -- > > > Loa Andersson email: loa@xxxxxxxxxxxxxxxxx > Senior MPLS Expert loa@xxxxx > Huawei Technologies (consultant) phone: +46 739 81 21 64