Subject: [Gen-art] Gen-ART LC review of draft-ietf-mpls-return-path-specified-lsp-ping-12

From: "Roni Even" <[email-masked]>
Date: Wed, 28 Aug 2013 16:06:28 +0300

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
2.	For the vendor or private use why a difference policy than the rest
of the sub-TLV registry 

Nits/editorial comments:

1.	In section 3.4 I assume that "TC" is traffic class. It will be good
to expand and have reference.

---

From: Loa Andersson <[email-masked]>
Date: Wed, 28 Aug 2013 16:20:15 +0200

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:
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
>     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.

>  2. For the vendor or private use why a difference policy than the rest

We don't assign vendor private use at all, so by default it is
different. I don't see that it could be different.

/Loa
>
> Nits/editorial comments:
>
>  1. In section 3.4 I assume that “TC” is traffic class. It will be good

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Roni Even" <[email-masked]>
Date: Wed, 28 Aug 2013 18:22:52 +0300

Hi Loa,
See inline
Roni

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: 28 August, 2013 5:20 PM
> To: Roni Even
> Cc: [email-masked];
gen-
> [email-masked]; [email-masked]
> 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.
> 
> I guess it could be changed to "Directly copied from TLV Type 1 (including
> future allocations for TLV Type 1, MUST NOT be assigned"
> 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 .

> 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."