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

Re: [IPSECKEY] new revision of draft



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


    Ólafur> Overview paragraph 4.  class independent ??? Ipsec is only
    Ólafur> defined for IP protocol that uses A and AAAA records that are
    Ólafur> only in IN class.

  A question was asked - is there any reason to limit it to the IN class.
  The view was - there was not.

  {as an aside, I certainly have things in other classes in my configuration,
and I certainly use A records to find name servers}

    Ólafur> Section 2 needs reordering Explain fields in the same order as
    Ólafur> they appear in the Resource record, currently they are out of

  good point.

    Ólafur> References RFC 103[45] are normative as well as 253[56] and
    Ólafur> 3110 others are informational.

  I think that I can remove 1884, as no IPv6 addresses are presented in
that format anymore.

  I have added the 2119 text.

>>>>> "Sam" == Sam Weiler <weiler@watson.org> writes:
    Sam> Abstract: ...describes the IPSECKEY resource...  and nuke the
    Sam> reference, as someone else noted.

  Do you mean, nuke the reference, or the entire sentence?

    Sam> I suggest striking: "It will be a public key as only public keys are
    Sam> stored in the DNS."

  okay.
  Somehow I wanted to be clear that no secret information is specified.a

    Sam> Section 1.1: It is expected that there will often be multiple
    Sam> resource records of the IPSECKEY type.  This will be due to the need
    Sam> to rollover keys, and due to the presence of multiple gateways.

    Sam> There will often be multiple IPSECKEY resource records (add: at the
    Sam> same name?), due to the presence of multiple gateways and the need
    Sam> to rollover keys.

  done.

    Sam> Section 2.2:

    Sam> Section 2.3: change to "in the same was as" or describe the exact
    Sam> interpretation -- the current wording is vague.

  okay.

    Sam> Section 2.4: Needs to have generic text for any value, then the
    Sam> expansion for RSA and maybe mention the DSA doc, but not in it's own
    Sam> subsection.

  I don't understand how what is there is wrong.

    Sam> Section 2.6: The first paragraph isn't a clear as I'd like to see
    Sam> it, but I don't have suggested text.

    Sam> wire-encoded ^ Drop the self-describing length mention (not
    Sam> necessary, since it's in the reference).

  Paul wondered at the term "wire-encoded"

    Sam> Rather than "most commonly", describe WHY it should be that.

  It shouldn't say that at all.

    Sam> 3.1 s/there/the/ s/should/???/ SHOULD?  MUST?

  Pointed out by Ólafur as well.

    Sam> 3.2 Make the lead-in text into correct sentences.
  
  By this, you mean "An example of a node..."?

    Sam> I'd omit the full
    Sam> length key -- use a short key for demonstration, or abbreviate it
    Sam> somehow.

  Sure, I can do that.

    Sam> 4 drop the 43 reference, presumably?  "public" algorithm field, huh?

  It was suggested that it would be good not to get DS confused :-)

]       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

iQCVAwUBPocgZYqHRg3pndX9AQHe3wQAhwvy47SEMLqilCNoLqP7VGGqTt3pv+mf
1osKz1VoQnCdn/1z37kgjqxx/iwdnUq2eCx0yeyfyJ++ogO6yX8NqoS9mhEVZ6Fs
dT1Lw/Ti64uWiJgfhU3aOufPyMbKtzvaETMVf55Nzh6v4lbD+nedYwWhl/kAzGn+
zTCEOX299WE=
=BXj3
-----END PGP SIGNATURE-----
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.