Subject: Summary of LC comments (so far) on RFC1984 to BCP

From: Robert Sparks <[email-masked]>
Date: Wed, 02 Sep 2015 09:20:42 -0500

Here is my summary of the last call discussion on
status-change-rfc1984-to-best-current-practice
so far for comment

The last call is open for a few more days.

A relatively high number of comments were sent in response
to this last call.

Many participants expressed support for this status change,
including people that were IAB or IESG members when RFC1984
was published. The current IAB expressed support for the
change.

Several people expressed concern that it was not clear why
this change was proposed. The relevance of citing RFC20's
status change was questioned. The discussion resulted in
agreement to remove the mention of RFC20. The remaining
text should focus clearly on the motivations for making the
change. It was suggested to explicitly note in the
status-change document that this is an exceptional action,
but that it falls within the processes laid out by RFC2026.

Concern was expressed that it would be difficult to find
the history explaining this change. A note in the tracker
is a difficult artifact find, or even to know to look for.
It was pointed out that the RFC Editor maintains a list
of approved status changes at
<status-change-rfc1984-to-best-current-practice>.
The IESG should consider further changes to improve
documenting status-change actions, keeping the notion
of the RFC series as an archival series in mind.

It was suggested to include RFC2804 (draft-iab-raven) in
this status change.  Responses were that moving RFC2804 to
BCP might also be a good thing to do, but that the actions
should be pursued independently.

Several commenters expressed opposition to making this
status change for several reasons:

* Some expressed a preference to use a separate document to
effect this change rather than to change the status of
RFC1984 in place. Both replacing RFC1984 with a new
document taken through the consensus process (a bis
document), and changing the status of RFC1984 along with a
companion RFC discussing the change were suggested.  There
were responses that updated text wouldn't be an
improvement, and that there was value in keeping the
current RFC number.  This last call would serve to gauge
whether the content of RFC1984 had IETF consensus. It was
also mentioned that if this status-change were to be
approved, it would not preclude additional work replacing
RFC1984 in the future.

* Concerns were raised about whether the content of RFC1984
was appropriate for a BCP. It was pointed out that it is
written as the opinion of the IESG and IAB at the time.
Discussion included members from those bodies at that
time expressing support for the change. A point was
raised that existing documents that reference RFC1984
would need to be analyzed for the impact of changing
the status of the document. One community member reported
looking at the set of references to RFC1984 and finding
no problems.

* Concerns were raised about whether moving an
Informational document to a BCP was supported by the
existing processes, or if this was a process end-run.
Discussion pointed out how this is not a violation
of process. One commenter expressed an opinion that
that type of status change is a bad idea anyhow.

Additionally, there was a discussion about whether RFC1984
was still correct, and an assertion that it suffered from
omitting topics it should discuss. There was a concern
expressed about whether an IETF document should be speaking
to governments. A point was also raised about whether the
correct balance between protecting privacy and supporting
law enforcement is being pursued. The discussions of these
points did not suggest changes to the status-change
document text. There were responses holding that what was
in RFC1984 was both correct and struck a good balance, and
that it was important in cases like this to provide
guidance to governments.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Sep 2015 15:25:00 +0100

Hiya,

Thanks Robert. Good summary.

> but that it falls within the processes laid out by RFC2026.

In case folks go looking, I didn't yet make the change to
the status change document. I'll get that done Friday or
over the weekend and send a mail here when it's done. (And
specific text suggestions welcome offlist in the meantime.)

Cheers,
S.

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Sep 2015 11:27:48 -0400

Robert,

While I disagree with some of the details (and have written you
separately about a few of them that I think have been adequately
covered on-list), I think this is mostly a fair and balanced
summary.  I do question one pair of statements:

--On Wednesday, September 02, 2015 09:20 -0500 Robert Sparks
<[email-masked]> wrote:

> It was suggested to explicitly note in the

[...]
> of process.

If the variance procedure is invoked, you can do almost
anything, but it has not been invoked.  Otherwise, an argument
that this change is justified by RFC 2026 processes would appear
to have to be justified either on the basis of our usual (but
much more recent than 2026) convention of referring to BCPs as
part of the standards track or by the invocation of Section 6.1
from Section 5.1 of 2026.  "Discussions pointed out..." is not
really a sufficient summary against that backdrop.  In
particular...

Given that 2026 separates "BCP" (in Section 5) from "Standards
Track" in Section 6 and elsewhere), making a "rules are the same
and this is allowed" conclusion is a stretch.  Inferring that
the reference in the second paragraph of Section 5 to Section
6.1.1 or the one in the third paragraph to Section 6.1 allows
the IESG to do anything to create a BCP that is allowed for
putting something on the standards track or advancing it seems
even more so.  I also note that 2026 has something very specific
to say about the relationship between Informational RFCs and
BCPs, namely:

	"Specifically, BCPs should not be viewed simply as
	stronger Informational RFCs, but rather should be viewed
	as documents suitable for a content different from
	Informational RFCs."

Getting from that to an assertion that it is ok under 2026 to
take an Informational document with content suitable for that
purpose and make it into a BCP by a status change with no change
in content seems very much inconsistent with the clearly-stated
intent of the above paragraph.

Recommendation: 

If the IESG concludes that there is community consensus for
doing this, either 

	(i) Explicitly invoke the variance procedure of RFC 2026
	Section 9, explicitly noting that the first part of
	Section 9 allows its applicability to any situation in
	which "...the procedures leads to a deadlock about a
	specific specification, or there may be situations where
	the procedures provide no guidance" even though Section
	9.1 discusses only standards track document.   Or
	
	(ii) Make sure the way in which you believe this is
	allowed by ("within the processes laid out by") RFC 2026
	is very carefully spelled out in the tracker statement,
	not just stated as an assertion like those quoted above.

Because the issue has been raised, approving this status change
without at least some approximation to the above would make the
decision appeal-bait.  Should some sorehead initiate such an
appeal, it would be entirely appropriate for an appellant to
request that the entire IAB be blocked from considering such an
appeal (because, as your summary indicates, they have already
expressed support for this move as a status change) and that
every IESG member who has taken a position on the
appropriateness of the change, including by not objecting to the
issuance of a Last Call that assumes the action is permitted, be
excluded as well.  Most of IESG might be able to avoid that
claim on the basis that opinions might have been changed by the
discussion but that would, itself, be a decision subject to
appeal; the IAB cannot.    Such a request in an appeal would,
IMO, bring us close to a constitutional crisis.  It would
probably not be desirable to get ourselves into that state,
especially over a document with the type of content and audience
represented by RFC 1984.

YMMD and probably does, but I thought it was important to get
the above point of view stated clearly at the point.

best,
    john

---

From: Dave Crocker <[email-masked]>
Date: Wed, 2 Sep 2015 08:42:58 -0700

> was published. The current IAB expressed support for the

While it's quite good that the summary goes into details about concerns
that were expressed, the summary misses an assessment of the number of
participants expressing objection to the status change and particularly
with the form of change being pursued.

Combined with the explicit statement that 'many' participants are in
support, this serves to imply that, as a group, those objecting were a
small enough percent to permit a claim of rough consensus in support.

I think that an objective assessment of the group expressing objection
will be a minority, compared against support, but will be quite a
substantial percent nonetheless.  On the average, the IETF usually
claims that the presence of a substantial constituency against a
proposal is enough to prevent a claim of rough consensus.

As an aside,

     I am not clear about the useful purpose of citing the positions of
those who authored RFC 1984, relative to the current discussion.  While
it no doubt adds some emotional force to justifying the path currently
being pursued, how is it that their views ought to carry more weight
than anyone else in the community?  To the extent that the original
authors of a document normally should have a say over changes in the
status of that document, RFC 1984 was the product of the IAB, rather
than an independent effort by those authors.  More generally, we
regularly revise documents and document status without consulting
original authors.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 8 Sep 2015 17:19:10 +0100

Hiya,

I've made what I think are the changes to the status-change text [1]
as per Robert's summary below. (BTW, the history/diff thing appears
to not work just now, it's not a huge change so you can fairly easily
see it manually, but I'll check that out separately with the tools
folks.)

My overall conclusion is that the last call has established that
there is rough consensus for this status change and I've put this
on the IESG telechat for Sept 17th so the rest of the IESG can
evaluate that.

I didn't get to do those edits as early as planned, so please
send any comments on the modified status change text in the next
few days and I'm happy to take those into account. If some major
change is needed, I'll push IESG evaluation of this out until a
later telechat. (Please try to not repeat earlier points made
already in the last call though as that'll just make it harder
for other ADs to evaluate things.)

Lastly, I do recognise that the consensus for at least the
in-place part of the status change is rough, so I've called
that out to the IESG via Robert's summary and Dave's response. [2]

Cheers,
S.

[1]
https://datatracker.ietf.org/doc/status-change-rfc1984-to-best-current-practice/
[2]
https://datatracker.ietf.org/doc/status-change-rfc1984-to-best-current-practice/ballot/#stephen-farrell

---

From: Dave Crocker <[email-masked]>
Date: Tue, 8 Sep 2015 10:03:58 -0700

> on the IESG telechat for Sept 17th so the rest of the IESG can
...
> that out to the IESG via Robert's summary and Dave's response. [2]

1.  Citing concerns is not the same as dealing with them.  My note
pointed out basic problems with Robert's summary.  It was meant as an
invitation to /repair/ it's deficiency's, rather than merely note that
someone had some concerns.

2. An essential contribution of RFC 7282 is to emphasize the importance
of attending to 'minority' concerns.  On the current topic, they have
not been attended to, although the concerns expressed have been
fundamental to the role and handling of the document.

3. There is a continuing pattern of citing SAAG as if its discussions
equate to that of a working group, such as noting "rough consensus"
within that group.  Advisory group discussions, such as by SAAG, can be
quite helpful.  /But they are not chartered working groups, with
advertised agendas and deliverables./  As I noted, SAAG's composition
and conduct are fundamentally inappropriate to cite for a
standards-oriented decision.  Worse, the citation of rough consensus on
SAAG has no obvious basis from the mailing list record.

d/

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 8 Sep 2015 22:15:17 +0100

On 08/09/15 18:03, Dave Crocker wrote:
> pointed out basic problems with Robert's summary. 

I don't agree that your note pointed out basic problems with Robert's
summary, nor that there remains anything you raised that needs to be
dealt with still.

I've gone back over the mails [1-5] you've sent to the IETF list in
this last call. The relevant points (*) that I see that you made are:

1. the intention behind the status change wasn't sufficiently clear

2. the saag list is somehow not a proper venue for initial discussion
   of this because it doesn't have a formal way of judging rough
   consensus

I think #1 was clearly discussed during the last call and is noted
in Robert's summary as a result of which I attempted to reflect what
I saw in the last call related to that in the status-change text
edit. If my text changes in that respect can be improved, which is
entirely possible, I'm fine with doing that. I don't think a claim
that wasn't discussed is compelling at all.

I think #2 is bogus. You asserted a number of times that somehow this
depends on asserting that there was a formal consensus call. There was
no such formal consensus call and no such assertion was made or
depended upon. Feel free to point out where I'm wrong on that. (Perhaps
you read between the lines when no subtlety was intended? That does
happen.) What happened is that Kathleen and I both judged that there
had been sufficient agreement on the saag list and in Prague to start
an IETF last call. If you want to argue we're not supposed to do that,
for an AD sponsored status change, go right ahead but please consider
the level of additional pointless bureaucracy  implied in your winning
that argument. So, I'm sorry, but your #2 is I conclude a non-issue.

Cheers,
S.

(*) I've omitted your discussion in the sub-thread with Stewart in
the above.

[1] https://www.ietf.org/mail-archive/web/ietf/current/msg94256.html
[2] https://www.ietf.org/mail-archive/web/ietf/current/msg94306.html
[3] https://www.ietf.org/mail-archive/web/ietf/current/msg94550.html
[4] https://www.ietf.org/mail-archive/web/ietf/current/msg94635.html
[5] https://www.ietf.org/mail-archive/web/ietf/current/msg94671.html

> It was meant as an