Subject: Re: [NSIS] Comments on requirements draft

From: Marcus Brunner <[email-masked]>
Date: Fri, 01 Nov 2002 21:54:41 +0100

Melinda,

Here my responses to your sugestions. There will be 2 follow-up mails 
containing (1) draft changes you and others sugested, which I include into 
the -05 draft. And (2) a list of open issues to be discussed in Atlanta

Marcus

--On Dienstag, 15. Oktober 2002 13:32 -0400 Melinda Shore 
<[email-masked]> wrote:
>should be "NSIS Working Group", not "Network Working Group"

No, see RFC 2223

>2) this requirement document contains a tremendous amount of
>framework material.  That material needs to be separated out
>and integrated into the framework document.

Removed some of that text.

>should be "NSIS Working Group", not "Network Working Group"

need to check

>References need to be split into normative and informative

there are no non-normative references

>Need to include:
>     "This memo provides information for the Internet community.  This
>      memo does not specify an Internet standard of any kind.
>      Distribution of this memo is unlimited."
>in "Status of this Memo" section

They will finally get this text. So far the document is still a draft and 
has the draft text in status

>Introduction: Change "It does not list any problems of existing
>signaling protocols such as RSVP" to something like "We do not
>identify problems with existing signaling protocols, such as
>RSVP".  Better still, delete it.

>Change paragraph starting with "QoS is a pretty large field"
>to "While we anticipate this protocol will be used for other
>applications in addition to QoS signaling, this document
>focuses on QoS" or something like that.

Deleted

[?]

>
>In terminology: define "Upstream" and "Downstream"
>

regard this as known.

[?]
>
>
>Substance:
>
>The QoS signaling scenarios belong in the framework
>document.  Shouldn't there be some scenarios for something
>beside QoS, so that we can better generalize the protocol?
>
>This document should *not* be presenting conceptual models,
>just requirements.  Conceptual models belong in the
>framework.  Remove related material, such as introductory
>paragraph beginning with "It is clear that the subject of
>QoS is uniquely complex"
>
>Delete first paragraph of terminology section, make sure
>that all terms are actually used in the document.
>Receiver-initiated signaling protocol and sender-initiated
>signaling protocol are not.  Get rid of mom-and-apple-pie or
>obvious terms, like "QoS Technology."
>
>"Resource Management Function" definition is far too
>abstract.
>
>Definitions too QoS-y.  For example, "Flow" can be defined
>in terms of resources requested rather than QoS requested.
>"QoS Provisioning" should be "Provisioning," etc.  I would
>give serious thought to a separate QoS application
>requirements document.
>
>"Trigger" used a lot - I think I probably know what's
>intended by it, but I don't know for a fact what it means.
>Needs definition.
>
>Delete section 3, refer to framework
>
>Delete section 4, refer to framework
>
>Consistent problem throughout Requirements section:
>requirements aren't stated *as* requirements.  Application
>and transport need to be separated out more cleanly (for
>example, 5.3.4 and 5.3.5)
>
>Use of "may be able to" - what does that mean?  Needs to be
>more definite.
>
>5.1.1 Needs to be hardened up lest risks being mom-and-apple-
>pie.
>

I wonder that you think this is apple-pie. I would think the requirement is 
the most important one for you.

>5.1.2 not stated as a requirement.  "The NSIS protocol MUST
>    allow the NI to query for resource availability without
>    initiating a request."
>
rephrased

>5.1.3 is a weak protocol requirement and is probably
>    redundant with 5.1.1.  It's unclear whether or not
>    bullet items are requirements
>

note that the requirements draft does not only cover protocol requirements 
but also framework requirements.

>5.1.4 is related to 5.1.1 and 5.1.3.  We should probably try
>    to distill them down to one or two requirements
>
They are only 2 with some explanation

>5.1.5 is not a protocol requirement
>

But an architectural.

>5.1.7 is related to 5.1.1, 5.1.3, and 5.1.4  See 5.1.4.
>    Also, not stated as requirement.

Sure it is related is in the same section for that reason. reading 5.1.7 I 
would more go split it up into several requirements

>
>5.2.1 Not stated as requirement.  The first sentence is
>    closer, I think, to what's intended than the header
>    (requirement) is.
>

I don't think the header must be specified as a requirement

>5.2.2 Not stated as requirement.  Also wrong - this is out
>    of scope
>

Here I hesitate to remove it before we hav3 resolved the data-path issue.

[...]

>5.3.2 Unclear.  Possibilities: do you mean that any NSIS
>    node, whether NI, NF, or NR, should be able to initiate
>    a teardown, or do you mean that any NSIS node that
>    releases its resources without a request from the
>    initiator should send out a teardown, or do you mean
>    that any NSIS node that releases its resources without a
>    request from the initiator should send out a notice?
>

The latter in case of failures.

>    Don't know what "The goal is to prevent stale state
>    within the network and adds robustness to the operation
>    of NSIS. So in other words, an NSIS signaling protocol or
>    mechanisms MUST provide means for an NSIS entity to
>    discover and remove local stale state." means.  Resource
>    discovery is covered in 5.1.2, and for a node to
>    discover its own state is node mechanism and not a
>    protocol requirement
>

It meant that there needs to be some house-keeping to prevent stale state. 
Softe state is one mechanisms how this can be solved.

>5.3.4 Some questions: Doesn't the answer depend on the
>    application (if we're using the two-layer architecture)?
>    If so, wouldn't the contents of the answer be opaque to
>    the protocol machinery anyway?
>

No, the protocol must have means to tell the NSIS initiator what happened 
to a request. But additional information why the request has failed is 
pretty service depended (in a two layer architecture)

>5.4.1 A bit frameworky.  At least make sure this is
>    consistent with framework
>

This is a req for the framework not the protocol I assume.

>5.4.2 See 5.3.4 and 5.3.5
>

as you pointed out before, you would like to remove 5.3.5 and you are happy 
with this one. But they are different. Put it to the open issue list 
whether we can remove 5.3.5

>5.4.3 This needs to be rewritten so that it's a protocol
>    requirement and not a mechanism requirement.  Also, it's
>    a bit application-ish and may depend on the application
>

I don't agree that this is not a protocol req. But you might be right with 
the application dependence. -> put it onto the open issues list.

>5.4.4. (the word "seamless" makes me queasy)  This can be
>    deleted - it's about NF mechanism
>

What make you queasy??

>5.5 This section really needs more discussion.  Some of it
>    is either obvious or meaningless, and some of it is
>    outside the scope of what is even possible.  A
>    requirements document should state requirements in the
>    form of things like "The NSIS protocol MUST support
>    aggregation of requests."
>

I know the problem, but again things cames out of a length agreement 
process.

>5.6 This might be best broken up and redistributed among
>    other sections
>

I will do this if I hear other concerns.

>5.6.1 I'm not sure what this means - something akin to IPSec
>    selectors?
>

NSIS must work in environemnt where you have flow aggregation on the data 
path.

>5.6.2 Can probably be deleted unless a specific protocol
>    requirement can be identified
>	

Is framework req. and get into a protocol req, but I am not sure

done

>5.6.4 "The NSIS protocol SHOULD permit signaling both
>    unidirectional and bidirectional reservation requests."
>    Delete second paragraph.
>

No, is needed. Was hard to agree on that one.

>5.7.1. "The NSIS protocol MUST support strong authentication
>    among NSIS nodes.  The protocol MUST NOT support the use
>    of plaintext passwords for authentication or
>    encryption."  Delete the rest.  (Note that this is
>    actually quite difficult to do in practice, particularly
>    interdomain).
>

see Hanne's reply

>5.7.2 Need to distinguish between application and
>  transport.  Delete frameworky text.
>

see Hanne's reply

>5.7.3 Need to think about protecting individual message
>    elements as well as entire message
>

see Hannes' reply

>5.7.5 Belongs in framework document
>

Why? It sounds like an requirement.

>5.7.6 Identity of what?  Where does this sit in terms of
>    transport layer/application layer split?  Accounting
>    stuff - application layer
>

>5.7.7 "The NSIS protocol SHOULD be resilient against
>    denial-of-service attacks."  Currently unclear.  Delete
>    rest of paragraph
>
>5.7.8 "The NSIS protocol MUST allow encryption of NSIS
>    messages between NSIS nodes."
>
>5.7.10 Delete
>
>5.8.1 Delete the word "efficient" - motherhood/apple pie
>

Probably for you, but this already went through several iterations to get a 
compromise

>5.9.1 Not a protocol requirement.
>
We are not talking about protocol requirements only

>
>5.9.4 Not just the security mechanism, need to identify
>    considerations for transport and for application.
>    Also, might want to think about interactions with 5.9.3

Changed

>5.9.5 Delete "seamless"  Isn't this redundant with 5.8.1?
>

I think it is not the same, but I rephrased it to try to get the difference.

>5.9.6 This is really unclear and should probably be
>    deleted.  There are specific issues with policy-based
>    routing that need to be addressed in the framework
>    document and may be reflected back here as specific
>    protocol requirements - needs more discussion.
>
>5.10.1 Keep first sentence, delete rest
>

Sorry, but also this one was a compromisee

>5.10.2 Um, how does this work with on-path signaling?  Delete
>
No.

--------------------------------------
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

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

---

From: Melinda Shore <[email-masked]>
Date: Fri, 01 Nov 2002 16:58:25 -0500

> there are no non-normative references

There will be - the framework document, for example.  Even
if there aren't, however, the normative references need to
be labeled as such.  You should probably give
draft-rfc-editor-rfc2223bis-03.txt a good read - the IESG
and the RFC editors are becoming stricter about formal
issues and if the document makes it through WG last call and
is sent to the IESG with format problems, John is going to
be spanked.

> >In terminology: define "Upstream" and "Downstream"

You probably shouldn't.  It's not intuitive (I still can't
figure out whether a given neighbor lives "up the road" or
"down the road") and is considerably less obvious than other
terms for which there are definitions in this document, such
as "End Host," "Subdomain," and "Path."

> I wonder that you think this is apple-pie. I would think the requirement is =
> 

Not really.  When I say "Mom and apple pie" I mean something
that's obvious and feels good but isn't particularly
meaningful.  For example, in this case something like "The
information exchanged over the signaling protocol must be in
such detail and quantity that it is useful for various
technologies" is probably self-evident.  There's something
that looks more like a requirement in there and it is
probably worth restating it so that it's less generic and
puts specific requirements on the protocol.

> note that the requirements draft does not only cover protocol requirements=20

Okay, but "modular" is one of those words, like
"scalability," that isn't very useful without an explanation
of specifically what is meant.  The examples given don't
necessarily have very much to do with modularity.  For
example "Work over any kind of network" might be an artifact
of modularity, but it might be just plain old IP.  "Uni- and
bi-directional reservations are possible" isn't really an
example of modularity.  Those themselves aren't descriptions
of what is meant by the word "modular."  I think I know what
you're trying to get at, and maybe you could extract some
language from Bob's "Two-Level" draft.

> I don't think the header must be specified as a requirement

The requirements need to be presented consistently.  In the
beginning they're stated in the section headers and later
they're placed in the body of each section.  It's not
necessarily that they belong in the header but that they be
treated consistently.  BTW, my favorite requirements
document as far as presentation is the one produced by the
sacred working group.

> Here I hesitate to remove it before we hav3 resolved the data-path issue.

I think this has been pretty much resolved by fiat (the ADs).

> It meant that there needs to be some house-keeping to prevent stale state.=20

It's unclear as stated, I think.  If you're saying that a NE
must release expired resources that's a node mechanism and
is out-of-scope.  Are you trying to say this?
"When an NSIS Entity detects a failure and releases a
reservation, it MUST notify other NSIS Entities along the
reservation's path."  It's not clear exactly what you're
requiring. 

(BTW, the second paragraph in 5.3.2 suffers from the "MUST
be able to" problem)

> I know the problem, but again things cames out of a length agreement=20
> process.

That doesn't make them correct, as you know.  Much of this
section falls into the "Mom and apple pie" category, since
the alternatives to what you're saying could be things like
"The NSIS protocol MUST be inefficient" or "The NSIS
protocol must consume vast amounts of bandwidth."  It's
better in these cases to be specific about what the
requirements are, like saying that the protocol MUST support
aggregation of requests or that the protocol MUST NOT
require more than a single end-to-end round trip to install
a reservation (unless there are errors).

> Why? It sounds like an requirement.

The material beginning with "It is a well-known ... " isn't
requirements text and should be moved into the framework
document. 

> Probably for you, but this already went through several iterations to get a =
> compromise

"Efficient" took several iterations and a compromise?

> Sorry, but also this one was a compromisee

Again, I'm not saying to delete the requirement, but to
delete the chatty stuff.

> >5.10.2 Um, how does this work with on-path signaling?  Delete

I think it needs a lot more discussion.  For one thing it
may be an implementation/mechanism issue rather than a
protocol issue.  For another, the text doesn't necessarily
match the requirement.  I'd put it high on the "needs
resolution" list.

Melinda