Subject: [NSIS] RE: what's part of NSIS? (was: RE: Comments on framework draft)

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 12 Nov 2002 17:27:19 -0000

Melinda,

more follow up comments:

> 4.2 Writing in para starting "We have a
>    basic design goal" is a little unclear - why not simply
>    state that we assume the following functions will be
>    available by other means and are therefore will not be
>    included in the NSIS protocol?

broadly I probably agree, with some modifications reflecting what has actually happened since the -00 version. The -00 version referred to three out of scope things:

1) since i suspect we are now more open to looking at particular signalling applications, I'm no longer happier about asserting that "Negotiation of service configuration" is out of scope, but instead it's obviously a question specific to the signalling application in question (so this particular factoid probably doesn't need to be mentioned here).

2) "Agreement to use NSIS for signaling" (and initiator selection) being something that happens outside NSIS seems a reasonable assumption, that could now go in 3.3.1.

3) The bit about peer discovery/selection has been clarified anyway, but in any case has nothing to do with upper layer services (I think?). So it should probably move elsewhere (maybe into its own section about how the end to end path actually gets tracked).

Are there other necessary stages in the overall signalling process which we think we should identify as not being NSIS's job to solve? It would be good if we could think of some...

> 6.1 seems to assume the use of an external security protocol
>    aside from key management (IPSec, SSL).  Does it need
>    to?  What about authenticating individual elements?

I think this one has been discussed extensively already. I don't think we have finalised a 'make or buy' decision on security mechanism yet (this could be clarified I guess).

If by "What about authenticating individual elements?" you mean securing individual information elements in messages (a la CMS for example), this should be mentioned. (The original discussion was very much with only the NTLP in mind, for which the technique seems less natural - in other words, this becomes another "what's appropriate for what layer" question.)

> 6.2 I'd restate question as "Does the requestor have
>    permission?"  Payment, etc. may very well not enter into
>    it.  No negotiation!  Request has a yes/no/"no but"
>    answer with possibility of additional information
>    ("these are the nodes that would not satisfy the request
>    and this is the reason they gave"), but negotiation
>    introduces complexity with no real advantages.

We can rephrase the first sentence of 6.2 in terms of "permission" rather than "payment", but I'd like to keep the latter term as well just to wake people up (as Mike has done on the same subject).
OTOH, I don't see that we can absolutely rule out negotiation as part of the process, and in fact, if the NTLP is properly transparent, I don't see any way to write the framework to prevent someone putting it in to the NSLP for their favourite signalling application. Do you?

Nearly done,

Robert H.
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis