Re: Submission Informational RFC

postel@isi.edu Wed, 03 May 1995 16:11 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04385; 3 May 95 12:11 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04381; 3 May 95 12:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10046; 3 May 95 12:11 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04374; 3 May 95 12:11 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04370; 3 May 95 12:11 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa10040; 3 May 95 12:11 EDT
Received: from zen.isi.edu by venera.isi.edu (5.65c/5.61+local-21) id <AA12512>; Wed, 3 May 1995 09:10:49 -0700
Date: Wed, 3 May 1995 09:10:48 -0700
X-Orig-Sender: iesg-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: postel@isi.edu
Posted-Date: Wed, 3 May 1995 09:10:48 -0700
Message-Id: <199505031610.AA00439@zen.isi.edu>
Received: by zen.isi.edu (5.65c/4.0.3-4) id <AA00439>; Wed, 3 May 1995 09:10:48 -0700
To: postel@isi.edu, Harald.T.Alvestrand@uninett.no
Subject: Re: Submission Informational RFC
Cc: iesg@isi.edu, pouffary@taec.enet.dec.com

Harald:

   From: Harald.T.Alvestrand@uninett.no
   To: postel@ISI.EDU
   Cc: iesg@ISI.EDU, pouffary@taec.enet.dec.com
   Subject: Re: Submission Informational RFC
   Date: Mon, 01 May 1995 15:10:08 -0400
   
   Jon,
   1) Has the port 399 been officially assigned, or is it a "grab"?

Port 399 is already assigned for this.

iso-tsap-c2     399/tcp    ISO-TSAP Class 2
iso-tsap-c2     399/udp    ISO-TSAP Class 2
#               Yanivk Pouffary <pouffary@yaec.enet.dec.com>

   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?

Asking for a revision based on your comments is reasonable, and your
suggestion that it go through an I-D stage even if it is eventually
informational is also ok.
   
                Harald A

--jon.