Subject: Re: History behind RFC numbers

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 1 Oct 2014 23:29:47 +0200

On Monday, September 29, 2014, Hosnieh Rafiee wrote:

. Sometimes I see it is not a sequential numbers for new RFCs.

IMHO the way the RFC number is done is just complicated for
history/discussions and difficult to remember (there is possibility of
error in discussions among participants when referring mistakenly with
wrong number).  Especially in the future where we will have many RFCs
and many updates which we need to refer to in discussions. RFC number were
done not to continue in future with very large numbers.

I understand the RFC-document mentioning Request For Comment, meaning as
having availability to be commented on and update at all times. I see the
RFC-numbers with no value or meaning, I think we should have more meaning
involved to help the reference number to be remembered or to help
in discussions.

We have RFC version zero we may need a new version. We can re-structure the
RFC-number so we can say Area (A one digit), WG (WW two digits). The RFC
numbers in digits meaning (1AWWSS). This structure type is 1 (or version
1), our current structure with no meaning can have type 0.

 For example for the new structure/version/series RFC, all start with 1 and
for all security area RFCs to follow with 9, routing area follow with 5,
etc. or another example to have three first decimal digits (we may change
to hexadecimal if there were interest) to indicate meaning and the
following being their sequence number. SS can have some reserve digits for
updates purposes. If the RFC191020 is obsolete then it will have new update
to be RFC191021. If the RFC is not obsolete but just updated then we can
have normal sequence while 21 is reserved for time to obsolete 20 and have
full update 21.

Furthermore, within meetings/on-list of a WG we don't need to refer WG-RFC
with large numbers but just say in speech our SS numbers for the WG, but
when writing within draft we need to reference full number of RFC1AWWSS or
RFC02460 or RFC01.

Just thoughts to make RFC numbers with good meaning, good sequences, and
more interconnected. I don't think it is right that we
MUST remember numbers/digits that have no meanings.

Regards

AB

---

From: Eric Burger <[email-masked]>
Date: Wed, 1 Oct 2014 17:52:07 -0400

That is why we call it IP, TCP, HTTP, SMTP, etc. That is the ‘thing’ that is easy to remember.

On Oct 1, 2014, at 5:29 PM, Abdussalam Baryun <[email-masked]> wrote:

> IMHO the way the RFC number is done is just complicated for history/discussions and difficult to remember (there is possibility of error in discussions among participants when referring mistakenly with wrong number).  Especially in the future where we will have many RFCs and many updates which we need to refer to in discussions. RFC number were done not to continue in future with very large numbers.
> 
> I understand the RFC-document mentioning Request For Comment, meaning as having availability to be commented on and update at all times. I see the RFC-numbers with no value or meaning, I think we should have more meaning involved to help the reference number to be remembered or to help in discussions.
> 
> We have RFC version zero we may need a new version. We can re-structure the RFC-number so we can say Area (A one digit), WG (WW two digits). The RFC numbers in digits meaning (1AWWSS). This structure type is 1 (or version 1), our current structure with no meaning can have type 0. 
> 
>  For example for the new structure/version/series RFC, all start with 1 and for all security area RFCs to follow with 9, routing area follow with 5, etc. or another example to have three first decimal digits (we may change to hexadecimal if there were interest) to indicate meaning and the following being their sequence number. SS can have some reserve digits for updates purposes. If the RFC191020 is obsolete then it will have new update to be RFC191021. If the RFC is not obsolete but just updated then we can have normal sequence while 21 is reserved for time to obsolete 20 and have full update 21. 
> 
> Furthermore, within meetings/on-list of a WG we don't need to refer WG-RFC with large numbers but just say in speech our SS numbers for the WG, but when writing within draft we need to reference full number of RFC1AWWSS or RFC02460 or RFC01. 
> 
> Just thoughts to make RFC numbers with good meaning, good sequences, and more interconnected. I don't think it is right that we MUST remember numbers/digits that have no meanings. 
> 
> Regards
> 
> AB
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 2 Oct 2014 13:33:03 +0200

I have attended some IETF WG meetings and they call protocols with numbers
with 4 digits. It is better to use numbers than use protocol name to refer
to specifications, because Internet-devices implement protocols by
specifications which may exclude update specifications.

AB

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 2 Oct 2014 11:46:11 +0000

>We have RFC version zero we may need a new version. We can re-structure the RFC-number so we can say Area (A one digit), WG (WW two digits). The RFC numbers in digits meaning (1AWWSS). This structur…

[Hosnieh] Interesting idea :-). Probably worth to discuss in rfc-interest list(?!). Because at the moment when someone talk about RFC number and if you didn't want to use it, you don't know which area it is related to unless you check everything on the internet. Sometimes the titles are not also good chosen and so general and one need to review the abstract and sometimes introduction so that he/she understands what area it is related to. 

> Furthermore, within meetings/on-list of a WG we don't need to refer WG-RFC with large numbers but just say in speech our SS numbers for the WG, but when writing within draft we need to reference fu…

Best,
Hosnieh

---

From: Riccardo Bernardini <[email-masked]>
Date: Thu, 2 Oct 2014 13:52:20 +0200

On Thu, Oct 2, 2014 at 1:46 PM, Hosnieh Rafiee <[email-masked]>
wrote:

>
> >We have RFC version zero we may need a new version. We can re-structure
> the RFC-number so we can say Area (A one digit), WG (WW two digits). The
> RFC numbers in digits meaning (1AWWSS). This structure type is 1 (or
> version 1), our current structure with no meaning can have type 0.
>
>
> [Hosnieh] Interesting idea :-). Probably worth to discuss in rfc-interest
> list(?!). Because at the moment when someone talk about RFC number and if
> you didn't want to use it, you don't know which area it is related to
> unless you check everything on the internet. Sometimes the titles are not
> also good chosen and so general and one need to review the abstract and
> sometimes introduction so that he/she understands what area it is related
> to.
>

Only one doubt: are enough two digits for the working group?  This means
100 WG maximum, unless the area acts as a "namespace" for the WG (so that
112300 and 122300 are from two differents WG).  Even in the latter case you
would have 100 WG per area, how much time this will last.

>
> > Furthermore, within meetings/on-list of a WG we don't need to refer
> WG-RFC with large numbers but just say in speech our SS numbers for the WG,
> but when writing within draft we need to reference full number of RFC1AWWSS
> or RFC02460 or RFC01.
>
> Best,
> Hosnieh
>

---

From: Loa Anderson <[email-masked]>
Date: Thu, 2 Oct 2014 13:53:27 +0200

Can someone tell me what is broken?

/Loa

Sent from my iPad

> On 02 Oct 2014, at 13:46, Hosnieh Rafiee <[email-masked]> wrote:
> 
>

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 2 Oct 2014 12:10:58 +0000

>Only one doubt: are enough two digits for the working group?  This means 100 WG maximum, unless the area acts as a "namespace" for the WG (so that 112300 and 122300 are from two differents WG).  Even in the latter case you would have 100 WG per area, how much time this will last.

That might be true. However, if the digits only are refer to general areas, are we still in trouble? This should be a problem if the digits refer to an a specific WG.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Oct 2014 13:23:16 +0100

> Can someone tell me what is broken?

IETF participant inability to refrain from commenting
on even the silliest proposals?

S

---

From: t.p. <[email-masked]>
Date: Thu, 2 Oct 2014 14:41:48 +0100

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "Loa Anderson" <[email-masked]>
Cc: "ietf" <[email-masked]>
Sent: Thursday, October 02, 2014 1:23 PM
> on even the silliest proposals?

but it is a nice exemplar of the point that incorporating structure in
an identifier is almost always a bad idea, as the structure does not
persist for very long.  An identifier should be an identifier, easy to
use, to read and write and to enter into some store of information where
the details can be found.

Tom Petch

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Thu, 02 Oct 2014 06:24:53 -0700

On 9/29/14 4:47 AM, Hosnieh Rafiee wrote:
> Hi, Anybody knows the history behind RFC numbers. How it started
> and which document explained this. Sometimes I see it is not a
> sequential numbers for new RFCs. Thanks Best, Hosnieh
> 
> 

Topics like this one are better sent to the rfc-interest list
(https://www.rfc-editor.org/mailman/listinfo/rfc-interest).  That
said, and to answer the later comments on this thread, creating a
unique cataloguing system for RFCs would, in my mind, provide very
little value versus how much work creating and maintaining such a
system would entail.  Meaningless numbers and a decent search engine
are a much saner approach for this kind of document series.

- -Heather Flanagan, RSE

---

From: manning bill <[email-masked]>
Date: Thu, 2 Oct 2014 10:12:59 -0700

or, best of all, we can remove confusing strings and numbers with the very specific and unique OIDs for documents, protocols, and people.  :)

last century, the RFC series and the IEN series that preceded it used the numbering sequence as an index into the catalog of related materials.
occasionally a number or numbers would be “earmarked” for material that was supposed to be forthcoming, but never arrived (for one reason or another).

such a system worked very well for nearly five decades.  but it does not work for a few of the more recent participants in the system.   which is fine, most of 
us are adaptable and are not committed to the status quo, IF you have a more workable solution.

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: Bob Braden <[email-masked]>
Date: Thu, 02 Oct 2014 13:31:05 -0700

This discussion is deeply flawed. RFC numbers are largely that -- 
DOCUMENT NUMBERS, assigned to the RFCs during publication.
They serve a vital function for cataloging RFC documents.

Over the years, the community has tended increasingly to use RFC numbers 
as PROTOCOL LABELS.  Originally life was simple;
protocols had labels. If  you wanted to refer to the TCP spec you could 
just ask for "TCP".   But protocol engineers tend to be
numerically oriented, not particularly verbal (with some notable 
exceptions you know ;-)), and they started to refer to
  "793" when they meant TCP.

We have managed to get along with a half-ACKed solution to protocol 
accession, typified by the sequence
RFC822 -> RFC2822. This was Jon Postel's and Joyce Reynolds' attempt to 
force RFC *document numbers*
  to serve as *protocol numbers*.  As noted in this discussion, this led 
to some apparent mysterious
randomness in RFC number assignment.

Now, a few years ago at a meeting of some sort of IETF reformation group 
(I forget the name), I advocated
  the development of *structured protocol names*. RFC (document) numbers 
do NOT fill that bill. We need
both  RFC document numbers and protocol names.

  Possible properties of protocol names might be:
(1) names, not numbers!!
(2) Probably hierarchical; think domain names.
(3) Might incorporate the "Obsoletes" attribute by some sort of 
generation number.
   ("TCP.1", "TCP.2," ...)
(4) Should be backwards compatible in general with our inherited 
protocol names.
(5) Would be assigned by the IESG early in the standards process, e.g., 
in the WG charter from the beginning.
But of course YMMV.

If we had such a name space, it might give the IESG a handle for 
organizing the currently highly random
standards development process.  See for example TCP.ROADMAP/1 (i.e., 
RFC4614 vers 1) to see how chaotic
the process has become.

Conclusions:

    Don't make small changes
    Think carefully before making any process changes.
    There are real and serious process problems in the IETF.

---

From: John C Klensin <[email-masked]>
Date: Fri, 03 Oct 2014 16:03:16 -0400

--On Thursday, October 02, 2014 13:31 -0700 Bob Braden
<[email-masked]> wrote:

> Now, a few years ago at a meeting of some sort of IETF
> reformation group (I forget the name), I advocated
>   the development of *structured protocol names*.

The ill-fated NEWTRK, which also included proposals to extend
the STD number model into comprehensive descriptions of just
what was, and was not, in a standard on a more dynamic basis
that static/ archival RFCs.

> RFC
> (document) numbers do NOT fill that bill. We need
> (3) Might incorporate the "Obsoletes" attribute by some sort
> of generation number.
>    ("TCP.1", "TCP.2," ...)
> (4) Should be backwards compatible in general with our
> inherited protocol names.
> (5) Would be assigned by the IESG early in the standards
> process, e.g., in the WG charter from the beginning.
> But of course YMMV.

yep.

    john

---

From: Nico Williams <[email-masked]>
Date: Fri, 3 Oct 2014 18:23:42 -0500

>  Possible properties of protocol names might be:

It should be possible to do this as aliases of numbered RFCs.

In some areas we already do this informally.

One of the nice things is that some aliases could be changed as RFCs get
obsoleted.  Just like STDs.

> (2) Probably hierarchical; think domain names.

Whatever's appropriate, sure.  Hierarchical naming won't work for some
things that have something like multiple inheritance.

For example, would RFC4121 be Kerberos.GSS or GSS.Kerberos??

Also, we already tend to speak of GSS-xyz when we mean "a GSS mechanism
based on xyz", and "xyz-GSS" when we mean that protocol "xyz using GSS".

I'd rather not make hierarchical naming a hard requirement, just give
guidance and let those picking the names do so wisely.

> (3) Might incorporate the "Obsoletes" attribute by some sort of

Hmmm, maybe.  Combining (2) and (3) we might end up with names like
PAWS.1.TCP.2 or PAWS.1:TCP.2, ...   Eww.

I'd rather that the aliases follow the latest, then we'd have just
PAWS.TCP.  But it's true that being able to refer to a past version of
something would be convenient.

This is worth doing.  I'm not sure that we need to do massive surgery on
the IETF process here.  I'd just allow something like first-come-first-
served assignment -by WG chairs and IESG members- of aliases to RFCs.

Later on we might require this for new publications.

Later still we might deprecate numbering for new publications.

KISS and all that.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 3 Oct 2014 18:32:54 -0500

Maybe hierarchical RFC names/aliases could look like:

    RFC.foo.bar.baz

Versioned names would look like:

    RFC.foo-0.bar-1.baz-3

Versions could be left off on the least significant elements:

    RFC.foo-0.bar-1.baz (OK)
    RFC.foo-0.bar.baz   (OK)
    RFC.foo-0.bar.baz-3 (NOT OK)
    RFC.foo.bar.baz     (OK)

Update != version change.

Obsolescence == version change.

Versioning should mostly be for each named component independent of the
rest.

Publishing a foo-1 that doesn't subsume/obsolete the others would lead to

    RFC.foo-1.bar-1
    RFC.foo-1.bar-1.baz-3

being new aliases for the old RFC.foo-0.bar-1 and RFC.foo-0.bar-1.baz-3
RFCs.  Which means: RFCs could have multiple names.

Nico
--

---

From: Melinda Shore <[email-masked]>
Date: Fri, 03 Oct 2014 15:37:34 -0800

> It should be possible to do this as aliases of numbered RFCs.

More to the point, RFC numbers are identifiers, and what's
being discussed here is metadata.  And classification.  Which
is a sort of metadata but also has a structural function.
Anyway.

There's an entire field of knowledge that deals with this
kind of thing.  It's called "librarianship."  That said, I'm
not convinced there's a problem.  Seems to me that we ought to
have some sort of token system whereby a document review earns
a person a token that entitles him or her to <n> comments in rathole
threads, and they don't get to comment in those threads without
tokens [not directed at you].

Melinda

---

From: Nico Williams <[email-masked]>
Date: Fri, 3 Oct 2014 18:54:26 -0500

> kind of thing.  It's called "librarianship."  That said, I'm

IOW, we need a librarian.

> tokens [not directed at you].

I guess I have enough tokens!

To make this really useful mailman would have to implement this
filtering function.  It might cause participants to do more reviews...