datatracker.ietf.org
Sign in
Version 5.6.3, 2014-09-19
Report a bug

Next Steps in Signaling (NSIS): Framework
RFC 4080

No Objection
(was Discuss)
(was Discuss)
(was Discuss)
(was Discuss)
No Record

Note: This ballot was opened for revision 05 and is now closed.

Summary: Needs a YES.

[Bert Wijnen]

Comment (2004-09-27 for -)

Document: draft-ietf-nsis-fw-06.txt

   Top of page 20:
       application level.  In this sense, up/down notifications are
       advisories which allow faster reaction to events in the network,
       but shouldn't be built into NSLP semantics.  (This is essentially
       the same distinction - with the same rationale - as SNMP makes
       between traps and normal message exchanges.)

   Would be better to s/traps/notifications/

[David Kessens]

Comment (2004-09-27 for -)

From ops directorate by Pekka Savola regarding draft-ietf-nsis-threats-05.txt:

It seems that a few more of the NSIS documents should be normative
references, e.g., the framework ?

[Harald Alvestrand]

Comment (2004-09-27 for -)

Reviewed by Mary Barnes, Gen-ART

Her review:

Summary:
--------

Both drafts are ready to publish as Informational with the correction of the
following editorial nits.

Nits (nsis-threats):
--------------------

- Section 3.1: There's a formatting problem in this section with the
 identation OR the phrase "following two cases:" on the top of page 10
 should read "following three cases:"

- Section 3.1: First paragraph following the idented parts (page 11),
  beginning with "Finally, we conclude a description". The word
  "conclude" needs to be changed to "include" or "conclude with".

 - Section 3.1: Page 11, Last paragraph, last sentence. "A malicious
   NSIS can be detected..." needs to change to "A malicious NSIS node
   can be detected..."

- Section 4.10: Page 24. Reference to "Figure 3" should be "Figure
  4".

Nits (nsis-fw):
---------------

- Abstract: It's longer than the guidelines recommendation of typically
5-10 lines, but no more than 20 lines. I would suggest a change from:

 "The Next Steps in Signaling working group is considering protocols
 for signaling information about a data flow along its path in the
 network. Based on existing work on signaling requirements, this
 document proposes an architectural framework for such signaling
 protocols.

 This document provides a model for the network entities that take
 part in such signaling, and the relationship between signaling and
 the rest of network operation. We decompose the overall signaling
 protocol suite into a generic (lower) layer, with separate upper
 layers for each specific signaling application. An initial proposal
 for the split between these layers is given, describing the overall
 functionality of the lower layer, and discussing the ways that upper
 layer behavior can be adapted to specific signaling application
 requirements.

 This framework also considers the general interactions between
 signaling and other network layer functions, specifically routing,
 mobility, and address translators. The different events that impact
 signaling operation are described, along with how their handling
 should be divided between the generic and application-specific
 layers. Finally, an example signaling application (for Quality of
 Service) is described in more detail."

to (adding the second sentence for clarity) and removing alot of unnecessary
detail:
   "The Next Steps in Signaling working group is considering protocols
   for signaling information about a data flow along its path in the
   network. The NSIS suite of protocols is envisioned to support various
   signaling applications that need to install and/or manipulate state
   in the network. Based on existing work on signaling requirements, this
   document proposes an architectural framework for such signaling
   protocols.

    This document provides a model for the network entities that take
   part in such signaling, and the relationship between signaling and
   the rest of network operation.  We decompose the overall signaling
   protocol suite into a generic (lower) layer, with separate upper
   layers for each specific signaling application."

- Section 2 Terminology - Signaling application.  I think the term
  "service" should be "signaling application" ?

 - Section 3.2.6 - Per the statement in 3.1.2 that path de-coupled is
   out of scope at this time, it would be useful to re-iterate that
   the information in this section is provided for completeness and to
   capture for future reference. I would suggest adding a statement
   something like the following to the beginning of this section:

 "Although, support of path de-coupled operation is not part of the
 initial goals of this NSIS Framework, this section is included for
 completeness and to caputure some initial considerations for future
 reference."

- Section 5.1.2: last paragraph, page 36. Change "traffic))" to
  "traffic)"

[Steven Bellovin]

Comment (2004-09-27 for -07)

The security analysis and considerations sections (4.7 and 7) in
draft-ietf-nsis-fw  are weak.  This is a framework document, so that's
(marginally) acceptable, but there's a lot of hard work ahead in this security
arena.  In particular, you're likely going to need a separate security
mechanisms document that relates back to the threats document.

[Ted Hardie]

Comment (2004-09-27 for -07)

[2004-09-24] in the Framework document, section 3.1.5  says

  A session is an application layer concept for a (unidirectional) flow
  of information between two endpoints, for which some network state is
  to be allocated or monitored.  (Note that this use of the term
  'session' is not identical to the usage in RSVP.  It is closer to the
  session concept of, for example, the Session Initiation Protocol.)

While I don't doubt that a higher-layer concept for the set of
flows that makes up one half of an exchange is useful, I don't think session
is the right term here, and I think suggesting it maps to that may do
harm as further development in the applications' interaction with the
signalling plane.  The Session of SIP, for example, seems to
me explictly the full exchange "There are many applications of the Internet
that require the creation and management of a session, where a session is
considered an exchange of data between an association of participants."
(3261, Section 1).  I wish I had a catchy phrase for the concept you
do want; I don't.  But I am concerned about re-using session here,
and I'd like to discuss it.