Re: let's talk about RFC2136bis

[gson@nominum.com (Andreas Gustafsson)]

Before I comment on the RFC2136 issues you mentioned, I'd like to add
two more...

#13 -- contradiction in section 3.4.2.2

   3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to
   the zone.  In case of duplicate RDATAs (which for SOA RRs is always
   the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL
   fields both match), the Zone RR is replaced by Update RR.  If the
   TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is
   lower (according to [RFC1982]) than or equal to the current Zone SOA
   RR's SOA.SERIAL, the Update RR is ignored.  In the case of a CNAME
   Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME
   Update RR, otherwise replace the CNAME Zone RR with the CNAME Update
   RR.

The last sentence contains a contradiction.  If we have a non-CNAME
Update RR and a CNAME Zone RRset (that's the "vice versa" case), it
says we should "ignore the CNAME Update RR" even though the Update
RR is not a CNAME.

Also, strictly speaking the "otherwise" condition means "either both
the Update RR and Zone RRset are CNAMEs, or neither one is", but the
text following the "otherwise" only applies to the former case.

I propose replacing the last sentence with the following two sentences:

					       In the case of a CNAME
   Update RR and a non-CNAME Zone RRset or vice versa, ignore the 
   Update RR.  In the case of a CNAME Update RR and a CNAME Zone RR,
   replace the CNAME Zone RR with the CNAME Update RR.


#14 -- conflict between section 3.4.2.4 and pseudocode

The text of RFC2136 says:

   3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose
   NAME, TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted,
   unless the NAME is the same as ZNAME and either the TYPE is SOA or
   the TYPE is NS and the matching Zone RR is the only NS remaining in
   the RRset, in which case this Update RR is ignored.

The corresponding pseudocode in section 3.4.2.7 says:

	   elsif (rr.class == NONE)
		if (rr.type == SOA)
		     next [rr]
		if (rr.type == NS && zone_rrset<rr.name, NS> == rr)
		     next [rr]
		zone_rr<rr.name, rr.type, rr.data> = Nil

The text and the pseudocode are in conflict in the case where the last
NS RR of an NS RR set in a place other than the zone apex (i.e., in a
delegation) is being deleted.  The text allows this deletion, but the
pseudocode would cause it to be ignored.  Since the text takes precendence
over the pseudocode, the pseudocode should be changed to say

	   elsif (rr.class == NONE)
		if (rr.type == SOA)
		     next [rr]
		if (rr.type == NS && rr.name == zname &&
		    zone_rrset<rr.name, NS> == rr)
		     next [rr]
		zone_rr<rr.name, rr.type, rr.data> = Nil

-- 
Andreas Gustafsson, gson@nominum.com

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>