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

[Jari Arkko <[e-mail]>]

On 05 Mar 2015, at 13:48, Adrian Farrel <[e-mail]> wrote:

> And thanks Meral for the review

indeed

> And thanks Bruno for the response with which I agree.

as do i. thanks.

jari

> 
> Adrian
> 
>> -----Original Message-----
>> From: Loa Andersson [mailto:[e-mail]]
>> Sent: 05 March 2015 11:09
>> To: [e-mail]; draft-ietf-mpls-lsp-ping-
>> [e-mail]; [e-mail]; [e-mail]
>> Subject: Re: Gen-ART Telechat Call review of
> draft-ietf-mpls-lsp-ping-registry-02
>> 
>> 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]
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art