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

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 17 Oct 2002 23:50:49 +0100

hi melinda,

modulo document timing, requirements/framework split, argument passing by reference or value and so on:

what do you actually think of the path coupled/decoupled definition (that is currently hanging out in the framework section 3.2.1)?

cheers,

robert h.

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: 16 October 2002 15:55
> To: Hancock, Robert
> Cc: [email-masked]
> Subject: Re: on/off path, and requirements vs. framework content (was
> RE: WG L ast call on the Requirements Draft?) 
> 
> 
> > 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
> 
========================================================================================
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: Fri, 18 Oct 2002 09:02:24 -0400

>what do you actually think of the path coupled/decoupled definition (that is currently hanging out in the framework section 3.2.1)?

D'oh!  Sorry not to mention that earlier - I like it a lot
and think that it's probably a better way to frame the distinction
than "on path/off path."

Melinda

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

---

From: [email-masked]
Date: Fri, 18 Oct 2002 16:05:57 +0300

Hi Melinda,

> >what do you actually think of the path coupled/decoupled 
> definition (that is currently hanging out in the framework 
> section 3.2.1)?
> 

So, should we use the definition going forward?

John

---

From: Melinda Shore <[email-masked]>
Date: Fri, 18 Oct 2002 09:30:39 -0400

>So, should we use the definition going forward?

If there's consensus, I think it's good.

Melinda