Subject: LLMNR Issue 67 (AD Review): Editorial issues

From: Bernard Aboba <[email-masked]>
Date: Thu, 2 Sep 2004 10:37:05 -0700 (PDT)

The list of current LLMNR issues and resolution is available here:
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html

The text of Issue 67 is enclosed below.  The proposed resolution is as
follows:

In Section 1 change:

"   In the future, it may be desirable to consider use of multicast name
   resolution with multicast scopes beyond the link-scope.  This could
   occur if LLMNR deployment is successful, the need arises for
   multicast name resolution beyond the link-scope, or multicast routing
   becomes ubiquitous.  For example, expanded support for multicast name
   resolution might be required for mobile ad-hoc networking scenarios,
   or where no DNS server is available that is authoritative for the
   names of local hosts, and can support dynamic DNS, such as in
   wireless hotspots."

To:

"In the future, it may be desirable to consider use of multicast name
resolution
with multicast scopes beyond
the link-scope. This could occur if LLMNR deployment is successful,
the need arises for multicast name resolution beyond the link-scope, or
multicast routing becomes ubiquitous. For example, expanded support
for multicast name resolution might be required for mobile ad-hoc
networks. "

Accept all the other editorial modifications.

----------------------------------------------------------------------------
Issue 67: Editorial Issues
Submitter: Thomas Narten
Submitter email address: [email-masked]
Date first submitted: August 27, 2004
Reference:
Document: LLMNR-34
Comment type: E
Priority: S
Section:  Various
Rationale/Explanation of issue:

> becomes ubiquitous. For example, expanded support for multicast name
> resolution might be required for mobile ad-hoc networking scenarios,
> or where no DNS server is available that is authoritative for the
> names of local hosts, and can support dynamic DNS, such as in
> wireless hotspots.

reword? sentence is hard to parse (especially last part).

> by an LLMNR responder. If the TC bit is set an LLMNR response,

s/an/in an/

> (e.g. A, AAAA, SRV, etc.) to the link-scope multicast address.

s/e.g./e.g.,/

> Upon configuring an IP address responders typically will synthesize

s/address/address,/

> 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.
> ip6.arpa IN PTR host1.
> IN PTR host1.example.com.

Text should somehow indicate that the above is one line that had to
be split for formatting reasons...

> For UDP queries and responses the Hop Limit field in the IPv6 header,

s/responses/responses,/ and drop the last , ??

> The responder should use a pre-configured TTL value in the records
> returned an LLMNR response. A default value of 30 seconds is

s/an/in an/?

> The responder should use a pre-configured TTL value in the records
> returned an LLMNR response. A default value of 30 seconds is

s/use a/insert a/ ??

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