Re: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt

["Georgios Karagiannis" <[e-mail]>]

Hi Allison

Regarding your comment on Section 5.7.5 about MUST implement and not a MUST
use.

Do you mean that the channel security between signaling entities
MUST be implemented, but this does not mean that it should be used?

Best Regards,
Georgios



----- Original Message -----
From: "Allison Mankin" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Monday, June 09, 2003 8:29 AM
Subject: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt


> Marcus, John and WG,
>
> Here are my AD Review comments on the NSIS requirements.  Overall
> it is a good document.  I have a few problems on charter, technical
> or clarity points.  Discussion welcome.
>
> Allison
>
> --------
>    However, QoS is not the only field where signaling
>    is used in the Internet. Others might be the use for middlebox
>    communication [RFC3234].
>
> It would be helpful to clarify the manner in which signaling would be
> used for middlebox communication (in one sentence) - this is so terse,
that
> only if a reader has been in the working group would they understand the
> sentence.
>
> Suggestion:  "Signaling might also be used as a communication protocol
> to set up the state in middleboxes."
>
> --------
>
>    There are several areas related to networking aspects which are
>    incomplete, for example, interaction with host and site multi-
>    homing, use of anycast services, and so on. These issues should be
>    considered in any future analysis work.
>
> Incomplete in the sense of requirements analysis?  This paragraph suggests
> a different kind of analysis.  Also anycast in particular seems very
unlikely
> to be a significant element in signaling requirements analysis - it seems
> like it should not be mentioned in the same sentence with a common issue
> like multihoming.
>
> Suggestion:  "This document does not cover requirements in relation to
some
> networking areas, in particular, interaction with host and site
multihoming.
> We leave these for future analysis. "
>
> --------
>
> NSIS Initiator - needs to say, in parallel with the NSIS Responder,
> it interacts with applications  (Definition does not say so).
>
> --------
> 3. Something that terminates the signaling path, the NSIS Responder.
>
>    The NSIS responder might be in an end-system or within other
>    equipment. The distinguishing feature of the NSIS Initiator is that
>                                                      ^^^^^^^^^
>    it responds to requests at the end of a signaling path.
>
> Typo? s/Initiator/Responder/
>
> --------
>    The host to first
>    router part includes all the layer 2 technologies to access to the
>    Internet.
>
> Consider a home network with a wireless router and a DSL router accessing
> the Internet.  The topology definition is less crisp than host to *first*
> router.  I suggest you add a sentence after this one:  "This part of the
> division is especially informal and may incorporate several access
segments."
> --------
>
> 5.2.2 NSIS MUST support path-coupled and SHOULD NOT exclude path-
>      decoupled signaling.
>
> SHOULD NOT is very strong, given that the WG is not chartered to work on
> this technology.
>
> The language needs to be "MAY support path-decoupled signaling."
>
> --------
>
> 5.3.2 Automatic release of state after failure SHOULD be possible
>
>    When the NSIS Initiator goes down, the state it requested in the
>    network SHOULD be released, since it will no longer be necessary.
>
> An important feature of RSVP was its soft-state character, in part to
> ensure that critical resources in the net were not fate-shared for too
long.
> Given this is about release after _failure_, these SHOULDs should be
MUSTs,
> if not going so far as to preserve the soft-state architecture.  Comments?
>
> --------
>
>
> 5.4.3 State MUST be addressed independent of flow identification
>
>    Addressing or identifying state MUST be independent of the flow
>    identifier (flow end-points, topological addresses). Various
>    scenarios in the mobility area require this independence because
>    flows resulting from handoff might have changed end-points etc. but
>    still have the same service requirement. Also several proxy-based
>    signaling methods profit from such independence.
>
> Add to the last sentence "though these are not chartered work items for
> NSIS".
>
> This is a tough requirement since it has to be globally unique.  It may
> turn out to be best met by the NI's authentication token, requiring an
> early integration of authentication design into the protocol.  No request
> to change this, but just noting how hard this is - WG is _sure_
> the mobility requirements are really so important?
>
> --------
>
>
> 5.4.1 Mutability information on parameters SHOULD be possible
>
>    It SHOULD be possible for the NSIS initiator to control the
>    mutability of the signaled information. This prevents them from
>    being changed in a non-recoverable way. The NSIS initiator SHOULD be
>    able to control what is requested end to end, without the request
>    being gradually mutated as it passes through a sequence of domains.
>    This implies that in case of changes made on the parameters, the
>    original requested ones must still be available.
>
>    Note that we do not require anything about particular parameters
>    being changed.
>
>    Additionally, note that the provider of the particular requested
>    services can still influence the provisioning but in the signaling
>    message the request should stay the same.
>
> The requirement is not expressed well.  Do you mean "It SHOULD be
> possible to have nodes modify parameters to interact with the
> signaling message, while still retaining an intact copy of the
> original form of the signaling message"?
>
> This requirement seems like it would vary a great deal depending on what
> the signaling application was, and as it is written here it is very close
> to a protocol design rather than a requirement.  Could you omit
> it from this document?
>
> --------
>
>                                                        One of the
>    reasons is that the protocol handling should have a minimal impact
>    on interior (core) nodes.
>
> Suggest adding that NSIS MAY also have a feature allowing core nodes
> to ignore it (though I hope it will be more elegant than RSVP's as
> document in RFC 3175 :)
>
> --------
>
> 5.7.5 Hop-by-hop security
>
>    Hop-by-Hop security SHOULD be supported. It is a well known and
>    proven concept in Quality-of-Service and other signaling protocols
>    that allows intermediate nodes that actively participate in the
>    protocol to modify the messages as it is required by processing
>    rules. Note that this requirement does not exclude end-to-end or
>    network-to-network security of a signaling message. End-to-end
>    security between the initiator and the responder may be used to
>    provide protection of non-mutable data fields. Network-to-network
>    security refers to the protection of messages over various hops but
>    not in an end-to-end manner i.e. protected over a particular network.
>
> Without minimum mandatory to implement channel security for the signaling,
> you can't be sure the other security features will be untampered with -
> this needs to be a MUST implement (it's not a MUST use).  Suggest changing
> the first sentence to "Channel security between signaling entities
> MUST be implemented'?
>
> --------
>
>
> 5.9.5 SHOULD interwork with seamless handoff protocols
>
> 5.9.6 MAY interwork with non-traditional routing
>
>    NSIS assumes L3 routing, but networks, which do non-traditional
>    routing, should not break it.
>
> NSIS should not be complex and interworked in ways that make it less
modular.
> Both of these requirements are complications.  The first one, because it
poses
> a certain environment and particular protocols, would make NSIS less
modular.
> It is probably improved by changing SHOULD to MAY.  The second one may
sound
> worse than it is - does it mean NATs?  Suggest this might have meant:
>
> 5.9.6. MAY operate in varied routing environments
>
>      NSIS assumes L3 routing, but it MAY be designed to operate in
>      varied routing environments, such as those with L4 switches and NATs.
>
> But if not, do explain...
> --------
>
> Scenarios -
>
> 's' as an abbreviation is not explained.
>
> --------
> 10.2
>
> The 3G Scenario is somewhat too specific to 3GPP and 3GPP2 still - IMS is
> mentioned without being expanded or explained.  All the terms are
specific.
> Try to make it a bit more abstract - say it is an All-IP multimedia
system.
>
> --------
>      This part of the wireless network has different
>      characteristics when compared to traditional IP networks:
>
>          1. The network supports a high proportion of real-time
>             traffic.  The majority of the traffic transported in the
>             wired part of the wireless network is speech, which is
>             very sensitive to delays and delay variation (jitter).
>
> Two things about IP networks - they carry whatever they carry, so
> it's not out of tradition to be a voice IP network.  Second, speech in
> Internet phones is quite a lot less sensitive to delays and jitter than
> often thought, due to the many good engineering designs in playout and
> speech cover that are known.  So this material places a context of more
> difference on the environment than most general transport experts view
> as necessary, seeing more continuum, while not disagreeing that signaling
> and resource reservation are valuable.
>
> So drop sentence 1, but leave the rest alone (I just wanted to make my
point :)
>
> --------
>
>
> 10.10  Application request end-to-end QoS path from the network
>
>    This is actually the easiest case, nevertheless might be most often
>    used in terms of number of users.
>
> Few believe that ordinary applications signaling for QoS is an easy matter
for
> the network - RFCs 2961, 2996 and 3175 are all about mitigating the
unscalability
> of edge signaling.  Probably this would go better if you substitute the
term
> "conceptually simplest" for "easiest" and note that there are these issues
with
> scaling.
>
>
>     Additionally, we assume no mobility and standard devices.
>
> Note: the end system application and NSIS do not know about the
> distinction between 10.10 and the other scenarios :), unless NSIS is not
> a modular Internet protocol.
>
> --------
>
> QoS for Virtual Private Networks - section needs a number
>
> IP-Sec -> IPSec
>
> The discussion of NSIS in VPNs ignores the whole world of the PPVPN WG.
> Cite draft-ietf-ppvpn-framework-08.txt early on in the section (it is in
the
> RFC-Editor Queue).
>
>
>
> Allison
>
>
> _______________________________________________
> nsis mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nsis
>

_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis