Subject: DISCOVER - the return

From: bill <[email-masked]>
Date: Fri, 2 Jan 2004 12:24:56 -0800 (PST)

I would ask the working group chairs to send this to WGLC at 
    the earliest.  No other comments have been received. This should
    be submitted as EXPERIMENTAL.

	draft-dnsext-opcode-discover-02.txt 
 
 Forwarded message:
 > To: [email-masked]
 > Date: Mon, 13 Oct 2003 13:40:46 -0700 (PDT)
 > 
 > FYI.
 > 	the draft that defines a new op-code, discover, that passed
 > WG last-call early this year and then went into suspended animation 
 > pending some language clarifications will be re-emerging shortly.
 > Given the delay between last call and the text cleanup, it might be
 > prudent to have folk look it over again (given the WG has new ADs,
 > new WG chairs, and has been re-chartered since the last time this doc
 > has seen the light of day... :)
 
--bill

--
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: Bernard Aboba <[email-masked]>
Date: Tue, 6 Jan 2004 15:38:19 -0800 (PST)

Here are some comments on draft-dnsext-opcode-discover-02.txt that appear
to impact the resolution of Issue 59 (see
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html).

Section 2:

"3. If QDCOUNT equals 0 then only servers willing to do recursion
should answer."

Section 2.1 as proposed in LLMNR Issue 59 says that the RD and RA bits
are reserved and MUST always be zero.  So there is no way for an LLMNR
sender to request recursion or for an LLMNR responder to specify that
it will support recursion.

When DISCOVERY opcode is used, is the intent to redefine the meaning of
the RD bit in an LLMNR query or the RA bit in an LLMNR response so as to
enable discovery of DNS servers supporting recursion?  If so, this needs
to be explicitly called out (and perhaps text needs to be changed in
LLMNR Section 2.1 to make this clear).

Also, text proposed in Issue 59 prohibits a DNS server from answering an
LLMNR query for an RR that does not directly relate to it.

"6. responses have standard Answer, Authority and Addition sections"

Section 2.8 of LLMNR-27 specifies differences between the way these
sections are handled in DNS and the way they are handled in LLMNR.  For
example, the draft specifies that RRs in the additional section SHOULD
NOT be processed.

"Cache all NS and A data learned in this process"

Section 2.8 of LLMNR-27 states:

"Responders MAY have NS records associated with the names for which they
are authoritative, but they SHOULD NOT include these NS records in the
authority sections of responses."

Also:

"Senders MUST NOT cache RRs from the authority or additional section of a
response as answers, though they may be used for other purposes such as
negative caching."

So again, there appears to be a contradiction.

Refererences:

There is a reference to an expired mDNS draft.  This should be updated to
a reference to LLMNR, if in fact the DISCOVER opcode is compatible with
it.

---

From: bill <[email-masked]>
Date: Wed, 7 Jan 2004 13:25:33 -0800 (PST)

Is LLMNR an implementation of DNS or is it something that looks very
	much like DNS but is not?  

> it will support recursion.

	These restrictions seem appropriate for LLMNR as defined by 
	the Namedroppers/IETF process.
 
> LLMNR Section 2.1 to make this clear).

	No. it does "redefine" the meaning of these bits to enable the 
	discovery of DNS servers.  Not at all clear on what this maydo
	to LLMNR servers/clients.  IT -could- be used for just such a 
	purpose, however it was not defined in an LLMNR context.

> So again, there appears to be a contradiction.

	The goal of TBDS, where DISCOVER was defined, revisits the whole 
	idea of "iterative, recursive-mode" resolvers and impacts they way
	they manage thier cache entries.  I would have to re-read LLMNR
	to see if they follow that model.

> a reference to LLMNR, if in fact the DISCOVER opcode is compatible with

	Unclear if they (the old draft) and LLMNR are compatable.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 7 Jan 2004 14:10:28 -0800 (PST)

>much like DNS but is not?

LLMNR utilizes the DNS packet format defined in [RFC1035] but operates on
a separate port with a distinct cache.

>Unclear if they (the old draft) and LLMNR are compatable.

If I understand this correctly, then the DISCOVER opcode is designed
to run over a different multicast DNS protocol than LLMNR.

That's fine, but then you either need a normative reference to the
protocol that you are using or you need to specify this protocol in detail
within the DISCOVER draft.  Some questions:

a. What port does the DISCOVER protocol use?
b. To what multicast address are DISCOVER messages sent?
c. Are responses sent via unicast or multicast?
d. How are name conflicts detected and resolved?
e. Exactly how are all the bits within the DNS header handled?

---

From: bill <[email-masked]>
Date: Thu, 8 Jan 2004 11:23:33 -0800 (PST)

> to run over a different multicast DNS protocol than LLMNR.

	LLMNR and mDNS may have evolved from the same root, but have taken
	minor varients in evolution.  LLMNR could adopt, with minor tweeks
	many of the original design features of mDNS.

> within the DISCOVER draft.  Some questions:

	the "normative" reference for mDNS was rejected by the IETF but
	is part of the DARPA final report for that effort.  mDNS is 
	normal DNS with multicast capabilities so there is no unique
	protocol.
 
> a. What port does the DISCOVER protocol use?

	Its not a protocol, its a DNS opcode.
	
> b. To what multicast address are DISCOVER messages sent?

	From http://www.iana.org/assignments/multicast-addresses

There is a concept of relative addresses to be used with the scoped
multicast addresses.  These relative addresses are listed here:

Relative     Description                                       Reference
---------    ------------------------------------------------- ---------
  0          SAP Session Announcement Protocol                 [Handley]
  1          MADCAP Protocol                                   [RFC2730]
  2          SLPv2 Discovery                                   [Guttman]
  3          MZAP                                               [Thaler]
  4          Multicast Discovery of DNS Services               [Manning]
	-----------------------------------------------

> c. Are responses sent via unicast or multicast?

	Unicast.

> d. How are name conflicts detected and resolved?

	See the TBDS/DARPA report.

> e. Exactly how are all the bits within the DNS header handled?

	Not clear what this means.  There is nothing particularly unique
	here, its just DNS.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 8 Jan 2004 19:53:30 -0800 (PST)

> 	many of the original design features of mDNS.

Is there a way to get a list of the "minor tweeks" that would be required?
I'm willing to make the modifications to section 2.1, for example, if this
would allow DISCOVER to run over LLMNR.  Right now, for example, -28
reserves the RD, RA, CD and AD bits (since they're not used
with the QUERY opcode).  So DISCOVER could define uses for these bits when
used with that opcode.

> 	normal DNS with multicast capabilities so there is no unique

I'm not sure that there is such a thing as "normal DNS with multicast
capabilities."  When you get into the details, there are elements of the
DNS header (RCODEs, for example) that just don't make sense when used with
multicast DNS.  For example, in LLMNR only responses with RCODE=0 are
allowed.  Are non-zero RCODEs in allowed in DISCOVER responses?

> Relative     Description                                       Reference

Are you suggesting that LLMNR should use the relative multicast address
originally allocated to you?

---

From: bill <[email-masked]>
Date: Mon, 12 Jan 2004 11:44:45 -0800 (PST)

> Is there a way to get a list of the "minor tweeks" that would be required?

	I expect so, but then one would have to revisit the remit of 
	LLMNR. DISCOVER, in conjunction w/ the TBDS modifications to
	DNS has zero link-local restrictions.  

> with the QUERY opcode).  So DISCOVER could define uses for these bits when

	It could, but I would not wish to derail LLMNR w/ its adoption of
	a clearly experimental OPCODE.

> allowed.  Are non-zero RCODEs in allowed in DISCOVER responses?

	Yes, they were.

> originally allocated to you?

	No. You asked what multicast addresses are used in an implementation
	that supports DISCOVER.  I'm not suggesting LLMNR adopt DISCOVER.

--bill