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

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 8 Mar 2002 19:47:20 -0000

hi all,

we should not remove a requirement just because it is hard. we should remove it if it is too hard for the benefit obtained.

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

robert h.

ps the security/DoS argument is also valid. but there are security/DoS arguments about all aspects of QoS signalling. i agree that the DoS requirement is probably more important than this one, but if we can solve the DoS problem for the core parts of the signalling, I doubt this non-core part will be much harder. 

> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:[email-masked]]
> Sent: 08 March 2002 10:37
> To: [email-masked]'; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [NSIS] Comment on draft-ietf-nsis-req-00.txt
> 
> 
> 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,
> 
> > 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. 
> 
> 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
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>

---

From: Sarantis Paskalis <[email-masked]>
Date: Mon, 11 Mar 2002 11:35:39 +0200

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

In that case the requirement should probably be:

"The QI MAY (or SHOULD) support being automatically notified from QCs for 
resources not previously available"

No requirement should be placed on QCs (or whatever they will be named).

-- Sarantis