Subject: Advance: Opcode Discover

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Thu, 01 May 2003 10:23:49 -0400

Erik

DNSEXT recommends the advance following document to experimental status:
www.ietf.org/internet-drafts/draft-dnsext-opcode-discover-01.txt

Background:
We had a last call concluded on this in November, the last call
required some minor changes in the document.
The editors concluded the edits in December.
Subsequently one of the editors sent in a request to have his name taken
off the draft, chairs waited for this to happen in a new version.
This particular editor has rescinded the request. Thus the document can
now be advanced.

         Olafur & Randy

 > From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
 > Date: Wed, 13 Nov 2002 12:33:40 -0500
 > Subject: DNSEXT WGLC Summary: Opcode-discover-00
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
 > Sender: [email-masked]
Precedence: bulk
X-UIDL: [0'"!C\S!!Dca!!(h[!!
 >
 >
 > This working group last call has concluded.
 > This work meets the technical criteria to be to be published as 
EXPERIMENTAL.
 >
 > Authors are requested to make the following changes before the document
 > is advanced to the IESG.
 >
 > 0. Number all sections that have titles.
 > 1. In the last paragraph before IANA consideration:
 >    Add a comment that a responder to DISCOVER, in some cases is not a
 >    traditional DNS server, it could be a special purpose software.
 > 2. References section needs to be broken into two "Normative References"
 >    and "Informational References", please fill out references fully.
 >
 >        Olafur
 >
 >
>This starts a 2 week last call for this document, the document is
>slated to be published as EXPERIMENTAL.
>
>http://www.ietf.org/internet-drafts/draft-dnsext-opcode-discover-00.txt
>
>This document specifies a new opcode that is used to discover DNS servers
>within the multicast scope of the address sent to.
>
>The authors main focus is to get a IANA assigned opcode for experimentation,
>does this document provide enough technical details for the framework to be
>experimented with.
>
>This working group last call completes on August 30'th 2002.
>
>         Olafur

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked]
Date: Fri, 02 May 2003 08:08:55 +1000

> >This working group last call completes on August 30'th 2002.

	Paul ask me to look at implementing this and I found that it
	was unimplementable as specified.

e.g.
	DISCOVER works like QUERY except:

	...

        3. if QDCOUNT==0 then only servers willing to do recursion should
           answer. Other servers must silently discard the DISCOVER request.

	Well QDCOUNT==0 results in FORMERR for QUERY.   I don't think we
	want FORMERR returned in this case.

e.g.
	"Compute the zone name of the enclosing in-addr.arpa, ip6.int, or
        ip6.arpa domain." 

	How do you determine this?  Are you expected to compute the full
	reverse name then remove labels after each probe fails.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]