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

From: Robert Sparks <[email-masked]>
Date: Tue, 12 Feb 2019 14:23:14 -0600

I realize this is a bit late (since the document has been pubreq'ed), 
but I wanted to call this out before IETF Last Call. A re-review of some 
of the documents going through the IAB stream caused me to read this one 
more closely this week. Apologies for not being active on the list when 
this was discussed.

I was surprised that this document was obsoleting things like RFC3929 ( 
Alternative Decision Making Processes for Consensus-Blocked Decisions in 
the IETF ) and RFC 4633 ( Experiment in Long-Term Suspensions From 
Internet Engineering Task Force (IETF) Mailing Lists ).

It seems outside the remit of this working group to deprecate/obsolete 
these (or perhaps any) RFCs (whether they should be or not).

I also note that the body had five RFCs that it asks to deprecate and 
move to historic, but only three of those listed as obsoleted.

RjS

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Feb 2019 10:14:59 +1300

Hi Robert,
> these (or perhaps any) RFCs (whether they should be or not).

Clearly, directly relevant RFCs may need to be obsoleted, but I agree
that these two in particular are essentially "collateral damage".
3716, on the other hand, is just an old Informational on how we used
to administer the IETF, so it needs to go.

4633 is explicitly time limited, so obsoleting it seems like routine
book keeping that the IESG could do at any time. All the same, it needs
to be called out during Last Call.

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?

> move to historic, but only three of those listed as obsoleted.

You are quite right about those other two. They should be in a separate
list which is essentially FYI. They don't need any status change.

3979 is not out of date. Its bullet point correctly says:

o  RFC 3979 [RFC3979], that is updated by [RFC8179], which corrects
   mentions of the IETF Executive Director to the IETF Secretariat

so it should not be deprecated.

4879 is already obsoleted by 8179. So its bullet point should say:

o  RFC 4879 [RFC4879], that is obsoleted by [RFC8179], which corrects
   mentions of the IETF Executive Director to the IETF Secretariat.

Regards
   Brian
> 
> RjS
> 
> _______________________________________________
> iasa20 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iasa20
>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 12 Feb 2019 15:21:51 -0600

Inline:

>     mentions of the IETF Executive Director to the IETF Secretariat.
There's also a call at the end of section 4 to move all 5 of the docs it 
calls out to historic...

---

From: Russ Housley <[email-masked]>
Date: Tue, 12 Feb 2019 16:29:29 -0500

Brian:

> 3716 [...] is just an old Informational on how we used

Really, I do not agree.  RFC 3716 is the report of a committee formed by the IETF Chair and the IAB Chair at the time.  It is informational, and it was used as inout to develop other BCP process documents.  What does it even mean to deprecate such a committee report?

Further, RFC 3716 only contains a single reference to "Executive Director", and that is a historical note about where the position was homed.  So, it is not clear to me how this got sucked up in the IASA2 activity.

Russ

---

From: Ted Hardie <[email-masked]>
Date: Tue, 12 Feb 2019 13:30:59 -0800

On Tue, Feb 12, 2019 at 1:15 PM Brian E Carpenter <
[email-masked]> wrote:

> I don't see how the lack of experimental deadline makes it this WG's job
to decide--can you clarify your thinking?  In this document's case, it is
hard to call the experiment done when it has never been exercised.  We can
say that the threat of it has been useful, but that the actual methods are
"not proven" (in the Scots legal sense).

My take on why they were included was more that they included the phrase
"IETF Executive Director"; the doc says that specific methods require
telling the IETF Executive Director something (e.g. that you volunteer to
serve).  The working group concluded that this didn't mean the new
Executive Director, but meant the Secretariat role that used that term
before.  I personally would fix that with an erratum, rather than
deprecation or obsolescence.

I may, of course, have a slight bias here.

Ted

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Feb 2019 13:39:51 +1300

> Really, I do not agree.  RFC 3716 is the report of a committee formed by the IETF Chair and the IAB Chair at the time.  It is informational, and it was used as inout to develop other BCP process do…

It means that it's no longer applicable, which I think is correct. It might well be of interest to a social historian, so "historic" doesn't seem inappropriate to me. That's the only word that will appear in the RFC index and other metadata.
 
> Further, RFC 3716 only contains a single reference to "Executive Director", and that is a historical note about where the position was homed.  So, it is not clear to me how this got sucked up in th…

Only because it uses the term ED in the now outmoded sense. My fault, I ran the grep command that found it.

   Brian

> .

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Feb 2019 13:49:31 +1300

On 2019-02-13 10:30, Ted Hardie wrote:
> On Tue, Feb 12, 2019 at 1:15 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Robert,
> 
> 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 ;-).

> In this document's case, it is hard to call the experiment done when it has never been exercised.  We can say that the threat of it has been useful, but that the actual methods are "not proven" (in the Scots legal sense).

Yes. But if we (the IETF, not this WG) want that threat to continue, surely "experimental" is the wrong status?
  
> My take on why they were included was more that they included the phrase "IETF Executive Director"; the doc says that specific methods require telling the IETF Executive Director something (e.g. that you volunteer to serve).  The working group concluded that this didn't mean the new Executive Director, but meant the Secretariat role that used that term before.  I personally would fix that with an erratum, rather than deprecation or obsolescence.

That's a perfectly defensible position, which is why I suggested calling this out explicitly in IETF Last Call. 
 
> I may, of course, have a slight bias here.

Regardless of that, I think we're agreeing that it isn't this WG's job to decide, but it probably *is* our job to point out the obsolete terminology.

Regards,
    Brian

---

From: Russ Housley <[email-masked]>
Date: Thu, 14 Feb 2019 18:19:07 -0500

> It means that it's no longer applicable, which I think is correct. It might well be of interest to a social historian, so "historic" doesn't seem inappropriate to me. That's the only word that will…

I would be much happier if it were "moved to historic" as opposed to "deprecated" for this situation.  However, see below.

> Only because it uses the term ED in the now outmoded sense. My fault, I ran the grep command that found it.

That is a fine way to create a list of documents that might need to be handled bu tthis WG.  But, this one is a false positive.

I think this any reference to RFC 3716 should be removed from draft-ietf-iasa2-consolidated-upd.  Since it contains no tasking to the Executive Director, I do not believe it falls under the charter of this WG.

Russ

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 15 Feb 2019 11:05:56 -0500

I started my AD review of this doc but it seems like the issues Robert raised need to get sorted out before I can do it properly. My take is below.

In terms of the document header, it doesn’t seem like this document should be obsoleting any other documents. The Obsoletes: header indicates a replacement version of the document being obsoleted [1]. The point of collecting together a set of updates here was precisely that these updates were not substantive enough to warrant obsoleting individual documents — otherwise that could have been done on a document-by-document basis, as with 4071 and 7437. So I would expect this document to have only an Updates: header, not an Obsoletes: header.

The updates as already explained in the document for 2028, 2418, 3005, 3710, and 6702 make sense to me. 

3979 and 4879 do not need to be touched by this document because they have been obsoleted by 8179 already. If people want to mention that in an appendix, that seems fine but not strictly necessary.

3929 seems like it should have the same treatment as 2028, 2418, 3710, and 6702 in Section 2, namely s/IETF Executive Director/Managing Director, Secretariat/. I agree with Ted’s logic there.

3716 and 4633 seem like they can be left alone without consequence. 4633’s incidence of “Executive Director" actually just quotes 2418, which this document is updating. And as Russ noted regarding 3716, it’s a historical record from a committe that existed at the time. If people wanted to move both of these to historic I don’t think that would be wrong, but I also doubt it’s worth the effort and would require a separate document.

Alissa
[1] https://www.ietf.org/blog/iesg-statement-designating-rfcs-historic/

> On Feb 12, 2019, at 3:23 PM, Robert Sparks <[email-masked]> wrote:
> 
> I realize this is a bit late (since the document has been pubreq'ed), but I wanted to call this out before IETF Last Call. A re-review of some of the documents going through the IAB stream caused me to read this one more closely this week. Apologies for not being active on the list when this was discussed.
> 
> I was surprised that this document was obsoleting things like RFC3929 ( Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF ) and RFC 4633 ( Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists ).
> 
> It seems outside the remit of this working group to deprecate/obsolete these (or perhaps any) RFCs (whether they should be or not).
> 
> I also note that the body had five RFCs that it asks to deprecate and move to historic, but only three of those listed as obsoleted.
> 
> RjS
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 15 Feb 2019 11:23:21 -0500

--On Tuesday, February 12, 2019 16:29 -0500 Russ Housley
<[email-masked]> wrote:

> Really, I do not agree.  RFC 3716 is the report of a committee
> formed by the IETF Chair and the IAB Chair at the time.  It is
> informational, and it was used as inout to develop other BCP
> process documents.  What does it even mean to deprecate such a
> committee report?

We have another meaning for that term, which is related to
terminology appropriate to Applicability Statements and what
would presumably be a "good idea while it lasted but it didn't
work out or was OBE" subcategory of "Not Recommended".   We use
A/S documents so infrequently as to forget they exist, but that
does not make it desirable to make them less useful.   I have no
idea what it means to deprecate a process document, whether a
committee report or not -- the procedure is in effect or it is
not in effect.   Unfortunately, we seem to have a category of
"in effect but usually or always ignored" too, but that doesn't
affect deprecation either.

On the other hand, there is no doubt in my mind that this report
is Historic, at least in the sense that it is of interest to
those who are trying to understand how we got here but that we'd
be very concerned if someone cane along today and wanted to
reference it normatively as an authority.

The question then becomes how to do that.  In principle, the
IESG can do it by a Last Call and action in the tracker and
metadata.    Would this document be a decent reference for such
an action and could approving it eliminate the need for an extra
IETF LC?  I think "yes"; YMMD.  Whether that is appropriate
and/or optimal or not is another question.   If people think it
isn't and separate action is appropriate, that is fine with me
as long as the IESG agrees to process it as Historic.   If they
don't want to do that or don't consider it a high priority, then
I think a comment in this document to the effect that the
Executive Director being referred to is the older function
rather than the new one is in order, is part of the price we pay
for reusing the term with a different meaning, and part of the
WG's mandate to clean up side-effects of the IASA transition.
Whether the phrasing in the I-D is optimal for that is, again,
another question but those who conclude it isn't are encouraged
to send text.

> Further, RFC 3716 only contains a single reference to
> "Executive Director", and that is a historical note about
> where the position was homed.  So, it is not clear to me how
> this got sucked up in the IASA2 activity.

See Brian's note(s) but the above reasoning suggests that its
getting sucked in was and is appropriate, at least unless the
IESG wants to move, now, to make 3716 Historic.

best,
    john

---

From: Russ Housley <[email-masked]>
Date: Fri, 15 Feb 2019 12:17:24 -0500

> IESG wants to move, now, to make 3716 Historic.

I have no problem with RFC 3716 being moved to historic, but that should not happen as part of the IASA2 effort.

Side note: Using "Executive Director" has already made this way more complicated that had we chosen other synonyms that were available before the LLC was stood up.

Russ

---

From: John C Klensin <[email-masked]>
Date: Sat, 16 Feb 2019 18:19:46 -0500

--On Friday, February 15, 2019 12:17 -0500 Russ Housley
<[email-masked]> wrote:

>...
> I have no problem with RFC 3716 being moved to historic, but
> that should not happen as part of the IASA2 effort.

Russ, 

I prefer that the IESG handle that separately so we are, up to
that point, in sync.  I also agree with Alissa that this
"consolidated" document should not be obsoleting most or all of
those old pieces, but should be moving them to historic.  The
problem with the latter is that I was trying to leave an
information chain. We don't seem to have either headers on RFCs
or even tracking information in RFC metadata about what
documents or actions resulted in something else becoming
Historic so, if one finds the older document, discovers that it
is no longer relevant, and tries to trace forward to what is,
that process is much harder than it should be unless the older
document is also obsoleted.

That is clearly a mess.   I believe it is the RFC Editor's mess
and Heather (copied) ought to be able to just figure out a way
to clean it up and get that implemented.  However I suspect that
at least one of the IESG, RSOC, or IAB would disagree and think
they needed to intervene, steer, or at least sign off (I'd be
delighted to be wrong about that).  It is rather clearly not an
IASA 2.0 mess or a WG mess except that I think the job of the WG
is to get the new system and transition documented and to do so
in a clear and orderly fashion.   I hope we can agree that
"mess" and "clear and orderly" are inconsistent.

Beyond that, I'm back to the disclaimer in my earlier note.
"Obsoleted" and "Historic" are in this I-D because the WG
co-chairs told me to put them in and because no one has raised
any objections up to this point.  If I get clear instructions to
do something different, I will make the changes and hope we are
converging.  I will complain if we lose the tracks/ footprints,
but I'm prepared to be in the rough.

> Side note: Using "Executive Director" has already made this
> way more complicated that had we chosen other synonyms that
> were available before the LLC was stood up.

A nearly identical observation was that the changed/ reused
title was what first caused a number of new (replacement/
obsoleting) documents to be created just to retune titles and
then the present I-D to be started to eliminate the need for all
of those separate documents and to be more clear about what was
actually being changed (titles rather than anything substantive
in most cases).  When that was brought up, my recollection is
that we were told that the lawyers liked  "Executive Director",
wrote it into the LLC agreement, and that we were stuck with it.
My enthusiasm for that way of doing business in a supposedly
bottom-up, consensus-based IETF is apparently worth less than
the proverbial cup of coffee and suggestions that we use a
different set of titles informally but consistently and document
them in one place got absolutely zero traction, so I'm trying to
make the best of what I consider a very bad situation.   But
yes, at least in retrospect, I think "way more complicated than
it needed to be" may be something of an understatement.

best,
   john

---

From: Heather Flanagan <[email-masked]>
Date: Thu, 21 Feb 2019 08:41:06 -0800

> On Feb 16, 2019, at 3:19 PM, John C Klensin <[email-masked]> wrote:
> 

Hi John, all,

This is a long standing mess, and one I brought up with the IESG some time ago. My preference (because I like a human-friendly information trail) is for there to be an RFC that documents (and perhaps explains) the action of moving another to Historic, and that happens sometimes. More often, especially these days, is just a database-level status change, which is considered sufficient by the IESG.

In either case, though, the information is noted on the Info page of the RFC that has been changed to Historic as well as on the RFC Status Change page (https://www.rfc-editor.org/status_changes.php <https://www.rfc-editor.org/status_changes.php>).

Hope that helps,
Heather