Subject: Update of RFC1886 Interop Report

From: Mohsen Souissi <[email-masked]>
Date: Mon, 10 Mar 2003 20:01:10 +0100

Hi,

RFC1886 Interop Report was reviewed and comments sent after the last
call related to draft-ietf-dnsext-rfc1886bis-01.txt were taken into
account. An updated version of the report is now available on :

http://w6.afnic.fr/RFC1886/testRFC1886.html (dual-stack)

This report corresponds to draft-ietf-dnsext-rfc1886bis-02.txt
announced on the mailing-list on March 5th.

Please note that the previous report
(http://www.6wind.com/RFC1886/testRFC1886.html) is outdated and will
be synchronised as soon as www.6wind.com web server is rebuilt.

Thank you for your understanding,

Vladimir & Mohsen.

--
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: Tue, 11 Mar 2003 14:30:05 +0700

Date:        Mon, 10 Mar 2003 20:01:10 +0100
    From:        Mohsen Souissi <[email-masked]>
    Message-ID:  <[email-masked]>

  | RFC1886 Interop Report was reviewed and comments sent after the last
  | call related to draft-ietf-dnsext-rfc1886bis-01.txt were taken into
  | account. An updated version of the report is now available on :
  | 
  | http://w6.afnic.fr/RFC1886/testRFC1886.html (dual-stack)

I'm sorry to have to say that you still don't have that right.

First, it is not "necessary" to test additional section processing of
SOA records, as none of that is required.   That is, it doesn't matter
in the slightest what happens when a SOA query is done, whether NS's
are put in the auth section or not, nor whether A/AAAA are then added
to the additional section for those NS's.

There's nothing wrong with noting that many servers do this, and thus
you decided to test it, and even to note the results, but please update
the interop report to stop it pretending that SOA testing is required
for 1886bis to go forward.

In other words, change this text from the new report:

    So, the additional section processing of authority section must be tested.

    It is necessary to test the following records: MX, NS, SRV and SOA.

into something like:

    So, additional section processing of the authority section was also
    tested to see what implementors have done there.

    It is necessary to test the MX NS and SRV records, SOA was also tested.

You do however need to test the additional section processing in a
referral, as distinct from an explicit NS lookup - those two should
be noted separately in the results.

Second, when a server fails the tests (which you report server Z as
having done for some) you should find out why, and include that
information.

It may be that from reading 1886 the authors of that server came to
different conclusions about what was required than others have.  In
that case, whatever was unclear about 1886 would need to be fixed in
1886bis so that future implementors don't get trapped the same way.

On the other hand, there may just be admitted implementation shortfalls
or bugs in implementation Z, along the lines of "oh yes, I didn't get
to that yet" or "oops, I see what happened" or even "I don't think that's
the right thing to do so I won't do it" from the implementor, indicating
that the text in 1886 was fine, but there were implementation errors (in
which case no revisions are needed to the doc, and the buggy implementation
is irrelevant, as there are still X and Y around, and only 2 are required.)

This is particularly true when there are just 3 implementations tested
(if there were 10 tested, and 9 did it the right way, and one didn't,
it might be reasonable to just assume "implementation bug", but with
1 out of 3 getting it wrong that's a much bigger risk).

[Aside: I'd love to know how an implementation can possibly fail to
support a particular domain name (as a server) ...  but that's not
really relevant here - but are you sure that the particular one you
tested just wasn't "not configured for IP6.ARPA" ?]

For the successful tests, you need to explicitly say what worked, just
"everything worked" isn't clear enough.

You should have a list of tests vs implementations, with an explicit
"ok/fail" marker for each.   There are many ways of setting out that
info, and which is used doesn't matter, but for just 3 implementations
a sensible way would be a list of things tested down the page, with
columns to the right for each of the 3 servers.

The resolvers (which should be more than just dig & nslookup I suggest)
should also be tested to see that they actually use the additional info
provided in the additional info section, and don't just ignore it.
That is, if a server returns

	maildomain.	IN	MX	0  mailserver.
	mailserver.	IN	AAAA	<stuff>

does a mailer using  the resolver actually successfully look up
maildomain. and then connect to its server (IPv6) without an additional
query ?

Similarly, some random clients that call gethostbyaddr() (or its newer
equivalent that I'm too lazy to look for) should be tested to see that
they do the correct PTR lookup.   Having servers support the PTR lookups
for IP6 addresses isn't very interesting (about the only thing that's
tested there is that the server can handle domain names with a very deep
domain tree - nothing else is even vaguely IP6 specific at the server
end) - what matters really is whether clients generate the correct domain
name for the PTR lookup (of course, we know they do, many of us use this
every day - but it needs to be documented in the interop report).
How that handles IP6.INT vs IP6.ARPA should be noted, though for 1886bis
all that really matters is that IP6.ARPA gets looked up (handling IP6.INT
is just an implementation requirement for transition, 1886bis doesn't
require anything at all about IP6.INT).

kre

---

From: Mohsen Souissi <[email-masked]>
Date: Fri, 21 Mar 2003 03:18:00 +0100

Robert,

On 11 Mar, Robert Elz wrote:
| Mon, 10 Mar 2003 20:01:10 +0100
|     From:        Mohsen Souissi <[email-masked]>
|     Message-ID:  <[email-masked]>
| 
|   | RFC1886 Interop Report was reviewed and comments sent after the last
|   | call related to draft-ietf-dnsext-rfc1886bis-01.txt were taken into
|   | account. An updated version of the report is now available on :
|   | 
|   | http://w6.afnic.fr/RFC1886/testRFC1886.html (dual-stack)
| 
| I'm sorry to have to say that you still don't have that right.
| 
| First, it is not "necessary" to test additional section processing of
| SOA records, as none of that is required.   That is, it doesn't matter
| in the slightest what happens when a SOA query is done, whether NS's
| are put in the auth section or not, nor whether A/AAAA are then added
| to the additional section for those NS's.
| 
| There's nothing wrong with noting that many servers do this, and thus
| you decided to test it, and even to note the results, but please update
| the interop report to stop it pretending that SOA testing is required
| for 1886bis to go forward.
| 
| In other words, change this text from the new report:
| 
|     So, the additional section processing of authority section must be tested.
| 
|     It is necessary to test the following records: MX, NS, SRV and SOA.
| 
| into something like:
| 
|     So, additional section processing of the authority section was also
|     tested to see what implementors have done there.
| 
|     It is necessary to test the MX NS and SRV records, SOA was also tested.

==> OK, point taken. We are working on a new version of the interop
report. It will be available soon.

| 
| You do however need to test the additional section processing in a
| referral, as distinct from an explicit NS lookup - those two should
| be noted separately in the results.

==> The "referral" case is the result of SOA queries and it is indeed separate
(in the report) from the "explicit NS lookup".

| Second, when a server fails the tests (which you report server Z as
| having done for some) you should find out why, and include that
| information.
| 
| It may be that from reading 1886 the authors of that server came to
| different conclusions about what was required than others have.  In
| that case, whatever was unclear about 1886 would need to be fixed in
| 1886bis so that future implementors don't get trapped the same way.
| 
| On the other hand, there may just be admitted implementation shortfalls
| or bugs in implementation Z, along the lines of "oh yes, I didn't get
| to that yet" or "oops, I see what happened" or even "I don't think that's
| the right thing to do so I won't do it" from the implementor, indicating
| that the text in 1886 was fine, but there were implementation errors (in
| which case no revisions are needed to the doc, and the buggy implementation
| is irrelevant, as there are still X and Y around, and only 2 are required.)
| 
| This is particularly true when there are just 3 implementations tested
| (if there were 10 tested, and 9 did it the right way, and one didn't,
| it might be reasonable to just assume "implementation bug", but with
| 1 out of 3 getting it wrong that's a much bigger risk).
| 
| [Aside: I'd love to know how an implementation can possibly fail to
| support a particular domain name (as a server) ...  but that's not
| really relevant here - but are you sure that the particular one you
| tested just wasn't "not configured for IP6.ARPA" ?]
| 

==> Yes, it was definitely not supported at the time of interop
tests. As for the other issues, we informed the implementors about
them. Our feeling is that there were bugs in the implementations in
question. Only the implementors can tell whether the issues are
related to the specifications or are simply bugs. We believe that if
the implementors had experienced any trouble with the specifications
(RFC 1886 and RC 3152), they would have shown up.

Vladimir and Mohsen.