Subject: Old transport-layer protocols to Historic?

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 06 Jan 2011 07:44:41 +0200

Hello all,

There have been a discussion on tsvwg mailing list about old transport 
layer protocols - exactly IRTP (RFC938), RDP (RFC908,1151) and NETBLT 
(RFC998). Initially there have been proposed to define IANA 
considerations for them. But after a discussion it was found out that it 
would be better to move them to Historic. I am writing to request more 
wider discussion on this topic.

There is quite strong consensus that IRTP should be Historic. There is a 
registered draft on this topic:

https://datatracker.ietf.org/doc/draft-yevstifeyev-tsvwg-irtp-to-historic/

But as for others it should be discussed. Moreover, maybe anyone knows 
some other old transport-layer protocols that are no longer in use?

Please copy tour answer to [email-masked]

All the best,
Mykyta Yevstifeyev

---

From: Bob Braden <[email-masked]>
Date: Thu, 06 Jan 2011 12:40:11 -0800

Historic might imply that they were once in service, but have later been 
replaced/deprecated. In fact, these protocols were always, and are 
still, *experimental*.  It would seem logical to assign them the 
Experimental category and be done with it.

Bob Braden

On 1/5/2011 9:44 PM, Mykyta Yevstifeyev wrote:
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Scott Brim <[email-masked]>
Date: Thu, 06 Jan 2011 16:00:59 -0500

> Experimental category and be done with it.

Yup.

---

From: Lixia Zhang <[email-masked]>
Date: Thu, 6 Jan 2011 13:08:26 -0800

On Jan 6, 2011, at 12:40 PM, Bob Braden wrote:

> 
> Historic might imply that they were once in service, but have later been replaced/deprecated. In fact, these protocols were always, and are still, *experimental*.  It would seem logical to assign them the Experimental category and be done with it.
> 
> Bob Braden

I would like to second Bob's position here.

as a co-author for  NETBLT (RFC998): NETBLT was out of a research effort to answer the question: can we *fully* utilize long delay, high bandwidth (and potentially error prone) networks?  NETBLT says and here is one way to do it. 
Over the years (it's published in 1987) I have received comments from many people saying that they learned something interesting or even useful from NETBLT. The NETBLT paper (SIGCOMM 1987) got cited over 200 times.

As RFC998 stated clearly:

   This document is published for discussion and comment, and does not
   constitute a standard.  The proposal may change and certain parts of
   the protocol have not yet been specified; implementation of this
   document is therefore not advised.

I don't see any harm to keep it as is.

Lixia
PS: on the other hand, what would a "historical status" imply?  the ideas obsolete?

---

From: "t.petch" <[email-masked]>
Date: Fri, 7 Jan 2011 18:04:46 +0100

----- Original Message -----
From: "Lixia Zhang" <[email-masked]>
To: "Bob Braden" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 06, 2011 10:08 PM
> > Historic might imply that they were once in service, but have later been
replaced/deprecated. In fact, these protocols were always, and are still,
*experimental*.  It would seem logical to assign them the Experimental category
and be done with it.
> as a co-author for  NETBLT (RFC998): NETBLT was out of a research effort to
answer the question: can we *fully* utilize long delay, high bandwidth (and
potentially error prone) networks?  NETBLT says and here is one way to do it.
> Over the years (it's published in 1987) I have received comments from many
people saying that they learned something interesting or even useful from
NETBLT. The NETBLT paper (SIGCOMM 1987) got cited over 200 times.
> I don't see any harm to keep it as is.

Which is more or less the opinion I see expressed on the tsvwg list.

Perhaps it needs raising it on yet other lists in order to get
different answers:-)

Tom Petch

---

From: Bob Hinden <[email-masked]>
Date: Fri, 7 Jan 2011 11:53:06 -0800

Mykyta,

On Jan 5, 2011, at 9:44 PM, Mykyta Yevstifeyev wrote:

> Hello all,
> 
> There have been a discussion on tsvwg mailing list about old transport layer protocols - exactly IRTP (RFC938), RDP (RFC908,1151) and NETBLT (RFC998). Initially there have been proposed to define IANA considerations for them. But after a discussion it was found out that it would be better to move them to Historic. I am writing to request more wider discussion on this topic. 

I see little value even thinking about this.  It's looks like a "make work" project to me.  Just because something is "old", doesn't mean it is "historic" in the sense the label is used in the IETF.

Regarding RDP (RFC908, RFC1151), of which I am one of the authors, both are currently labeled as Experimental.  I do not see any reason to change that. 

Bob

> There is quite strong consensus that IRTP should be Historic. There is a registered draft on this topic:
> 
> But as for others it should be discussed. Moreover, maybe anyone knows some other old transport-layer protocols that are no longer in use?
>

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 08 Jan 2011 07:13:36 +0200

> Regarding RDP (RFC908, RFC1151), of which I am one of the authors, both are currently labeled as Experimental.  I do not see any reason to change that.
Dear all,

RFC2026 mentions:

>   A specification that has been superseded by a more recent
>     specification or is for any other reason considered to be obsolete is
>     assigned to the "Historic" level.
and gives 2 reasons for making the RFC Historic: 1) RFC is obsoleted 
(superseded) or 2) obsolete.

Obsoleted = made obsolete. This is obvious. When one RFC replaces 
another, it obsoletes it, and second becomes obsolete.

What is obsolete (adj.)? Obsolete = deprecated, outdated, out of use, 
non-current, etc.

Moreover, RFC2026 does not set any other guidelines for setting the 
Historic status. That is why if the protocol is out of use, even 
specified by Experimental RFC, it is a reason to move its spec. to 
Historic, in accordance with RFC2026.

All the best,
Mykyta Yevstifeyev

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 07 Jan 2011 21:26:02 -0800

On 1/6/2011 12:40 PM, Bob Braden wrote:
> replaced/deprecated.

We assign labels to indicate the status of the specification, not the status of 
a service that might use it.

We say 'experimental' to mean that we thinks it's ok to play around with the 
spec and maybe that we are hoping to get further information about it.  But it 
also means that we very much caution about use.  It's our "caveat emptor" label.

We say 'historic' when we frankly think the spec should now not be used, for 
whatever reason and no matter its prior status.

These both are affirmative labels.  I too do not think we should use them for 
"housekeeping" and the mere fact that a specification is not used does not mean 
that it shouldn't be used.

To the extent that having a spec around -- especially one on standards track -- 
might seem to conflict with another, preferred spec, then it's worth considering 
making the one that is out of favor become historic.  The same holds for 
specifications that are now deemed problematic.

But none of this is about propriety or neatness or a community OCD neurosis.  It 
needs to be about pragmatic guidance to the community.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 08 Jan 2011 07:35:58 +0200

08.01.2011 7:26, Dave CROCKER wrote:
> We assign labels to indicate the status of the specification, not the 
> status of a service that might use it.
But the specification without service is nothing. We should look at the 
service using it, first of all.
>
> We say 'experimental' to mean that we thinks it's ok to play around 
> with the spec and maybe that we are hoping to get further information 
> about it.  But it also means that we very much caution about use.  
> It's our "caveat emptor" label.
>
> We say 'historic' when we frankly think the spec should now not be 
> used, for whatever reason and no matter its prior status.
>
> These both are affirmative labels.  I too do not think we should use 
> them for "housekeeping" and the mere fact that a specification is not 
> used does not mean that it shouldn't be used.
>
> To the extent that having a spec around -- especially one on standards 
> track -- might seem to conflict with another, preferred spec, then 
> it's worth considering making the one that is out of favor become 
> historic.  The same holds for specifications that are now deemed 
> problematic.
But it is the same what is with IRTP. RFC938 is obviously not acceptable 
to be used in the current Internet. In order it remains useful, it's 
needed to be rewritten or moved to Historic. And I really do not 
understand how did it become Experimental. The first notices of current 
classification system appeared in RFC1370, while this spec is RFC938.

Mykyta Yevstifeyev
>
> But none of this is about propriety or neatness or a community OCD 
> neurosis.  It needs to be about pragmatic guidance to the community.
>
> d/
>

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 8 Jan 2011 08:12:48 -0800

On Jan 7, 2011, at 9:13 PM, Mykyta Yevstifeyev wrote:

> and gives 2 reasons for making the RFC Historic: 1) RFC is obsoleted (superseded) or 2) obsolete.
> 
> Obsoleted = made obsolete. This is obvious. When one RFC replaces another, it obsoletes it, and second becomes obsolete.
> 
> What is obsolete (adj.)? Obsolete = deprecated, outdated, out of use, non-current, etc.
> 
> Moreover, RFC2026 does not set any other guidelines for setting the Historic status.

that is because only standard track protocols need such guidelines

> That is why if the protocol is out of use, even specified by Experimental RFC, it is a reason to move its spec. to Historic, in accordance with RFC2026.

First, you said RFC2026 did *not* say anything on moving non-standard protocols to Historic status.

Then you said Experimental RFCs need to move to Historic, in accordance with RFC2026.

Doesn't this sound self-conflicting to you?

Lixia

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 08 Jan 2011 18:19:29 +0200

> that is because only standard track protocols need such guidelines
Where is that, once more?
> Then you said Experimental RFCs need to move to Historic, in accordance with RFC2026.
RFC2026 in Section 4.2.4. says nothing about this.  It is indefinite, 
per this section.  What you said 'first' was what do all think.  And the 
second what I do.  And maybe not need to move but may be moved.

Mykyta Yevstifeyev

---

From: John C Klensin <[email-masked]>
Date: Sat, 08 Jan 2011 11:57:14 -0500

--On Friday, January 07, 2011 21:26 -0800 Dave CROCKER
<[email-masked]> wrote:

>> Historic might imply that they were once in service, but have
>> later been replaced/deprecated.
> 
> 
> We assign labels to indicate the status of the specification,
> not the status of a service that might use it.
> 
> We say 'experimental' to mean that we thinks it's ok to play
> around with the spec and maybe that we are hoping to get
> further information about it.  But it also means that we very
> much caution about use.  It's our "caveat emptor" label.
> 
> We say 'historic' when we frankly think the spec should now
> not be used, for whatever reason and no matter its prior
> status.
> 
> These both are affirmative labels.  I too do not think we
> should use them for "housekeeping" and the mere fact that a
> specification is not used does not mean that it shouldn't be
> used.

Dave (and Bob),

I'm clearly on record as believing that it is time we do
something about the category labels we have, either to improve
clarity and distinctions or to supplement or replace the
categories with narrative.  I've also got doubts as to whether
this sort of reclassification effort is worth the energy it
takes (an opinion I think I expressed privately to Mykyta very
early in the process).  To some extent, if someone cannot figure
out that they should at least ask a lot of questions about a
protocol that was identified 20+ years ago as Experimental and
that has not been followed up on since, maybe they deserve
whatever happens to them.

But, in a context in which we have stretched "best current
practice" to including both IETF procedures and ideas about how
things should be operated and other statements that have not
been tested in practice a all, we disagree a bit about the
meaning of terms.   I think "experimental" isn't just a warning
label, it is also an implicit invitation to experiment.   Here,
if the experiments were performed (and some were) and the
results written up, recommendations with those results might
well have said "don't use this in this form".  That would have
met most criteria for reclassification to Historic.

It has long been my personal view that, while the automatic
timeout provisions of RFC 2026 have never been successfully
applied to standards-track protocols, a somewhat similar rule
should apply to Experimental work: either some progress --a
report on the experiment, an update to the protocol spec
(possibly including a move to Standards Track but not
necessarily), or something equivalent occurs in some reasonable
period of time, the spec automatically moves to Historic
(because it is the only nearly-appropriate category we have) as
no longer of interest.

Interestingly, NETBLT seems to be a special case of just that
situation: it was implemented, small problems with it were
discovered in a different environment, changes were made, and a
revised spec was published outside the IETF under another name
(there was also an I-D within the IETF pointing to that spec,
but it was allowed to expire without any action).  If Mykyta (or
someone else) is willing to do the work, and an appropriate AD
is willing to sponsor it or assign review to a WG, then I see
considerable advantage in publishing that newer spec or a
pointer to it, preferably with an analysis of limitations, as
either an Informational or Historic record for the community and
using that document to obsolete the original experimental spec.
Documenting ideas that didn't quite work, or that work only in
specialized environments with a good description of those
environments, is the only way we can make progress rather than
repeating ideas that are known to be failures or limited in
scope.

As far as the others are concerned, the procedures don't work
the way I've described above.  While I wouldn't personally want
to invest significant effort in reclassification (and didn't put
significant effort into the successful "de-crufting" effort of
several years ago), I also don't see any harm in it if Mykyta
(or someone else) wants to invest the energy and can find
appropriate AD sponsorship.   I only wish that we had not made
reclassification to Historic, even of experimental specs to
which no one has paid attention for years, into a painful
process that requires nearly as much work as getting a
standards-track specification approved.  There is actually
nothing in RFC 2026 or related documents that requires that much
effort.

    john

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 09 Jan 2011 08:19:00 +0200

08.01.2011 18:57, John C Klensin wrote:
> categories with narrative.
Here I agree with you.  At least as for Historic one.
>    I've also got doubts as to whether
I also agree here.  Experiment has been conducting and some improvements 
should be made or we should claim that during the experiment no one 
found it useful etc
> nothing in RFC 2026 or related documents that requires that much
IMO old, outdated, out-of-use specification wither they are Standards 
Track or Experimental should be moved to Historic.  It is clearly stated 
in RFC2026 - is considered to be obsolete (i.e. outdated).  I don't find 
anything harmful in identifying, e.g. IRTP as 'Not Recommended For Use' 
via Historic status.

Mykyta

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 09 Jan 2011 08:27:54 +0200

>> Regarding RDP (RFC908, RFC1151), of which I am one of the authors, both are currently labeled as Experimental.  I do not see any reason to change that.
Bob, all,

Personally I don't support the idea to move the RDP to Historic. The 
initial idea was to defined IANA procedures for assignment RDP ports, 
that remains undefined. But when I presented the corresponding draft to 
tsvwg, many claimed that it would be better to move it ti Historic 
rather than specify IANA procedures for it. Currently, there is a draft 
on this topic:

http://tools.ietf.org/html/draft-yevstifeyev-rdp-ports-registry-02

My initial idea was just that.  And you, Bob, do you find this topic 
interesting (RDP ports assignment) as the developer of RDP?

Mykyta Yevstifeyev

>>> Please copy tour answer [email-masked]
>>>
>>> All the best,
>>> Mykyta Yevstifeyev

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 9 Jan 2011 01:06:10 -0700

Mykyta,

RDP is still in use (I know of companies using it).  It is
used heavily as a transport for a "popular brand" of NAS for
dial access call control and was a precursor to MEGACO/H.248.
RDP was the initial transport used for gateway control (such
as SGCP) until SCTP was developed.  Many commercial gateways
still support these older pre-standard (to MEGACO) control
protocols.  Some older devices still provisioned in the network
only support the older protocols.

Yah, I know it was EXPERIMENTAL, but we had nothing before SCTP
that would fit the bill.  Its limitations was one of the driving
forces behind developing SCTP.  One of the original protocol
attempts abandonned before SCTP was based on RDP.

Please leave RDP alone.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Eric Rosen <[email-masked]>
Date: Mon, 10 Jan 2011 12:45:56 -0500

> RDP is still in use

> was the initial transport used for gateway control (such as SGCP) until
> SCTP was developed.

> Many commercial gateways still support these older pre-standard (to
> MEGACO) control protocols.  Some older devices still provisioned in the
> network only support the older protocols.

> but we had nothing before SCTP that would fit the bill.  Its limitations
> was one of the driving forces behind developing SCTP.

So RDP is a useful and deployed pre-standards protocol that was one of the
driving forces behind a successful standardization effort.  But newer
applications that need that kind of transport instead use the standard,
SCTP.

I don't know how one could possibly make a stronger case for classifying the
RDP spec as Historic!

However, I do agree with John Klensin's remark that reclassification is not
worth the energy it takes.

---

From: "t.petch" <[email-masked]>
Date: Tue, 11 Jan 2011 12:36:10 +0100

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "Mykyta Yevstifeyev" <[email-masked]>
Cc: "Bob Hinden" <[email-masked]>; <[email-masked]>; "IETF Discussion"
<[email-masked]>
Sent: Sunday, January 09, 2011 9:06 AM

>From the tsvwg list
Date: Tue, 11 Jan 2011 11:21:38 +0200
Message-ID: <AANLkTi=[email-masked]>
"I personally think there is no useful way in moving NETBLT spec to
historic, as well as RDP. I consider that useful only for IRTP. Do you
think there is still a need in such protocol? what has it been made
for?

Mykyta."

which sounds like consensus on NETBLT and RDP.

Tom Petch

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 11 Jan 2011 17:15:33 +0200

11.01.2011 13:36, t.petch wrote:
> From: "Brian F. G. Bidulock"<[email-masked]>
> To: "Mykyta Yevstifeyev"<[email-masked]>
> Cc: "Bob Hinden"<[email-masked]>;<[email-masked]>; "IETF Discussion"
> <[email-masked]>
> Message-ID:<AANLkTi=[email-masked]>
Tom,

But not IRTP.  I was initially, and I am now strongly concerned that 
this protocols is not useful anyway.

Mykyta