Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129

From: Peter Hessler <[email-masked]>
Date: Tue, 1 Nov 2016 10:40:32 +0100

I support adoption.

On 2016 Oct 31 (Mon) at 17:18:57 -0400 (-0400), John G.Scudder wrote:
:Hi Everyone,
:
:The author has asked for the WG to adopt  draft-snijders-idr-deprecate-30-31-129. 
:
:If you support or oppose adoption please reply indicating so. Reasons for your position are helpful, as volunteering to review, comment, and/or shepherd. As an aside, I will note that I don't think the WG has the option of doing nothing, so if you oppose adoption please address what you think should be done instead.
:
:The adoption call will end November 13.
:
:Thanks,
:
:--John
:
:P.S.: https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01
:
:Abstract
:
:   This document requests IANA to deprecate the following BGP path
:   attributes values: 30, 31 and 129.
:
:
:_______________________________________________
:Idr mailing list
:[email-masked]
:https://www.ietf.org/mailman/listinfo/idr

---

From: Gert Doering <[email-masked]>
Date: Tue, 1 Nov 2016 12:32:01 +0100

Hi,

On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote:
> The author has asked for the WG to adopt  draft-snijders-idr-deprecate-30-31-129. 

Support adoption.

Read the text as well, while at it, and it's short and to the point, so
support for the content as well :)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 01 Nov 2016 12:00:50 +0000

> The author has asked for the WG to adopt  draft-snijders-idr-deprecate-30-31-129. 

support.

Nick

---

From: Job Snijders <[email-masked]>
Date: Tue, 1 Nov 2016 14:32:40 +0100

Dear working group,

To prevent having multiple drafts in quick succession covering the same
style of issue - I'd like your feedback on the following:

I believe that bgp path attribute 241, 242, 243 should also be added to
this draft for the same reasons as 30, 31 and 129 are listed.

OLD:
    This document requests IANA to deprecate the following BGP Path
    attributes: 30, 31, and 129.

NEW:
    This document requests IANA to deprecate the following BGP Path
    attributes: 30, 31, 129, 241, 242, and 243.

Does anyone object? If so, why?

Unilaterally changing the document while in its mid-flight through the
working group adoption process might be considered bad form, hence my
request for feedback on the 241,242,243 topic.

Please note - the deprecation of an attribute can be undone if proper
process is followed. The priority here is to prevent IANA from assigning
tainted codepoints to innocent bystanders, thus a deprecation document
needs to exist. In time the working group has the power to undeprecate
them for specific purposes.

Kind regards,

Job

On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote:
> Hi Everyone,
> If you support or oppose adoption please reply indicating so. Reasons for your position are helpful, as volunteering to review, comment, and/or shepherd. As an aside, I will note that I don't think the WG has the option of doing nothing, so if you oppose adoption please address what you think should be done instead.
> 
> The adoption call will end November 13.
> 
> Thanks,
> 
> --John
> 
> P.S.: https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01
> 
> Abstract
> 
>    This document requests IANA to deprecate the following BGP path
>    attributes values: 30, 31 and 129.
> 
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 1 Nov 2016 15:02:37 +0100

Hi Job,

Have you consider marking those codepoints as "RESERVED" rather then
"DEPRECIATED".

Reason being that if any of the applications they have been squatted on
behalf of want to use them - it would be pretty easy to allocate them.

The other alternative would be to allocate them to those applications now
(for which the drafts exist) as IANA early allocations. If you depreciate
them now and we know that as example Contrail Multicast is important either
your draft will need to quickly be moved to historic or yet another types
will need to be allocated again.

In any of the above Large Communities will get virgin BGP attribute type
which I believe is the main point here.

Cheers,
R.

On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders <[email-masked]> wrote:

> > If you support or oppose adoption please reply indicating so. Reasons
> for your position are helpful, as volunteering to review, comment, and/or
> shepherd. As an aside, I will note that I don't think the WG has the option
> of doing nothing, so if you oppose adoption please address what you think
> should be done instead.
> >

---

From: Job Snijders <[email-masked]>
Date: Tue, 1 Nov 2016 15:12:29 +0100

> Have you consider marking those codepoints as "RESERVED" rather then

"DEPRECIATED" is an IANA attribute state I am not familiar with, I
assume you mean "deprecated"? :)

> Reason being that if any of the applications they have been squatted
> on behalf of want to use them - it would be pretty easy to allocate
> them.
> 
> The other alternative would be to allocate them to those applications
> now (for which the drafts exist) as IANA early allocations. If you
> depreciate them now and we know that as example Contrail Multicast is
> important either your draft will need to quickly be moved to historic
> or yet another types will need to be allocated again.

That is not how the process works. An implementor should not be rewarded
with the possibility of laziness after they squat on a codepoint.
"Laziness" being that they don't have to renumber, and that they didnt
have to go through the normal process to obtain the codepoint.

I argue that we cannot tolerate: "I'll just take this one, IANA will
give it to me anyway later on if the product becomes popular"

Also, the 'deprecate' draft (if published) would be "updated", not moved
to historic. Only when all six proposed squatted points are returned to
the "unassigned" pool the document can be declared historic.

> In any of the above Large Communities will get virgin BGP attribute
> type which I believe is the main point here.

No, the main point is to prevent another deployment issue like Large BGP
Communities suffered. Large BGP Communities has been resolved now (after
considerable effort I might add).

This document protects innocent bystanders from being assigned
undeployable tainted codepoints.

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 1 Nov 2016 15:17:30 +0100

> An implementor should not be rewarded with the possibility
> of laziness after they squat on a codepoint.

+

> I argue that we cannot tolerate:

Ahh got it.

So the point of the document is *punishment* for early attempts to
implement anything not to technically address the problem at hand. Thx for
clarification ...

Cheers,
R.

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 1 Nov 2016 10:23:46 -0400

AFAICT the function of the draft is simply to kick the IANA code point state to "deprecated". It doesn't anchor it there for all time. Presumably a later request can move the state to assigned or whatever, as we've previously discussed. I don't think any update to the current "deprecate" document would be needed to achieve this (I guess maybe the later document might list this one in its "updates" header).

I'll confirm this understanding with IESG and IANA before the end of the WG adoption call. (Unless someone can point me to chapter-and-verse of a reference that explains the process clearly enough, unfortunately I have not found such.)

Thanks,

--John

> On Nov 1, 2016, at 10:02 AM, Robert Raszuk <[email-masked]> wrote:
> 
> Hi Job,
> 
> Have you consider marking those codepoints as "RESERVED" rather then "DEPRECIATED". 
> 
> Reason being that if any of the applications they have been squatted on behalf of want to use them - it would be pretty easy to allocate them.
> 
> The other alternative would be to allocate them to those applications now (for which the drafts exist) as IANA early allocations. If you depreciate them now and we know that as example Contrail Multicast is important either your draft will need to quickly be moved to historic or yet another types will need to be allocated again. 
> 
> In any of the above Large Communities will get virgin BGP attribute type which I believe is the main point here.
> 
> Cheers,
> R.
> 
> 
> On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders <[email-masked] <mailto:[email-masked]>> wrote:
> Dear working group,
> 
> > P.S.: https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01 <https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01>
> >
> > Abstract
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
>

---

From: Peter Hessler <[email-masked]>
Date: Tue, 1 Nov 2016 15:25:51 +0100

On 2016 Nov 01 (Tue) at 15:17:30 +0100 (+0100), Robert Raszuk wrote:
:> An implementor should not be rewarded with the possibility
:> of laziness after they squat on a codepoint.
:
:+
:
:> I argue that we cannot tolerate:
:
:Ahh got it.
:
:So the point of the document is *punishment* for early attempts to
:implement anything not to technically address the problem at hand. Thx for
:clarification ...
:
:Cheers,
:R.
:

Early development in support of an ID is desirable, and in this WG
pretty much required.  For that, a lab image and (in the open source
case) patches floating around is good.  Pushing these to innocent
customers is not.

Squatting on random (e.g. Huawei with code 30) codepoints *should* be
punished, imho.

Regardless if we consider it to be punishment or not-punishment, it
should be documented that these code points are tainted, and cannot be
considered pure and clean for future assignments.

I don't care either way if 129 is used for a future Early Assignment of
Wide Communities.  But I do care if 31 is assigned to someone that has
to fight the existing ecosystem.

:On Tue, Nov 1, 2016 at 3:12 PM, Job Snijders <[email-masked]> wrote:
:
:> On Tue, Nov 01, 2016 at 03:02:37PM +0100, Robert Raszuk wrote:
:> > Reason being that if any of the applications they have been squatted
:> > on behalf of want to use them - it would be pretty easy to allocate
:> > them.
:> >
:> > The other alternative would be to allocate them to those applications
:> > now (for which the drafts exist) as IANA early allocations. If you
:> > depreciate them now and we know that as example Contrail Multicast is
:> > important either your draft will need to quickly be moved to historic
:> > or yet another types will need to be allocated again.
:>
:> That is not how the process works. An implementor should not be rewarded
:> with the possibility of laziness after they squat on a codepoint.
:> "Laziness" being that they don't have to renumber, and that they didnt
:> have to go through the normal process to obtain the codepoint.
:>
:> I argue that we cannot tolerate: "I'll just take this one, IANA will
:> give it to me anyway later on if the product becomes popular"
:>
:> Also, the 'deprecate' draft (if published) would be "updated", not moved
:> to historic. Only when all six proposed squatted points are returned to
:> the "unassigned" pool the document can be declared historic.
:>
:> > In any of the above Large Communities will get virgin BGP attribute
:> > type which I believe is the main point here.
:>
:> No, the main point is to prevent another deployment issue like Large BGP
:> Communities suffered. Large BGP Communities has been resolved now (after
:> considerable effort I might add).
:>
:> This document protects innocent bystanders from being assigned
:> undeployable tainted codepoints.
:>
:> Kind regards,
:>
:> Job
:>

-- 
Command, n.:
	Statement presented by a human and accepted by a computer in
such a manner as to make the human feel as if he is in control.

---

From: Job Snijders <[email-masked]>
Date: Tue, 1 Nov 2016 15:28:07 +0100

On Tue, Nov 01, 2016 at 03:17:30PM +0100, Robert Raszuk wrote:
> > An implementor should not be rewarded with the possibility of
> > laziness after they squat on a codepoint.
> 
> +
> 

Am I to understand that you consider deployment problems not to be
technical problems?

BGP Path attribute codepoints are a global, shared resources. As
Internet community we have vested IANA with the authority to assign
resources from this pool. The social contract is that we abide by the
rules related to IETF and IANA. The same rules we write ourselves.

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 1 Nov 2016 15:30:43 +0100

Hi John,

>From IDR WG standpoint could you state clearly the process for Early
Allocation of Attribute Types, Message Types or AFI/SAFIs codepoints ?

Does the process differ between IETF WGs ? Say if BESS will try to do also
early allocation for given BGP Attribute Type ?

I think this is the key here and root of the problem.

If we require interoperable implementations for any draft to proceed WG
should enable authors to create those implementations in the first place.

Thx a lot,
Robert.

On Tue, Nov 1, 2016 at 3:23 PM, John G. Scudder <[email-masked]> wrote:

> AFAICT the function of the draft is simply to kick the IANA code point
> state to "deprecated". It doesn't anchor it there for all time. Presumably
> a later request can move the state to assigned or whatever, as we've
> previously discussed. I don't think any update to the current "deprecate"
> document would be needed to achieve this (I guess maybe the later document
> might list this one in its "updates" header).
>
> I'll confirm this understanding with IESG and IANA before the end of the
> WG adoption call. (Unless someone can point me to chapter-and-verse of a
> reference that explains the process clearly enough, unfortunately I have
> not found such.)
>
> Thanks,
>
> --John
>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Nov 2016 10:40:36 -0400

> If you support or oppose adoption please reply indicating so. Reasons for your position are helpful, as volunteering to review, comment, and/or shepherd. As an aside, I will note that I don't think…

I have a few points to raise here:
1. Do we actually need a draft published to request IANA to block out
allocation of these code points?  If so, we're going to end up with a number
of trivial drafts for these corrective actions.  I'm interested in hearing
the IESG's opinion on this point.

If we do need a draft, this draft is as fine as any.  Hopefully we don't
need one.

2. Much as it's tempting to try to use this process to try to be the clue
hammer and "punish" people for grabbing code points, you burn enough bridges
you eventually run out of wood.

We have a few issues code shipping with such use suggest:

2a. Some of these things are features in use.  If so, they're just going to
have to get a different official code point.  

IMO, the right answer here is to push the implementors to get their
registrations in order and officially request them.  The penalty on *them*
is the potential that someone else has already collided with them due to
different squatting.

2b. Some of these things are early implementations that are against drafts
that aren't fully mature.  This means there will be versioning issues.
Either the code point gets re-used and deals with the versioning problem or
the code point needs deprecation.

And even then, the fact that there's an early implementation means that
eventually a code point is needed.

---

It seems to me what is needed is some work to classify such early
deployments as 2a or 2b.  2a just involves getting some administrative
issues cleared.  2b means we should discuss how do we "clean" a code point
sooner than later.

Final observation:  Some of this is messy due to scope propagation issues of
internal features.  This is another wake-up to deal with that propblem.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 1 Nov 2016 15:41:12 +0100

> Am I to understand that you consider deployment problems not to be

​You stated clearly that Large is not subject to suffer from deployment
problems. So what other deployment problems you envision if those types
would be moved to early allocation by IANA ? ​

> rules related to IETF and IANA. The same rules we write ourselves.

​Few days back You and others complained that Wide was not implemented by
anyone for so many years. Now when we see it actually was implemented at
least by few BGP code basis ​it is again bad.

So to me the problem we need to solve is how to allow early implementations
for any proposal on the table especially now when we have no two but at
least 8 production BGP implementations (and growing). Forbidding it does
not seems to me like a solution to the main problem.

Kind regards,
R.

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 1 Nov 2016 10:53:59 -0400

> the IESG's opinion on this point.

IANA did specifically request an RFC to reference although they stopped short of explicitly saying "if you don't promise to give us a document, we won't do this action". I have asked them to clarify and will report back, but I suggest that for now the WG should assume that we do actually need to publish draft and progress it to RFC.

Thanks,

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 1 Nov 2016 10:55:25 -0400

Robert,

> On Nov 1, 2016, at 10:30 AM, Robert Raszuk <[email-masked]> wrote:
> 
> Hi John,
> 
> From IDR WG standpoint could you state clearly the process for Early Allocation of Attribute Types, Message Types or AFI/SAFIs codepoints ? 

It's spelled out in RFC 7120. The RFC is short, so summarizing it is kind of redundant, basically just look at sections 2 and 3.1 (approx 1 page of text). 

> Does the process differ between IETF WGs ? Say if BESS will try to do also early allocation for given BGP Attribute Type ? 

There could be some variability between working groups since two of the RFC 7120 Section 3.1 steps involve working group chairs using their judgment:

   2.  The WG chairs determine whether the conditions for early
       allocations described in Section 2 are met, particularly conditions (c) and (d).

FYI, condition (c) requires there to be a stable specification, condition (d) requires there to be "sufficient interest in the community".

   3.  The WG chairs gauge whether there is consensus within the WG that
       early allocation is appropriate for the given document.

Sue and I have chosen to gauge this by means of a two-week consensus call, as we do with other working group consensus items. This also serves to confirm conditions (c) and (d). 

> I think this is the key here and root of the problem. 

FWIW, I don't.

> If we require interoperable implementations for any draft to proceed WG should enable authors to create those implementations in the first place. 

I'm not aware of there having been an early allocation request for any of the code points in question.

 Regards,

--John

---

From: Job Snijders <[email-masked]>
Date: Tue, 1 Nov 2016 16:01:48 +0100

On Tue, Nov 01, 2016 at 03:41:12PM +0100, Robert Raszuk wrote:
> You stated clearly that Large is not subject to suffer from deployment
> would be moved to early allocation by IANA?

You might misunderstand what I intended to convey, my apologies for not
being able to articulate myself better.

Large BGP Communities was assigned BGP Path attribute, by IANA according
to the Early Allocation rules (value 30 - 2016.09.26). Turns out that an
implementor had already used that codepoint. This proved to cause issues
during an experimental deployment of Large BGP Communities. Large BGP
Communities had to back to the WG, the chairs and then IANA assigned a
new codepoint (value 32 - 2016.10.26). So, today, Large BGP Communities
does not suffer from the squatted '30' codepoint, because a renumbering
effort was undertaken. The above is a description of a deployment
problem and its resolution. 

In short: any new (early) allocations should not come from tainted
codepoints. To ensure this, IANA needs instruction not to do so (that is
the draft at hand).

Maybe a pragmatic example will help clarify the situation: If IANA
assigns Path Attribute 30 as early allocation of
draft-chen-idr-geo-coordinates-03, I suspect the
draft-chen-idr-geo-coordinates effort will encounter considerable
deployment problems. This would be a waste of time for the authors and
implementors of draft-chen-idr-geo-coordinates.

> Few days back You and others complained that Wide was not implemented
> by anyone for so many years. Now when we see it actually was
> implemented at least by few BGP code basis it is again bad.

You might not view it this way, but I am actually looking out for Wide's
chances of deployment. At this point it is not known which version of
the wide draft was implemented, or even if the implementation is
compatible with said specification. It really is in -wide-'s best
interest to _not_ use attribute 129.

> So to me the problem we need to solve is how to allow early
> implementations for any proposal on the table especially now when we
> have no two but at least 8 production BGP implementations (and
> growing). Forbidding it does not seems to me like a solution to the
> main problem.

But isnt the solution simple? I think early implementors should just
request an Early IANA Allocation and follow that process!

Kind regards,

Job

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 1 Nov 2016 15:03:17 +0000

Support adoption.

Thanks,
Linda Dunbar

-----邮件原件-----
发件人: Idr [mailto:[email-masked]] 代表 John G.Scudder
发送时间: 2016年11月1日 5:19
收件人: IETF IDR Working Group
主题: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129

Hi Everyone,

Thanks,

--John

Abstract

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 1 Nov 2016 16:04:13 +0100

​John,​

> the code points in question.

​Well I am not sure how some of the documents in question could ask for
early allocation based on RFC7120 published in 2014 if they were written
and published well before that date ...

https://tools.ietf.org/html/draft-marques-l3vpn-mcast-edge-01
https://www.ietf.org/archive/id/draft-vandevelde-idr-remote-next-hop-00.txt
...

Thx,
R.

​

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 1 Nov 2016 11:04:48 -0400

I have changed the subject line to reflect the fact we are off on a tangent and no longer relevant to adoption of the draft in question.

On Nov 1, 2016, at 10:41 AM, Robert Raszuk <[email-masked]> wrote:
> ​Few days back You and others complained that Wide was not implemented by anyone for so many years. Now when we see it actually was implemented at least by few BGP code basis ​it is again bad. 

I'm not sure what you mean by "it is again bad" but see the message I just sent -- we were not asked for an allocation for the code base in question (not sure what other code bases you are including in "few", I think one was reported).

When the question of early allocation for wide came up recently (I don't recall if it was on the list, in private email, in conversation or what, sorry) my feedback was to ask whether wide satisfies the stability requirement given in RFC 7120 Section 2 (c). Certainly if there is need for an allocation for wide and it can satisfy the RFC 7120 requirements, let's do it. If it can't satisfy the requirements, read on:

> So to me the problem we need to solve is how to allow early implementations for any proposal on the table especially now when we have no two but at least 8 production BGP implementations (and growing). Forbidding it does not seems to me like a solution to the main problem.

I expect we will be discussing this at our upcoming meeting, although that's no reason not to continue the conversation on the list right now, on the contrary. Jeff has also written a draft that tries to address the problem, he posted a pointer to it yesterday, https://datatracker.ietf.org/doc/draft-haas-idr-extended-experimental/

Thanks,

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 1 Nov 2016 11:10:45 -0400

Robert,

Let's not split hairs, please, it's not productive. You can see as well as I can that RFC 7120 was preceded by RFC 4020 which is substantially similar for purposes of this discussion, and was published in 2005.

--John

> On Nov 1, 2016, at 11:04 AM, Robert Raszuk <[email-masked]> wrote:
> 
> ​John,​
>  
> ​Well I am not sure how some of the documents in question could ask for early allocation based on RFC7120 published in 2014 if they were written and published well before that date ...
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 1 Nov 2016 16:14:30 +0100

> even if the implementation is compatible with said specification

Well I think this is completely different problem regardless on how the
types/codepoints will be allocated.

> draft-chen-idr-geo-coordinates-03

That was not what I have tried to express ... I suggested to assign all
detected points to the drafts they belong as early allocation rather then
to deprecate them. Result is the same - geo will not be allocated code
point which is already used.

So is 32 final code point for Large or early allocated one. If what LC got
is final one why geo would need to ask for early allocation vs final one :)
?

Best,
R.

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 1 Nov 2016 12:20:13 -0400

> IANA did specifically request an RFC to reference although they stopped short of explicitly saying "if you don't promise to give us a document, we won't do this action". I have asked them to clarif…

Update: Michelle @ IANA confirms that they do require RFC for deprecation from a Standards Action registry but agrees there is no documentation of this requirement specific to deprecation, they've just inferred it from the requirement to assign one. She says she'll bring it up on the Thursday IESG telechat.

Again, for now the WG should assume we do need an RFC.

--John

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Nov 2016 12:20:38 -0400

> On Nov 1, 2016, at 11:01 AM, Job Snijders <[email-masked]> wrote:
> 

FWIW, I concur with this point.  For the time being, making sure 129 is out of the pool makes sense.

Robert and I will be discussing reverting the most recent changes to the common header in our attempt to get that onto Large communities.  That should put the document back in harmony with the likely implementation.  (That, and removing code point 2 since it's covered by Large now anyway.)

-- Jeff

---

From: heasley <[email-masked]>
Date: Tue, 1 Nov 2016 16:20:55 +0000

> eventually a code point is needed.

shouldnt that implementation be done with 255 AND, regardless of an early
allocation, never leave the lab?  meaning that versioning is unnecessary,
in this scenario.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 1 Nov 2016 12:32:58 -0400

> allocation, never leave the lab?  meaning that versioning is unnecessary,

To be clear, I have a strong opinion about what should be done to not get us
into a squatting situation.  I submitted a draft that gives a proposal to
hopefully not get us into that situation again.

However, 2b is intended to cover the situation we're in today.  

-- Jeff

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 1 Nov 2016 16:44:24 +0000

I support an early attribute code allocation for wide communities.
I'm happy for it to have 129 if that's what it's been using.
Of course, it's not my call to make, just my opinion.

Thanks,
Jakob.

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of John G. Scudder
> Sent: Tuesday, November 01, 2016 8:05 AM
> To: Robert Raszuk <[email-masked]>
> Cc: IETF IDR Working Group <[email-masked]>
> Subject: [Idr] Early allocations and other ways to avoid squatting on code points
> 
> > ​Few days back You and others complained that Wide was not implemented by anyone for so many years. Now when we see
> it actually was implemented at least by few BGP code basis ​it is again bad.
> 
> I'm not sure what you mean by "it is again bad" but see the message I just sent -- we were not asked for an
> allocation for the code base in question (not sure what other code bases you are including in "few", I think one was
> reported).
> 
> When the question of early allocation for wide came up recently (I don't recall if it was on the list, in private
> email, in conversation or what, sorry) my feedback was to ask whether wide satisfies the stability requirement given
> in RFC 7120 Section 2 (c). Certainly if there is need for an allocation for wide and it can satisfy the RFC 7120
> requirements, let's do it. If it can't satisfy the requirements, read on:
> 
> > So to me the problem we need to solve is how to allow early implementations for any proposal on the table
> especially now when we have no two but at least 8 production BGP implementations (and growing). Forbidding it does
> I expect we will be discussing this at our upcoming meeting, although that's no reason not to continue the
> conversation on the list right now, on the contrary. Jeff has also written a draft that tries to address the problem,
> he posted a pointer to it yesterday, https://datatracker.ietf.org/doc/draft-haas-idr-extended-experimental/
> 
> Thanks,
> 
> --John

---

From: Keyur Patel <[email-masked]>
Date: Tue, 1 Nov 2016 17:03:22 +0000

+1. 

Regards,
Keyur

Sent from my iPhone

> On Nov 1, 2016, at 9:44 AM, Jakob Heitz (jheitz) <[email-masked]> wrote:
>

---

From: [email-masked]
Date: Tue, 01 Nov 2016 17:04:10 +0000

October 31, 2016 10:19 PM, "John G.Scudder" <[email-masked]> wrote:
> If you support or oppose adoption please reply indicating so. Reasons for your position are
> helpful, as volunteering to review, comment, and/or shepherd. As an aside, I will note that I don't
> think the WG has the option of doing nothing, so if you oppose adoption please address what you
> think should be done instead.
> 

Support

---

From: Job Snijders <[email-masked]>
Date: Tue, 1 Nov 2016 18:07:13 +0100

Keyur, Patel, this is not a thread about -wide- early allocation...

---

From: Jared Mauch <[email-masked]>
Date: Tue, 1 Nov 2016 13:15:43 -0400

> On Nov 1, 2016, at 10:17 AM, Robert Raszuk <[email-masked]> wrote:
> 
> So the point of the document is punishment for early attempts to implement anything not to technically address the problem at hand. Thx for clarification ...

No, punishment is reading the IDR list.  :-)

You can look for malice and find it wherever you want, even where none is found.  Documenting known issues will help those in the future.  It may not prevent history from being repeated, but attempts to prevent repeats are valuable.

- Jared

---

From: Jared Mauch <[email-masked]>
Date: Tue, 1 Nov 2016 13:23:13 -0400

> On Nov 1, 2016, at 11:14 AM, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Well I think this is completely different problem regardless on how the types/codepoints will be allocated. 
> 
> That was not what I have tried to express ... I suggested to assign all detected points to the drafts they belong as early allocation rather then to deprecate them. Result is the same - geo will not be allocated code point which is already used. 
> 
> So is 32 final code point for Large or early allocated one. If what LC got is final one why geo would need to ask for early allocation vs final one :) ? 

My suggestion is that authors should promptly request attributes and disclose which ones they’re using in testing for documentation.  It’s always easier to help find “who broke the internet” if it’s written down somewhere vs tracking down BGP updates, but both have been done for years.

None of this seems unreasonable, but some of the positions coming from you (Robert) seem to be outside of the WG and industry documented norms.  I saw a lot of this during the -large- vs -wide- discussion and found it troubling.  I’m personally grateful for the WG chairs in that discussion, as well as here in highlighting what is outside the WG process/norms.

- Jared

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 1 Nov 2016 13:34:06 -0400

On Nov 1, 2016, at 1:07 PM, Job Snijders <[email-masked]> wrote:
> this is not a thread about -wide- early allocation...

Right.

Also, Jeff (wearing his coauthor of wide hat) just commented less than an hour ago that wide's not ready yet (per the requirements we've discussed recently):

> Robert and I will be discussing reverting the most recent changes to the common header in our attempt to get that onto Large communities.  That should put the document back in harmony with the like…

So, please curb your enthusiasm while remaining ready to provide support for an early allocation for wide when the authors are ready (sounds like that may be soon).

Regards,

--John

---

From: t.petch <[email-masked]>
Date: Tue, 1 Nov 2016 17:44:27 +0000

Oppose

We all know what deprecate means which, based on recent discussions of
other topics on this list, means we are using many divergent
ones in our assessment of this I-D.

'deprecate' is a technical term in the processes of the IETF.  You need
to define it, or better, use the existing definition.

That definition is in
 draft-leiba-cotton-iana-5226bis-18
which therefore MUST/SHALL be/is REQUIRED to be a Normative Reference,
and yes, that means waiting for that to become an RFC before this can
advance; which interaction I see as a necessity.

Otherwise, we haven't a clue what we are adopting.  Well we have, but it
is about a dozen different clues.

Likewise, but not so critical at this stage, having an RFC that starts
' This document requests IANA   ..'
will look, well, not very sensible.  If you believe in what you are
doing, then I would like you to state it as a fact.
'This memo changes the status of ... in the IANA Registry to
'deprecated'

And what you have at present sits oddly with the IANA Considerations.
Usually, the latter says
'IANA is asked to ...'
which is edited by the RFC Editor
'IANA has ...'

Yet you have an IANA Considerations of
'IANA has  ...
Back to front, IMHO.

Tom Petch

----- Original Message -----
From: "John G. Scudder" <[email-masked]>
To: "Jeffrey Haas" <[email-masked]>
Cc: "IETF IDR Working Group" <[email-masked]>
Sent: Tuesday, November 01, 2016 4:20 PM

> > IANA did specifically request an RFC to reference although they
stopped short of explicitly saying "if you don't promise to give us a
document, we won't do this action". I have asked them to clarify and
will report back, but I suggest that for now the WG should assume that
we do actually need to publish draft and progress it to RFC.
>
> Update: Michelle @ IANA confirms that they do require RFC for
deprecation from a Standards Action registry but agrees there is no
documentation of this requirement specific to deprecation, they've just
inferred it from the requirement to assign one. She says she'll bring it
up on the Thursday IESG telechat.

---

From: Job Snijders <[email-masked]>
Date: Tue, 1 Nov 2016 19:00:47 +0100

On Tue, Nov 01, 2016 at 05:44:27PM +0000, t.petch wrote:
> other topics on this list, means we are using many divergent ones in
> our assessment of this I-D.
> 
> 'deprecate' is a technical term in the processes of the IETF.  You
> need to define it, or better, use the existing definition.

Why does it need to be defined? Are you saying that it is unclear what
the existing "deprecated" entries in
http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-2
mean?

> That definition is in draft-leiba-cotton-iana-5226bis-18 which
> therefore MUST/SHALL be/is REQUIRED to be a Normative Reference, and
> yes, that means waiting for that to become an RFC before this can

I am confused, it appears you assign normative value to something that
as of yet is a draft? Why is there a dependency? Can you also point out
which specific section of draft-leiba-cotton-iana-5226bis-18 you are
referring to?

For the working group's overview: I've taken as example:
https://tools.ietf.org/html/rfc6938 . This document does not contain
RFC2119 language.

> ' This document requests IANA   ..' will look, well, not very
> sensible.  If you believe in what you are doing, then I would like you
> to state it as a fact.  'This memo changes the status of ... in the
> IANA Registry to 'deprecated'

A stylistic comment wrapped around "if you believe in what you are
doing", .. really?

> Yet you have an IANA Considerations of

I can update the grammatical tense. No big deal.

Kind regards,

Job

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 1 Nov 2016 14:20:11 -0400

Tom,

I'm confused by your message. 

It appears to relate to the proposed adoption of draft-snijders-idr-deprecate-30-31-129 and not to my most recent message regarding IANA process at all, even though you followed up to, and quoted, mine. I'll proceed on that assumption.

I agree that it's unfortunate there is apparently no referenceable definition of "deprecate" but on the other hand, this has not impeded many code points from being deprecated in the past. Somehow we have muddled through. I suppose it wouldn't be the end of the world to do as you suggest and normatively reference 5226bis even if it means sitting in downref indefinitely, because I think IANA will be willing to mark the code points deprecated on the strength of the internet draft, following the early (de!) allocation process. But also think it would be fine to follow the other branch of your suggestion and quote their definition, removing the downref.

Apart from the question of providing a reference/definition for what "deprecate" means (which I thought we'd already settled), the rest seems to be editorial minutiae. 

None of these things (request for a definition, other editorial issues) seems to me to be a basis for "Oppose". The question before the WG is really "do we want to deprecate these code points", and that's what I'd most like to see people engage with in deciding to adopt (or not) the document. 

To be clear, for purposes of this adoption call, I'm assuming we are using the 5226bis Section 9.6 definition (or "definition") you refer to, viz.:

   Specific entries in a registry can be marked as "obsolete" (no longer
   in use) or "deprecated" (use is not recommended).

If someone who has already responded did so on the basis of thinking that "deprecated" means something other than "use is not recommended" they may of course revise their position.

Regards,

--John
 
> On Nov 1, 2016, at 1:44 PM, t.petch <[email-masked]> wrote:
> 
> Oppose
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 1 Nov 2016 19:32:02 +0000

I support it for all these attribute codes.
However, we should give the users of 129, 241, 242 and 243 a chance to ask for a reservation of the codes they are using.
At least give them the option to reserve them once they are deprecated by this document.

Thanks,
Jakob.

> From: Idr [mailto:[email-masked]] On Behalf Of Job Snijders
> Sent: Tuesday, November 01, 2016 6:33 AM
> To: John G.Scudder <[email-masked]>
> Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129
> 
> Dear working group,
> 
> > If you support or oppose adoption please reply indicating so. Reasons for your position are helpful, as
> volunteering to review, comment, and/or shepherd. As an aside, I will note that I don't think the WG has the option
> of doing nothing, so if you oppose adoption please address what you think should be done instead.
> >

---

From: Jared Mauch <[email-masked]>
Date: Tue, 1 Nov 2016 16:40:06 -0400

> On Nov 1, 2016, at 3:32 PM, Jakob Heitz (jheitz) <[email-masked]> wrote:
> 

There seems to be carrot here, which I’m in favor of.  We can always remove items during WG LC if they attain their allocation through implementations.

- Jared

---

From: t.petch <[email-masked]>
Date: Wed, 2 Nov 2016 10:32:45 +0000

John

Yes, I really was replying to the adoption call, opposing adoption on
the grounds that the I-D as it stands is insufficiently precise.

I first saw IANA using 'deprecated' as a status in 2013 and this led to
a discussion on the main IETF list, that the term had been in use for a
while in SMI but that the SMI definition seemed inappropriate for the
use to which IANA were now putting it and that we needed a definition.

The then current version of
draft-leiba-cotton-iana-5226bis
was put foward as the place to define 'deprecated', IETF-wide, and
AFAIK, that has been the practice since.

So we have a definition that has been in use for three years, in the
context of IANA, which is, to quote,
"  Specific entries in a registry can be marked as "obsolete" (no longer
   in use) or "deprecated" (use is not recommended). "

I believe that this I-D cannot be understood without reference to that
definition, hence my opposition to an I-D that leaves the interpretation
of 'deprecated' up to the reader (who may assume that the SMI definition
is appropriate).

I also wonder if those agreeing to adoption still do so with that as the
meaning of the term; perhaps they do, but Robert questioned whether or
no 'deprecated' was really the right status and I am of like mind,
although my reasons may differ from his.

Tom Petch

----- Original Message -----
From: "John G. Scudder" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "IETF IDR Working Group" <[email-masked]>
Sent: Tuesday, November 01, 2016 6:20 PM
Subject: Re: [Idr] Working group adoption call for
draft-snijders-idr-deprecate-30-31-129

Tom,

It appears to relate to the proposed adoption of
draft-snijders-idr-deprecate-30-31-129 and not to my most recent message
regarding IANA process at all, even though you followed up to, and
quoted, mine. I'll proceed on that assumption.

I agree that it's unfortunate there is apparently no referenceable
definition of "deprecate" but on the other hand, this has not impeded
many code points from being deprecated in the past. Somehow we have
muddled through. I suppose it wouldn't be the end of the world to do as
you suggest and normatively reference 5226bis even if it means sitting
in downref indefinitely, because I think IANA will be willing to mark
the code points deprecated on the strength of the internet draft,
following the early (de!) allocation process. But also think it would be
fine to follow the other branch of your suggestion and quote their
definition, removing the downref.

Apart from the question of providing a reference/definition for what
"deprecate" means (which I thought we'd already settled), the rest seems
to be editorial minutiae.

None of these things (request for a definition, other editorial issues)
seems to me to be a basis for "Oppose". The question before the WG is
really "do we want to deprecate these code points", and that's what I'd
most like to see people engage with in deciding to adopt (or not) the
document.

To be clear, for purposes of this adoption call, I'm assuming we are
using the 5226bis Section 9.6 definition (or "definition") you refer to,
viz.:

If someone who has already responded did so on the basis of thinking
that "deprecated" means something other than "use is not recommended"
they may of course revise their position.

Regards,

--John

> 'deprecate' is a technical term in the processes of the IETF.  You
need

---

From: Gert Doering <[email-masked]>
Date: Wed, 2 Nov 2016 11:37:46 +0100

Hi,

> of 'deprecated' up to the reader (who may assume that the SMI definition

So what you're saying is "add a link to that reference, and all is good"?

Why is that interfering with draft *adoption*?  Sounds more like wordsmithing
for the then-WG document before WGLC to me, not a fundamental reason to not
accept the draft.

Gert Doering
        -- NetMaster

---

From: Job Snijders <[email-masked]>
Date: Wed, 2 Nov 2016 12:27:54 +0100

> for the then-WG document before WGLC to me, not a fundamental reason to not

No, it appears that Tom is saying that IDR cannot deprecate codepoints
until IETF/IANA have developed a deeper understanding of the word
"deprecate".

Tom, can you confirm that in retrospect you would've opposed
https://tools.ietf.org/html/rfc6938 too, and that it is not clear to you
what that RFC accomplishes?

Tom, do you have an alternative strategy to prevent value 30 from being
assigned as path attribute value to the next early allocation, other
then adopting and publishing draft-snijders-idr-deprecate-30-31-129?

Kind regards,

Job

---

From: t.petch <[email-masked]>
Date: Wed, 2 Nov 2016 12:48:34 +0000

----- Original Message -----
From: "Job Snijders" <[email-masked]>
To: "Gert Doering" <[email-masked]>
Cc: "t.petch" <[email-masked]>; "IETF IDR Working Group"
<[email-masked]>
Sent: Wednesday, November 02, 2016 11:27 AM
> until IETF/IANA have developed a deeper understanding of the word

Job, Gert

I think that that may go beyond what I have said.

If draft leiba-cotton becomes an RFC soon, then a Normative Reference to
that would be my preferred option, so that IDR is on the same page as
IANA and the rest of the IETF.  Note the leiba-cotton is in state IESG
Evaluation AD follow up for 163 days with Pete Resnick holding a DISCUSS
and Terry Manderson as AD so it is Pete (or Terry) you need to light a
fire under.

I did however mention another possibility in my first post, of putting
in our own definition so that it is clear what is intended (if only to
those wishing to adopt the I-D).  Given 20 years of (different) usage in
SMI, which some readers will be familiar with, I think we need a
definition so include one!  We could just lift the existing text from
leiba-cotton then, if that does not change between now and whenever
leiba-cotton becomes an RFC, we will be in line with them - which is
good.

I think that IETF/IANA developed all the understanding that is needed of
the meaning of 'deprecated' in 2013 and all we have to do now is to use
that understanding.

Tom Petch

---

From: Job Snijders <[email-masked]>
Date: Wed, 2 Nov 2016 14:03:39 +0100

> the meaning of 'deprecated' in 2013 and all we have to do now is to use

Thanks for your feedback, I'll respin the draft into a -02 version based
on this discussion and submit it later today.

Kind regards,

Job

---

From: "Dickinson, Ian" <[email-masked]>
Date: Wed, 2 Nov 2016 13:48:03 +0000

I support adoption of this draft

Ian

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of John G.Scudder
Sent: 31 October 2016 21:19
To: IETF IDR Working Group <[email-masked]>
Subject: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129

Hi Everyone,

Thanks,

--John

Abstract

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr
Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

---

From: Job Snijders <[email-masked]>
Date: Wed, 2 Nov 2016 15:12:48 +0100

On Wed, Nov 02, 2016 at 02:03:39PM +0100, Job Snijders wrote:
> > If draft leiba-cotton becomes an RFC soon

In previous discussion about -large- you said, and I quote:

    "I proposed 'registry' and 'group' because that is what
    draft-leiba-cotton-iana-5226bis recommends (one day, perhaps in the
    coming decade, that I-D will become an RFC but in the meantime, it
    ^^^^^^^^^^^^^
    is the best guidance we have:-)."

Despite the smiley, I took the 'decade' part as a serious remark about
the document's volatility.

> > I think that IETF/IANA developed all the understanding that is
> > needed of the meaning of 'deprecated' in 2013 and all we have to do
> > now is to use that understanding.
> 
> Thanks for your feedback, I'll respin the draft into a -02 version
> based on this discussion and submit it later today.

Since we are past IETF Draft submission cutoff date for IETF97 in Seoul,
I can't submit the draft. However this would be my proposed -02 version
based on the feedback so far received in this thread.

https://raw.githubusercontent.com/job/idr-deprecate/master/draft-snijders-idr-deprecate-30-31-129-02.txt

Changelog

    o add 241, 242, 243 codepoints
    o add "use is not recommended" (copied im verbatim) from informative
        reference leiba-cotton-iana-5226bis
    o Change grammatical tense 

let me know your thoughts.

Kind regards,

Job

---

From: heasley <[email-masked]>
Date: Wed, 2 Nov 2016 16:22:20 +0000

>         reference leiba-cotton-iana-5226bis

I'll bet a beer that IANA writes "deprecated" in the registry :)

---

From: t.petch <[email-masked]>
Date: Wed, 2 Nov 2016 17:08:00 +0000

----- Original Message -----
From: "heasley" <[email-masked]>
To: "Job Snijders" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 02, 2016 4:22 PM
> I'll bet a beer that IANA writes "deprecated" in the registry :)

A fairly safe bet since it is there already (for 30!).

Tom Petch

---

From: John Scudder <[email-masked]>
Date: Thu, 3 Nov 2016 19:30:37 +0000

> Update: Michelle @ IANA confirms that they do require RFC for deprecation from a Standards Action registry but agrees there is no documentation of this requirement specific to deprecation, they've…

Concluding update: Michelle says IESG confirmed the RFC requirement; she will update 5226bis to reflect.

--John

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 3 Nov 2016 21:22:57 -0400

John: 

My understanding with the IESG and IANA is that this is true.   The best
reference is the BIS for RFC226bis below: 

https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-11

The RFC5226bis-11.txt got stalled due to the IESG wandering if the revision
is needed.  Based on our experience, I think it is needed.  Alvaro will kick
off this work, but the process of updating a "process" document should not
impede this document's process.  We need to think outside the box. 

I suggest we complete this adoption of
draft-snijders-idr-deprecate-30-31-129 draft by 11/13/2016, and do a WG LC
on the draft directly following this process draft (11/14 to 11/28).    This
should allow the draft-idr-large-communities to have the necessary registry
"glue" ready so the IESG publication of large communities can go quickly.

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of John G. Scudder
Sent: Tuesday, November 1, 2016 10:24 AM
To: Robert Raszuk
Cc: IETF IDR Working Group
Subject: Re: [Idr] Working group adoption call for
draft-snijders-idr-deprecate-30-31-129

AFAICT the function of the draft is simply to kick the IANA code point state
to "deprecated". It doesn't anchor it there for all time. Presumably a later
request can move the state to assigned or whatever, as we've previously
discussed. I don't think any update to the current "deprecate" document
would be needed to achieve this (I guess maybe the later document might list
this one in its "updates" header).

I'll confirm this understanding with IESG and IANA before the end of the WG
adoption call. (Unless someone can point me to chapter-and-verse of a
reference that explains the process clearly enough, unfortunately I have not
found such.)

Thanks,

--John

Hi Job,

Cheers,

R.

Dear working group,

OLD:

NEW:

Kind regards,

Job

On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote:

> If you support or oppose adoption please reply indicating so. Reasons for
your position are helpful, as volunteering to review, comment, and/or
shepherd. As an aside, I will note that I don't think the WG has the option
of doing nothing, so if you oppose adoption please address what you think
should be done instead.
> P.S.:
https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 3 Nov 2016 21:50:47 -0400

Robert and others: 

The draft-snijders-idr-deprecate-30-31-129 draft should not delay an
official request for the Wide Community implementation.   The three
requirements are: 

1)      Stable draft, 

2)      1 or more Implementation, and testing work toward interoperability.
Implementers must be able to switch to another reference point if needed. 

3)      Approval by the IDR working group for early adoption. 

https://www.ietf.org/mail-archive/web/idr/current/msg16814.html

What is needed is a stable draft.   I recommend you work with Jie Dong, Mach
Chen, and Shunwan Zhang to make sure the next Wide communities draft aligns
with their implementation.  At that point, these teams can apply for an
early allocation. 

If you complete a stable draft by the beginning of IETF week, and the
implementers align their code with your draft - we can begin step 3.  Your
challenge is to get the stable specification that aligns with the code work
so the code work can progress quickly. 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Thursday, November 3, 2016 9:23 PM
To: 'John G. Scudder'; 'Robert Raszuk'
Cc: 'IETF IDR Working Group'
Subject: Re: [Idr] Working group adoption call for
draft-snijders-idr-deprecate-30-31-129

John: 

 

Sue 

Thanks,

--John

Hi Job,

Cheers,

R.

Dear working group,

OLD:

NEW:

Kind regards,

Job

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 3 Nov 2016 22:34:28 -0400

Robert: 

<chair hat on> 

At the time RFC7120 was published, the IDR chairs and the RTG ADs invited all drafts that were written and published prior to that point to submit requests for early allocation with a simple IANA process.   Prior to RFC7210, there was an way to get this drafts done if we ask the IESG to review the documents.  The early allocation process did not start with RFC7120, but was simplified.   

By the way, draft-vandevelde-idr-remote-next-hop-00.txt was included in: https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/.   You will find this on the IDR web page.   On the  draft-marques-l3vpn-mcast-edge-01,  if the authors are working on this draft – then it is a bess draft.   If the authors have problems with the early code point allocation, then can copy me and I will transfer information to the appropriate BESS chairs.  I will ask the ADs to present a quick summary of Early Allocation processes to the whole Area so that people will have a better understanding of Early Allocation.  I realize the process may be frustrating to you and others.  I am willing to help solve the problems for specific drafts or via a proposal such as Jeff Haas made for private space.  However, this discussion should be done in a separate discussion thread or privately. 

<chair hat off> 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, November 1, 2016 11:04 AM
To: John G. Scudder
Cc: IETF IDR Working Group
Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129

​John,​

...

Thx,
R.

​

---

From: t.petch <[email-masked]>
Date: Fri, 4 Nov 2016 13:10:30 +0000

----- Original Message -----
From: "Susan Hares" <[email-masked]>
To: "'John G. Scudder'" <[email-masked]>; "'Robert Raszuk'"
<[email-masked]>
Cc: "'IETF IDR Working Group'" <[email-masked]>
Sent: Friday, November 04, 2016 1:22 AM

Sue

The reason I am being a bit 'snarky' on this adoption call is my concern
that there may be differing views of what 'deprecate' means.  For
example, the SMI world gives it a different (and IMO unsuitable) meaning
which some on this list will know.  Even the 5226bis text might not be
quite right.  Robert did query whether or not 'deprecate' was suitable.

If we take 5226bis as gospel, then 'deprecate' is probably the option to
choose but I wish that there were more alternatives.

I was about to post to the main IETF list and Terry Mandelson(as
responssible AD) about 5226bis (again:-) but the list has erupted with a
discussion about DMARC(again) so I will hold off and see what develops.

Tom Petch

> AFAICT the function of the draft is simply to kick the IANA code point
state
> Reason being that if any of the applications they have been squatted
on
> The other alternative would be to allocate them to those applications
now
> In any of the above Large Communities will get virgin BGP attribute
type
> >    attributes values: 30, 31 and 129.

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

---

From: Job Snijders <[email-masked]>
Date: Fri, 4 Nov 2016 14:40:43 +0100

For clarity, do you still oppose the proposed -02 i shared earlier?

Job

On Friday, 4 November 2016, t.petch <[email-masked]> wrote:

> From: "Susan Hares" <[email-masked] <javascript:;>>
> To: "'John G. Scudder'" <[email-masked] <javascript:;>>; "'Robert
> Raszuk'"
> <[email-masked] <javascript:;>>
> Cc: "'IETF IDR Working Group'" <[email-masked] <javascript:;>>
> > From: Idr [mailto:[email-masked] <javascript:;>] On Behalf Of
> John G. Scudder
> > On Nov 1, 2016, at 10:02 AM, Robert Raszuk <[email-masked]
> <javascript:;>> wrote:
> >
> >
> >
> > Hi Job,
> >
> >
> >
> > On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders <[email-masked]
> <javascript:;>>
> wrote:
> >
> > Dear working group,
> >
> > > [email-masked] <javascript:;>
> > [email-masked] <javascript:;>
> > [email-masked] <javascript:;>
> [email-masked] <javascript:;>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 4 Nov 2016 11:11:46 -0400

Tom: 

<WG chair hat on> 
The IETF list discussion of RFC5226bis is the right place to make progress
on this work.   Alvaro Retana (the AD for IDR) has agreed to help push this
along as well.  Send Alvaro notes on your concerns.   With a reference to
RFC5226bis, then draft-snijders-idr-deprecate-30-31-129 will be able to
"deprecate" the code points at this point.  When the RFC5226bis comes out,
Michelle Cotton (and all the great folks at IANA) will adjust the tables. 

<WG Chair hat off> 
<individual contributor hat on> 
As the IDR list has indicated, deprecate needs to be carefully defined.  I
appreciate you working on this topic on the IETF list.  Otherwise, we'll
have this conversation again with 2-3 years. 
</individual contributor hat off> 

Sue Hares   

----- Original Message -----
From: "Susan Hares" <[email-masked]>
To: "'John G. Scudder'" <[email-masked]>; "'Robert Raszuk'"
<[email-masked]>

Sue

The reason I am being a bit 'snarky' on this adoption call is my concern
that there may be differing views of what 'deprecate' means.  For example,
the SMI world gives it a different (and IMO unsuitable) meaning which some
on this list will know.  Even the 5226bis text might not be quite right.
Robert did query whether or not 'deprecate' was suitable.

Tom Petch

state
on
now
type

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 14 Nov 2016 17:05:25 +0900

The WG has consensus to adopt the document. Job, please resubmit as draft-ietf-idr- etc.

Also, I can't see why we wouldn't start a WGLC for it. We can discuss at our meeting tomorrow.

Thanks,

--John

> On Nov 1, 2016, at 6:18 AM, John G.Scudder <[email-masked]> wrote:
> 
> Hi Everyone,
>