Subject: whither rfc2052bis (SRV) and rfc2136bis (UPDATE)?

From: Paul A Vixie <[email-masked]>
Date: Wed, 23 Jun 1999 23:23:18 -0700

i've made no changes to these since the last ietf.  this usually but
not always indicates that i received no comments on the last versions
i published.  does that mean we can advance at least rfc2052bis and
that rfc2136 is for some reason not ready for an update before it goes
to proposed?

---

From: Robert Elz <[email-masked]>
Date: Thu, 24 Jun 1999 17:28:50 +1000

Date:        Wed, 23 Jun 1999 23:23:18 -0700
    From:        Paul A Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | i've made no changes to these since the last ietf.  this usually but
  | not always indicates that i received no comments on the last versions
  | i published.  does that mean we can advance at least rfc2052bis

"We" supposedly already did that, it went through IETF last call, then
was bounced from the IESG.   There was quite a bit of discussion about
that in April, but no resolution on exactly what we should do, yet anyway.

If you saw my draft charter for the merged group, you'll see I have a milestone
on getting this through te IESG by April 2013.   Some might consider that
a poor attempt at sarcasm, others realistic, and others wildly optimistic.

  | that rfc2136 is for some reason not ready for an update before it goes
  | to proposed?

I assume you mean draft there, not proposed?   22136 isn't going to DS any
time soon - it needs some kind of security also ready to go to DS, and as
we have none of that even at PS yet (or none that seems workable enough that
anyone has implemented it) there's no way we can get the necessary interop
reports on any kind of secure dynamic update that would allow that to move
to DS, and drag 2136 along with it.

As I recall from the first set of interop tests, there were a few small
items that were requested to be changed - I think we've discussed those
before - but as making a new doc isn't going to achieve much (they're
just clarifications which wouldn't require restarting at PS) there has
not been much in the way of incentive to push those along.

kre

---

From: [email-masked]
Date: Fri, 25 Jun 1999 08:57:51 +1000

> not been much in the way of incentive to push those along.
	The only thing that I can remember coming out of implementing
	UPDATE relates to updates that add a SOA record that is
	not at the top of a zone.  This is clearly an error condition
	because by definition you are updating a different zone to
	that in the ZONE section.  We decided that the error code
	that closest matched this condition was NOTZONE.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Robert Elz <[email-masked]>
Date: Fri, 25 Jun 1999 18:34:09 +1000

Date:        Fri, 25 Jun 1999 08:57:51 +1000
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	The only thing that I can remember coming out of implementing
  | 	UPDATE relates to updates that add a SOA record that is

You're missing half the point of doing interop testing.   It isn't enough
that the docs be correct and complete, it is also important that they're
clear enough that everyone who reads them (everyone reasonable anyway)
reads them the same way.

It was an issue of that kind (actually two I think) that the first of
the interop testing found.   One of them I now remember related to wildcards.
That is, one of the implementations, when testing for the existance of
a pre-requisite in a zone which contained a wildcard, had done a "normal"
lookup of the name - the lower level nameserver functions had detected the
wildcard and returned "name exists" (as would be correct for any other
lookup of the name), and hence the pre-requisite was satisfied (or not, I
don't recall whether the test that found this was "name must exist" or
"name must not exist").

Now there's no question but that this is not what is intended - a prereq
name lookup must only find names that actually apepar in the zone file,
only a lookup for '*' is permitted to find the wildcard record.

However whoever it was (I have forgotten, and in any case, it doesn't matter)
who did the implementation that didn't work this way hadn't been aware that
what was being done wasn't correct, until we did the test and found it.
This indicates that the doc isn't quite explicit enough on the requirement
here, and so one of the outcomes of that interop testing was a request that
some more wording be added to make this absolutely explicit.

There was another similar issue (when we actually need an updated update
doc, I will dig out my notes and find the other one).

kre

---

From: [email-masked]
Date: Sat, 26 Jun 1999 10:15:10 +1000

> doc, I will dig out my notes and find the other one).
	I wasn't saying that it was the only issue, just that it
	was the only one that was not already noted (you had already
	stated there were other issues noted) that we found during
	implementation (not inter-op testing).

	During inter-op there was also the issue of whether the
	zone can get temporarially into a "non valid zone" state.
	i.e. delete all NS at top of zone then add a new NS RRset.
	This is within the spirit of the RFC (maintain zone validity)
	but has a invalid intermediate state.  It's harder to code
	(more checks at the end of the update before committing).

	Mark