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. > >