Subject: RE: [NSIS] WG Last call on the Requirements Draft?

From: [email-masked]
Date: Tue, 15 Oct 2002 15:50:31 +0300

Hi Melinda,

> I think that if last call is needed to stimulate discussion
> we should forge ahead but it seems to me that the document
> is nowhere near ready to go to the IESG.  I've been remiss
> about going through it in detail, but a quick scan shows
> that there's quite a bit of framework material in it.  Aside
> from being unnecessary to the document, it runs the risk of
> conflicting with the separate framework document that's
> currently under development.  

If the current Requirements has fluff, duplicate information and
or unnescessary requirements, we should clean it up.  Of course,
WG last call is still quite far from IESG last call.  
 
> If you take a look at other requirements documents that have
> recently been published as RFCs in the Transport Area you'll
> see that the actual requirements material typically starts
> somewhere around page 4 or 5 and sometimes as early as page
> 1.  In the NSIS requirements document the requirements
> material starts on page 10.  I think a great deal of that
> introductory material should be removed from the
> requirements document and integrated into the framework
> document if it's not already in there.
>
> I'll post more specific comments by the end of the week, but
> thought that the above may bear on the question of whether
> or not the document should go into last call.

The best way forward on this is for you to document specific
concerns. 

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

---

From: Melinda Shore <[email-masked]>
Date: Tue, 15 Oct 2002 11:12:25 -0400

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

---

From: Melinda Shore <[email-masked]>
Date: Thu, 17 Oct 2002 13:06:53 -0400

> But as far as I have seen the list the consensus was to
> not rule-out the off-path (what ever it is, see the E-Mail
> thread on that), but focus on the on-path. And I hope that
> the formulation does reflect this.  Or in other words if
> we find a protocol which works mainly on-path but also for
> off-path we can still use it in NSIS and are not obliged
> to throw it away.

I think it would be a big mistake and could easily result in
never producing a working protocol.  It would be helpful if
someone who thinks that it is in scope could scratch
together a diagram of how they think it might work.

That's not to say that I think this is not IETF work - I do
think it is.  I just don't think that it could reasonably
fit into an end-to-end signaling protocol.  As it happens,
there is a diagram in the framework document of how it could
be done by NSIS working in conjunction with another
protocol, and that's Figure 8.

Melinda

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 17 Oct 2002 18:53:31 +0200

But as far as I have seen the list the consensus was to not rule-out the 
off-path (what ever it is, see the E-Mail thread on that), but focus on the 
on-path. And I hope that the formulation does reflect this.

Or in other words if we find a protocol which works mainly on-path but also 
for off-path we can still use it in NSIS and are not obliged to throw it 
away.

Marcus

> This also needs to be consistent with the framework document.

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
personal home page: http://www.brubers.org/marcus

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 18 Oct 2002 09:50:03 +0200

What I have seen from CASP as well as our proposal for RSVP version 2 does 
have the off-path signaling option.

The main difference (and I regard this as implementation issue) is that 
there need to be two ways of finding the next hop in an NSIS deamon ( I 
think CASP even provides more cases).

Marcus