David B -05 review -- 4 The NQB PHB and its Relationship to the DiffServ Architecture

[thomas-fossati]

s/DiffServ/Diffserv/
 
Top of p.5:
   performance "requirements" are not hard ones (e.g. applications will
s/hard/strict/ or s/hard/absolute/ to avoid "hard" being misread as "difficult".  Not every reader will understand that the meaning of "hard" in "hard real time" is intended here.
 
A few paragraphs further down:
      The intent of the NQB DSCP is that
   it signals verifiable behavior as opposed to wants and needs.
Hmm – perhaps s/as opposed to/in addition to/ ??
The NQB PHB definitely signals desired traffic treatment/conditioning, but it also signals verifiable behavior that justifies applying that treatment/conditioning.  FWIW, EF and VOICE-ADMIT go part of the way there, but explaining that in this draft is probably a diversion.
 
       As a result, the NQB
   PHB does not aim to meet specific application performance
   requirements, nor does it aim to provide a differentiated service
   class as defined in [RFC4594].  Instead the goal of the NQB PHB is
Suggest changing that text to:
       As a result, the goal of the NQB PHB is
The statement about RFC 4594 is probably wrong, and it may be simpler just remove that statement rather than debate it.
 
   These attributes eliminate the inherent value judgments that underlie
   the handling of differentiated service classes in the DiffServ
   architecture as it has traditionally been defined, they also
   significantly simplify access control and admission control
   functions, reducing them to simple verification of behavior.
s/the inherent value judgements/many of the tradeoffs/
Otherwise, the draft will likely have to explain what an "inherent value judgement" is – better to not go there.

[gwhiteCL]

addressed in draft-06 & draft-07