Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation identifier

From: Bob Braden <[email-masked]>
Date: Mon, 4 Nov 2002 17:24:48 GMT

*> 
  *> hi marcus
  *> 
  *> i hope that i am not fully misunderstanding something but it had the
  *> impression that this concept was agreed by everyone. even the framework says
  *> that the separation of a reservation (or session) identifier and the flow
  *> identifier is important to address mobility issues.
  *> 
  *> ciao
  *> hannes
  *> 
  *> 

I believe we had considerable discussion on this point, and I don't
think a final agreement was reached.

Bob Braden

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

---

From: [email-masked]
Date: Wed, 6 Nov 2002 09:57:35 +0200

Hi Rüdiger,

> I'd like to to keep a reservation ID as a requirement and 
> I prefer to look at it as a "must" (no capitals). Two 
> issues: it may save signaling load if you refresh by using 
> reservation IDs instead of flow IDs. That may be 
> intersting on wireless interfaces, but not only there. 
> The other argument I see is aggregation. I'm aware of 
> RFC 3175 and I regard the aggregation 
> mechanism designed there as smart but non trivial. A 
> reservation ID may be useful in this context.
> 
> I've twice used "may" here. It would be great if could 
> decide on the strength of requirement (must, should, may) 
> after we checked some real world designs and a proof of 
> concept.

I think the concept is a good one, but I somehow feel funny
that it would be a 'requirement' - perhaps it could listed
as a SHOULD or 'SHOULD be considered' - would that work?

John

---

From: [email-masked]
Date: Wed, 6 Nov 2002 10:15:44 +0200

Hi Rüdiger,

> "SHOULD" is ok. "To be considered" sounds a bit too weak.

SHOULD or SHOULD be considered were my suggestions.  Either are
OK with me.

John