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

["Roni Even" <[e-mail]>]

Hi Loa,
See inline
Roni

> -----Original Message-----
> From: Loa Andersson [mailto:[e-mail]]
> Sent: 28 August, 2013 5:20 PM
> To: Roni Even
> Cc: [e-mail];
gen-
> [e-mail]; [e-mail]
> Subject: Re: Gen-ART LC review of
draft-ietf-mpls-return-path-specified-lsp-
> ping-12
> 
> Roni,
> 
> Thanks for an insightful review, you have captured much of what we been
> struggling with when it comes to the IANA allocations.
> 
> On 2013-08-28 15:06, Roni Even wrote:
> > 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
> > 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.
> 
> Yes the document says "Directly copied from TLV Type 1, MUST NOT be
> assigned" the intention is that this applies to future sub-TLVs also.
> I guess it could be changed to "Directly copied from TLV Type 1 (including
> future allocations for TLV Type 1, MUST NOT be assigned"
> if that makes thing clearer.
> 
> >     This should be clear, and if there is some
> >     relation I think it should be reflected in the IANA registry for TLV
> >     type 1
> 
> I guess that makes sense - but it has not been the what we've done earlier
- I
> think we could add this where needed by directly communicate  this to
IANA.


[Roni Even] I think that the directive for future allocation must be clear
both in the IANA registry and the document for example look at
http://tools.ietf.org/html/rfc6426#section-7.3 
I also think that is this case this document updates RFC4379 .

> 
> >  2. For the vendor or private use why a difference policy than the rest
> >     of the sub-TLV registry
> 
> We don't assign vendor private use at all, so by default it is different.
I don't
> see that it could be different.> 
[Roni Even] RFC4379 says 
"If a TLV or sub-TLV has a Type that falls in the range for Vendor
   Private Use, the Length MUST be at least 4, and the first four octets
   MUST be that vendor's SMI Private Enterprise Number, in network octet
   order.  The rest of the Value field is private to the vendor."

> /Loa
> >
> > Nits/editorial comments:
> >
> >  1. In section 3.4 I assume that "TC" is traffic class. It will be good
> >     to expand and have reference.
> >
> 
> --
> 
> 
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Huawei Technologies (consultant)     phone: [phone]