At 04:10 PM 8/13/2015, Pete Resnick wrote: >Mike, > >I think there are a couple of factual mistakes in here, I'm pretty sure I differ with you on whether they constitute factual mistakes versus different interpretations. > though I don't think they'll change either of our opinions about this particular document: > >On 13 Aug 2015, at 10:26, Michael StJohns wrote: > >>1) Unlike the publication of a new RFC and its associated dates, there isn't any way to permanently associate the change of status date with the RFC. At some future time (and here I'm talking 10-20 years), will it ever be important to be able to identify when the change was made (without having to do email archeology)? > >A change in status of a Standards Track document (whether up in the Standards Track or down to Historic) requires a "Standards Action" notification, and that gets documented in the IESG minutes. Not an ideal markup system (only half better than email spelunking), but the process is there. (See 2026 6.1.3, and RFC 7100.) Yes but as I noted - finding that in the IESG minutes requires email archeology. There is nothing associated with the document itself, nor for that matter with the RFC index system that indicates that a document was made a BCP on a date other than the date it was published. >>Changes to Historic require the submission of an RFC to mark the change > >Not according to 2026 6.4. All it requires is a Last-Call and then the notification procedures in 6.1.3. https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html While you are correct that 2026 only requires what you say it does, I read the IESG statement on saying "no, we're not doing it that way any more and it's our call". And the reason that was put in place is pretty clear: >We have reclassified RFCs as Historic through different mechanisms and with different documentation over time. All reclassifications have suffered from a common problem: there is no direct reference from the RFC that has been made Historic to the explanation of why that action was taken. Finally, the section in that document that begins "The current process, then, of moving an RFC to Historic..." no longer just permits the simple last call. Or do you believe that page is not the current process? >>2) According to RFC 2026, BCPs are documents of the IESG, not the IAB and IESG together. > >Well, they go through IESG review, but they're documents that are "viewed as having the technical approval of the IETF". That said, 2026 does recognize the IAB as a potential author of a BCP: > > While it is recognized that entities such as the IAB and IESG are > composed of individuals who may participate, as individuals, in the > technical work of the IETF, it is also recognized that the entities > themselves have an existence as leaders in the community. As leaders > in the Internet technical community, these entities should have an > outlet to propose ideas to stimulate work in a particular area, to > raise the community's sensitivity to a certain issue, to make a > statement of architectural principle, or to communicate their > thoughts on other matters. The BCP subseries creates a smoothly > structured way for these management entities to insert proposals into > the consensus-building machinery of the IETF while gauging the > community's view of that issue. > >My read has always been that the IAB and/or IESG can create a document for the purposes above, it goes through an IETF discussion/edit, and then it can become a BCP of the IETF. I can live with the reading of the text. But does that then mean that the IAB of the current era should be giving its approval as a group prior to asking the IESG for its approval? Given that it is a joint statement and both groups are listed as authors. Later, Mike