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

From: Erik Wilde <[email-masked]>
Date: Wed, 7 Dec 2016 21:52:01 -0800

hello john.

On 2016-09-15 09:37, John C Klensin wrote:
> Independent of where it is discussed (as
> long as it is on a public list), this I-D would be, at least
> IMO, a much more satisfactory basis for discussion if it
> demonstrated more convincingly that the author was aware of
> those earlier discussions and had considered them, rather than
> assuming (or appearing to assume) that no one had thought about
> these topics.

it was not my intention to ignore or belittle previous discussions. it 
just occurred to me as a frequent reader of RFCs that there is a large 
variation in quality how updates are documented. the idea was that some 
simple documentation guidelines might help to improve that, without 
necessarily being hard definitions on what exactly updates are, and how 
exactly they have to be documented.

i'd be more than happy to include these earlier discussions, but i am 
afraid if that involves going through a long list of mail archives, this 
simply is beyond the time commitment i can reasonably make. i'd be more 
than happy to have somebody co-authoring and filling in those gaps, but 
that of course assumes that somebody else would be willing to put in the 
effort of writing up this history.

thanks and cheers,

dret.

-- 
erik wilde | mailto:[email-masked] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |

---

From: John C Klensin <[email-masked]>
Date: Sun, 11 Dec 2016 14:22:37 -0500

Erik,

Sorry for the delay in responding. Let me try a very high-level
summary of the implications of what I, at least, consider the
most important history of the problem you are trying to bite off
a piece of (others will have other histories).  First, it isn't
easy.  Even if one just ignores the various flavors of
Informational documents, the right documentation rules for
single-stage processes (e.g., BCPs) are inevitably different
from those for two (and previously three)-stage technical
standards track ones.  That problem is further complicated by
the fact that we use BCPs, and occasionally technical standards,
for what are really procedural or policy statement documents.
Second, there is a complexity tradeoff.  Today, for normative
documents, we have BCP documents and 2 1/2 levels of standards
track  one (depending on what one thinks Experimental is).  

The issues of updating and categories are also inevitably
complicated by the nearly-orthogonal one of interrelated and
interdependent documents, some developed at different times and
by different groups and often with non-obvious overlaps.

We tried to take all of this on some years ago in a WG called
"NEWTRK".  It was not successful.  In particular (and trying to
state this as neutrally as I can manage), the WG concluded that
we needed a new type of Standards Track document that would talk
about status and relationships among documents, rather than
being one or more technical specification itself.  At least some
of what you seem to be proposing would go into those
standards-description documents and not the technical
specifications themselves.  In addition, at least some of us
believe that the relevant documents would be living documents
with change histories rather than the inherently-static (at
least per-document) RFC series.  

WIthout revisiting the argument and various opinions about
motivations, the IESG concluded that the idea was just too
complicated and/or inappropriate and the idea when nowhere.  In
retrospect, they might have been right.  Or not.  Either way,
the experience left many of us reluctant to start nibbling at
the issues again unless there was a comprehensive plan that the
IETF was willing to sing off on.

However, I do believe that it is unrealistic to believe one can
take on inter-document relationships without at least reviewing
the issues that the NEWTRK WG examined and the options it
considered.

best,
    john

--On Wednesday, December 07, 2016 21:52 -0800 Erik Wilde
<[email-masked]> wrote:

>> assuming (or appearing to assume) that no one had thought
>> about these topics.
> 
> it was not my intention to ignore or belittle previous
> discussions. it just occurred to me as a frequent reader of
> RFCs that there is a large variation in quality how updates
> are documented. the idea was that some simple documentation
> guidelines might help to improve that, without necessarily
> being hard definitions on what exactly updates are, and how
> i'd be more than happy to include these earlier discussions,
> but i am afraid if that involves going through a long list of
> mail archives, this simply is beyond the time commitment i can
> reasonably make. i'd be more than happy to have somebody
> co-authoring and filling in those gaps, but that of course
> assumes that somebody else would be willing to put in the

---

From: "Scott O. Bradner" <[email-masked]>
Date: Sun, 11 Dec 2016 16:23:14 -0500

see, for example, https://datatracker.ietf.org/doc/draft-ietf-newtrk-repurposing-isd/

Scott (network WG chair)

> On Dec 11, 2016, at 2:22 PM, John C Klensin <[email-masked]> wrote:
> 
> Erik,
>

---

From: John C Klensin <[email-masked]>
Date: Sun, 11 Dec 2016 17:51:29 -0500

--On Sunday, December 11, 2016 16:23 -0500 "Scott O. Bradner"
<[email-masked]> wrote:

> see, for example,
> https://datatracker.ietf.org/doc/draft-ietf-newtrk-repurposing
> -isd/

Yep.   Like that.  :-)

>        ^^^^^^^

Typing too fast, are we?   :-)

best,
    john

---

From: "Scott O. Bradner" <[email-masked]>
Date: Sun, 11 Dec 2016 19:02:22 -0500

> On Dec 11, 2016, at 5:51 PM, John C Klensin <[email-masked]> wrote:
> 
> 
> 

nope - Apple being too helpful (autocorrect)

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Dec 2016 13:39:18 +1300

> see, for example, https://datatracker.ietf.org/doc/draft-ietf-newtrk-repurposing-isd/

And while we're reviewing ancient history, let me say that the new IESG in 2005,
with me as the new Chair, did spend hours discussing that draft and failing to
reach a useful consensus. But not because we thought there was no problem. As I've
said more than once, there is a problem, for any protocol that is complicated enough
to need several interlocking RFCs to define it. As those various components require
updating, we grow a dependency tree. The "Updates" tag on the more recent RFCs is a
very coarse way of expressing the dependencies.

Requiring the updating RFC to be clear about why and how it is updating other RFCs
is IMHO a good idea. However, I don't think that a mandatory section in the updating
RFC is the right way to ensure this. It would just become a box-ticking exercise.

Regards
    Brian

---

From: Alia Atlas <[email-masked]>
Date: Sun, 11 Dec 2016 19:48:14 -0500

> very coarse way of expressing the dependencies.

Off-topic for the draft and updates questions, but in response....

A place where we could work on capturing the relationships of how various
RFCs and drafts
in a WG relate to each other and what the WG is focusing on is the IETF
WG's wiki.  Done well,
one could have references to it from other sites (e.g. Wikipedia) to help
folks coming newly
to the IETF or trying to learn about the related protocols and how they
plug together.
With this information written down - even informally and with just the WG
chairs or AD reviewing it,
I think it would be useful.

I've been encouraging some of my WG Chairs to think about this and see if
they can find
volunteers to do one for their WG.   Once it is written, I think that
updating it periodically wouldn't
be too challenging and having something that describes technology in
something other than
a difference architecture would be helpful.    I've seen some enthusiasm
and agreement, but
no text so far.

Regards,

Requiring the updating RFC to be clear about why and how it is updating
> other RFCs

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Dec 2016 10:11:04 -0500

Sorry... I was going to not get further involved in this
discussion, but...

--On Monday, December 12, 2016 13:39 +1300 Brian E Carpenter
<[email-masked]> wrote:

>> https://datatracker.ietf.org/doc/draft-ietf-newtrk-repurposin
>> g-isd/
 
> And while we're reviewing ancient history, let me say that the
> new IESG in 2005, with me as the new Chair, did spend hours
> discussing that draft and failing to reach a useful consensus.
> But not because we thought there was no problem. As I've said
> more than once, there is a problem, for any protocol that is
> complicated enough to need several interlocking RFCs to define
> it. As those various components require updating, we grow a
> dependency tree. The "Updates" tag on the more recent RFCs is a

And a vague one that covers a large range of relationships.  I
have assumed that the indefiniteness of that range is at least
part of what motivated Erik's effort.

> Requiring the updating RFC to be clear about why and how it is
> updating other RFCs is IMHO a good idea. However, I don't
> think that a mandatory section in the updating RFC is the
> right way to ensure this. It would just become a box-ticking
> exercise.

Bite that the IESG has tried that by, IIR, requiring "updates
Foo" statements in Abstracts and Introductions or separate
section, and, IMO, has gotten, not merely box-ticking but
meaningless statements that contain no useful information and
almost no one reads.

The other difficulty is that, even if each updating RFC is clear
about what it is changing, if there are multiple documents
(either contemporaneously, serially, or both) and multiple
updates, one rapidly ends up with hopeless spaghetti-threading
and even some question about what the standard actually is.
That is the problem to which draft-ietf-newtrk-repurposing-isd
was addressed and for which it got WG consensus as a solution.
It then became the problem that the IESG decided was not
important enough to be worth the trouble (or at least couldn't
reach agreement that it was).  Attempts to reintroduce the topic
from time to time over the last decade have gotten similar
levels of enthusiasm from the IESG.

If anyone thinks this is really a problem, tell it to the Nomcom
and tell them that they should extract promises from IESG
candidates.  I hope they would listen if enough people deliver
that message.   Otherwise, well, it is probably worth just
getting used to the problem because narrow rules about
descriptions of the updates won't help much.

     john

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Dec 2016 15:56:36 -0500

see inline. A great summary, just one nit which might be relevant:

    > IETF was willing to sing off on.

My understanding was that a major reason NEWTRK could not reach consensus was
that it realized that no proposal could attain IESG consensus and IETF
consensus at the same time because:
  a) IESG people didn't have cycles to engage with the community.
  b) the people selected for the IESG (and who were successful) were the
     people who could operate well with the current rules.

That is, the IESG suffered from a variation of the Innovator's Dilema.
I think that a decade later things are mostly the same, but I think that
the IESG members are generally much more self-aware about the need to
reduce their I* workload so that they can engage in other things.

{NEWTRK is approximately the same age as my son. I recall him being
an infant at a NEWTRK dinner. And he is 11 now}

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Dec 2016 16:31:12 -0500

> see inline. A great summary, just one nit which might be relevant:

I should add, having now read the document in question, which is remarkably
short, if a been ironic:

   The obsoleted "Instructions to RFC Authors" [2] in Section 12
   describe what "Updates" and "Obsoletes" mean.  These descriptions do
   not appear in RFC 7322, and even if they did, they might still not
   always be sufficient to understand the exact nature of the update.

   {RFC7322 obsoleted 2223, and 7322 doesn't include Updates or Obsoletes,
   then it seems we've painted ourselves into a corner :-)}

but, my substantive comment is that we should obsolete the term "Updates"
due to:

    Generally speaking, using "Updates" often has one of two possible
    motivations: One is a bug fix ....

    The second motivation is that the updating RFC is a backwards
    compatible extension, which means that strictly speaking, it does not

and instead use terms "Extends" and "Corrects".

I'm unclear if there is a new required section "Reasons for updating"?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Dec 2016 11:06:25 +1300

Michael,
> and instead use terms "Extends" and "Corrects".

I think this illustrates the dictum that "there is always a well-known
solution to every human problem — neat, plausible, and wrong."
[HL Mencken, 1917]. It's not that it wouldn't clarify the exact
status of certain RFCs - but it would hardly scratch the surface
of the underlying standards spaghetti.

IMHO, the problem tackled in
https://tools.ietf.org/html/draft-ietf-newtrk-repurposing-isd-04
is too complex to be fixed by simple measures.

It's also worth looking at this (out of date) example:
https://tools.ietf.org/html/draft-ietf-newtrk-sample-isd-stdproc-00

Anybody up for newnewtrk?

    Brian

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Dec 2016 22:47:29 -0500

--On Tuesday, December 13, 2016 11:06 +1300 Brian E Carpenter
<[email-masked]> wrote:

> I think this illustrates the dictum that "there is always a
> well-known solution to every human problem — neat,
> plausible, and wrong." [HL Mencken, 1917]. It's not that it
> wouldn't clarify the exact status of certain RFCs - but it
> would hardly scratch the surface of the underlying standards
> spaghetti.
> 
> https://tools.ietf.org/html/draft-ietf-newtrk-repurposing-isd-
> 04 is too complex to be fixed by simple measures.
> 

Alternate proposal:  IIR, the IESG never did a write up or
initiated a Last Call on that proposal despite a request from
the WG to do so.   They simply announced that they were not
going to consider it, an action that is dubious under RFC 2026
but not prohibited.  Some of us who were active in Newtrk
assumed that, if there was a Last Call and fairly clear
community consensus, the IESG would be in an intolerable
position if they decided to advance the document, but that is
just speculation.

As co-author of
https://tools.ietf.org/html/draft-ietf-newtrk-repurposing-isd-04,
I'd be happy to find time to update references and boilerplate
and reissue it if the community wants to take it up and the IESG
is willing to given it serious consideration, either on the
basis of the Newtrk recommendations or through some restarted
process.

Where I think I agree with Brian is that this is a complicated
issue and that a new rule or required paragraph will make things
even more complicated without improving things.

best,
   john

---

From: "Scott O. Bradner" <[email-masked]>
Date: Tue, 13 Dec 2016 05:45:06 -0500

John’s description of how things looked to the working group is consistent with 
my view as chair of the working group

it was a very frustrating experience

Scott

> On Dec 12, 2016, at 10:47 PM, John C Klensin <[email-masked]> wrote:
> 
> 
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 21 Dec 2016 12:03:28 -0600

So, backing up a tiny bit ...

What follows is me, speaking as a currently serving AD, and as a survivor
of NEWTRK (so, an inmate who is now helping to steer the asylum, although I
didn't take it over).

I have had the pleasure of talking with the most recent three IESGs about
what UPDATES actually means in relationship to a specific document on a
current telechat agenda. Those have not been easy discussions.

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.

More broadly,
https://tools.ietf.org/html/draft-ietf-newtrk-repurposing-isd-04#appendix-A
is a perfectly serviceable list of stuff that was broken in 2006, and since
we haven't changed much since 2006, still seems to be broken today.

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.

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

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.

What I'm wondering now, is how un-ambitious we could be, and still do
something useful to get started.

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.

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?

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.

Thanks,

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Dec 2016 13:38:46 +1300

Hi Spencer,

> current telechat agenda. Those have not been easy discussions.

Which, I think, explains why tying this down to formal requirements
around the use of <rfc updates="xxxx"> is not easy either.

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

> we haven't changed much since 2006, still seems to be broken today.

2004 actually:
https://tools.ietf.org/html/rfc3774#section-2.4

> descriptions, or at least approve them.

You can also look at the minutes of the 2005 IESG retreat:
https://www.ietf.org/iesg/archive/iesg-retreat-2005-04.txt
and the resulting IESG message:
https://www.ietf.org/mail-archive/web/newtrk/current/msg00991.html

Clearly there were individuals in the IESG with divergent opinions,
so that message was a compromise.

> https://datatracker.ietf.org/doc/rfc7414/ (for TCP), and seeing what we end

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.

I had ISDs in mind when I originally drafted https://www.ietf.org/about/process-docs.html

So yes, a nearly-ISD experiment could start today, IMHO.

> to AD sponsor drafts after IETF 98, so I'd like to do some homework now,

Fair enough, but if the community wants to do this, that's a community choice.

    Brian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 22 Dec 2016 02:05:57 -0600

Hi, Brian,

> that to a formula. The discussions you mention haven't been easy because

Right. We can make it harder than it needs to be by trying to do too much,
but it isn't easy, in any case.

> reflected

Thanks for the pointers.

> So yes, a nearly-ISD experiment could start today, IMHO.

This sounds right to me.

> Fair enough, but if the community wants to do this, that's a community

Of course.

My point is that I'd rather be sure that I can AD sponsor work on this
after March, rather than start something that another AD will have to
finish.

Spencer

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 22 Dec 2016 09:59:08 +0000

I’ve written a few RFCs, and had debates about whether this is an update or not (usually resolved as whatever makes the IESG happy).

But as a reader of RFCs I have one simple rule of thumb. If I’m reading RFC ABCD, I want to know what other RFCs I need, or might need, to read because they modify, or extend, RFC ABCD in a manner that matters. For example (and maybe we need more examples) if I’m parsing an RFC ABCD message, what new options do I need to know about that are in other RFCs? Whether that’s called update I don’t really care, but that’s my practical need for such a field.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: ietf [mailto:[email-masked]] On Behalf Of Spencer Dawkins at IETF
Sent: 21 December 2016 18:03
To: IETF discussion list
Subject: Re: I-D Action: draft-wilde-updating-rfcs-00.txt

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Dealing%20With%20Suspicious%20Emails.pdf>.
So, backing up a tiny bit ...

What follows is me, speaking as a currently serving AD, and as a survivor of NEWTRK (so, an inmate who is now helping to steer the asylum, although I didn't take it over).

I have had the pleasure of talking with the most recent three IESGs about what UPDATES actually means in relationship to a specific document on a current telechat agenda. Those have not been easy discussions.

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.

More broadly, https://tools.ietf.org/html/draft-ietf-newtrk-repurposing-isd-04#appendix-A is a perfectly serviceable list of stuff that was broken in 2006, and since we haven't changed much since 2006, still seems to be broken today.

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.

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

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.

What I'm wondering now, is how un-ambitious we could be, and still do something useful to get started.

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.

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?

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.

Thanks,

Spencer
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: John C Klensin <[email-masked]>
Date: Thu, 22 Dec 2016 05:05:57 -0500

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
<[email-masked]> 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 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.

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

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

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

---

From: John C Klensin <[email-masked]>
Date: Thu, 22 Dec 2016 05:08:41 -0500

--On Thursday, December 22, 2016 09:59 +0000 "Dearlove,
Christopher (UK)" <[email-masked]> wrote:

> I've written a few RFCs, and had debates about whether this
> is an update or not (usually resolved as whatever makes the
> IESG happy).
> 
> But as a reader of RFCs I have one simple rule of thumb. If
> I'm reading RFC ABCD, I want to know what other RFCs I need,
> or might need, to read because they modify, or extend, RFC
> ABCD in a manner that matters. For example (and maybe we need
> more examples) if I'm parsing an RFC ABCD message, what new
> options do I need to know about that are in other RFCs?
> Whether that's called update I don't really care, but
> that's my practical need for such a field.

And that is exactly the problem ISDs (and some of the other
changes needed to make them work) were intended to solve.
Paragraphs or sections here and there in documents don't do it,
partially because "you need to go read those two things as well"
may not be reflected in an 'updates' relationship and often are
not.

    john