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:
chris(_dot_)dearlove(_at_)baesystems(_dot_)com<mailto:chris(_dot_)dearlove(_at_)baesystems(_dot_)com>
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:ietf-bounces(_at_)ietf(_dot_)org] 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.
********************************************************************