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

["Dearlove, Christopher (UK)" <[e-mail]>]

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:  [phone]  |  E: [e-mail]<mailto:[e-mail]>

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

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