Document: draft-ietf-ipsec-rfc2401bis-05.txt 
Review: Brian E Carpenter 
Date: 20 december 2004 

I think this is basically ready to go, but I have a few minor comments
and there are some nits.



Slightly substantive:
=====================


> 4.1 Definition and Scope
...
>    If different classes of traffic (distinguished by Differentiated
>    Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on 
> the
>    same SA, and if the receiver is employing the optional anti-replay
>    feature available in both AH and ESP, this could result in
>    inappropriate discarding of lower priority packets due to the
>    windowing mechanism used by this feature.  Therefore a sender SHOULD
>    put traffic of different classes, but with the same selector values,
>    on different SAs to support QoS appropriately.  To permit this, the
>    IPsec implementation MUST permit establishment and maintenance of
>    multiple SAs between a given sender and receiver, with the same
>    selectors.  Distribution of traffic among these parallel SAs to
>    support QoS is locally determined by the sender and is not 
> negotiated
>    by IKE. The receiver MUST process the packets from the different SAs
>    without prejudice.

I think it would be helpful to remind readers that (as indicated
in RFC 2983) we are talking here about the "inner" DSCP in a tunnel,
which will not be changed en route (since in general, the DSCP
value may be changed en route and that destroys the model described,
since there would be no fixed relationship between DSCP value and SA).

I also note that there is no reference to the IPv6 Flow Label. Since 
this
is an e2e field (RFC 3697) it would actually be easier to handle than 
the
DSCP, if there was any need to do so.

 > 4.4.2.1 Data Items in the SAD
...
>     o Bypass DF bit (T/F) - applicable to tunnel mode SAs

Note that this only applies to IPv4 (ditto section 8.1).

>     o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if
>       needed to restrict bypass of DSCP values - applicable to tunnel
>       mode SAs

This is unclear to me and needs some explanation. Actually, it's
unclear how the earlier suggested treatment of DSCPs works,
since the DSCP value(s) corresponding to an SA aren't stored anywhere
that I noticed, so the model does not allow for demultiplexing on
DSCP values in any case.



Nits:
=====

 > 4.4.1 The Security Policy Database (SPD)
...
 > Decorrelation
...
 > (unordered) state.  ppendix B provides an algorithm that can be

s/Appendix/ppendix/


Then idnits has complaints:

idnits 1.58

tmp/draft-ietf-ipsec-rfc2401bis-05.txt:

   Checking nits according to http://www.ietf.org/ID-Checklist.html :

     Checking conformance with RFC 3667/3668 boilerplate...
   * The document seems to lack an RFC 3667 Section 5.4 Copyright Notice 
--
     however, there's a paragraph with a matching beginning. Boilerplate 
error?
     ( - It does however have an RFC 2026 Section 10.4(C) Copyright 
Notice.)
   * The document seems to lack an RFC 3667 Section 5.5 Disclaimer --
     however, there's a paragraph with a matching beginning. Boilerplate 
error?
   * The document seems to lack an RFC 3668 Section 5, para 3 IPR 
Disclosure
     Invitation -- however, there's a paragraph with a matching 
beginning.
     Boilerplate error?
   * There are 105 instances of too long lines in the document, the 
longest
     one being 7 characters in excess of 72.

   Checking nits according to 
http://www.ietf.org/ietf/1id-guidelines.txt :

   * The document seems to lack a 1id_guidelines paragraph about
     Internet-Drafts being working documents.
   * The document seems to lack a 1id_guidelines paragraph about 6 months
     document validity.
   * The document seems to lack a 1id_guidelines paragraph about the 
list of
     current Internet-Drafts.
   * The document seems to lack a 1id_guidelines paragraph about the 
list of
     Shadow Directories.

   Miscellaneous warnings:

   - There are 28 instances of lines with hyphenated line breaks in the
     document.
   - Line 512 has weird spacing: '...support  multi...'
   - Line 1029 has weird spacing: '...g value  examp...'
   - Line 1031 has weird spacing: '...elector  selec...'
   - Line 1610 has weird spacing: '...oc addr  list ...'
   - Line 1615 has weird spacing: '...em addr  list ...'
   - (18 more instances...)

     Run idnits with the --verbose option for more detailed information.


      Brian