HI, I do not follow all the MPLS work, this Gen-ART review is done during the IETF LC. I would think that your point should have been discussed in the WG before sending the return path ping to publication. BTW: I took a quick look at draft-andersson-mpls-lsp-ping-upd-00 third paragraph of section 2 and I am not sure that the return path ping is influenced since it does not use all the sub-tlv from tlv type 1 so it should be a separate registry Roni > -----Original Message----- > From: t.p. [mailto:daedulus@xxxxxxxxxxxxx] > Sent: 29 August, 2013 6:33 PM > To: Roni Even; draft-ietf-mpls-return-path-specified-lsp- > ping.all@xxxxxxxxxxxxxx > Cc: gen-art@xxxxxxxx; ietf@xxxxxxxx > Subject: Re: Gen-ART LC review ofdraft-ietf-mpls-return-path-specified-lsp- > ping-12 > > Roni > > I find it difficult to know whether to agree with you or not since there is > another "gorilla" operating in this namespace, namely > draft-andersson-mpls-lsp-ping-upd-00 > which sort of gives the option of taking out the sub-TLV types of a TLV Type > into a separate registry which can then be referenced by the specifications of > several TLV Types. This I-D formally calls for no action by IANA, except that it > implies a reorganisation of the registries which IANA might well already have > executed - certainly, the registries no longer look the same as they did a few > months ago although that might also be a coincidence. > > You make reference to the registry set up by RFC6426 but you should be > aware that what is now in the IANA registries is not what was there when > that RFC was approved; rather, it has changed as alluded to above.. > > If > draft-andersson-mpls-lsp-ping-upd-00 > is approved, and my perception is that IANA assumes it has been, then this, > return-path I-D would appear to be barking up the wrong tree and needs > revising to reflect the new IANA structure, namely that it needs to update > the title which already exists Sub-TLVs for TLV Types 1 and 16 to become Sub- > TLVs for TLV Types 1 and 16 and 21 whereupon things start to fall into place > > draft-andersson-mpls-lsp-ping-upd-00 > also updates RFC4379 which, if accepted, means, I think, that this I-D need > not. > > All very technically sound but we seem to have our processes upside down. > > There is of course a lengthy history to this that is not material to the current > discussion. > > Tom Petch > > ----- Original Message ----- > From: "Roni Even" <ron.even.tlv@xxxxxxxxx> > To: "'Mach Chen'" <mach.chen@xxxxxxxxxx>; <draft-ietf-mpls-return-path- > specified-lsp-ping.all@xxxxxxxxxxxxxx> > Cc: <gen-art@xxxxxxxx>; <ietf@xxxxxxxx> > Sent: Thursday, August 29, 2013 11:24 AM > Subject: RE: Gen-ART LC review > ofdraft-ietf-mpls-return-path-specified-lsp-ping-12 > > > > 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 > > > >