Re: Submission Informational RFC

Harald.T.Alvestrand@uninett.no Wed, 03 May 1995 08:42 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00633; 3 May 95 4:42 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00629; 3 May 95 4:42 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01443; 3 May 95 4:42 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00621; 3 May 95 4:42 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00617; 3 May 95 4:42 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa01437; 3 May 95 4:42 EDT
Received: from domen.uninett.no by venera.isi.edu (5.65c/5.61+local-21) id <AA29812>; Wed, 3 May 1995 01:42:55 -0700
Received: from dale.uninett.no by domen.uninett.no with SMTP (PP) id <09196-0@domen.uninett.no>; Wed, 3 May 1995 10:38:47 +0200
Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.9) with ESMTP id PAA03117; Mon, 1 May 1995 15:10:08 -0400
Message-Id: <199505011910.PAA03117@dale.uninett.no>
X-Orig-Sender: iesg-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Harald.T.Alvestrand@uninett.no
To: postel@isi.edu
Cc: iesg@isi.edu, pouffary@taec.enet.dec.com
Subject: Re: Submission Informational RFC
In-Reply-To: Your message of "Fri, 28 Apr 1995 11:18:51 PDT." <199504281818.AA09355@zen.isi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <3114.799355407.1@dale.uninett.no>
Date: Mon, 01 May 1995 15:10:08 -0400
X-Orig-Sender: hta@dale.uninett.no

Jon,
1) Has the port 399 been officially assigned, or is it a "grab"?
2) I would *much* prefer that the document start out with "this is the
   documentation for how DECNET/OSI works over TCP/IP".

There are a number of problems with the protocol described, including:
- Expedited follows an idea that Marshall used for an 
  *earlier* RFC1006 version, but abandoned; there is no guarantee that
  the expedited PDU does not arrive *later* than normal data sent at
  the same time, and this is required by the ISO protocol
- Multiplexing is recommended against, but not forbidden; this combined
  with no explicit flow control means that multiplexing can happen
  and will lead to some *fun* reactions on congestion
- The idea that one can tell from the TPDUs whether this is RFC1006
  or this new protocol is simply wrong, unless one watches every
  packet from session establishment onwards
- There is no description on what to do if someone suggests that we
  negotiate down to class 0 on establishment; is this allowed?

All in all, I feel very good about DEC wanting to document its protocol,
but I don't like the present submission very much.
Would it be appropriate to suggest that he publish it as an Internet-draft,
so that other people can take a look at it to ensure clarity before it
is published as Informational?

             Harald A