A Multicast Extension to MAPOS NSP (Node Switch Protocol)
draft-ogura-mapos-nsp-multiexp-03

Message to RFC Editor:

After discussing this document, the IESG has decided that it is the RFC Editor's responsibility to judge whether this document is fit material for the RFC series or not; the document seems to do no harm to the Internet or the IETF.

Please add the following IESG note to the document:

  This document is NOT the product of an IETF working group
  nor is it a standards track document.  It has not necessarily
  benefited from the widespread and in-depth community review that
  standards track documents receive.

On Jan 8, the IESG discussed the RFC Editor's note, and decided that it did not see publication of the document as harmful. The IESG was therefore willing to go along with the RFC Editor's decision.

[Note]: 'Here is a proposed DNP note: The IESG requests that 'A Multicast Extension to MAPOS NSP (Node
Switch Protocol)'  NOT be
published as an Experimental RFC. MAPOS is a link-layer protocol for transmitting network-layer
datagrams encapsulated in HDLC frames over SONET/SDH. Like most
link-layer protocols, MAPOS has no particular relationship with IP
other than that it can carry IP datagrams.  This document describes
NSP+, MAPOS-specific extensions whose scope is restricted to MAPOS
itself.  The extensions described here are entirely an internal MAPOS
issue and are not directly related to the higher-layer protocols
(e.g., IP) that MAPOS can carry. While we do not have an issue with
the technical content of the document per se, we do question how the
scope of the document relates to the RFC series, and in particular its
focus of being "about the Internet".
' has been cleared by Harald Alvestrand

[Note]: 'Here is a proposed DNP note: The IESG requests that ''A Multicast Extension to MAPOS NSP (Node
Switch Protocol)''  NOT be
published as an Experimental RFC. MAPOS is a link-layer protocol for transmitting network-layer
datagrams encapsulated in HDLC frames over SONET/SDH. Like most
link-layer protocols, MAPOS has no particular relationship with IP
other than that it can carry IP datagrams.  This document describes
NSP+, MAPOS-specific extensions whose scope is restricted to MAPOS
itself.  The extensions described here are entirely an internal MAPOS
issue and are not directly related to the higher-layer protocols
(e.g., IP) that MAPOS can carry. While we do not have an issue with
the technical content of the document per se, we do question how the
scope of the document relates to the RFC series, and in particular its
focus of being "about the Internet".
' added by Harald Alvestrand

On Jan 5, the RFC Editor wrote:

The RFC Editor believes that this document is well within the scope of the RFC series.  While the primary focus of the IETF has not been at the link layer, surely even link layer technology is a technical aspect
of the Internet.  Indeed, one would have to ask why this document is less relevant than MPLS or GMPLS.  Or, searching for RFCs on "optical", you get 13 hits.  Searching on "ethernet", you get 25 hits.  "Token
ring" gets 4 hits.  Etc.

It happens that most link layer technology has other venues for publication (e.g., IEEE or ITU); publication of an occasional link layer document as an RFC seems appropriate.

Therefore, the RFC Editor intends to publish this document as an RFC. If the IESG wishes to include a statement, please let us know.  We will enter the document into our queue for publication, in the meantime.

[Note]: 'Here is a proposed DNP note: The IESG requests that ''A Multicast Extension to MAPOS NSP (Node
Switch Protocol)''  NOT be
published as an Experimental RFC. MAPOS is a link-layer protocol for transmitting network-layer
datagrams encapsulated in HDLC frames over SONET/SDH. Like most
link-layer protocols, MAPOS has no particular relationship with IP
other than that it can carry IP datagrams.  This document describes
NSP+, MAPOS-specific extensions whose scope is restricted to MAPOS
itself.  The extensions described here are entirely an internal MAPOS
issue and are not directly related to the higher-layer protocols
(e.g., IP) that MAPOS can carry. While we do not have an issue with
the technical content of the document per se, we do question how the
scope of the document relates to the RFC series, and in particular its
focus of being "about the Internet".
' added by Amy Vezza

[Note]: 'Here is a proposed DNP note:

The IESG requests that ''A Multicast Extension to MAPOS NSP (Node
Switch Protocol)''  NOT be
published as an Experimental RFC.

MAPOS is a link-layer protocol for transmitting network-layer
datagrams encapsulated in HDLC frames over SONET/SDH. Like most
link-layer protocols, MAPOS has no particular relationship with IP
other than that it can carry IP datagrams.  This document describes
NSP+, MAPOS-specific extensions whose scope is restricted to MAPOS
itself.  The extensions described here are entirely an internal MAPOS
issue and are not directly related to the higher-layer protocols
(e.g., IP) that MAPOS can carry. While we do not have an issue with
the technical content of the document per se, we do question how the
scope of the document relates to the RFC series, and in particular its
focus of being "about the Internet".
' added by Thomas Narten

From: Thomas Narten
To: yoshida@peta.arch.ecl.net, mitsuru@core.ecl.net, ogura@core.ecl.net
Date: Thu, 09 Oct 2003 07:30:03 -0400
Subject: draft-ogura-mapos-nsp-multiexp-02.txt

Greetings.

This document has been submitted to the RFC editor for publication as
an informational RFC, and I've reviewed it on behalf of the IESG.

I have not objections to publishing this document, but have two
comments.

1) I assume that we will add a note at the beginning (as has been done
for other MAPOS documents) along the lines of:

  This memo documents a multiple access protocol for transmission of
  network-protocol datagrams, encapsulated in High-Level Data Link
  Control (HDLC) frames, over SONET/SDH.  This document is NOT the
  product of an IETF working group nor is it a standards track
  document.  It has not necessarily benefited from the widespread and
  in depth community review that standards track documents receive.

Any objections?
 
2)

> 4. Security Considerations
>
>    Security issues are not discussed in this memo.

This is not really an adequate section, as it can be read to indicate
that security issues have not even been thought about. At a minimum, I
would expect similiar issues to arise as with NSP 1, but I note that
that RFC 2173 has no security considerations section, as it was
published in 1997, before they were really required. So you may need
to add stuff to this document that would have been discussed in 2173.
 
Thomas