Subject: Re: wg last call for draft-ietf-dnsext-dhcid-rr-03.txt to ps

From: Mark Stapp <[email-masked]>
Date: Wed, 21 Nov 2001 16:39:57 -0500

At 02:37 PM 10/19/2001 -0700, Randy Bush wrote:

>there seem to be folk too tired to speak for themselves on the mailing list,
>so they send this stuff to me in email.  as 2026 does not specify that one
>has the right to confront one's accusors, i will forward anonymously :-)

I've made revisions that address these comments and submitted a new draft. 
The notification will show up as soon as the draft editor processes my 
submission. Specifics inline:

-- Mark

>1. Canonical format redefined instead of being inherited.

Done.

>2. Does not define that this type is only allowed in class IN

Done.

>3. Does not explicitly state if this is a singleton type or multiple
>    DHCID RR can be in a set.

Done.

>4. Section 3.4 should be structured something like:
>          "digest is calculated over <dhcpid> | <option> | <canonical FQDN>"
>          followed by list of what <dhcpid> + <option> pairs are allowed
>          followed by paragraph defining how to convert each option into
>          "digestable" data.
>    Right now it is really hard to comprehend, I'm sure the authors
>    understand this but interoperabilty is going to be a problem.

I've re-arranged some of this section, and added a couple of illustrations 
in an attempt to make it sufficiently clear.

>5. Section 3.2 references to RFC2535 base 64 should be in the beginning not
>    at the end.

Done.

>6. Section 3.1 should state that the DHCID is fixed length 18 bytes RR.
>    Most of second paragraph does not belong, all text until "the DHCID
>    resource" should be moved or deleted.  The "n bytes" MUST be changed to
>    "16 bytes".

Not correct. If the 0xffff identifier 'escape' is used at some point, the 
format may change and the RDATA length may change. Since the opaque RDATA 
has no semantic significance to the DNS protocol, there's no need to 
restrict its format in this way. I'd be concerned that someone would build 
such a limitation into a parser somewhere, when this RR should be treated 
as opaque binary data by DNS resolvers.

>7. Last paragraph of section 2 is bogus, it is not this documents role to
>    make statements about SHA1 being significantly slower than MD5, only to
>    make the statement that MD5 is strong enough for this purpose.

I had proposed language doing just that; this section was added at the 
insistance of one of the WG chairs in order to last-call the -03 revision. 
I'd be happy to change it or remove it, but I don't see that there's 
consensus about doing that. If there are no more comments on the issue, 
I'll leave the text.

>8. Section 3.5 and 3.6 do not fit in section 3 but should be in new section
>    4 called something like "Use of DHCID record by DHC servers" Section 3.7
>    should be new section 3.5.

Done.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.