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.