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, 03 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.
- Re: Submission Informational RFC Harald.T.Alvestrand
- Re: Submission Informational RFC Yanick
- Re: Submission Informational RFC postel
- re: Submission Informational RFC Allison Mankin