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

[Job Snijders <[e-mail]>]

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

Job

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

> ----- Original Message -----
> From: "Susan Hares" <[e-mail] <javascript:;>>
> To: "'John G. Scudder'" <[e-mail] <javascript:;>>; "'Robert
> Raszuk'"
> <[e-mail] <javascript:;>>
> Cc: "'IETF IDR Working Group'" <[e-mail] <javascript:;>>
> 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] <javascript:;>] 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]
> <javascript:;>> 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]
> <javascript:;>>
> 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] <javascript:;>
> > > https://www.ietf.org/mailman/listinfo/idr
> >
> > _______________________________________________
> > Idr mailing list
> > [e-mail] <javascript:;>
> > https://www.ietf.org/mailman/listinfo/idr
> >
> >
> >
> >
> >
> >
>
>
> ------------------------------------------------------------------------
> --------
>
>
> > _______________________________________________
> > Idr mailing list
> > [e-mail] <javascript:;>
> > https://www.ietf.org/mailman/listinfo/idr
> >
>
> _______________________________________________
> Idr mailing list
> [e-mail] <javascript:;>
> https://www.ietf.org/mailman/listinfo/idr
>