Subject: [IPSECKEY] Re: comments and nits (not including SC)

From: Michael Richardson <[email-masked]>
Date: Tue, 20 May 2003 14:21:31 -0400

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

{Rob, I'm reordering so that things were discussion/conversation is needed
is at the top}

>>>>> "Rob" == Rob Austein <[email-masked]> 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[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-
This is the [email-masked] list.
Email to [email-masked] to be removed.

---

From: Rob Austein <[email-masked]>
Date: Tue, 20 May 2003 15:07:04 -0400

> 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").

> by just deleting the [11], or the RFC3445. as well?

Deleting just [11] may suffice, deleting both is safest.

>   See next message dealing with SC section.

Ack, let's revisit this one after the Security Considerations section.

>   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.)

>   Bill Manning says that there is an example allocation in IPv6.

Cool, I must've missed it.  Reference?
-
This is the [email-masked] list.
Email to [email-masked] to be removed.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 20 May 2003 16:44:12 -0400

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

    >> Perhaps I should say "<domain-name>"?

    Rob> As I said, a nit, but anyway...  The RFC 1035 context is a (partial)
    Rob> BNF grammer, which replaces interword whitespace in multi-word token
    Rob> names with hyphenation.

    Rob> In ordinary running text it's still "domain name" (or "DNS name").

  Done.

    >> Bill Manning says that there is an example allocation in IPv6.

    Rob> Cool, I must've missed it.  Reference?

  I don't have one. he says one was allocated, but hasn't provided a
reference.

-

---

From: [email-masked]
Date: Tue, 20 May 2003 14:08:55 -0700 (PDT)

>   I don't have one. he says one was allocated, but hasn't provided a

	APNIC made the following delegation in late 2002:

the IPv6 prefix 2001:0DB8::/32 has been set aside for use in documentation.

ref:

http://www.apnic.net/info/faq/ipv6-documentation-prefix-faq.html

--bill
-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 20 May 2003 18:12:21 -0400

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

>>>>> "bmanning" == bmanning  <[email-masked]> writes:

    bmanning> 	APNIC made the following delegation in late 2002:

    bmanning> the IPv6 prefix 2001:0DB8::/32 has been set aside for use in documentation.

    bmanning> ref:

    bmanning> http://www.apnic.net/info/faq/ipv6-documentation-prefix-faq.html

  Got it, thank you.

-