RE: Evaluation: draft-ietf-ipsec-nat-reqts-05

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

I think I did not raise any comments. Randy did (or maybe
they came in via OPS directorate). So Randy will you handle?

Thanks,
Bert 

> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: dinsdag 21 oktober 2003 15:11
> To: iesg@ietf.org
> Subject: Evaluation: draft-ietf-ipsec-nat-reqts-05
> 
> 
> Bert & Randy:
> 
> When the updated document appears, please see if the fix that Bernard 
> applied is sufficient.
> 
> Russ
> 
> 
> >Date: Mon, 20 Oct 2003 23:05:59 -0700 (PDT)
> >From: Bernard Aboba <aboba@internaut.com>
> >To: Russ Housley <housley@vigilsec.com>
> >cc: tytso@mit.edu, byfraser@cisco.com, kivinen@ssh.fi, 
> angelos@cs.columbia.edu
> >Subject: Re: IESG Comments on draft-ietf-ipsec-nat-reqts-05
> >
> >Fixed and resubmitted.
> >
> >On Mon, 20 Oct 2003, Russ Housley wrote:
> >
> > > Three comments.  Let me know how you want to proceed.
> > >
> > > Russ
> > >
> > > = = = = = = = = =
> > >
> > > 1.  Minor error: the text currently says
> > >
> > >      For example, there are security risks
> > >      relating to IP source routing that are precluded
> > >      by AH, but not by ESP with null encryption.
> > >
> > > That's only true for IPv6. Per RFC 2402, source
> > > routing options are zeroed before calculation the
> > > AH ICV. I suggest changing "IP" to "IPv6" in that
> > > sentence.
> > >
> > > 2. The NOT should be chaned to lower case in:
> > >
> > >      For example, requiring that a protocol support 
> confidentiality
> > >      is NOT the same thing as requiring that all protocol 
> traffic be
> > >      encrypted.
> > >
> > > 3.  You will enjoy this one, but I do not think a change 
> is needed.
> > >
> > > The document says:
> > >
> > >      A protocol submission is not compliant if it fails to satisfy
> > >      one or more of the MUST or MUST NOT requirements for the
> > >      capabilities that it implements.  A protocol submission that
> > >      satisfies all the MUST, MUST NOT, SHOULD and SHOULD NOT
> > >      requirements for its capabilities is said to be
> > >      "unconditionally compliant"; one that satisfies all the MUST
> > >      and MUST NOT requirements but not all the SHOULD or 
> SHOULD NOT
> > >      requirements for its protocols is said to be "conditionally
> > >      compliant."
> > >
> > > Use of RFC 2119 is abstracted an amusing level.  But I 
> don't think it
> > > can be improved.
> > >
> 
>