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

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Sun, 09 Dec 2001 13:06:52 -0500

At 04:39 PM 11/21/2001, Mark Stapp wrote:
>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
>
>
> >3. Does not explicitly state if this is a singleton type or multiple
> >    DHCID RR can be in a set.
>
>Done.

I assume that there is some other document that specifies how
to interpret multiple DHCID, it would be helpful to have a pointer to
that.
My understanding has been this is supposed to be a semaphore for
DHCP servers but allowing multiple DHCID that semantics are broken.

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

This is still not clear and the size of MD5 is still refered to as 'n bytes'.

         Olafur

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