[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IPSECKEY] Re: comments and nits (not including SC)
At Tue, 20 May 2003 14:21:31 -0400, Michael Richardson wrote:
>
> >>>>> "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>"?
As I said, a nit, but anyway... The RFC 1035 context is a (partial)
BNF grammer, which replaces interword whitespace in multi-word token
names with hyphenation.
In ordinary running text it's still "domain name" (or "DNS name").
> 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?
Deleting just [11] may suffice, deleting both is safest.
> 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.
Ack, let's revisit this one after the Security Considerations section.
> 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.
s/holding/named by the owner name of/
("owner name" is the DNS weenie term for the thing on the left.)
> 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.
Cool, I must've missed it. Reference?
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.