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

[Mach Chen <[e-mail]>]

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:[e-mail]]
> Sent: Thursday, August 29, 2013 5:21 PM
> To: Mach Chen; [e-mail]
> Cc: [e-mail]; [e-mail]
> 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:[e-mail]]
> > Sent: 29 August, 2013 11:33 AM
> > To: Roni Even; draft-ietf-mpls-return-path-specified-lsp-
> > [e-mail]
> > Cc: [e-mail]; [e-mail]
> > 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:[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