Subject: Re: draft-ietf-dnsext-dhcid-rr-03.txt

From: Randy Bush <[email-masked]>
Date: Thu, 11 Oct 2001 18:17:06 -0700

> Date: Wed, 26 Sep 2001 11:56:35 -0700 
> this starts a two week wg last call on draft-ietf-dnsext-dhcid-rr-03.txt
> for proposed standard.

the wg last call has ended.  there seems to have been zero comment on
this draft.  unless i hear to the contrary, i will assume that no one
is sufficiently interssted in adding yarr, and we can let it die.

randy

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

---

From: Mark Stapp <[email-masked]>
Date: Fri, 12 Oct 2001 09:32:56 -0400

I wonder whether the lack of objections to this draft might be interpreted 
another way. The rr is designed for use in networks where dhcp servers and 
clients are updating A and PTR rrs as dhcp protocol interactions take 
place. Since the dhcid rr doesn't have any special dns protocol semantic 
significance, it doesn't raise any contentious issues for the dns server 
community. It's not surprising, then, if the dns community doesn't have 
much objection to the new rr.

The dhcp community has a dependency on this specification, however, and the 
use of this rr does have significance for us. Perhaps I've misunderstood 
the point of the wg last call: I thought it was a way of soliciting 
suggestions and complaints. I didn't realize that if no one objected, that 
the draft would die. That doesn't quite make sense to me, actually. In any 
case, I'm cross-posting this to the dhc working group list in the hope that 
some of that group's participants will express some support for this dnsext 
draft. If it dies, however quietly, the dhc group will have to start 
designing dhcp-dns interaction specifications from scratch.

-- Mark

---

From: Randy Bush <[email-masked]>
Date: Fri, 12 Oct 2001 10:03:09 -0700

if folk want it, they should speak up.  we don't need a hoard.  just a
few folk to say "yes, we want this."

randy

---

From: Ralph Droms <[email-masked]>
Date: Fri, 12 Oct 2001 13:11:40 -0400

I have no objections to draft-ietf-dnsext-dhcid-rr-03.txt and
recommend that it be accepted by the WG for submission as
a Proposed Standard.

This new RR is crucial to the standard mechanism under
review in the DHC WG to support the interaction of DHCP
and DNS in dynamic updates to DNS.

The DHCID RR is of specific interest to the DHCP
community, so posting to the DHC WG mailing list is likely
to reach the widest audience of interested persons.  Randy,
now that we know you're looking for positive responses as well
comments, the DHC WG will be able to respond to indicate our
interest in seeing this draft move forward.

- Ralph

At 09:32 AM 10/12/2001 -0400, Mark Stapp wrote:
>The dhcp community has a dependency on this specification, however, and 
>the use of this rr does have significance for us. Perhaps I've 
>misunderstood the point of the wg last call: I thought it was a way of 
>soliciting suggestions and complaints. I didn't realize that if no one 
>objected, that the draft would die. That doesn't quite make sense to me, 
>actually. In any case, I'm cross-posting this to the dhc working group 
>list in the hope that some of that group's participants will express some 
>support for this dnsext draft. If it dies, however quietly, the dhc group 
>will have to start designing dhcp-dns interaction specifications from scratch.
>
>-- Mark
>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Fri, 12 Oct 2001 13:25:27 -0400

> few folk to say "yes, we want this."

Folk have flown to IETF in foreign countries specifically for the purpose 
of saying "yes, we want this."   I have done it on several occasions.   I 
know Mark has as well.   That is why it was before the working group.   You 
now have three people who have publically stated on namedroppers that they 
want it, all within a matter of minutes of you unexpectedly proposing to 
kill it.   So please send it along.

Thanks!

				_MelloN_

---

From: "Barr Hibbs" <[email-masked]>
Date: Fri, 12 Oct 2001 11:01:02 -0700

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Randy Bush
> Sent: Thursday, October 11, 2001 18:17

> is sufficiently interested in adding yarr, and we can let it die.
>

I don't see why "zero comment" is equivalent to "no one is sufficiently
interested" but aside from that, this RR type is necessary for a DHCP server
to dynamically update a DNS server on behalf of a client that has received
an IP address lease from the DHCP server.  Do not let this simply slip into
oblivion.

--Barr

---

From: Randy Bush <[email-masked]>
Date: Thu, 18 Oct 2001 07:11:46 -0700

i have received comment that this draft does not make explicit that this RR
should only be defined for the IN class.

randy

---

From: Mark Stapp <[email-masked]>
Date: Thu, 18 Oct 2001 10:22:43 -0400

May I make that change and resubmit the -04 rev? Do you then submit that to 
the iesg, or do I need to do something to move it there?

Thanks,
Mark

---

From: Randy Bush <[email-masked]>
Date: Fri, 19 Oct 2001 14:37:12 -0700

> May I make that change and resubmit the -04 rev? Do you then submit that
> to the iesg, or do I need to do something to move it there?

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

1. Canonical format redefined instead of being inherited.

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

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

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.

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

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

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.

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.

randy

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 19 Oct 2001 16:57:47 -0700 (PDT)

>    DHCID RR can be in a set.

No other RR type definition does that.  In practice, all the RR types
that have not been singled out (no pun intended) as singleton types by
specific language in RFC 1035, 2136, or 2181 are assumed to allow
multiple RRs.

If this really needs to be stated explicitly, I suggest the following
text:

  The DHCID RR type is not restricted to a single RR per RRSet.
  Although the protocol for resolution of name conflicts by means
  of DHCID RRs may in fact employ only a single DHCID RR per
  RRSet, any such limitation is a property of that protocol,
  not of the DHCID RR itself, and is to to be enforced by that
  protocol, not by the DNS implementation.

-- 
Andreas Gustafsson, [email-masked]