Subject: [Tsvwg] RE: draft-baker-diffserv-basic-classes-04

From: "Jozef Babiarz" <[email-masked]>
Date: Wed, 10 Nov 2004 10:52:33 -0500

Thanks Brian for the additional comments, see answers below.
************************
Hi,
 
I find more to comment in this draft each time I look at it. Maybe it's
getting longer each time...

>    The key words "SHOULD", "SHOULD NOT", "REQUIRED", "SHALL", "SHALL
>    NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
>    this document are to be interpreted as described in [RFC2119].

It's very strange to find this in the Abstract, not the Introduction.
[Joe] Moved to Introduction. 

> 1.2  Service Class Definition
> 
> 
>    A "service class" represents a set of traffic that requires specific
>    delay, loss and jitter characteristics from the network for which a
>    consistent and defined per-hop behavior (PHB) [RFC2475] applies.

The Proposed Standard is RFC2474 and that should surely be the primary
normative reference; 2475 is Informational.
[Joe] Will change (PHB) reference to [RFC2474]
 
Also, this section still lacks any reference to the PDB document and any
explanation of the relationship between Service Class and PDB.
I suspect it is something like this:

   A Service Class as defined here is essentially a statement of
   the required characteristics of a traffic aggregate; the actual
   specification of the expected treatment of a traffic aggregate
   within a domain is defined as a Per Domain Behavior [RFC3086].
You need this, since you later refer to a PDB [RFC3662].
[Joe] OK, will add a reference to PDB in section 1.2 as requested.

> 1.3  Key Differentiated Services Concepts
> 
> 
>    The reader SHOULD be familiar with the principles of the
>    Differentiated Services Architecture [RFC2475].  However, we
>    recapitulate key concepts here to save searching.

Again, the normative reference is [RFC2474].
[Joe] Will change to [RFC2474] and [RFC2475]
 
> 1.4.1  Default Forwarding (DF)
> 
> 
>    The basic forwarding behavior applied to any class of traffic are
>    those described in [RFC2475] and [RFC2309].

And again.
[Joe] Will replace RFC2475 with RFC2474.

> 4.3  Multimedia Conferencing Service Class
...
> 
>    RECOMMENDED DSCP marking:
>    o  Video conferencing packets are marked with AF4x
>    o  VPN service may be marked with AF4x, depending on the service
>       characteristics
>    o  Server to server data transfer with AF4x, depending on the service
>       characteristics

It makes no sense to suddenly mention VPNs and server2server data transfer
here. Either this is the multimedia conferencing service class, or it isn't.
If you think this service class also contains VPN and server2server traffic,
that needs stating up front.
[Joe]Will remove the above text.
The name for the service class "Multimedia Conferencing" was chosen because
many currently deployed rate adaptive multimedia conferencing solutions are
configured this way. Other applications may use this service class as well,
if the characteristics and performance requirements of this service class
are appropriate.

> 5.3  Explanation of Ring Clipping

If we allowed such things in RFCs, this would be a footnote. I think this
should either be a subsection 4.2.1, or at least it should contain a
reference back to 4.2.
[Joe] Will move it to Appendix and provide reference back to 4.2. This is a
problem that needs to be address in real networks as interworking with
Public Switched Telephony Network (PSTN) is needed. 
It uses jargon and acronyms unknown in the IETF (Tandem Office??? ISUP??)
and English errors.
[Joe] Will explain the acronyms and fix any English errors.

> 5.4  VPN Service Mapping

You don't refer to RFC 2983 (Differentiated Services and Tunnels), and I'm
not sure you are consistent with it. You should certainly indicate which of
the conceptual models in 2983 you are suggesting. And of course if it's an
IPSec VPN, IPSec specifies certain rules that you have to follow.

[Joe] This section will be moved to the Appendix and will add reference to
RFC 2983. In this draft we are not address all the different options for
VPNs and what the QoS guidelines should to be. As stated in the draft
further study is required. 
  
     Brian

Regards, Joe.
Jozef Babiarz
email: [email-masked]

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