Subject: [mpls] Poll for Adoption draft-lcap-mpls-moving-iana-registries-02

From: Ross Callon <[email-masked]>
Date: Thu, 5 Sep 2013 16:01:42 +0000

This is to start a "two week" poll on adopting
draft-lcap-mpls-moving-iana-registries-02
as an MPLS working group document.

Please send your comments (support/not support) to the mpls working
group mailing list ([email-masked]<mailto:[email-masked]>).

This poll will end September 20, 2013.

Thanks, Ross

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 5 Sep 2013 14:44:14 -0400

Ross,

Yes, this is a much-needed cleanup of the associated IANA registries.

Thanks,
Andy

On Thu, Sep 5, 2013 at 12:01 PM, Ross Callon <[email-masked]> wrote:

>   This is to start a "two week" poll on adopting****
>
> draft-lcap-mpls-moving-iana-registries-02****
>
> as an MPLS working group document.****
>
>  ****
>
> Please send your comments (support/not support) to the mpls working****
>
> group mailing list ([email-masked]).****
>
>  ****
>
> This poll will end September 20, 2013.****
>
>  ****
>
> Thanks, Ross****
>
>  ****
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: t.petch <[email-masked]>
Date: Fri, 6 Sep 2013 12:53:29 +0100

Messy

We end up with a better IANA registry but with worse underlying RFC,
since this updates seven of them, making it harder to find the current
status of the MPLS standards, and we already have an awful lot of MPLS
RFC interacting with each other.

Is there a half-way house which gives us most of the benefit with fewer
updates?

And this hits PWE3 so I think that they should be polled as well.

On balance, I do not support this.

Tom Petch

----- Original Message -----
From: "Ross Callon" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, September 05, 2013 5:01 PM
Subject: [mpls] Poll for Adoption

Thanks, Ross

------------------------------------------------------------------------
--------

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 6 Sep 2013 13:20:52 +0000

+1

Regards,

    SASHA

________________________________
From: [email-masked] [[email-masked]] on behalf of Andrew G. Malis [[email-masked]]
Sent: Thursday, September 05, 2013 8:44 PM
To: Ross Callon
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] Poll for Adoption draft-lcap-mpls-moving-iana-registries-02

Ross,

Thanks,
Andy

On Thu, Sep 5, 2013 at 12:01 PM, Ross Callon <[email-masked]<mailto:[email-masked]>> wrote:
This is to start a "two week" poll on adopting
draft-lcap-mpls-moving-iana-registries-02
as an MPLS working group document.

Thanks, Ross

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 6 Sep 2013 13:29:10 +0000

Tom,

It is, indeed, a tradeoff whether to update IANA registries (or documents for that matter) after-the-fact. I agree that both sides of the equation need to be weighted, and thanks for the input. I will add that there is a timing condition to the trade-off, such that controlling mess earlier prevents compounded mess.

Based on these points, my thoughts:
I contend that in this case, we end up with better underlying RFCs as well -- if you actually check the RFCs being updated, none of them have pointers (URIs) to the actual IANA registries. Only vague descriptions -- so the registries are really hard to find. With this update, the RFCs' metadata are updated, and the new RFC will have precise pointers.
Is the WG planning on adding features that require numbers for G-ACh? If the answer is at least "maybe" or "potentially", then we should do this now to prevent exponential mess. Arguably we should have done this earlier.
Regarding PWE3, I agree as well -- Andy Malis weighted in, feel free to also forward the poll to PWE3.

Thanks,

-- Carlos.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 6 Sep 2013 10:04:49 -0400

Tom and Carlos,

Thanks for the hint, I just forwarded the call for adoption to the PWE3
list and asked for comments on the MPLS list.

Tom, with my PWE3 co-chair on, I really agree with Carlos that the end
benefits are much better than the current situation where we've organically
arrived. There are times where a cleanup really does help, and this is one
of them.

Cheers,
Andy

On Fri, Sep 6, 2013 at 9:29 AM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Tom,
>
> It is, indeed, a tradeoff whether to update IANA registries (or documents
> for that matter) after-the-fact. I agree that both sides of the equation
> need to be weighted, and thanks for the input. I will add that there is a
> timing condition to the trade-off, such that controlling mess earlier
> prevents compounded mess.
>
>    1. I contend that in this case, we end up with better underlying RFCs
>    as well -- if you actually check the RFCs being updated, none of them have
>    pointers (URIs) to the actual IANA registries. Only vague descriptions --
>    so the registries are really hard to find. With this update, the RFCs'
>    metadata are updated, and the new RFC will have precise pointers.
>    2. Is the WG planning on adding features that require numbers for
>    G-ACh? If the answer is at least "maybe" or "potentially", then we should
>    do this now to prevent exponential mess. Arguably we should have done this
>    earlier.
>
> group mailing list ([email-masked]<mailto:[email-masked] <[email-masked]>>).
>

---

From: Loa Andersson <[email-masked]>
Date: Sat, 07 Sep 2013 13:08:18 +0200

All,

I agree with Andy - draft-lcap-mpls-moving-iana-registries improve
things. It does not make them perfect, but the strategy do do everything
on one giant leap have failed, not we approach this is in small steps.

/Loa

On 2013-09-06 16:04, Andrew G. Malis wrote:
> benefits are much better than the current situation where we've
> organically arrived. There are times where a cleanup really does help,
> and this is one of them.
>
> Cheers,
> Andy
>
>
> On Fri, Sep 6, 2013 at 9:29 AM, Carlos Pignataro (cpignata)
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Tom,
>
>     It is, indeed, a tradeoff whether to update IANA registries (or
>     documents for that matter) after-the-fact. I agree that both sides
>     of the equation need to be weighted, and thanks for the input. I
>     will add that there is a timing condition to the trade-off, such
>     that controlling mess earlier prevents compounded mess.
>
>      1. I contend that in this case, we end up with better underlying
>         RFCs as well -- if you actually check the RFCs being updated,
>         none of them have pointers (URIs) to the actual IANA registries.
>         Only vague descriptions -- so the registries are really hard to
>         find. With this update, the RFCs' metadata are updated, and the
>         new RFC will have precise pointers.
>         G-ACh? If the answer is at least "maybe" or "potentially", then
>         we should do this now to prevent exponential mess. Arguably we
>         should have done this earlier.
>
>     On Sep 6, 2013, at 7:53 AM, t.petch <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>>     Messy
>>
>>     From: "Ross Callon" <[email-masked] <mailto:[email-masked]>>
>>     To: <[email-masked] <mailto:[email-masked]>>
>>     Cc: <[email-masked]
>>     <mailto:[email-masked]>>; <[email-masked]
>>     <mailto:[email-masked]>>
>>     group mailing list ([email-masked]
>>     <mailto:[email-masked]><mailto:[email-masked]>).
>>
>>>     [email-masked] <mailto:[email-masked]>
>>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 

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

---

From: Mach Chen <[email-masked]>
Date: Mon, 9 Sep 2013 02:41:38 +0000

Support!

Best regards,
Mach

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Friday, September 06, 2013 12:02 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls] Poll for Adoption draft-lcap-mpls-moving-iana-registries-02

Thanks, Ross

---

From: t.petch <[email-masked]>
Date: Tue, 10 Sep 2013 14:11:28 +0100

More opposition - see below,

Tom Petch

----- Original Message -----
From: "Carlos Pignataro (cpignata)" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Ross Callon" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Friday, September 06, 2013 2:29 PM
Subject: Re: [mpls] Poll for
Adoptiondraft-lcap-mpls-moving-iana-registries-02

Tom,

It is, indeed, a tradeoff whether to update IANA registries (or
documents for that matter) after-the-fact. I agree that both sides of
the equation need to be weighted, and thanks for the input. I will add
that there is a timing condition to the trade-off, such that controlling
mess earlier prevents compounded mess.

Based on these points, my thoughts:
I contend that in this case, we end up with better underlying RFCs as
well -- if you actually check the RFCs being updated, none of them have
pointers (URIs) to the actual IANA registries. Only vague
descriptions -- so the registries are really hard to find. With this
update, the RFCs' metadata are updated, and the new RFC will have
precise pointers.
Is the WG planning on adding features that require numbers for G-ACh? If
the answer is at least "maybe" or "potentially", then we should do this
now to prevent exponential mess. Arguably we should have done this
earlier.

<tp>
I do not understand the logic of this I-D.  It renames the "Pseudowire
Associated Channel Types"  into "MPLS Generalized Associated Channel
(G-ACh) Types  (including Pseudowire Associated Channel Types)".

It identifies RFC5586, in Section 3, as being affected, but why not
RFC4385 or the ten other RFC which define entries in the to-be-renamed
registry?  Read one of them (e.g. RFC5885), check that this is not
affected by errata or updates thereto, go looking for the registry by
name and you will not find it (once this has been implemented).

Tom Petch

Regarding PWE3, I agree as well -- Andy Malis weighted in, feel free to
also forward the poll to PWE3.

Thanks,

-- Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 10 Sep 2013 14:02:25 +0000

Tom,

> More opposition - see below,

Thanks -- frankly I did not read your comments as "opposition" but as two small pieces of improvement since the root problem is still there, and gets worst.

> (G-ACh) Types  (including Pseudowire Associated Channel Types)".

Do you find the Abstract particularly difficult to parse? We really aimed for a simple logic: The PW-ACH has been generalized, in RFC5586, and is applicable beyond PWs. However, the IANA registries did not track this change, and consequently MPLS registrations are made in PWE3 registries, and G-ACh registrations (meaning the ones that are fields of the ACH Type) are distributed throughout many different registries.

Perhaps the "including" threw you off? If that is so, I think you have a point, and that could be renamed to "previously" or "formerly".

> name and you will not find it (once this has been implemented).

The approach has been to minimize the updates. In that, we chose to only update RFC5586 for the renaming and moving of the registry. Perhaps what's needed (as IANA does sometimes) is leave a pointer in the old registry. Another option is to list the other RFCs. We can ask IANA for their current best practice.

Thanks,

-- Carlos.

---

From: Yaacov Weingarten <[email-masked]>
Date: Tue, 10 Sep 2013 19:45:13 +0300

Support

BR,
yaacov

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 11 Sep 2013 08:14:09 +0000

Support.

 
Please send your comments (support/not support) to the mpls working
group mailing list ([email-masked]).

Thanks, Ross

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 11 Sep 2013 08:42:42 +0000

Support.

Xiaohu

---

From: Ross Callon <[email-masked]>
Date: Mon, 23 Sep 2013 16:21:56 +0000

Working Group,

This poll has been closed.  We have accepted the draft as an mpls working group document.

Could the authors please re-publish the draft with no other
changes than file-name, date and version as:

draft-ietf-mpls-moving-iana-registries-00

Thanks, Ross
(as WG co-chair)

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Thursday, September 05, 2013 12:02 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls] Poll for Adoption draft-lcap-mpls-moving-iana-registries-02

Thanks, Ross