Subject: [NSIS] Comments on framework draft

From: Melinda Shore <[email-masked]>
Date: Wed, 16 Oct 2002 18:32:09 -0400

I've appended some comments on the framework draft.  As with
the requirements draft, some are substantive and others are
just nitpicky.  However, this document does raise some
significant issues that I think need resolution before the
requirements draft can be wrapped up, and I've listed those
towards the top (and I have absolutely no doubt that I've
missed some).  One thing that particularly concerns me is
that while in some places these issues are treated as open
in others they're treated as settled, and settled in the
direction of the CASP protocol.  Let's not do that.

Melinda

ISSUES TO RESOLVE
-----------------
1) Addressing - hop-by-hop or end-to-end?  If hop-by-hop,
   how is it routed?

2) Are "sessions" established between NSIS Entities?  Note
   that they don't eliminate state, but just move it to
   another layer - what advantages does this have over the
   more stateless RSVP protocol machinery?

3) Is multicast really out of scope?

4) receiver-oriented vs. sender-oriented

5) Will NFs be able to request, release, or modify
   reservations (either initiate requests or modify existing
   requests in transit)?

6) Is the use of periodic refresh messages the primary means
   of installing state?  Should these messages be
   idempotent?

7) Rely on internal or external security mechanisms?  (Can
   we punt on this until we know more about the protocol?)

===============
This document reads more like a framework for discussion
than as a framework for a protocol.  Need to talk about the
protocol rather than the working group (Section 1, first
sentence, for example)

The document is clear about distinctions between protocol
layer and application layer.

1.1 "This document will provide a framework for the NSIS
  protocol, both an architecture for the protocol itself and
  potential use scenarios.  It is not intended to define an
  overarching resource management architecture for the
  Internet."

Terminology:
"Classifier" - small nit but decision may be based on
something other than packet header - I'd say "packet
contents." 

"Resource Management Function": set of functions within an
NSIS Entity ... "  I don't think it's that abstract.  Maybe
need to clean up use in this document; later it seems to be
used to describe a policy function rather than specifically
resource management.

"peer session" - "session" implies some sort of persistence
in the connection between two nsis forwarders that's not yet
agreed upon.  The use of double-headed arrows in
Figure 1 implies (nsis) hop-by-hop signaling (addressing).
 
Need to be clear that NSIS Forwarders and NSIS Receivers
MUST be on the data path.  NSIS Initiators MUST be placed
somewhere topologically appropriate.  This may be a
deployment issue rather than a protocol design issue, but
off-path signaling is out-of-scope and we shouldn't design
for it (unless it's "free" - i.e. it doesn't complicate the
protocol).

3.2 should be clearer that these are *NOT* nsis modes of
operation, but rather a discussion of possible modes of
operation and tradeoffs.  Out-of-band is out of scope, and
discussion of it in sections other than 3.2.1 should be
deleted. 

3.2.2 Maybe definition should say crosses more than one
administrative domain.  I would be more concerned with
issues of authorization, etc.  What's the real difference
between functioning within one domain and functioning across
more than one domain?  Also, some of this discussion is
specific to QoS application.

3.2.4 What's the difference between local objects and opaque
data?

3.2.6 Disagree that error reporting is faster for sender-
oriented reservations - it need not be if you allow an nsis
device to send an error report back to the sender
immediately, rather than continuing to forward the message.

The definition of receiver initiated signaling is
incorrect.  In receiver-initiated signaling the
*reservation* is confirmed and installed in response to a
message from the receiver to the sender, but the data still
originate with the sender.

There may be cases in which you're looking for the last
appropriate NE on the path, for example when you use the
protocol for tunnel endpoint discovery.  Receiver-oriented
signaling works better for this case.  Sender-oriented
signaling would work but would require more messages.

3.3 contains requirements and those should be excerpted once
there's agreement and the material is consolidated
elsewhere.

3.3.1 "Optimized for unicast" is not the same thing as "not
    doing multicast" - can this decision be either finalized
    or tabled and revisited later?
    I'd put in some language about two-layer model here.

3.3.2 The first sentence is *excellent* - IETF documents
    need more of this kind of thing.  Otherwise section
    needs to be aligned with requirements document -
    currently they're somewhat out of alignment

3.3.3 Need to clarify what's meant by "maintaining
    relations".  We haven't agreed to session model.  Think
    it would be helpful to reframe some of the discussion in
    terms of policy and authorization - helps to modularize
    architecture. 

3.3.4 "Peer session" and "hop-by-hop" are not the same
    thing, and this section desribes hop-by-hop.  "Peer
    session" implies a connection model that's orthogonal to
    the addressing model.  (we could have end-to-end
    sessions, too)

3.3.5 I don't understand what the problem being addressed is

4.1 Feel quite strongly that interface selection should be
    handled by IP routing

4.2 control primitives seem to assume sender-oriented
    signaling (para 3).  Writing in para starting "We have a
    basic design goal" is a little unclear - why not simply
    state that we assume the following functions will be
    available by other means and are therefore will not be
    included in the NSIS protocol?

4.3.2 depends entirely on whether sender-oriented or
    receiver-oriented signaling is used.

4.4 Idempotent refresh messages allow routes to be changed
    transparently to the NSIS protocol machinery

4.5.1 Why do you want to identify "flows" at the NSIS
    protocol layer?  The text doesn't make a good case for
    it.  This belongs in the application

4.5.2 Text describes application use of reservation ids.
    The actual NSIS control layer use of application ids
    would be in manipulation of existing reservations
    (teardown, modification, etc.)

5.2 Some of this would fall under the rubric "policy
    routing," which could be mentioned

5.2.4 The old path may no longer exist

6.1 seems to assume the use of an external security protocol
    aside from key management (IPSec, SSL).  Does it need
    to?  What about authenticating individual elements?

6.2 I'd restate question as "Does the requestor have
    permission?"  Payment, etc. may very well not enter into
    it.  No negotiation!  Request has a yes/no/"no but"
    answer with possibility of additional information
    ("these are the nodes that would not satisfy the request
    and this is the reason they gave"), but negotiation
    introduces complexity with no real advantages.

6.3 Accounting also includes auditing

6.5 Not always reasonable to assume hop-by-hop protection,
    but is reasonable to assume "session" (if that's what
    we're doing) protection.  There are many situations in
    which you cannot assume transitivity of trust (financial
    institutions, for example, hate it).  Could this be a
    group keying application?  If so, how would that affect
    arguments here?

7.4 For a framework for middlebox signaling, see my
    "Network-friendlier Midcom" draft

7.5 Split Figure 9 into two?  Does two things: 1) provides
    picture of proxies, and 2) shows multilayer
    architecture.  Probably should do (2) before (1), or
    else move (1) up to section 3 somewhere

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

---

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

hi melinda,

thanks for the comments (appreciated). i thought i'd make a couple of points on your 'major issues' to encourage some more feedback.

one background process point: all the substantive text was written before the any of the authors knew anything about the approach proposed by casp (or indeed any of the other protocols other than Bob's cstp proposal, so far as i know). i don't think the issues are settled in any direction at the moment.

[snip]
> ISSUES TO RESOLVE
[reh] at the moment, it did't seem we could rule out either. RSVP uses both, after all. it's possible that a pure sender-initiated-everything approach could use end-to-end addressing only.

>    more stateless RSVP protocol machinery?
[reh] all 'session' is is a name for whatever protocol layer state is established between NSIS peers. this could be very small (nothing), just next/previous hop id (like RSVP), or quite complex (including security information).

the relative amounts of state in NSIS protocol vs. signalling applications is a very good question, as is working out how it can be minimised. i don't personally expect it can be eliminated in a real protocol, but nothing is fixed.

(people are free to suggest a less loaded term than 'session'.)

> 3) Is multicast really out of scope?
[reh] question for the group (and a requirements question, as you point out).

> 4) receiver-oriented vs. sender-oriented
[reh] good question (again). i suspect the answers may be different at the NSIS protocol layer and signalling applications (this is something we haven't really thought about, however.)

>    reservations (either initiate requests or modify existing
[reh] good question (again). i think this is especially critical for the mobility case (is re-authorisation logically required if the actual path changes?)

>    of installing state?  Should these messages be
[reh] i think in fact this may be a protocol design question, it might be at the boundary of what the framework document is supposed to define. (john, any views?)

>    we punt on this until we know more about the protocol?)
[reh] i think the basic point here is that there may be very significant advantages to at least considering using existing security infrastructure, namely (a) it may be hard to design ourselves and (b) in deployment terms, maybe one would rather avoid having to manage an NSIS-specific (or signalling application specific) set of identities and keys and rights. however, at this stage in the process, i think the main point is to try to map the overall security requirements onto the various components in the framework, and (maybe) look at goodness of fit to existing mechanisms.

cheers,

robert h.

========================================================================================
Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.

---

From: [email-masked]
Date: Thu, 17 Oct 2002 11:11:54 +0300

Hi all,

My two cents. I  believe that, after the Yokohama meeting,
there was WG consensus to move to a two layer approach:

	1) Upper layer, defining services, running end-to-end
	2) lower layer, defining transport, running hop-by-hop
		(though if only a single hop is needed, I guess
		that would qualify as end-to-end - for example
		if the service you are signaling for is on your
		access router ...)

> [reh] at the moment, it did't seem we could rule out either. 
> RSVP uses both, after all. it's possible that a pure 
> sender-initiated-everything approach could use end-to-end 
> addressing only.

I would think that the Framework document could take my proposal
above to resolve this issue. 

> [reh] all 'session' is is a name for whatever protocol layer 
> state is established between NSIS peers. this could be very 
> small (nothing), just next/previous hop id (like RSVP), or 
> quite complex (including security information).

Agreed.
 
> the relative amounts of state in NSIS protocol vs. signalling 
> applications is a very good question, as is working out how 
> it can be minimised. i don't personally expect it can be 
> eliminated in a real protocol, but nothing is fixed.
> 

I'd prefer to think that multicast is not out of scope, but we
are not defining the NSIS protocol for multicast services.
 
> [reh] good question (again). i suspect the answers may be 
> different at the NSIS protocol layer and signalling 
> applications (this is something we haven't really thought 
> about, however.)

This we should discuss and make some decisions on it.
 
> [reh] i think in fact this may be a protocol design question, 
> it might be at the boundary of what the framework document is 
> supposed to define. (john, any views?)

This may be getting into protocol design.  Should the framework
document define this?  I am no so sure.
 
> [reh] i think the basic point here is that there may be very 
> significant advantages to at least considering using existing 
> security infrastructure, namely (a) it may be hard to design 
> ourselves and (b) in deployment terms, maybe one would rather 
> avoid having to manage an NSIS-specific (or signalling 
> application specific) set of identities and keys and rights. 
> however, at this stage in the process, i think the main point 
> is to try to map the overall security requirements onto the 
> various components in the framework, and (maybe) look at 
> goodness of fit to existing mechanisms.

I think we punt, but perhaps we can at least can start setting the
table.  My knee-jerk reaction would be that the transport layer
use something like TLS and the service layer use some sort of end-to-end
encryption of payload.

John

---

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

john,

i think (hope?) that the 2 layer (or "2 level") approach is agreed as a way forward. i suspect there is also a fair amount of agreement about the scopes of the two layers (although the framework currently doesn't cover this, maybe it should - if people want to propose something & where it should go...)

however, i suspect that's orthogonal to melinda's concern, which is that merely using what we call peer-session addressing (either for things with local or end-to-end scope) is a Bad Idea, because you lose certain self-healing properties. i don't think the layering separation helps matters. (melinda, did i get your message?)

personally, i think you may gain as much as you lose, or even more. but that's the argument we have to work out here.

cheers,

robert

PS why did we use 'peer session' rather than 'hop by hop' in the framework? because people tend to assume 'hop' = 'IP hop' which wouldn't be valid here. but if people think hop-by-hop is a better term, we can go back to it.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 17 October 2002 09:12
> To: Hancock, Robert; [email-masked]; [email-masked]
> Subject: RE: [NSIS] Comments on framework draft
> 
> 
> Hi all,
>

---

From: [email-masked]
Date: Fri, 18 Oct 2002 15:55:19 +0300

Hi,

> i think (hope?) that the 2 layer (or "2 level") approach is 
> agreed as a way forward. i suspect there is also a fair 
> amount of agreement about the scopes of the two layers 
> (although the framework currently doesn't cover this, maybe 
> it should - if people want to propose something & where it 
> should go...)

My working assumption is the same as yours.

> however, i suspect that's orthogonal to melinda's concern, 
> which is that merely using what we call peer-session 
> addressing (either for things with local or end-to-end scope) 
> is a Bad Idea, because you lose certain self-healing 
> properties. i don't think the layering separation helps 
> matters. (melinda, did i get your message?)

That should be worked out in the discussion of the framwork, I 
think.
 
> personally, i think you may gain as much as you lose, or even 
> more. but that's the argument we have to work out here.

Exactly.

John

---

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

>however, i suspect that's orthogonal to melinda's concern, which is that merely using what we call peer-session addressing (either for things with local or end-to-end scope) is a Bad Idea, because y…

Sort of.  I'm less concerned about hop-by-hop addressing (in
the reverse direction, anyway) than I am about the creation
of persistent links between NSIS entities.  I'm unclear on
why this would be considered advantageous (at this point I see
it as highly disadvantageous), but at the very least I think that 
it's something that needs to be agreed to by the working group 
before becoming part of the framework.

Melinda

---

From: Bob Braden <[email-masked]>
Date: Sat, 19 Oct 2002 13:06:21 -0700 (PDT)

*> 
  *> > 
  *> > 2) Are "sessions" established between NSIS Entities?  Note
  *> >    that they don't eliminate state, but just move it to
  *> >    another layer - what advantages does this have over the
  *> >    more stateless RSVP protocol machinery?
  *> [reh] all 'session' is is a name for whatever protocol layer state is established between NSIS peers. this could be very small (nothing), just next/previous hop id (like RSVP), or quite complex (including security information).
  *> 
  *> the relative amounts of state in NSIS protocol vs. signalling applications is a very good question, as is working out how it can be minimised. i don't personally expect it can be eliminated in a real protocol, but nothing is fixed.
  *> 
  *> (people are free to suggest a less loaded term than 'session'.)
  *> 

I suggest that the solution is to simply eliminate the term.  It does
not seem necessary, and perhaps not useful.  Note that in routing
protocols, neighboring routers announce their presence to each other
and may even exchange security information, but these neighbor
announcements are not said to create sessions.  My 2-level signaling
draft simply says:

      A CSTP module must maintain state that lists the node's neighbors.
      This state includes the IP address of the neighbor and the local
      interface used to reach it.  This per-neighbor state also includes
      two Boolean flags giving important properties of the neighbor,
      e.g., ISPS-capable and Direct-Neighbor.  A node builds the
      neighbor list as a result of receiving CSTP messages.  The
      neighbor list should be implemented as soft state that is deleted
      if it is not refreshed.

Introducing a term like "session" for this neighbor state does not
seem to me to add any clarity.

Bob Braden

---

From: Bob Braden <[email-masked]>
Date: Sat, 19 Oct 2002 13:25:00 -0700 (PDT)

Melinda,

Here are a few comments on your questions.

  *> 
  *> 
  *> ISSUES TO RESOLVE
  *> -----------------
  *> 1) Addressing - hop-by-hop or end-to-end?

Yes. ;-)

        If hop-by-hop, how is it routed?

This is a deep question.  In fact, NSIS has not even begun to talk
about the issue of the interaction of routing and signaling.  This
is the one major area of IntServ/RSVP that was never satisfactorily
answered, because it is a very hard technical problem.

  *> 
  *> 2) Are "sessions" established between NSIS Entities?  Note
  *>    that they don't eliminate state, but just move it to
  *>    another layer - what advantages does this have over the
  *>    more stateless RSVP protocol machinery?

I commented separately on this.

  *> 
  *> 3) Is multicast really out of scope?
  *> 

It would be good if the NSIS result was not actively hostile to
multicasting as an option.  That is, a multicast extension could be
engineered later without extreme trauma on the underlying mechanisms.
RSVP1 shows us about the resulting additional complexity, while
substantial, should not be outrageous.

  *> 4) receiver-oriented vs. sender-oriented

Receive-initiated vs. sender-initiated, I think. (The discussion
of this in the Requirements doc seemed to me to be confused.
RSVP1 does receiver-initiated reservations.)

  *> 
  *> 5) Will NFs be able to request, release, or modify
  *>    reservations (either initiate requests or modify existing
  *>    requests in transit)?
  *> 
  *> 6) Is the use of periodic refresh messages the primary means
  *>    of installing state?  Should these messages be
  *>    idempotent?
  *> 

I didn't think this was even a question any more.  (I assume the
question you are asking is: can we get along without reliable delivery
of trigger messages, instead depending upon refresh messages for
reliability?)  The vendors doing (or considering) implementation of
RSVP1 certainly said "NO!".  That is, the signaling protocol has to at
least include the option of reliable delivery.

  *> 7) Rely on internal or external security mechanisms?  (Can
  *>    we punt on this until we know more about the protocol?)
  *> 

The general security issues are pretty much independent
of the protocol details, I would claim.  They are also hard,
if you go beyond the hop/hop security of RSVP1.

You could have broadened your question from "security" to "policy".

Bob Braden

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Tue, 29 Oct 2002 15:27:00 +0100

Hi Melinda 

Thank you very much for your comments!
Below some remarks (after [georgios]) on your 
comments (after [Melinda]):

[Melinda] 3.2.4 What's the difference between local objects and opaque
data?

[georgios] Local objects are part of the NSIS protocol, while 
opaque data is not. Local objects can be inserted, used and 
removed by one single domain.
Robert maybe we could enlarge the definition of local objects!

-------------------------------------------------------------

[melinda] 3.2.6 Disagree that error reporting is faster for sender-
[melinda] oriented reservations - it need not be if you allow an nsis
[melinda] device to send an error report back to the sender
[melinda] immediately, rather than continuing to forward the message.

[georgios] this statement is not about error reporting, but it is about
the reporting of an unsuccessful reservation, i.e., a reservation 
that cannot be supported due to the fact that there are not enough 
bandwidth resources (Admission Control failure due to unavailable 
resources). 
In a receiver initiated approach, e.g., RSVPv1, the receiver of the 
data path confirms and starts installing the reservation on the path 
from receiver to sender. During this procedure (receiver to sender) 
the reservation can be accepted or rejected. In RSVPv1 an Admission 
Control failure (due to unavailable resources) can only be 
notified by a ResvErr, with an Error_Spec object that carries 
the Error Code = 01: Admission Control failure.

In a sender initiated approach the sender of the data path is actually
installing the reservation on the path from sender to receiver, giving the 
possibility to any node in this path to reject the request. 

Robert maybe we could elaborate more in the definition of an 
unsuccessful reservation (see above).

-----------------------------------------
[melinda] The definition of receiver initiated signaling is
[melinda] incorrect.  In receiver-initiated signaling the
[melinda] *reservation* is confirmed and installed in response to a
[melinda] message from the receiver to the sender, but the data still
[melinda] originate with the sender.

[georgios] I think that there is a misunderstanding, maybe Robert 
could explain this term in more detail. Your definition is in my 
opinion better!
-------------------------------------

[melinda] There may be cases in which you're looking for the last
[melinda] appropriate NE on the path, for example when you use the
[melinda] protocol for tunnel endpoint discovery.  Receiver-oriented
[melinda] signaling works better for this case.  Sender-oriented
[melinda] signaling would work but would require more messages.

[georgios] good addition!
-------------------------------------------

[Melinda] 7.5 Split Figure 9 into two?  Does two things: 1) provides
[Melinda] picture of proxies, and 2) shows multilayer
[Melinda] architecture.  Probably should do (2) before (1), or
[Melinda] else move (1) up to section 3 somewhere

[georgios] The intention of introducing this picture (Figure 9) 
was to emphasise that the NSIS signaling protocol can be separated 
into more than one hierarchical levels. For example, level 1 can 
be seen as a CSTP (NSTP) level and levels 2 and level 3 can be 
parts of an ALSP (NSLP).

Best Regards,
Georgios

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: donderdag 17 oktober 2002 0:32
To: [email-masked]
Subject: [NSIS] Comments on framework draft

Melinda

ISSUES TO RESOLVE
-----------------

===============

Terminology:

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 29 Oct 2002 23:03:35 -0000

hi all,
> Robert maybe we could enlarge the definition of local objects!

[reh] seems reasonable. we could also clarify (i think) that 3.2.4 mainly applies in the NSIS signalling layer (as we are now calling it) rather than to the NTLP ("NSIS Transport Layer Protocol").

[reh] i think we should expand on the various conditions and possibilities for reject/error reporting in section 3.3.6. there are several issues which are all intertwined, not only related to sender/receiver initiation. for example:
*) if there is a NAT between the initiator and notification generator, the notification almost certainly can't be directly sent. should NSIS adapt its behaviour around this?
*) how do you protect against false notifications?
*) etc.

thoughts/text are welcome.

[reh] the difference is too subtle for my grasp. currently we have "In a receiver-initiated approach the receiver of the data flow initiates and maintains the resource reservation used for the data flow." I think we have used "sender" consistently to mean "data flow sender" regardless of whether signalling is sender or receiver initiated; maybe we should add that definition (and "receiver") explicitly.

[however, we have spotted an error in the last paragraph: "incoming" should--> "outgoing", and 3.2.7 is possibly ambiguous.]

[reh] we can add this comment to 3.2.6. there is also an i-d imminent trying to summarise sender/receiver issues (which misses this point, however...)

cheers,

robert

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 30 Oct 2002 15:19:49 -0000

hi melinda,

i've gone through the less technically demanding of the framework comments, and have some suggestions/questions. (i've left out ones which have already been covered in other threads, or which are sufficiently technically interesting to deserve their own threads. in other words, what follows is mainly clarification/editorial changes - i hope).

robert h.

============================================================

[MS] Terminology:
"Classifier" - small nit but decision may be based on
something other than packet header - I'd say "packet
contents." 
[reh] I suggest just 'packet'.

[MS] "Resource Management Function": set of functions within an
NSIS Entity ... "  I don't think it's that abstract.  Maybe
need to clean up use in this document; later it seems to be
used to describe a policy function rather than specifically
resource management.
[reh] We had a lot (I mean a *lot*) of discussions about this. The main point was we wanted a name for the thing the protocol (in fact, any NSLP) interacted with to actually do stuff, so we could separate all discussions of whether 'do stuff' was e.g. a centralised or distributed function. So, abstraction was actually a goal - but I'm open to alternative/better definitions.

[MS} "peer session" - "session" implies some sort of persistence
in the connection between two nsis forwarders that's not yet
agreed upon.  The use of double-headed arrows in
Figure 1 implies (nsis) hop-by-hop signaling (addressing).
[reh] We're proposing to drop the term session anyway now.
For the "<====>", the meaning is just supposed to be "this is how big an NSIS hop/peer-relationship is" (either addressing model possible). maybe we can separate these arrows off somehow and have a better caption.
 
[MS] Need to be clear that NSIS Forwarders and NSIS Receivers
MUST be on the data path.  NSIS Initiators MUST be placed
somewhere topologically appropriate.  This may be a
deployment issue rather than a protocol design issue, but
off-path signaling is out-of-scope and we shouldn't design
for it (unless it's "free" - i.e. it doesn't complicate the
protocol).
[reh] The terminology section (if this is what you are referring to) can be cleaned up about placement issues w.r.t. path-[de]coupled signalling.

[MS} 3.2 should be clearer that these are *NOT* nsis modes of
operation, but rather a discussion of possible modes of
operation and tradeoffs.  Out-of-band is out of scope, and
discussion of it in sections other than 3.2.1 should be
deleted. 
[reh] On the first point I agree.
On the second point I propose for now to try to localise discussion of the path-decoupled case in paragraphs beginning "Note: In the case of path-decoupled signalling..." or something (or I may get more pointed advice from the management).

[MS] 3.2.2 Maybe definition should say crosses more than one
administrative domain.  I would be more concerned with
issues of authorization, etc.  What's the real difference
between functioning within one domain and functioning across
more than one domain?  Also, some of this discussion is
specific to QoS application.
[reh] I don't really understand your point here. Are you looking for more detailed discussion?

[MS] 3.2.6 Disagree that error reporting is faster for sender-
oriented reservations - it need not be if you allow an nsis
device to send an error report back to the sender
immediately, rather than continuing to forward the message.
[reh] We will probably try to have a better section covering notification issues in more detail (as discussed in a separate email, covering also the next snipped points).

[MS] 3.3 contains requirements and those should be excerpted once
there's agreement and the material is consolidated
elsewhere.
[reh] I agree, in the long term.

[MS] 3.3.3 Need to clarify what's meant by "maintaining
    relations".  We haven't agreed to session model.  Think
    it would be helpful to reframe some of the discussion in
    terms of policy and authorization - helps to modularize
    architecture. 
[reh] I think this will be cleared up by the session terminology changes. (At least, it will be a start.)

[MS] 3.3.4 "Peer session" and "hop-by-hop" are not the same
    thing, and this section desribes hop-by-hop.  "Peer
    session" implies a connection model that's orthogonal to
    the addressing model.  (we could have end-to-end
    sessions, too)
[reh] Same comment as above.

[MS] 3.3.5 I don't understand what the problem being addressed is
[reh] OK, partly, this is historical overhang from the Minneapolis side discussions when we were still very much QoS focussed and were just making the discovery that issues like pre-emption could be pushed up out of the protocol into opaque service-specific data. (Recording this insight didn't prevent some tedious discussions at a later date on pre-emption issues, but that now seems to be past.)
Now, this is pretty much overtaken by the 2 layer approach, and this section should probably be replaced by one describing it and the isssue that we don't know where the split between them should go. Suggestions for text for such a section are welcome. We can take some of draft-braden-2-... as a starting point for the issues.

[MS] 7.4 For a framework for middlebox signaling, see my
    "Network-friendlier Midcom" draft
[reh] I'll add the reference. Would you propose to incorporate any of it directly?
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: [email-masked]
Date: Fri, 1 Nov 2002 00:01:05 +0200

Hi Bob,

> seem to me to add any clarity.

I completely agree.  I think that this terminology simplifies things.
I think your text has a particular 'solution' so at least for now,
perhas we could take the concept into the framework.

John

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 31 Oct 2002 23:46:14 -0000

john:

> Sent: 31 October 2002 22:01
> To: [email-masked]; [email-masked]; [email-masked]; Hancock, Robert
                       ^^^^^^^^^^^
which concept? (recall we are proposing to drop the term 'session' anyway, the last proposal was just to talk about 'peer relationship' and not say anything that could be thought of as implying a 'session model' as melinda calls it.)
PS I'm also still in a state of preferring 'peer' over 'neighbo[u]r', do people really find the term unbearable?

robert