Re: [mpls] Early AD comments on draft-ietf-mpls-psc-updates

Loa Andersson <loa@pi.nu> Fri, 21 March 2014 11:52 UTC

Return-Path: <loa@pi.nu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37DB1A0969 for <mpls@ietfa.amsl.com>; Fri, 21 Mar 2014 04:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SdAbxOXfwtY for <mpls@ietfa.amsl.com>; Fri, 21 Mar 2014 04:52:46 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id D184D1A096D for <mpls@ietf.org>; Fri, 21 Mar 2014 04:52:45 -0700 (PDT)
Received: from [192.168.0.116] (81-229-83-119-no65.business.telia.com [81.229.83.119]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 9CFCD180150F; Fri, 21 Mar 2014 12:52:35 +0100 (CET)
Message-ID: <532C2803.5040900@pi.nu>
Date: Fri, 21 Mar 2014 12:52:35 +0100
From: Loa Andersson <loa@pi.nu>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Eric Osborne <eric@notcom.com>
References: <290801cf4210$dccee410$966cac30$@olddog.co.uk> <CA+97oKMEpLmkvLSbfDePVM_qszvSENgBOT5awB1++b1ii8sZeg@mail.gmail.com> <055001cf4455$98a3e320$c9eba960$@olddog.co.uk> <CA+97oKMsYrW+iqTVNV+aXjy22VzYZ5YE929M=uYykqvPCnF0Sg@mail.gmail.com> <056101cf4459$257a1690$706e43b0$@olddog.co.uk> <532B1921.5020205@pi.nu> <CA+97oKM6woYXsTOTLMMyMoK0ftxdnr6Rq_5d=bv140sNO+_qtw@mail.gmail.com>
In-Reply-To: <CA+97oKM6woYXsTOTLMMyMoK0ftxdnr6Rq_5d=bv140sNO+_qtw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/sRAbmVOOYZWYGqiKy9-3g68Rnko
Cc: "mpls@ietf.org" <mpls@ietf.org>, Eric Osborne <eric.osborne@notcom.com>
Subject: Re: [mpls] Early AD comments on draft-ietf-mpls-psc-updates
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Mar 2014 11:52:50 -0000

Folks,

I'm OK with that text, however it is a documentation of change to a
standards track RFC. I'm not sure that it is a good idea to ask the
RFC Editor to remove the text.

I think the RFC Editor will change it to "IANA has marked the
value 0 ..." I think this should stay in the document.

/Loa

On 2014-03-21 12:44, Eric Osborne wrote:
> OK.  Here's the exact text I've got:
>
>
> --
> 8.  IANA Considerations
>
>     IANA is requested to mark the value 0 in the "MPLS PSC TLV Registry"
>     as "Reserved, not to be allocated" and to update the references to
>     show [RFC6378] and [RFC-ietf-mpls-psc-updates-03].  Note that this
>     action provides documentation of an action already taken by IANA but
>     not recorded in RFC 6378.
>
>     Note to RFC Editor: this section may be removed on publication as an
>     RFC
> ---
>
>
> I wasn't sure if [This.ID] was intended to provoke variable
> substitution, nor was I sure whether the square brackets meant that
> the self-reference should also be a normative reference (to the
> eventual This.RFC).  It seems overkill for a document to cite itself
> as a normative reference ("in order to understand this document, you
> should read it")...but on the other hand, perhaps we should start
> doing that for all drafts that come out of MPLS now.
>
> I took the exact formatting from the reference section of the MPLS PSC
> TLV Registry, which does it like this:
>
> ---
> Reference
>    [RFC6378][RFC-ietf-mpls-moving-iana-registries-04]
> ---
>
> and I did not cite the draft itself in its normative reference section.
>
> Please let me know if this exact text is acceptable and then I will
> post the draft.
>
>
>
>
>
> eric
>
>
> On Thu, Mar 20, 2014 at 12:36 PM, Loa Andersson <loa@pi.nu> wrote:
>> Folks,
>>
>> I can live with the:
>>
>> "...update the references to show [RFC6378], [This ID]".
>>
>> It is correct that the action was taken for RFC 6378, but it is
>> also correct that it was never mentioned in RFC 6378. So I guess
>> that what we need to say is:
>>
>>
>> "IANA is requested to mark the value 0 in the "MPLS PSC TLV Registry"
>>   as "Reserved, not to be allocated" and to update the references to
>>   show [RFC6378], [This.I-D].  Note that this action provides
>>
>>   documentation of an action already taken by IANA but not recorded
>>   in RFC 6378. This is an update to RFC 6378."
>>
>> /Loa
>>
>>
>> On 2014-03-20 17:26, Adrian Farrel wrote:
>>>
>>> The action was taken for RFC 6378, so it should be mentioned.
>>>
>>>> -----Original Message-----
>>>> From: Eric Osborne [mailto:eric@notcom.com]
>>>> Sent: 20 March 2014 16:18
>>>> To: Adrian Farrel
>>>> Cc: Eric Osborne; mpls@ietf.org
>>>> Subject: Re: Early AD comments on draft-ietf-mpls-psc-updates
>>>>
>>>> OK.
>>>> Loa's suggestion is
>>>>
>>>> "... update the reference to RFC 6378 to say [this ID]"
>>>>
>>>> Adrian's is "...update the references to show [RFC6378], [This ID]".
>>>>
>>>> I think Loa's makes more sense...why would we have the registry
>>>> allocation point to both 6378 and thisID if 6378 doesn't say anything?
>>>>
>>>> Whatever text you guys agree on, I'll use.
>>>>
>>>>
>>>>
>>>> eric
>>>>
>>>> On Thu, Mar 20, 2014 at 12:01 PM, Adrian Farrel <adrian@olddog.co.uk>
>>>> wrote:
>>>>>
>>>>> Yes, you're right. Should be a comma not a period.
>>>>>
>>>>> A
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Eric Osborne [mailto:eric@notcom.com]
>>>>>> Sent: 20 March 2014 14:39
>>>>>> To: Adrian Farrel
>>>>>> Cc: Eric Osborne; mpls@ietf.org
>>>>>> Subject: Re: Early AD comments on draft-ietf-mpls-psc-updates
>>>>>>
>>>>>> Hi Adrian-
>>>>>>
>>>>>>
>>>>>>
>>>>>>     Thanks for these.  I am OK with them and will add them to the
>>>>>> version I post next. I'm not clear on the nuances of your IANA text,
>>>>>> though.  You say:
>>>>>>
>>>>>>
>>>>>> ---
>>>>>> IANA is requested to mark the value 0 in the "MPLS PSC TLV Registry"
>>>>>> as "Reserved, not to be allocated" and to update the references to
>>>>>> show [RFC6378].
>>>>>> [This.I-D].  Note that this action provides documentation of an action
>>>>>> already taken by IANA but not recorded in RFC 6378.
>>>>>> ---
>>>>>>
>>>>>>
>>>>>> What exactly does the [This.I-D] do in its own sentence?  Did you mean
>>>>>> something like " update the references to show [RFC6378] and
>>>>>> [This.I-D].  Note that this action..." or is there something subtle
>>>>>> I'm not picking up on with your original phrasing?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> eric
>>>>>>
>>>>>> On Mon, Mar 17, 2014 at 2:43 PM, Adrian Farrel <adrian@olddog.co.uk>
>>>>
>>>> wrote:
>>>>>>>
>>>>>>> Hi Eric,
>>>>>>>
>>>>>>> A couple of discussion points on draft-ietf-mpls-tp-psc-itu (which is
>>>>>
>>>>> currently
>>>>>>>
>>>>>>> in IESG evaluation) have given rise to two small proposed additions to
>>>>>>> draft-ietf-mpls-psc-updates
>>>>>>>
>>>>>>> 1. I think this warrants a very small section of its own...
>>>>>>>
>>>>>>> x.y  PSC TLV Format
>>>>>>>
>>>>>>> [RFC6378] defines the capability to carry TLVs in the PSC messages.
>>>>>>> This
>>>>>
>>>>> section
>>>>>>>
>>>>>>> defines the format to be used by all such TLVs.
>>>>>>>
>>>>>>> Type field (T)
>>>>>>> A two octet field that encodes a type value in network byte order. The
>>>
>>> type
>>>>>>>
>>>>>>> values are recorded in the IANA registry "MPLS PSC TLV Registry".
>>>>>>>
>>>>>>> Length field (L)
>>>>>>> A two octet field that encodes the length in octets of the Value field
>>>>>>> in
>>>>>>> network byte order. The value of this field MUST be a multiple of 4.
>>>>>>>
>>>>>>> Value field (V)
>>>>>>> The contents of the TLV. This field MUST be a multiple of 4 octets and
>>>>>>> so
>>>>>
>>>>> may
>>>>>>>
>>>>>>> contain explicit padding.
>>>>>>>
>>>>>>>
>>>>>>> 2. There was a trivial snafu with the 0 value in the "MPLS PSC TLV
>>>>>
>>>>> Registry". It
>>>>>>>
>>>>>>> was agreed that 0 would be reserved, but this was not recorded in RFC
>>>
>>> 6378.
>>>>>>>
>>>>>>> Therefore, the IANA section of draft-ietf-mpls-psc-updates should
>>>>>>> include
>>>>>
>>>>> the
>>>>>>>
>>>>>>> text...
>>>>>>>
>>>>>>> IANA is requested to mark the value 0 in the "MPLS PSC TLV Registry"
>>>>>>> as
>>>>>>> "Reserved, not to be allocated" and to update the references to show
>>>>>>
>>>>>> [RFC6378].
>>>>>>>
>>>>>>> [This.I-D].  Note that this action provides documentation of an action
>>>>>
>>>>> already
>>>>>>>
>>>>>>> taken by IANA but not recorded in RFC 6378.
>>>>>>>
>>>>>>>
>>>>>>> Hope everyone is comfortable with this.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Adrian
>>>>>>>
>>>>>
>>>
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>
>> --
>>
>>
>> Loa Andersson                        email: loa@mail01.huawei.com
>> Senior MPLS Expert                          loa@pi.nu
>> Huawei Technologies (consultant)     phone: +46 739 81 21 64

-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64