Re: [Gen-art] Gen-ART Telechat Call review of draft-ietf-mpls-lsp-ping-registry-02

[Loa Andersson <[e-mail]>]

Folks,

When I sent the question I intended to send it to the authors only,
but only change the "name" of the receiver (removed .all) and let the
.all stay in the actual mail address, so we have been spreading this a
bit wider than intended. So I put all the initial mail addresses back.

However, I agree with Bruno's responses. The difference between "not
assigned" and "reserved" is a Bruno put it.

/Loa

On 2015-03-05 17:55, [e-mail] wrote:
> Hi Loa, all,
>
> Please see inline [Bruno] the proposed resolution
>
>> From: Loa Andersson [mailto:[e-mail]] > Sent: Thursday, March 05, 2015 8:19 AM
>> To: [e-mail]
>> Subject: Re: Gen-ART Telechat Call review of draft-ietf-mpls-lsp-ping-registry-
>> 02
>>
>> Folks,
>>
>> Did we respond to the Gen ART review?
>
> [Bruno] Not yet.
>
>> /Loa
>>
>> On 2015-03-05 03:03, Meral Shirazipour 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 wait for direction from your document shepherd or AD before
>> posting a new version of the draft.
>>>
>>> Document: draft-ietf-mpls-lsp-ping-registry-02
>>> Reviewer: Meral Shirazipour
>>> Review Date: 2015-03-04
>>> IETF LC End Date: 2015-03-02?
>>> IESG Telechat date: 2015-03-05
>>>
>>> Summary: This draft is ready to be published as Standards Track RFC but I
>> have some comments.
>>>
>>> Minor issues:
>>> -[Page 3], Section 2.1, Table "Registry Name: DS Flags.". Is there a reason bits
>> 5-0 are listed as "Unassigned" and not "Reserved (MBZ)" ?, with Reference
>> being RFC4379 Section 3.3.
>
> [Bruno] Indeed RFC4379 marks these flags as "Reserved".
> However, my understanding is that in an IANA registry, "reserved" means that the IANA can't use it. While "Unassigned" means that the IANA is free to pick a value and assign.
> I think we do mean "Unassigned" as we want the IANA to be able to make assignment. (otherwise, there is no point in making a IANA registry)
>
>>>
>>> -[Page 4], Section 2.3, Table "Registry Name: Pad Type.". RFC4379 did not
>> reserve value 0. I could be wrong please double check.
>
> [Bruno] Indeed, RFC4379 does not talk about value 0. Probably an oversight.
> IMHO it's better for this document to document value 0 (probably required by IANA). IMO making 0 "reserved" is the safest option.
> At least the WG did not object/comment.
> Hower the document indicates  "0    Reserved                                 RFC4379" and this is not strictly true that RFC 4379 is the reference for this value 0.
> Hence I would propose
> OLD:  0    Reserved                                 RFC4379
> New:  0    Reserved                                 This document.
>
>>>
>>> -[Page 5], Section 2.4, Table "Registry Name: Interface and Label Stack
>> Address Type.". Same as above, RFC4379 did not reserve value 0.
>
> [Bruno] idem
>
>>>
>>>
>>>
>>> Nits/editorial comments:
>>> -[Page 2], Section 2.1, please put in parenthesis (DSMAP) and (DDMAP) right
>> after when the terms are spelled out. The acronyms are use later on.
>
> [Bruno] Yes. Thank you. Done in my local copy
>
>>>
>>>
>>>
>>> Best Regards,
>>> Meral
>>> ---
>>> Meral Shirazipour
>>> Ericsson
>>> Research
>>> www.ericsson.com
>>>
>>
>> --
>>
>>
>> Loa Andersson                        email: [e-mail]
>> Senior MPLS Expert                          [e-mail]
>> Huawei Technologies (consultant)     phone: [phone]
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]