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

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

----- Original Message -----
From: "Job Snijders" <[e-mail]>
To: "Gert Doering" <[e-mail]>
Cc: "t.petch" <[e-mail]>; "IETF IDR Working Group"
<[e-mail]>
Sent: Wednesday, November 02, 2016 11:27 AM
> On Wed, Nov 02, 2016 at 11:37:46AM +0100, Gert Doering wrote:
> > On Wed, Nov 02, 2016 at 10:32:45AM +0000, t.petch wrote:
> > > 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).
> >
> > 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.
>
> No, it appears that Tom is saying that IDR cannot deprecate codepoints
> until IETF/IANA have developed a deeper understanding of the word
> "deprecate".

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

>
> 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