Subject: Re: DNSEXT WGLC Summary: RFC1886bis-01

From: [email-masked]
Date: Fri, 14 Feb 2003 09:32:15 +1100

> 
> > The DNSEXT working group has concluded a last call on this document
> > 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)
	
	CNAME records do not cause additional section processing.

>     * PTR records (mentioned in RFC1886, but not explicitly)

	PTR records do not cause additional section processing.

>     * SRV records (not mentioned in RFC1886)

	SRV records do have additional section processing involving
	address records.

>     * SOA records (not mentioned in RFC1886)

	SOA records cause KEY record additional section processing.
	They do not cause address records to be added despite what
	Microsoft does.

> 
> 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
> 
> 
> --
> 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/>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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: Robert Elz <[email-masked]>
Date: Fri, 14 Feb 2003 10:35:51 +0700

Date:        Thu, 13 Feb 2003 13:56:44 +0100 (CET)
    From:        Erik Nordmark <[email-masked]>
    Message-ID:  <[email-masked]>

  | The interoperability report identifies some RR types for which AAA
  | additional section processing makes sense that are
  | not explicitly specified in the draft:

The implementation report is nonsense, and really needs to be fixed.

  |     * CNAME records (not mentioned in RFC1886)

There is (never) any additional section processing for CNAME records.

What the report should be saying, and what I assume was tested, is
that when an AAAA lookup is done, and the name looked up turns out
to be an alias (own a CNAME RR), then the RDATA of that RR needs to
be looked up for the AAAA, and the result returned (in the ANSWER
not additional section).

  |     * PTR records (mentioned in RFC1886, but not explicitly)

There is no additional section processing for PTR records.   The only
relevance of PTR at all for 1886 (1886 bis) is for its use in IP6.{ARPA,INT}
lookups.

  |     * SRV records (not mentioned in RFC1886)

Additional section processing is not required for SRV.   It can be done
however (it isn't prohibited), testing whether or not it is done for AAAA
I suppose makes some sense, but isn't important for the interop report.

  |     * SOA records (not mentioned in RFC1886)

There is no additional section processing for SOA records.   I can't
even imagine why they're mentioned in the interop report.

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

No, that would merely add confusion.   NS and MX are the only RR types
where address record additional section processing is important (though
some would say that NS is the only one where it really matters at all).

What is needed here (for this part, your point on normative references is
good, and that should be fixed in the draft) isn't any changes to the
draft, but a rational implementation report, which documents that what was
required to be tested was tested, and omits all the extraneous noise.

The draft contains just 4 things that I can see

AAAA records - they should be tested for lookups (testing lookup indirectly
via a CNAME probably makes sense too - but this is testing CNAME is
correctly processed, which has nothing much to do with AAAA specfically).

AAAA record textual format - the various forms of representing AAAA
records should all be tested (with and without ::, with and without the
trailing IPv4 format dotted quad at the end, etc) and documented to have
been tested, using the same RR's (exactly) in more than one server.

PTR lookups in IP6.ARPA

Additional section processing of AAAA records for NS MX (and, I suppose,
MB, the only other 1035 RR still alive which requires this - though "alive"
when talking about MB is stretching credulity a little).   The test should
be documenting that the 3 cases of interest work correctly - a lookup
where there is only an AAAA record for the name in the RDATA, a lookup
where there are both A and AAAA (the server is required to return both)
and a lookup where there is only an A (the server better not be broken by
including AAAA support so that it no longer returns the A record).

All that needs documenting.   Nothing more than that is required (though
extraneoous info in the implementation report shouldn't block progress of
the document - even if the extraneous information is bogus - it can claim
that all milk extracted from 17 pink cows tested was green if it wants to...)

kre

---

From: Vladimir Ksinant <[email-masked]>
Date: Fri, 14 Feb 2003 16:11:51 +0100

Erik Nordmark wrote:

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

Our opinion is that the draft should not list all the types that require
additional section processing. The reason is that some new types may
have to be added in the future and they will not be listed in the
document. 

If the interoperability report creates confusion on this point, we can
fix it.

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

Point taken.

> read and understand in order to implement RFC1886bis?

Our own opinion is that [4] is rather informative reference.

> Also, [5] through [8] seems like informative references.

Agreed

> (But [3] is normative for the textual representation.)

Agreed too.

If there is consensus on this, we can modify the references in the
draft.

Vladimir and mohsen