Subject: [NSIS] Few comments on draft-brunner-nsis-req-00.txt

From: [email-masked]
Date: Tue, 19 Feb 2002 10:40:33 -0500

Hi:
 
I understand that the authors are in process of revising the above draft. I would like to provide few comments that may be considered during the revision process. Thanks.
 
Hemant
 
-----

Section 2. Terminology:
 
[QoS] Domain: I think this should be called [Administrative] domain, as the definition has no relation to the uniformity of QoS technology (as with the definition of QoS subdomain) of the domain, rather it is based on administrative uniformity.
 
Section 3.1, items 1) Handoff decision and 2) Trigger sources:
 
The handoff decision and trigger sources should be out of scope of NSIS. NSIS should rather focus only on "establishing" QoS along the packet path after handoff. The handoff decision and triggers should be left to mobility management protocols to consider.
 
Also, all the scenarios (at least end host oriented) in this section are somehow related to mobile terminals. There is a lack of other scenarios, such as say scenarios with inter-domain QoS establishment, QoS establishment over a path that traverses diverse QoS provisioning technologies, QoS accounting and authorization, QoS management etc. It will be useful to add such diverse scenarios there (I do not have text for them handy with me though). If the section becomes too big, it might be worthwhile to separate scenarios document and requirements document.
 
Section 5.1:
 
It may be useful to explicitly state the following requirement: "The signaling protocol should be independent of the QoS provisioning paradigms." This is in contrast to RSVP which is very tightly coupled to IntServ (though later force fitted to DiffServ).

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 19 Feb 2002 21:23:19 -0000

Hi Hemant,
 
On the 5.1 comment, I would be very keen to establish these sorts of 'decoupling' boundaries. 5.1.4 is about decoupling signalling protocol and signalling data, which [I think] corresponds partly to the question of RSVP/IntServ coupling. In 5.1.1 we said that signalling had to be applicable to a variety of QoS technology, but this could be strengthened to say that independence of signalling and provisioning paradigm is a (the?) way to do this. 
 
Sometimes it's hard to work out where the dividing line between protocol and service class/provisioning paradigm should actually lie (what about session identification, policy attributes, authentication, soft/hard-state-ness...). Do you have specific concerns about which of these things [or others] have caused problems in coupling rsvp and intserv together?
 
robert h.
 
PS. Briefly, I might well agree with you on the terminology and scenario issues. (For terminology, we started with 'Domain' but then I wanted to dress it up a little since 'Domain' is such an over-used word. And I'd like more core-oriented scenarios, but we need people to write them ... )

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 19 February 2002 15:41
To: [email-masked]
Subject: [NSIS] Few comments on draft-brunner-nsis-req-00.txt

Hi:

Hemant
 
-----

Section 2. Terminology:

 

Section 5.1: