[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[IPSECKEY] Re: draft 01 nits



-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Sam" == Sam Weiler <weiler@watson.org> writes:
    Sam> 1.1  terminal node?  What's a terminal node?  Do you mean in a
    Sam> terminal node in the DNS tree?  Can't there be A records for
    Sam> example.com as well as 
    Sam> host.example.com?  Why not IPSECKEY records?

  Well, in the *OE* use, for which we have an acceptable threat model
description, there isn't. However, if RR may have use elsewhere, then 
you may be correct. I will remove the word "terminal"

    Sam>    Is class independent the right answer? 

  We decided this in SFO.

    Sam> 2.  I'd strip this line, instead putting it the IANA section as I've
    Sam> done in my draft.  Go ahead and put in the number so they don't get
    Sam> confused -- they can always change it.

  Did Jakob figure out what the recommendation was going to be?

    Sam> 2.1 strip the parenthetical, just put algorithm type in the
    Sam> comma-separated list

  Done.

    Sam> 2.2 Can you summarize the precendence interpretation?  

<t>
Gateways listed in IPSECKEY records records with  lower precedence are
to be attempted first. Where there is a tie in precedence, they order
should be non-deterministic.
</t>

    Sam> 2.3 First paragraph.  Commas both seem out of place, or lacking a
    Sam> mate. 

Fixed already.

    Sam> 2.4 Should client handling of unknown formats be defined?

You mean, what should the client do if the value isn't 0, 1, 2 or 3? I'm
open to suggestions. I'd say just pretend that the record didn't exist.

    Sam> 2.6 s/then public key/then the public key/
    Sam>     s/RFC3110 to/RFC3110 extended that limit to/
    Sam>     "for the purposes of encoding and decoding" didn't make sense on 
    Sam> 	a first reading.  Can you clean it up?

    Sam>    You say "no such limit", but a two byte octet count, while huge, is
    Sam>    still a limit.  Why not say so?  The rest of the text could be
    Sam>    clearer, 
    Sam>    but it's verbatim 3110, so may as well leave it.

  so, it is cleaned up a bit already, the point of "encoding and decoding"
is that DNS implementations MUST permit the entire size to be encoded
and decoded. But, for practical purposes a document that uses this may
set a lower limit on the size of the keys.

    Sam> 3.1 s/There/The/

    Sam>    Should client handling of the root (.) gateway be specified?

  That's already mentioned now.

    Sam> 3.2 "a node 192.2.0.38" is awkward and probably needs to be changed.
    Sam> Why 
    Sam> not just drop the address from the prose entirely?  Even in the third
    Sam> example, you could say "...to another node specified by IPv4 address".
    Sam> "with the identity" seems like a bizarre phrasing.

  okay.

    Sam> The second example: again, what does the client do?  What does . mean?

  that would be a question as to semantics of this record, right? I was
going to say that this is out of scope, but I just re-read the charter, which
seems to be a bit broader than I had originally thought:

   The WG will define the semantics of the record only in terms of how the
   data in the record can be used for initializing an IPSEC session. Questions
   of when it is appropriate to do so are regarded as policy issues that are
   out of scope for this WG. 

  I am reluctant to write very much here, because I feel that it will quickly
become dozens of pages. 

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPsp1rIqHRg3pndX9AQGp9AQAto0xtsHVrBsSE8HrG4ITNc0rlCMPnZbC
VGowgKpZ+BExIH/eTriWTVpnAtvA4X1o9vH5mVgEivUomq0jV19xAVZDuUsU1C3K
nZfk7NRHVpWUDSbLCsfjbyuZR5UcYnIeEfMaTNE8RMCWC+ngKZh8A4xDsCDEhfJm
FKdXPjYMhDQ=
=ibmY
-----END PGP SIGNATURE-----
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.