Subject: DNSEXT WGLC Summary: RFC1886bis-01

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Wed, 12 Feb 2003 23:47:06 -0500

Erik,

The DNSEXT working group has concluded a last call on this document
and there is consensus on requesting it be advanced as Draft Standard.

>This document replaces RFC1886 with minimal changes incorporated from
>interoperabilty testing and RFC3152 (ip6.arpa. delegation)
>
>This document is on standards track and is to be advanced to Draft
>Standard it and supporting interoperabilty test report and is available 
>via following URLs:
>http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc1886bis-01.txt
>
>
>http://www.6wind.com/RFC1886/testRFC1886.html

         Olafur & Randy

--
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: Erik Nordmark <[email-masked]>
Date: Thu, 13 Feb 2003 13:56:44 +0100 (CET)

> and there is consensus on requesting it be advanced as Draft Standard.

I've looked it over.

The interoperability report identifies some RR types for which AAA
additional section processing makes sense that are
not explicitly specified in the draft:
    * CNAME records (not mentioned in RFC1886)
    * PTR records (mentioned in RFC1886, but not explicitly)
    * SRV records (not mentioned in RFC1886)
    * SOA records (not mentioned in RFC1886)

Wouldn't it make sense to add explicit mention of those types to section 3
(right now the section says for example NS and MX).

> Normative References

For this document to become a draft standard all normative references need to
be draft standard or higher.

>   [4]  Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6
>        Hosts and Routers", RFC 2893, FreeGate Corp., Sun Microsystems
>	Inc., August 2000.
>	This RFC is being updated. The current draft is 
>        "draft-ietf-ngtrans-mech-v2-00.txt", Gilligan, R., and 
>        E. Nordmark, July 17, 2002

Is this really a normative reference i.e. something that one needs to
read and understand in order to implement RFC1886bis?

Also, [5] through [8] seems like informative references.
(But [3] is normative for the textual representation.)

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 10:42:02 +0100 (CET)

> 	CNAME records do not cause additional section processing.
> 
> 	PTR records do not cause additional section processing.
> 
> 	SRV records do have additional section processing involving
> 	address records.
> 
> 	SOA records cause KEY record additional section processing.
> 	They do not cause address records to be added despite what
> 	Microsoft does.

It seems like the interoperability report for 1886bis should
be clarified based on the above.

And that the 1886bis document should mention SRV record additional
section processing. 

   Erik