[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[IPSECKEY] Re: ipseckey out of iesg
-----BEGIN PGP SIGNED MESSAGE-----
The IESG has made the following comments, which you can read at:
https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1082&filename=draft-ietf-ipseckey-rr
I include the comments below, as a quote, and am responding to them,
as I act on them.
IESG> Last Call to expire on: 2003-11-17
IESG> Please return the full line with your position.
IESG> Yes No-Objection Discuss Abstain
IESG> Harald Alvestrand [ ] [ XX] [ X ] [ ]
IESG> Steve Bellovin [ X ] [ ] [ ] [ ]
IESG> Bill Fenner [ ] [ X ] [ ] [ ]
IESG> Ned Freed [ ] [ X ] [ ] [ ]
IESG> Ted Hardie [ ] [ X ] [ ] [ ]
IESG> Russ Housley [ ] [ X ] [ ] [ ]
IESG> Allison Mankin [ X ] [ ] [ ] [ ]
IESG> Thomas Narten [ ] [ ] [ X ] [ ]
IESG> Jon Peterson [ ] [ X ] [ ] [ ]
IESG> Margaret Wasserman [ ] [ X ] [ ] [ ]
IESG> Bert Wijnen [ ] [ ] [ X ] [ ]
IESG> Alex Zinin [ ] [ X ] [ ] [ ]
IESG> 2/3 (9) Yes or No-Objection opinions needed to pass.
IESG> DISCUSSES AND COMMENTS:
IESG> ======================
IESG> Ned Freed:
IESG> Comment:
IESG> No IPR boilerplate
Added. I didn't find anything in the IRP WG's documents with a template.
I took one from the first RFC I found that had one, which happened to be
3584.txt.
IESG> Ted Hardie:
IESG> Comment:
IESG> This text:
IESG>
IESG> 2.1 IPSECKEY RDATA format
IESG>
IESG> The RDATA for an IPSECKEY RR consists of a precedence value, a
IESG> public key, algorithm type, and an optional gateway address.
IESG>
IESG> seems to leave out gateway type, described in section 2.4. The
IESG> rest of the document is clear, but it would probably be good to add
IESG> it in here.
Fixed.
IESG> Allison Mankin:
IESG> Comment:
IESG> Instead of RFC1521 for Base64 (v. old), reference RFC3548.
Done.
IESG> In the examples, replace ip6.int with ip6.arpa.
Already done in my copy.
IESG> In the IANA Considerations, there's a typo:
IESG>
IESG> This document creates an IANA registry for the algorithm type field.
IESG>
IESG> Values 0, 1 and 2 are defined in Section 2.3. Algorithm numbers 3
IESG> through 255 can be assigned by IETF Consensus (see RFC2434 [6]).
IESG>
IESG> This document creates an IANA registry for the gateway type field.
IESG>
IESG> Values 0, 1, 2 and 3 are defined in Section 2.4. Algorithm
IESG> numbers 4
IESG> ^ Gateway type
IESG> through 255 can be assigned by Standards Action (see RFC2434 [6]).
Fixed.
IESG> Thomas Narten:
IESG> Discuss:
IESG> Meta issue (this is why I'm putting in a discuss):
IESG>
IESG> Intro (actually no part of the document) actually explains what this
IESG> RR is useful for. Consider a reader not familar with this effort who
IESG> would like to understand why this RR is needed, who uses it, and in
IESG> what situations its useful. For instance, it would be useful to
IESG> include an example of how the RR is expected to be used. I.e., it's
IESG> not until halfway down the document that one figures out the RR could
IESG> identify a gateway one connects to to create an IPsec tunnel to a
IESG> particular site. But the RR is keyed by an address. Why does one need
IESG> to map from the address to a gateay? I suspect 1 or 2 paragraphs
IESG> would to the trick.
IESG>
IESG> Specific comments:
IESG>
IESG> Abstract could be a lot better. Reading it, one doesn't really know
IESG> what this document is about or how the RR is used.
Hmm. The purpose of this WG is to replace the functionality lost in the
RFC3445. 2535 doesn't say what the record is for either. So I feel that this
is really putting a higher standard on this record than there was in 2535.
In addition, we carefully avoided saying very much about what the key
means, (semantics), since that goes towards usage. We did say that any system
that defines semantics must specify this stuff. Having grumbled, my next
message contains suggested text, since I want to highlight this.
IESG>
IESG> > The RDATA for an IPSECKEY RR consists of a precedence value, a public
IESG> > key, algorithm type, and an optional gateway address.
IESG>
IESG> picture also shows a 'gateway type' field...
Already caught above.
IESG>
IESG> > 2.2 RDATA format - precedence
IESG> >
IESG> > This is an 8-bit precedence for this record. This is interpreted in
IESG> > the same way as the PREFERENCE field described in section 3.3.9 of
IESG> > RFC1035 [2].
IESG>
IESG> say "unsigned"? also, why not just specify the semantics of the
IESG> preference here, rather than pointing to a (rather unrelated) MX
IESG> record RR? Hunting for the MX text in another document seems
IESG> suboptimal (and results in an odd normative reference).
Chairs? Copy and paste from 1035?
We already reference 1035 for other reasons.
IESG> > Gateways listed in IPSECKEY records with lower precedence are to be
IESG> > attempted first. Where there is a tie in precedence, the order
IESG> > should be non-deterministic.
IESG>
IESG> Note: the above text seems out of place, given the previous paragraph
IESG> which just points to MX. Can't you just specify the behavior here (in
IESG> its entirety) and remove the normative dependency?
We could do that. Chairs?
IESG> > 3 A wire-encoded domain name is present. The wire-encoded format is
IESG> > self-describing, so the length is implicit. The domain name MUST
IESG> > NOT be compressed.
IESG> >
IESG>
IESG> "wire-encoded" could be made more precise. I.e., Refer to DNS spec
IESG> (and specific section?). (There is better text later in the draft,
IESG> actually)
I've added a reference to 1035,
IESG> > A 32-bit IPv4 address is present in the gateway field. The data
IESG> > portion is an IPv4 address as described in section 3.4.1 of RFC1035
IESG> > [2]. This is a 32-bit number in network byte order.
IESG> >
IESG> > A 128-bit IPv6 address is present in the gateway field. The data
IESG> > portion is an IPv6 address as described in section 2.2 of RFC1886
IESG> > [7]. This is a 128-bit number in network byte order.
IESG>
IESG> Why are (apparently normative) references to other RRs given here?
IESG> Can't the format just be written out here, since it's basically one
IESG> sentence saying N-bits in network byte order?
Chairs?
The reference seems appropriate to me, but I don't care.
IESG> >
IESG> > This document updates the IANA Registry for DNS Resource
IESG> > Record Types
IESG> > by assigning type X to the IPSECKEY record.
IESG>
IESG> Add:
IESG>
IESG> This document creates two new IANA registries, both specific to the
IESG> IPSECKEY Resource Record.
Done.
IESG> Jon Peterson:
IESG> Comment:
IESG>
IESG> The end of Section 4 says:
IESG>
IESG> Any user of this resource record MUST carefully document their trust
IESG> model, and why the trust model of DNSSEC is appropriate, if that is
IESG> the secure channel used.
IESG>
IESG> Does that really mean "any user"? Do we require end-users of our
IESG> specifications to generate documentation these days? If this is
IESG> instead referring to derivate specifications or IETF-shepherded
IESG> operational models based on these RRs, it should say so explicitly
IESG> here.
now reads:
Any derivative standard that makes use of this resource record MUST
carefully document their trust
model, and why the trust model of DNSSEC is appropriate, if that is
the secure channel used.
IESG> Nit: Should we encourage/require people who use xml2rfc to use the
IESG> <?rfc
IESG> compact="yes"?> directive? The amount of whitespace that is
IESG> generated otherwise is a little bothersome.
Didn't know about it.
Hmm. My version doesn't have that. I will look later, when online.
IESG> Bert Wijnen:
IESG> Bigger issue:
IESG>
IESG> - The examples use the reverse DNS records to convey IPSECKEY record.
IESG> Does this have some unstated assumptions about the deployment of
IESG> IPSECKEY (e.g., to be usable, the participating nodes should record
IESG> the RRs in reverse records), or is this just a coincidence?
IESG> I note that the document does not discuss the deployment at all, but
IESG> that is probably intentional.
IESG>
IESG> If there is no connection to the reverse records, I'd suggest
IESG> rewording at least 3 of the 5 examples to use e.g. "nodeX.example.com
IESG> IN IPSECKEY ..."; if there is a requirement for reverse records, this
IESG> issue needs to be explicitly discussed.. DNS deployment folks might
IESG> have something to say about that :-)
Chairs. Reverse is clearly in scope here.
Can you discuss with Bert?
IESG> Nits:
IESG>
IESG> - Reorder sections 2.3 and 2.4 to be in the saem order as the fields.
Done.
IESG> - Replace the references to RFC1886 with RFC3596.
Done.
IESG> - Add IPR section
Done.
IESG> - Rename the draft shortname (at each page header) from "ipsecrr" to
IESG> something else.
Any suggestions?
IESG> - Remove the dot from the title and upper-case it.
upper-case what? "IPsec"? the whole thing?
I'll ask Bert directly.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBP9ehZYqHRg3pndX9AQFPFAP8CSrYOof39FLt8ba3MFoDZ+ANnQmSQqDr
Bc9F8mWxgG91VircwqOnftoOJOi8XnaKa25ix1g3SuEl7GJo7H+N94VVy1VH61D+
LrZel5UdtssFqhqT1KQQAUm5iCYMFO+mvJzPyD8gC+3/KwQh1y+jtk6XLgw4Pxe1
uHXBgLiafW0=
=Ylnq
-----END PGP SIGNATURE-----
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.