Brian, I agree with most of what you wrote. The possibly exception is discussed below, as are my partial responses to some of Spencer's questions. --On Thursday, December 22, 2016 13:38 +1300 Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: >... >> I have been talking to Rick about AD sponsoring some version >> of his draft, and he's not quite sure what to do next, >> because any discussion of his draft opens a Pandora's Box of >> stuff that's broken about the way we have tried to document >> protocols over a very long period of time. I was hoping that >> it would be possible to do something useful with a narrow >> scope, that doesn't involve fixing everything, but might fix >> a few things. >> >> I'd like to hear opinions about that. > > I think that it's pretty much impossible to make firm rules > about this. I do think that those writing, reviewing and > approving documents SHOULD spend time on ensuring that an > implementer of the updating and updated RFCs is in no doubt > about what to write in her code. But I just don't see how to > reduce that to a formula. The discussions you mention haven't > been easy because the topic isn't easy. Agreed. My intuition, after trying to sort through these issues for far more years than I care to think about (long before Newtrk and back to when the decision to identify "updates" was an RFC Editor issue, not an IESG one) is that creating a rigid set of rules that are modeled on a single situation and implicitly assuming that all situations are the same will set up back rather than moving us forward. >... >> What I'm remembering about NEWTRK, and other folks may >> remember it differently, was that we had pretty ambitious >> goals, and proposals like >> https://tools.ietf.org/html/draft-ietf-newtrk-repurposing-isd >> -04 reflected those goals. Whether characterized as "pretty ambitious" or not, the goal was a fix the problem. I think that problem can be characterized more or less the way Brian does so above: making it absolutely clear to implementers, and those procuring or evaluating implementations, what they need to read and how documents mesh together to understand both what should be implemented and what the standard actually is. Because of the ways in which our documents interlock over time, I don't think solutions to problems such as exactly what to say if a document updates another are likely to be meaningful and useful. >> For instance, I'm re-reading >> https://tools.ietf.org/html/draft-ietf-newtrk-repurposing-isd >> -04 (one of the few NEWTRK documents I'm not even >> acknowledged in - but I liked it a lot at the time), and >> remembering that we assumed that all STDs would have ISDs >> (even if they were basically formulaic, with little or no >> explanation initially). Especially for those who are trying to think about this without rereading Newtrk documents, it is worth noting that another aspect of those proposals was that we would recognize that few specs progressed beyond Proposed Standard, and assign STD numbers at Proposed, rather than waiting for full Standard status. So the above was intended to be equivalent to "all standards-track technical specifications would have STD numbers and ISDs". For all practical purposes, the STD number would belong to the ISD, which would be a relationship and applicability statement (or incorporate them by reference) to everything else. >> NEWTRK petered out almost simultaneously with the beginning >> of narrative minutes for IESG telechats, so it's hard for >> non-IESG members to reconstruct all the concerns expressed at >> the time, but I'm remembering discussions about who would >> write this descriptive text, and who would approve it - and >> talking to at least a couple of IESG members after the fact, >> who'd told me they'd assumed the IESG would have to provide >> those descriptions, or at least approve them. Which was never the intent. It is interesting that, in the decade between the Newtrk meltdown and today, many of the issues a ISD was expected to reflect had ended up a requirements or near-requirements for Shepherd reports, documents that are fairly non-transparent and not subject to IETF Last Call. The intent was essentially that a WG producing a technical spec intended for standards track would do the analysis of relationships and produce a draft ISD that would become part of the Last Call and approval process. That sounds like additional work for the WG, but, if the WG isn't considering relationships to work that is closely enough related to be considered part of the same standard, and those relationships exposed to the Last Call process, I think we are in big trouble. Note too that, as a side effect of the same requirements, the downref problem should essentially go away, rather than promoting incremental patching along the lines of RFC 3967, 4897, and draft-leiba-3967upd-downref. >... >> What I'm wondering now, is how un-ambitious we could be, and >> still do something useful to get started. My guess, both in 2005 and today, is that trying to do this by baby steps would just result in a lot of confusion about multiple messy transitions and experiments that move us closer to ISDs without making the move. Increased specificity about Shepherd reports and the downref problem are both symptoms of that pattern, as are the Informational documents mentioned below and draft-wilde-updating-rfcs. >> John did a couple of examples of ISDs, in >> https://www.ietf.org/archive/id/draft-ietf-newtrk-sample-isd- >> 00.txt (John, is that the best pointer for this?) on SMTP >> (complicated) and on POP/IMAP Authentication with CRAM-MD5 >> (much simpler), circa 2004 or so. Probably the best pointer for anything published. Because of the work of the EAI WG, both would be considerably more complex today. IIR, someone also tried (or at least started on) an example for TCP based on what eventually became RFC 4614 and then 7414. >> Is it worth taking a look at that, and producing samples for >> a couple of protocols that are more complicated than a single >> RFC, and less complicated than >> https://datatracker.ietf.org/doc/rfc5411/ (for SIP) or >> https://datatracker.ietf.org/doc/rfc7414/ (for TCP), and >> seeing what we end up with? > > First, an observation: nothing in the last ten years has > actually prevented someone proposing an ISD to the relevant AD > as a Proposed Standard under the "applicability statement" > category defined by RFC2026. Agreed, there would be some > compromises compared to the actual ISD proposal, but IMHO > nothing in our rules would prevent such a publication. For > example, we could suggest that the authors of > https://tools.ietf.org/html/draft-clw-rfc6434-bis-00 format > that document as an ISD. Up to a point. The ISD concept doesn't really work unless the documents are normative (RFC 5411 and 7414 are both Informational; one is described as a "guide", the other as a "roadmap"). To some extent, that just adds to the confusion. Equally important, if one is going to propose anything ISD-like for a non-trivial case, my guess is that a WG would almost certainly be needed. Whether the IESG would encourage approve such a WG >... >> Administrivia: both Jari's position on the IESG and mine are >> under review by the current Nomcom, and I'm loath to get very >> far down the road without talking to Jari's replacement, and >> without knowing whether I will be able to AD sponsor drafts >> after IETF 98, so I'd like to do some homework now, but not >> go crazy yet. > > Fair enough, but if the community wants to do this, that's a > community choice. Yes, but, IMO, the community, at least the fraction of the community who had been studying the issues carefully, wanted ISDs and the IESG killed it. I can't remember how much we discussed pushing back on the IESG's decision to not allow community consensus to become clear, but it was certainly obvious to at least some of us that the IESG's enthusiastic involvement would be needed to make ISDs work and that, if ISDs were forced down their throats, they could easily arrange to have the idea fail and then tell the community that it had been warned. So I agree with Spencer (and possibly would go further) that it is not worth putting a lot of energy into this until the complexion of the next IESG is known and it is possible to at least do an internal straw poll about enthusiasm or opposition. best, john