[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[IPSECKEY] Re: comments and nits (not including SC)
-----BEGIN PGP SIGNED MESSAGE-----
{Rob, I'm reordering so that things were discussion/conversation is needed
is at the top}
>>>>> "Rob" == Rob Austein <sra+ipseckey@hactrn.net> writes:
Rob> Nit:
Rob> | 3 A wire-encoded domain-name is present. The wire-encoded format is
Rob> | self-describing, so the length is implicit.
Rob> Change:
Rob> s/domain-name/domain name/
Rob> Rational:
Rob> There's no such thing as a "domain-name".
RFC1035:, section 3.3:
<domain-name> is a domain name represented as a series of labels, and
terminated by a label with zero length. <character-string> is a single
length octet followed by that number of characters. <character-string>
is treated as binary information, and can be up to 256 characters in
length (including the length octet).
Perhaps I should say "<domain-name>"?
Rob> Minor content:
Rob> This record replaces the functionality of the sub-type #1 of the
Rob> KEY Resource Record, which has been proposed to be obsoleted by
Rob> RFC3445 [11].
Rob> Change:
Rob> s/proposed to be obsoleted/obsoleted/
Done. Original was written prior to publication.
I've been told to get rid of the reference in the abstract. Do I do this
by just deleting the [11], or the RFC3445. as well?
Rob> s/name/name for use with the IPsec protocol suite/
Rob> Rationale:
Rob> Our charter clearly limits us to the IPSEC-specific scope, so the
Rob> document needs to be equally clear about that. I don't particularly
Rob> care how this is phrased so long as the scope is stated clearly enough
Rob> that nobody can claim it's ambiguous. What the abstract says is fine,
Rob> but the introduction needs to say it too.
Done.
Rob> Minor content:
Rob> An IPSECKEY resource record SHOULD be authenticated DNSSEC resource
Rob> record.
Rob> Change:
Rob> s/SHOULD be authenticated DNSSEC resource record/MUST be used in
Rob> combination with DNSSEC unless some other means of authenticating the
Rob> IPSECKEY resource record is available/
Done.
Rob> I think that this rephrasing of the SHOULD as a conditional MUST
Rob> captures the intent of the WG (I could be wrong), and seems more
Rob> likely to survive IETF last call and IESG review than the original.
I think that I agree with your intent.
But, I thought that this is where "SHOULD" was was useful. I was trying
to write:
An IPSECKEY resource record SHOULD be authenticated.
DNSSEC is the recommended method.
See next message dealing with SC section.
Rob> Strunk & White, "The Elements of Style", section 1, rule 3 :).
Rob> Summary: it's ok to omit both of the commas surrounding a brief
Rob> parenthetical clause, but if you keep one, you have to keep the other.
Did I mention English was my second language? :-)
marajade-[~] mcr 1036 %echo $LANG
C
Rob> Change:
Rob> s/format of the gateway/format of the information/
Done.
Rob> ================================================================
Rob> Nit:
Rob> | The gateway field indicates a gateway to which an IPsec tunnel may be
Rob> | created in order to reach the entity holding this resource record.
Rob> Change:
Rob> s/holding/named by/
Rob> Rational:
Rob> Not clear what it means for an entity to "hold" a DNS name.
I'd say "naming" - Its the thing on the left that I want to refer to.
Rob> s/, as defined/. The data portion is an IPv4 address as described/
Rob> s/name (section 3.3 of RFC1035 [2])/name, as described in section 3.3 of RFC1035 [2]/
Rob> Rational:
Done.
Rob> s/value 5/value 5,/
Done.
Rob> Nit:
Rob> RFC2065 limited the exponent and modulus to 2552 bits in length, and
Rob> RFC3110 to 4096 bits. No such limit is specified here for the
Rob> purposes of encoding and decoding.
Rob> Change:
Rob> s/RFC3110 to 4096/RFC3110 limits them to 4096/
Rob> Rational:
Rob> I don't -think- that RFC2065 limits RFC3110 to 4096 bits :).
Done.
Rob> s/255 and by/255, and as/
Done.
Rob> ================================================================
Rob> Minor content:
Rob> IPSECKEY RRs may appear as lines in a zone data master file. The
Rob> | precedence, gateway type and algorithm and gateway fields are
Rob> | REQUIRED. There base64 encoded public key block is OPTIONAL.
Rob> If no gateway is to be indicated, then the root (".") SHOULD be used.
Rob> Change:
Rob> s/appear as lines/appear/
Done.
Rob> s/then the root (".") SHOULD be used/then the gateway type field MUST
Rob> be zero, and the gateway type MUST be "."/
Rob> s/OPTIONAL; if not present, then the public key field of the resource
Rob> record MUST be construed as being zero octets in length/
Done.
Rob> Rational:
Rob> The first change is because we're not defining the format of master
Rob> files, just the format of the RDATA portion of this one RR.
Rob> The rest of the changes are intended to remove potential ambiguities.
Rob> Nit:
Rob> | An example of a node, 3ffe:501:4819:2000:210:f3ff:fe03:4d0 that has
Rob> | delegated authority to the node
Rob> Change:
Rob> s/to the node/to the node 2001:200:0:8002::2000:1./
Done.
Rob> See ID-nits comments (below), though, the address itself will probably
Rob> have to change.
Switched to 2002: example.
Bill Manning says that there is an example allocation in IPv6.
Rob> ID-nits:
Rob> You can't use non-US-ASCII, so you'll have to change the spelling of
Rob> both occurances of Olafur's name in the acknowledgements section.
okay.
] 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
iQCUAwUBPspyKYqHRg3pndX9AQFoNgP3TVZUU801wvN+dm1nPMtoPzi/GB5MWpFc
fduS2IKGyMUB9SvBx8P/uasDmhzyzHC//TkvrWLTj9dhPMWPQaM6S54Anm+bQKx5
vNGZgLeu7QGtANGRx4tELvWZCEe32jikKO5qteQRxgPDXgmV6aAR0bW7+bvqvzU+
9EmJf8adcQ==
=R4O5
-----END PGP SIGNATURE-----
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.