Next Steps in Signaling (NSIS): Framework
Note: This ballot was opened for revision 05 and is now closed.
(Allison Mankin) Yes
(Harald Alvestrand) No Objection
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) (was Discuss) No Objection
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.
(Bill Fenner) No Objection
(Ned Freed) No Objection
(Ted Hardie) (was Discuss) No Objection
[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.
(Scott Hollenbeck) (was Discuss) No Objection
(Russ Housley) (was Discuss) No Objection
(David Kessens) No Objection
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 ?
(Margaret Wasserman) No Objection
(Alex Zinin) No Objection
(Bert Wijnen) No Record
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/