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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Brian,

On Wed, Dec 21, 2016 at 6:38 PM, Brian E Carpenter <
[e-mail]> wrote:

> Hi Spencer,
>
> On 22/12/2016 07:03, Spencer Dawkins at IETF wrote:
> > 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.
>
> Which, I think, explains why tying this down to formal requirements
> around the use of <rfc updates="xxxx"> is not easy either.
>
> > 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.


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.


> > 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.
>
> 2004 actually:
> https://tools.ietf.org/html/rfc3774#section-2.4
>
> >
> > 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.
>
> 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


Thanks for the pointers.


> Clearly there were individuals in the IESG with divergent opinions,
> so that message was a compromise.
>
> > 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?
>
> 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.
>

This sounds right to me.


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


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