Subject: [NSIS] on/off path, and requirements vs. framework content (was RE: WG L ast call on the Requirements Draft?)

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 16 Oct 2002 01:14:39 +0100

hi melinda,

one of the problems we had during the on/off path discussion shortly after yokohama was agreeing how to define the terms for what was in and out of scope in the first place, since there seemed to be many nuances (in some minds) about possible meanings of the terms.

the latest framework contains a carefully worded proposed definition (we used the terms path coupled/decoupled). if we could agree that was a useful definition, maybe it could be incorporated into some scoping section of the requirements document.

on the other hand, I probably agree with you (other mails) that some of the requirements draft material is more framework related.

what i'm unclear about is just how 'bare bones' the requirements document should be. without context, terminology and so on, the requirements could end up being a write-only RFC. from a frameworker's perspective, i guess i'm interested in suggestions for where the requirements/framework split should go. 

robert

ps. i didn't follow the midcom work in detail, but the RFCs appear very much as companion documents. that's nice, but at the moment (in my view anyway) the NSIS requirements content is vastly more mature than the framework, so the same approach doesn't necessarily apply.

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: 15 October 2002 17:12
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [NSIS] WG Last call on the Requirements Draft? 
> 
> 
> I'm in the process of going through the document and one
> thing pops out at me that I really think has to be addressed
> ASAP.  In section 5.2, several requirements (which are not
> actually stated as requirements, incidentally) suggest that
> we're supporting off-path signaling.  I believe that this is
> currently (and possibly forever) out of scope.  This has
> been discussed quite a bit and it's my recollection that the
> working group never came to a decision.  
> 
> This also needs to be consistent with the framework document.
> 
> Melinda
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 
========================================================================================
Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 16 Oct 2002 10:54:52 -0400

> the latest framework contains a carefully worded proposed
> definition (we used the terms path coupled/decoupled). if
> we could agree that was a useful definition, maybe it
> could be incorporated into some scoping section of the
> requirements document.

That's a good suggestion, although my personal preference is
to refer between the documents rather than to include large
amounts of redundant material.  But maybe one of the first
things we need to focus on in the framework document are the
on-path/off-path definition and to come to some absolute,
documented agreement about what the NSIS protocol will cover.

> ps. i didn't follow the midcom work in detail, but the
> RFCs appear very much as companion documents. that's nice,
> but at the moment (in my view anyway) the NSIS
> requirements content is vastly more mature than the
> framework, so the same approach doesn't necessarily apply.

It's impossible, I think, to have two document progress at
exactly the same rate of speed.  I think it's almost
certainly the case that there are requirements either
implied or explicitly stated in the framework draft, and
those will need to be identified and incorporated into
requirements draft, and it's likely that the requirements
currently identified in the requirements draft may change as
the framework is solidified.  I wouldn't be in favor of
completing one document too far in advance of the other.

Melinda