RE: feedback on algorithms-00

[Gregory Lebovitz <Gregory@netscreen.com>]

including the list...

> -----Original Message-----
> From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org]
> Sent: Thursday, May 15, 2003 7:49 AM
> To: Gregory Lebovitz
> Subject: Re: feedback on ipsec-algorithms-00
> 
> 
> >- Makes perfect sense to have this separate from the actual 
> proto docs.
> >Thanks for getting it done.
> 
> Your welcome. See below.
> 
> >- Sect 2, first sentence, typo "used in IKEv2 for may security..."
> 
> Thanks, go it.
> 
> >- format help: would be nice in 2.1-2.4 to add a 4th column 
> to each chart
> >that holds MUST, SHOULD, etc. That way the reader can see 
> what's what very
> >quickly.
> 
> I didn't do that because of the difference between "MUST today" and 
> "MUST tomorrow". That is, I wanted to keep the wording below the 
> tables being definitive.

no argument about keeping the wording; I wouldn't have suggested removing
it. Adding the column will make ingestion easier on the reader.
Additionally, you could put a "*" by the SHOULD that calls to text below
highlighting the "MUST Later" stuff.
 
> >- 2.4 - the DH values for 1-5 are currently defined in 
> [IKEv2]. Since this
> >is the crypto doc, shouldn't we pull those definitions out 
> of the [IKEv2]
> >and into this doc, along with the definitions of values for 
> the others?
> 
> Yes, but no one had a strong opinion on this.

I'd say just do it and see if anyone screams. Probably no one will care, and
most will think its a good idea.

> 
> >   - second sentence says values 6-200. But really it is 
> 6-13, 19-200, right?
> >Because 14-18 are defined in [MODP]?
> 
> Correct; good catch.
> 
> 
> >- 3.0 1st para, last sentence, TYPO:  "Instead *they* give..."
> 
> Fixed.
> 
> >-3.x - I really like the idea of doing suites via 
> "profiling" that dictates
> >the suites we will all use in practice, while the actual 
> protocol should
> >call for "a la carte" method of SA proposal. It makes for 
> (a) a much more
> >powerful and flexible protocol, while (b) providing the ease 
> of use and
> >crypto sanity checking that are needed on both ends of the
> >security/convenience spectrum.  We can even name them the 
> same thing in our
> >UI's, which will make interop all that much easier.
> 
> Exactly.