Subject: Revising full standards

From: John C Klensin <[email-masked]>
Date: Thu, 06 Dec 2007 11:20:38 -0500

Hi.  I had intended to bring this up at the plenary last night
but, since I had not raised it on the list and was tired,
decided not to.

Our standards process (RFC2026 and updates) more or less assumes
that documents progress from idea -> I-D -> Proposed -> Draft ->
Full.  Ignore, for now, the question of how much we use all of
that (and why we don't do so often enough).   When the rules
associated with that progression are applied to an update to a
full standard -- a protocol that is widely deployed, tested by
much use and independent implementations-- things get a little
strange.  For example:

	* The RFC Editor discovers that the community doesn't
	quite know what to do with the STD number: It can't be
	reassigned to the new document because it is at
	Proposed.  I shouldn't be left on the original document
	because it really isn't our latest and best thinking on
	the subject.  And it shouldn't be withdrawn because that
	leads to silly states in documents that have been
	written to call on "STD 999" precisely because those
	numbers were expected to refer to current specs.  
	
	* It is not quite clear what implementation reports and
	interoperability testing mean.  Presuming that the
	original spec doesn't count and the update is completely
	new would be a major triumph of procedure over good
	sense.  But...

There are other issues but, in the interest of keeping this note
short, I'll leave them for another time.

So, three questions:

(1) Does the community think this is a problem worth solving?
If the answer is "no", then trying to write up a proposal is
clearly a waste of time.

(2) Assuming a draft and mailing list are created, are people
willing to review and contribute?  Do we need to start thinking
in terms of a WG for this issue alone? (Experience with NEWTRK
suggests to me that a WG with a broader charter would be a bad
idea.)

(3) Would the IESG be inclined to look on a proposal -- either a
request to Last Call a draft document or a WG request, depending
on (2)-- with favor?  If the answer is, as it was with some
NEWTRK work (which, incidentally, would have eliminated this
problem), "we would rather you didn't pursue that", then I don't
believe this is a rock that we should start pushing uphill.  

     john

Disclaimer: rfc2821bis, now in last call, would clearly have
benefited from some changes along this line and thinking about
issues associated with it definitely got me motivated to think
about the problem.  But it is already in Last Call, so any
changes that are made to the procedures will not affect its
processing in any way (although they might ultimately effect how
it, 821, 2821, and STD10 are identified).

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Dec 2007 09:18:30 +1300

John,

> If the answer is "no", then trying to write up a proposal is

Yes. I think the STD numbering issue is extremely confusing to
outside users of our standards. I hadn't noticed the interop
testing hiccup, but that's also a valid concren.

> suggests to me that a WG with a broader charter would be a bad

I'm willing. I think it could be done without a WG if the focus
is kept very narrow. Without wanting to get into solutionism,
let me note that the STD numbering issue is mentioned in
draft-carpenter-rfc2026-changes-01.

    Brian

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 6 Dec 2007 12:34:32 -0800

The numbering is problematic for many reasons, people have difficulty keeping two sets of numeric identifiers straight. If you want me to refer to something other than RFC-822 you have to give me something more memorable to both myself and the audience I am attempting to communicate to.
 
STD23 does not do it for me
 
If you want to introduce an alternative identifier that people are likely to use use something of the form IETF-SMTP-2008
 
This has the additional advantage of reminding folk when a protocol standard has maybe continued for too long without a maintenance session. It also creates added incentive to deploy new protocols. 
 
Consumers don't know what IPv6 is or why they might want it. But an ISP offering an Internet connection supporting IETF-IP-2008 is probably going to be somewhat more successful than one that only offers IETF-IP-1981.
 
Marketechture, 

________________________________

From: Brian E Carpenter [mailto:[email-masked]]
Sent: Thu 06/12/2007 3:18 PM
To: John C Klensin
Cc: [email-masked]
Subject: Re: Revising full standards

John,

    Brian

---

From: Eric Burger <[email-masked]>
Date: Thu, 06 Dec 2007 16:55:14 -0800

Hardly seems worth the effort.

Of the 5092 RFCs published, just 67 are Full Standards.

Of those, how many realistically need updates?

Ad hoc may be a more efficient approach.  Or, are you thinking about a
"lessons learned from RFC 2821-bis"?

> it, 821, 2821, and STD10 are identified).

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

---

From: John C Klensin <[email-masked]>
Date: Thu, 06 Dec 2007 21:25:39 -0500

--On Thursday, 06 December, 2007 16:55 -0800 Eric Burger
<[email-masked]> wrote:

> Ad hoc may be a more efficient approach.  Or, are you thinking
> about a "lessons learned from RFC 2821-bis"?

Most of it would actually be "lessons learned from RFC 2821".
The only new issue introduced by 2821bis is the need, as some
have read the rules, to formally demonstrate that email works
and interoperates (not just whatever changes were introduced in
2821, but the whole business).  Now, if you and a few thousand
other people get this message, I'd claim a reasonable case has
been made that it works, but one could always debate that.

On the other hand, the STD number situation is leading us into
silly states.  For example, there are documents all around the
world that do what we told them, which is to write "implement
STD 10" for "support SMTP".   Try the exercise of determining
what STD 10 is today (because a pointer to RFC 821 would be
wrong and one to 2821 would violate the rules).  So one
alternate fix is to abandon STD numbers.  Those silly states are
a bad idea and since, as you point out, there are only 67 full
standards, maybe we don't need the numbers.

    john

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 7 Dec 2007 14:24:16 +0100

John C Klensin wrote:

> Now, if you and a few thousand other people get this
> message, I'd claim a reasonable case has been made 
> that it works

s/it/something/  

Likely you didn't test EXPN, even if you did you can't
tell if it didn't work because EXPN is default disabled
or not implemented.

The IETF list happily ignored 2821 3.10 and added its 
List header fields to the header.  It would also ignore
the same MUST in 2821bis 3.9.

For a good test you'd have to send your message from an
"IPv6 only" address and account, and ask folks to reply,
and report problems in public.

You used ns.jck.com as EHLO, that's no test of a domain
literal containing NO-WS-CTL or similar oddities.

You likely didn't test HELO and a non-trivial reverse
path in your message.  "Source routing" was deprecated 
18 years ago, it's not obvious what happens if somebody
still tries (in vain) to use it, is it ignored or does
it cause havoc.

Your article arrived as MAIL FROM <ietf-bounces@ietf> at
GMane, I can guess why this was accepted as "originator
(as indicated by the reverse-path)", but 2821bis doesn't
explain (1) why this is not more specified as in RFC 821,
(2) why it's a crucial decision where geting it wrong is
no option, and (3) why it's not more exactly the same
situation as 1989 when RFC 1123 was published.

"Better than 2821" and "good enough for DS" are unrelated
concepts.  Just because nobody uses 821 anymore (because
1123 rendered it useless) doesn't prove that the design
of 821 was wrong, or that the 1123 design inherited by
2821bs was "better".

And the utter contempt for mail standards demonstrated by
the approach to promote them without a proper WG is sad.

2821bis only demonstrates one thing, *never ever again*,
all wannabe-improvements of the standards process based
on this experience are dead on arrival.

 Frank

---

From: Bob Braden <[email-masked]>
Date: Mon, 10 Dec 2007 11:03:29 -0800

>Of the 5092 RFCs published, just 67 are Full Standards.

The real issue is not "STANDARDs", but "standards".  The great majority
of today's operational Internet protocol standards have status (category)
PROPOSED STANDARD or DRAFT STANDARD.  But they are in fact
standards for the Internet.  I believe that we need a naming/numbering
system for standards, independent of the numbering system we have
for documents.  See http://www.rfc-editor.org/rfcxx00.html, in case
you are unfamiliar with past efforts to solve this problem: STDs.

Bob Braden

---

From: Bob Braden <[email-masked]>
Date: Mon, 10 Dec 2007 11:16:21 -0800

>         numbers were expected to refer to current specs.

As I told you at IETF, I believe we can temporarily patch this
problem by adding information to
http://www.rfc-editor.org/rfcxx00.html#STDbySTD; entries like:

RFC#: (none) STD#: 10    SMTP  Simple Mail Transfer Protocol [Was RFC 821,
                                        obsoleted by RFC 2821 (Proposed 
Standard)]
RFC#: (none) STD#: 10    SMTP Service Extensions [Was RFC 1869,
                                        obsoleted by RFC 2821 (Proposed 
Standard)]
RFC#: (none) STD#: 10     Mail routing and the domain system [Was RFC 974,
                                        obsoleted by RFC 2821 (Proposed 
Standard)]

But this might help newbies, but it would only be a patch.

>If the answer is "no", then trying to write up a proposal is
Yes.

>willing to review and contribute?  Do we need to start thinking

Yes.

>suggests to me that a WG with a broader charter would be a bad

I 'dunno'

Bob Braden

---

From: Bob Braden <[email-masked]>
Date: Mon, 10 Dec 2007 11:20:22 -0800

At 12:34 PM 12/6/2007, Hallam-Baker, Phillip wrote:
>The numbering is problematic for many reasons, people have difficulty 
>keeping two sets of numeric identifiers straight. If you want me to refer 
>to something other than RFC-822 you have to give me something more 
>memorable to both myself and the audience I am attempting to communicate to.
>

I agree.  Note that there are quite a number of mnemonics assigned in 
http://www.rfc-editor.org/rfcxx00.html#STDbySTD.

>If you want to introduce an alternative identifier that people are likely 
>to use use something of the form IETF-SMTP-2008
>

Not bad.

Bob Braden

---

From: Bob Braden <[email-masked]>
Date: Mon, 10 Dec 2007 11:24:00 -0800

>what STD 10 is today

Starting from where we are now, this is not the interesting question.
I would claim that STD 10 is rcurrrently "Reserved for SMTP standard" but the
interesting issue is a hint on where to find the expected
replacement for RFC 821 and friends, ie 2821, in the standards
track.

Bob Braden

---

From: John C Klensin <[email-masked]>
Date: Mon, 10 Dec 2007 15:24:05 -0500

--On Monday, December 10, 2007 11:16 AM -0800 Bob Braden 
<[email-masked]> wrote:

>>         Proposed.  I shouldn't be left on the original
>>         document because it really isn't our latest and best
>>         thinking on the subject.  And it shouldn't be
>>         withdrawn because that leads to silly states in
>>         documents that have been written to call on "STD 999"
>>         precisely because those numbers were expected to
>>         refer to current specs.
>
>                                         obsoleted by RFC 2821
> (Proposed Standard)]
>                                         obsoleted by RFC 2821
> (Proposed Standard)]
>                                         obsoleted by RFC 2821
> (Proposed Standard)]

It is only a patch.  If you do it, it is not clear to me what 
the STD number (still) accomplishes.

The proposals (from others) to go to IETF-foo-2010 types of 
names solves one problem, but does not solve the problem of 
needing a _stable_ reference to the current state of a standard, 
nor the problem of assignment of designators  to Proposed and 
Draft Standards.   It, too, almost certainly requires an update 
to RFC 2026.

I see two fairly simple ways out of this.   I also see 
opportunities for a whole series of better solutions, but any of 
them would require some serious writing and discussion. 
IETF-mnemonic-date is included in that list because dates would 
need either resolution to days or a suffix and we'd have to 
decide whether normative errata changed the dates.

The simple ways:

(1) Decide that STD numbers raise too many complex issues and 
just drop them, despite the desire for a standard reference.

(2) Assign STD numbers to Proposed Standards, retaining them 
through the process and permitting the STD number to shift to a 
Proposed Standard that replaces a Full one.    Note that I 
proposed essentially that in draft-ietf-newtrk-docid-00, but it 
followed ISDs down the NEWTRK hole.

More complex ways include completely different identifier models 
(see above), pulling ISDs out of the trash bin, pulling "rfc 
sets" out of the trash bin, or trying to patch the various 
indexes to simulate one or the other of the latter two.

And, to be a little more explicit than my earlier note was, I 
think the entire discussion is a waste of time until the IESG 
spends a few minutes deciding what sorts of proposal they would 
take seriously enough to process.   I'm unlikely to spend more 
time on this until they do.

     john

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Dec 2007 09:43:55 +1300

On 2007-12-11 09:24, John C Klensin wrote:
> It is only a patch.  If you do it, it is not clear to me what the STD 
> number (still) accomplishes.

It's a new way into the maze and I think it's worth doing quickly, since
it doesn't misrepresent the formal standards process in any way. Ideally,
www.rfc-editor.org/smtp and www.rfc-editor.org/STD10 would also
take you straight there too. (Tools prototype?)

<snip>

> (2) Assign STD numbers to Proposed Standards, retaining them through the 
> process and permitting the STD number to shift to a Proposed Standard 
> that replaces a Full one.    

I agree with this. Thus a standard would be somewhere in a loop:

   PS10-->DS10-->STD10-->|
   ^                     |
   |_____________________|

      Brian

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 10 Dec 2007 12:50:29 -0800

To return to John's issue. It is not enough to have a unique identifier, there is a stability issue. Here there are two types of stability:
 
1) The ability to refer to a specific version of a standard in perpetuity: e.g. our mail server implements IETF-SMTP-2007
 
2) The ability to refer to a protocol specification without reference to the specific version, e.g. OCSP over IETF-HTTP transport.
 
In programming terms the second identifier may be considered to be an abstract class which must be realised as a concrete class. If IETF-FOO has a dependence on IETF-HTTP then IETF-FOO-YYY1 and IETF-HTTP-YYY2 must exist such that YYY1 >= YYY2.
 
The nice thing about this approach is that we can apply it retrospectively without having to do a lot of work as we already have mnemonics. The problem is that we do not have a means of distinguishing FTP (a standard) from HTTP (not a standard).

On a lexical level I would suggest that the default mnemonic be IETF-<wgname>[-<specifier>]-<year> where the specifier is optional.
 
This allows for the various PKIX standards to be grouped together: IETF-PKIX, IETF-PKIX-OCSP, IETF-PKIX-SCVP and so on.
 
In the case of a WG that is chartered to revise an existing protocol the name of the protocol it is chartered to revise is used.

Knowing in advance what the standard name is going to be is very helpful. It means that we can save an edit pass on documents for the RFC editor. But the IETF prefix makes it easy to grep for dependencies that are not yet declared a standard.
 
But I also agree with John in that this is all pointless unless the IESG can give direction as to what process they will support.

From: Bob Braden [mailto:[email-masked]]
Sent: Mon 10/12/2007 2:24 PM
To: John C Klensin
Cc: [email-masked]
Subject: Re: Revising full standards

Bob Braden

---

From: John C Klensin <[email-masked]>
Date: Mon, 10 Dec 2007 15:51:45 -0500

> take you straight there too. (Tools prototype?)

Of course, if "STD10" is a separate document, we are on the path 
to ISDs.   If it isn't, RFC 2026 and the application of STD 
numbers only to Full Standards takes a hit.

    john

---

From: Iain Calder <[email-masked]>
Date: Tue, 11 Dec 2007 06:22:27 -0500

Phillip Hallam-Baker wrote:
>
> On a lexical level I would suggest that the default mnemonic be
> IETF-<wgname>[-<specifier>]-<year> where the specifier is optional.

I expect specialists will continue to prefer the raw RFC
numbers and I doubt that others (including many decision
makers) care about working group acronyms.  Keep it short,
as was originally proposed:

  IETF-<protocol>  and
  IETF-<protocol>-<minimal-date>

<minimal-date> can be a 4-digit year where that suffices,
or something longer (year + letter suffix?) when multiple
documents superseding or extending each other are published
in the same year.

I foresee another problem, however.  SMTP remains the
Internet's email protocol, after decades of use and
extending.  Yet things could have turned out differently.
Protocols *can* get pushed aside by challengers that aren't
their descendants.  For example, suppose a completely
different protocol called IEP (Internet Email Protocol)
arises in the future and, due to its vastly superior
characteristics, becomes the dominant mail transport
system.  SMTP would then become historic and IEP would
need to be marked as the current standard.  Under these
circumstances, an IETF-SMTP label proves a poor choice.
The usefulness of the STD-10 label, however, is unaffected.

So perhaps the generic, undated labels proposed above
should be based on service descriptions rather than
protocol names:

  IETF-<service type>  and
  IETF-<protocol>-<minimal-date>
Eg:
  IETF-EMAIL     = STD-10   -> IETF-SMTP-1986
  IETF-SMTP-1986 = RFC-821
  IETF-SMTP-2001 = RFC-2821

> [but this lacks a] means of distinguishing FTP (a
> standard) from HTTP (not a standard).

I would argue that the real world thinks both are equally
standard.  Which brings me to my final point.  I am
fully in favour of a symbolic naming convention for STDs.
But that won't help rejuvenate the STD series -- symbolic
names are *already* used by people who aren't immersed
in the standards process.  Eg people refer to the email
transport protocol as SMTP, not STD-10.

I think that, for implementors and adopters alike, a
single, absolute definition is too simplistic a view to
be meaningful in today's world.  Merely renaming the STD
series won't solve the problem of deciding when/if the
STD-10 / IETF-EMAIL pointer should be changed from RFC-821
to RFC-2821.  But that's a bigger can of worms.

BTW, can anyone point me to documentation of previous
attempts to solve that bigger can of worms?

-ic

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 11 Dec 2007 08:16:07 -0800

> attempts to solve that bigger can of worms?

The archives and meeting notes from the late NEWTRK working group should 
prove interesting, albeit not uplifting, reading.

In particular, draft-ietf-newtrk-repurposing-isd and 
draft-otis-newtrk-rfc-set should be entertaining.

The WG was shut down without reaching a conclusion.

              Harald

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Dec 2007 09:24:46 -0800

> circumstances, an IETF-SMTP label proves a poor choice.

I think that that depends upon whether the <protocol> label defines a 
technology or a function. (This is in line with your later discourse, I 
believe.)  The word <protocol> is rather specific and says that the label 
applies to a particular technology.

> The usefulness of the STD-10 label, however, is unaffected.

Well, it's difficult to go below zero utility...

>   IETF-EMAIL     = STD-10   -> IETF-SMTP-1986

I think that we ask for trouble if we use a service-oriented label.  It 
invites the conflict that you cite, as well as trying to encompass too much.

There are simply too many technologies that are covered by service terms, like 
"email" or "web" or "routing" or "transport".

In fact, particular technologies, like SMTP and SIP, have more than enough 
specification pieces, to warrant a particular label, IMO.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Tony Finch <[email-masked]>
Date: Wed, 12 Dec 2007 15:43:55 +0000

On Tue, 11 Dec 2007, Iain Calder wrote:
>
> Protocols *can* get pushed aside by challengers that aren't their
> descendants.  For example, suppose a completely different protocol
> called IEP (Internet Email Protocol) arises in the future and, due to
> its vastly superior characteristics, becomes the dominant mail transport
> system.  SMTP would then become historic and IEP would need to be marked
> as the current standard.  Under these circumstances, an IETF-SMTP label
> proves a poor choice. The usefulness of the STD-10 label, however, is
> unaffected.

This has already happened in at least two cases. Telnet and rsh have
largely been displaced by ssh, and FTP and Gopher by HTTP. I'm not sure
that it's useful to have a formal numeric label for remote login, or file
transfer, or email, when we have perfectly adequate generic terminology.
I'm not even sure the IETF should make a de jure choice between
competitors, especially when it's likely to be embarrassingly different
from the market's de facto choice. That, too, has already happened, to the
OSI protocols.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
LUNDY FASTNET IRISH SEA: SOUTH 5 TO 7. MODERATE OR ROUGH. DRIZZLE. MODERATE OR
GOOD.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 12 Dec 2007 08:53:46 -0800

I don't see the relevance of a service label such as 'email' in the context of standards identifier either.
 
I do not think that there is any real likelihood that SMTP will be displaced by another email protocol ever. When SMTP is displaced it is going to be displaced by something that offers more functionality than mail. Probably some form of hybrid protocol that seamlessly integrates asynchronous and synchronous messaging.
 
So lets return to my actual proposal rather than the strawman. IETF-SMTP is the designator for the class of SMTP protocols, IETF-SMTP-2007 would be the designator for the latest incarnation to be designated as a standard.

STD10 corresponds to IETF-SMTP. In my view it is an almost useless designator as currently used because it means nothing. If someone tries to refer to STD10 they cannot refer to a specific version.
 
There is a context in which I would like to be able to refer to an abstract class and that is in the area of crypto protocols. Imagine that IETF-CRYPTO refers to the set of currently recommended algorithms for use in IETF protocols. 
 
IETF-CRYPTO-2007 probably looks something like RSA-2048, SHA256, AES-128.
IETF-CRYPTO-2020 will probably look something like ECC-XX, SHA3-512, AES-256
 
I would argue that if we have done the job of specifying a cryptographic protocol standard correctly we have also specified the interface to cryptographic algorithms. It should be possible for a specification to make a statement of the form 'implementations MUST support the bulk encryption cipher specified as required in IETF-CRYPTO-2007 and successors.' 
 
What this then allows us to do is to define specifications for S/MIME, TLS, IPSEC, etc. in such a way that they upgrade automatically. Once an algorithm is a MUST implement it becomes essential for interoperation more or less in perpetuituy. 
 
Clearly there would be a likelihood of some fixup work that was protocol specific to be specified. I would expect that the IETF-CRYPTO-XXXX RFCs would point to other RFCs defining algorithm identifiers, parameters and in some cases fixups for specific protocols (e.g. definition of CBC mode).
 
This approach has the potential to save the IESG a whole heap of work in future years. Instead of having to re-process every one of the underlying protocol specifications independently there is a single set of work. We are likely to get better consistency as well, we are more likely to discover peculiar situations where different specifications take different positions on padding, endian-ness and such.
 
The crypto area is somewhat constrained, we have a fairly strong consensus as to what crypto algorithms make up the cannon. I don't think the same applies to many other areas. I don't think we are likely to come to a unanimous agreement as to what a single canonical IETF-WEBSERVICES-XXXX might be, but we might be able to come to agreement on what IETF-WSHTTP, IETF-WSBEEP, IETF-WSSOAP mean and then let market forces, support in Web Services platforms etc eliminate the superfluous options.

I simply cannot see the same mechanisms evolving if we stick to the STD-10 approach. Its a machine code approach. I know that we worked at the machine code level in the 1980s. I was programming machine code myself in those days. Later on I wised up and got myself an asembler.
 
I have a limited number of memory slots for opaque numeric identifiers and they are all full.

From: Dave Crocker [mailto:[email-masked]]
Sent: Tue 11/12/2007 12:24 PM
To: Iain Calder
Cc: [email-masked]; Hallam-Baker, Phillip; John C Klensin; Bob Braden
Subject: Re: Revising full standards

d/
--

   Dave Crocker

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 12 Dec 2007 09:18:48 -0800

Although HTTP has effectively displaced FTP the functionality is quite different and very few people would consider them interchangeable to the extent that a common identifier would be useful or meaningful.
 
The replacement of Telnet by SSH is closer but I still don't think that there are many people who want a single identifier to refer to them both.
 
I don't think HTTP is ever going to superceed the terminal interaction style mode of FTP. I can however see the residual functionality of FTP being absorbed into SSH-Plus. This would be logical for another reason, it would allow the problem of tunelling and encrypting the data channel through NAT to be solved.

Given that Iain was raising an objection to a proposal nobody was actually making I think it can be dropped.

From: Tony Finch [mailto:[email-masked]]
Sent: Wed 12/12/2007 10:43 AM
To: Iain Calder
Cc: [email-masked]
Subject: Re: Revising full standards

Tony.