Re: [Iasa20] Odd deprecations in draft-ietf-iasa2-consolidated-upd-05

[John C Klensin <[e-mail]>]

Robert, Brian, Russ, Ted, and other WG participants,

I've been effectively off email since last weekend and am likely
to continue to be off for a few more days.  However, since the
question of what documents should be reflected in
draft-ietf-iasa2-consolidated-upd has come up again, two things
may be worth mentioning (neither is new):

(1) This document originated because reissuing a large set of
documents, one at a time, to reflect almost (but not quite)
trivial terminology or equivalent changes seemed like a bad
idea.  The reasons weren't to save bits or RFC numbers, but to
make it clear to readers -- both contemporary and ones looking
back historically several years in the future -- what was
changing and how the new system and ways of doing things fit
with the previous one.  That could have been done by reworking
the other draft new documents to include more clarity about, and
better explanations of, changes, but that would have required
more work than this document did and made it harder, at least in
the absence of a grand, consolidated, IASA2.0 document that
explained and referenced everything else, for readers to figure
out what they needed to read and understand and what were just
procedural details or housekeeping.   My hope is that we are now
down to the maximum number of revised documents that are
actually necessary (or a very few more) plus this one.

In that regard, the choices that were made are part of an old
problem.  "Deprecated" is not defined in the IETF and the
definitions of and relationships among "Historic", "Obsolete",
and "Updates" have never been entirely clear (see the recent
IESG note about the latter).   That has been an advantage in
some ways because, if we really dig into those issues to try to
get the terminology exact, we will almost certainly end up
inventing new categories and then spending time debating _their_
applicability.    On the other hand, what should be said is up
to the WG (see #2 below).

As at least one note mentioned, in principle, we could do almost
everything this I-D does by errata.  I think, personally, that
would be a bad idea: we have little evidence that people read
errata until they are explicitly pointed out on a per-document
basis, the changes are changes and not errors in the documents
as originally published, and, if we are concerned about the
historical record, we have few guarantees that errata-like
metadata will remain obviously bound to the relevant documents
(especially given that they are not obviously bound to them
today).

My own preference is that this document contain a (definitely
non-normative) appendix that identifies the documents that were
sort of borderline as to whether they needed inclusion here,
separate publications, or just notes somewhere.  IIR, I
suggested that several weeks and got no response, much less
traction, and basically said "ok, less work for me" to myself.

(2) I am very much just trying to be the helpful but passive
editor of this document and will do whatever the WG
(specifically the WG Chairs) tell me to do.  However, I do note
that this is almost the first time I've heard from anyone but
Jason, Brian, Bob Hinden, and whomever concluded that this IETF
Stream document should not mention the IAB-issued ones.
Nonetheless, documents have been added to and removed from this
piece and its "updates" and "obsoletes" list with each iteration
of the I-D.  It would be good if we had a plan that converged
rather than people showing up with each iteration and saying
"these should be out and/or those should be in".

best,
   john




On Wed, 13 February 2019 00:49 UTC, Brian E Carpenter
<[e-mail]> wrote:


> On 2019-02-13 10:30, Ted Hardie wrote:
>> On Tue, Feb 12, 2019 at 1:15 PM Brian E Carpenter
>> <[e-mail]
>> <mailto:[e-mail]>> wrote:
>> 
>>     Hi Robert,
>> 
>>     3929 has no explicit time limit, which these days is
>>     considered bad practice for procedural experiments. So
>>     yes, it isn't this WG's job to decide. But the IETF can
>>     of course decide. If it's clear that this is subject to
>>     Last Call comments, is there really a problem?
>> 
>> I don't see how the lack of experimental deadline makes it
>> this WG's job to decide--can you clarify your thinking?  
> 
> I agree entirely - please re-read my sentence, whose syntax
> could be improved ;-).
>...