Subject: [NSIS] Comment on draft-ietf-nsis-req-00.txt

From: Sarantis Paskalis <[email-masked]>
Date: Fri, 8 Mar 2002 11:03:25 +0200

Hi all,

While reading the requirement draft I fell upon this requirement:

5.3.7 Automatic notification on available resources not been granted
     before

   In many cases, a QoS initiator does want to get a notification when
   the resource, he requested for some time ago, gets free. In order to
   keep it simple, information on how long a request is kept and
   notified. It implies keeping state about requests, which have been
   rejected.

I believe this could lead to scalability and/or security problems and
should be removed from the requirements list.

To elaborate:
- A QI will most likely request again for the service after some time
  (since this requirement is optional).  The QC must then associate
  the new request with the blocked request, and so on for any further
  requests. 
- On peak traffic time, there has to be a policy about informing the
  blocked QIs or accepting new requests, leading to possible DoS attacks.
- It adds design complexity, without catering to NSIS scope.

Best Regards,

-- Sarantis

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

---

From: [email-masked]
Date: Fri, 8 Mar 2002 10:12:10 +0100

Sarantis, 

I agree and would propose to write: 

The nsis architecture MUST NOT support "automatic notification on available resources not been granted before". 

or just to remove the requirement. 

Anders

---

From: [email-masked]
Date: Fri, 8 Mar 2002 11:16:43 +0200

Hi Anders,

> The nsis architecture MUST NOT support "automatic 
> notification on available resources not been granted before". 
> 

The two things are entirely different.  The best solution is 
to remove the requirement.

MUST NOT requirements are generally used when something is
known to cause incompatabilities.

John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 8 Mar 2002 11:37:02 +0100

Hi John, Anders and Paskali

I also agree, please remove this requirement!

Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: vrijdag 8 maart 2002 10:17
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [NSIS] Comment on draft-ietf-nsis-req-00.txt

Hi Anders,

John

---

From: [email-masked]
Date: Sat, 16 Mar 2002 00:58:47 +0200

Robert,

I still don't really see this  a requirement.  It could
be a nice feature, in some environments, but I'm
not completely convinced that it is really useful.
Additionally, it will create state in the network 
and I'm not sure that is so good, especially in the
case when there are not enough resources.

John

> > in this particular case, i think the requirement came from 
> the context of not wanting to have a frustrated QI polling an 
> access network (e.g. a cellular one) at some ridiculous rate 
> to find out if resources have become available. (note in 
> particular that it is quite hard in some cellular 
> architectures to bill for this sort of polling, so far as i know.)
> > 
> > in some environments, this will be worth doing, and in some 
> it won't. i guess that makes it a SHOULD (which is what the 
> draft says), and there are a number of different modularity 
> approaches which would minimise the pain caused by providing 
> it as an option. (existence argument: QI says 'I want QoS for 
> flow labelled by reference R', QC responds in the event of 
> failure with either 'sorry, try later, in the meantime i've 
> forgotten about R' or 'sorry, i'll tell you later, in the 
> meantime don't ask again for flow R'. related tricks are 
> needed in mobile scenarios. if QI doesn't want notification 
> it omits R. the overhead in the protocol is some optional 
> fields, which either end can ignore. i'm not saying that this 
> is the right way to do it, but i don't see that allowing this 
> as a should causes too much pain for people who don't 
> actually want to implement the functionality.)
> 
> In that case the requirement should probably be:
> 
> "The QI MAY (or SHOULD) support being automatically notified 
> from QCs for resources not previously available"