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

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 9 Jun 2003 16:50:51 +0100

hi all,

i have a few comments on some of these:
5.3.2/5.4.3/5.4.1/5.9.5/5.9.6

cheers,

robert h.

> 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?

[reh] I would have no problems with a 'MUST' here, but I suspect the word
'possible' has to be kept as well. That is, some people were quite concerned
that transient failures in NSIS processing shouldn't necessarily have to
cause all state to be released (a sort of 'NSIS hitless restart'
possibility).
Some of this is as much an operational matter as a protocol requirements
matter, of course.

> 
> -------- 
> 
> 
> 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?
> 
> -------- 

[reh] This requirement has a tortured history, and the difficulties
in meeting it have been discussed several times (coming up with a sensible
way to secure the identification seems even harder); there is an I-D in 
preparation on that subject. If making MUST->SHOULD
would seem less reckless that might be a good idea (it won't stop us looking
for good solutions after all).

> 
> 
> 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?

[reh] IIRC the motivation behind this was to recognise that nodes would
change messages, but they shouldn't be allowed to have their modified
messages masquerade as the originals. So, Allison's reformulation covers
most of the point, but there is also the issue of the originator's desire
to control the process.
The discussion here was very similar to what I later saw in a much more
concrete form in draft-rosenberg-sipping-session-policy-00.txt (now
expired).
I'm not sure if a specific requirement is needed, but I still think the 
point should be covered somehow.

> -------- 
> 
> 
> 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...
> -------- 

There are two issues here:

a) the handoff protocols requirement is supposedly a sort of reflection of 
what is (currently) in the charter, i.e. "The work produced in this Working
Group should work with existing IETF mobility ... protocols, including ...
SeaMoby Context Transfer...".
There was a long-ish discussion cross-posted with seamoby on how to draw the

boundary between NSIS features which could be used in mobile networks and 
seamless handover protocols themselves. Given that we have to draw a
boundary
round NSIS somehow, that sort of analysis seems reasonable, and not likely
to
decrease modularity/usefulness.
Maybe the word 'interwork' is problematic. 'Work with' or 'coexist
rationally 
with' might be better.

b) The second requirement is about wanting NSIS protocols that aren't broken

by the presence of policy-based forwarding in NSIS-unaware regions of the 
network. Again, 'interwork' is probably the wrong word.
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Allison Mankin <[email-masked]>
Date: Thu, 12 Jun 2003 21:33:24 -0700

Robert,

Thanks for the explanations and comments.  They were helpful.

> network. Again, 'interwork' is probably the wrong word.

So my guess that what the group meant by non-traditional (non-L3) routing
was L4 switches/NATs was incorrect.  The text is not fixed by changing the
word 'interwork', it needs to have a clearer statement of the environment
in which you expect NSIS to be robust.  Policy-based forwarding would seem
to me to be a form of L3 routing, so I'm still not sure.  Could you clarify?

This part of what you say:

  NSIS must be function in circumstances where parts of the network are
  NSIS-aware

does not have to be coupled to the network having unusual routing, so this
is not coming through clearly.

Allison