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

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

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" <[e-mail]>
To: "t.petch" <[e-mail]>
Cc: "IETF IDR Working Group" <[e-mail]>
Sent: Tuesday, November 01, 2016 6:20 PM
Subject: Re: [Idr] Working group adoption call for
draft-snijders-idr-deprecate-30-31-129


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 <[e-mail]> wrote:
>
> 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" <[e-mail]>
> To: "Jeffrey Haas" <[e-mail]>
> Cc: "IETF IDR Working Group" <[e-mail]>
> Sent: Tuesday, November 01, 2016 4:20 PM
>
>
>> On Nov 1, 2016, at 10:53 AM, John G. Scudder <[e-mail]> wrote:
>>> On Nov 1, 2016, at 10:40 AM, Jeffrey Haas <[e-mail]> wrote:
>>>> 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.
>>>
>>> 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.
>>
>> Again, for now the WG should assume we do need an RFC.
>>
>> --John
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>