ietf
[Top] [All Lists]

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

2015-09-08 11:19:53

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

On 02/09/15 15:20, Robert Sparks wrote:
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.