Subject: [NSIS] scope of framework document

From: Roland Bless <[email-masked]>
Date: Wed, 20 Nov 2002 23:28:51 +0100

Hi,

coming back to John's statement at the meeting that he likes
short documents:
I got the impression that the framework document currently
contains a lot of solution-oriented stuff that would rather belong
to a protocol design (discussion) document. Having two separate
layers is a design decision to me that has its advantages,
but now there are issues in the framework coming up like
"which functions belong to which layer?". Doesn't this rather
belong to a protocol design document? In my understanding,
the main WG documents would cover:
- analysis of existing signaling protocols
  -> why we might need a new signaling protocol, shortcomings
  and lessons learned
- requirements -> functions and features that a signaling protocol should
  possess (mainly derived from various scenarios/use cases)
- framework -> general interaction models and possible applications
  of the protocol in different environments.

So the currently discussed options for the structure of a protocol may be
derived from the framework, requirements and analysis documents, but
should be kept/discussed IMHO in a separate protocol design document.

Cheers,
 Roland

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 20 Nov 2002 21:48:48 -0000

hi all,

having spent some time worrying about what should go in this document, i also have some views on the issue. the main concern i have with the discussion below is in the parts that go '...the protocol...'. there isn't such a thing, there is (unless I have got very confused) an assumption of a general purpose transport protocol with a set of signalling application protocols above it.

if the 'top-level' framework document simply discusses how the NSIS protocols ***as a group*** might interact with the rest of the world and do interesting things, i don't see how that really advances our work. in particular, there is no obvious point at which to stop thinking of and describing new signalling applications which could have clever and complex interactions with the outside world. also, we are basically stumped at the moment on the security issues because it's impossible to make progress without having a more concrete structure to analyse, so we need to start breaking up the problem to make progress here.

i would much rather trim the framework (if it needs trimming) from the top: i.e. work out the approximate layer split (which would actually be progress) and then move the signalling application specific aspects into a separate document. in particular, in such a separate document, we could relax from pretending we weren't talking about QoS when we really were.

the other way to trim the document is to make progress on some of the open issues, in which case we could segregate some of the discussion and option analysis. (hint.)

cheers,

robert h.

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]]
> Sent: 20 November 2002 17:29
> To: [email-masked]
> Subject: [NSIS] scope of framework document
> 
> 
> Hi,
>