Re: I-D Action: draft-wilde-updating-rfcs-00.txt

[John C Klensin <[e-mail]>]

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
<[e-mail]> 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