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

[t.petch <[e-mail]>]

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

> 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

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

>
>
>
> Sue
>
>
>
> From: Idr [mailto:[e-mail]] 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
>
>
>
> On Nov 1, 2016, at 10:02 AM, Robert Raszuk <[e-mail]> 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 <[e-mail]>
wrote:
>
> 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,
> >
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>
>
>
>
>


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


> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>