wcard discussions in Minneapolis

[Edward Lewis <Ed.Lewis@neustar.biz>]

This is a summary of wcards at Minneapolis.

On Monday of IETF week an informally gathered subset of the WG 
discussed issues in detail, here is the outcome of that discussion 
(note - this is not a WG decision, but a set of recommendations that 
were then discussed in the face-to-face meeting):

1) Considering '* NS' and '* DNAME'

1A) Change the text in RFC 1034, 4.3.2, step 3, part c to this:

c. If at some label, a match is impossible (i.e., the corresponding 
label does not exist), look to see if a the "*" label exists AND DOES 
NOT OWN AN NS RRSET NOR A DNAME RRSET.

1B) Any query that would have otherwise resulted in a wildcard match 
received a "return code=name error" (NXDOMAIN) so that caches can 
retain the negative answer.

1C) The label count in the RRSIG is not decremented for the presence 
of an asterisk label if there is a NS or DNAME owned there, as this 
name is now not capable of being a source of synthesis.

2) No other issues were raised, recognizing the document had changed 
once since the last meeting.  In particular I was curious about the 
SRV text.

During the scehduled IETF meeting on Wednesday morning, this proposal 
met with a something between a "less than enthusiastic" response and 
"tomato throwing" response.  One person did indeed brandish a piece 
of fruit, although it was not a tomato and it was not rotten.  (I.e., 
it would have left a welt.)

The cry was "don't change the signer."  Instead, the prevailing 
suggesting became to "outlaw" '* NS' and '* DNAME'.

"Outlawing" would entail:

1) Defining the semantics of '* NS/DNAME' on zone loading.
2) Defining the semantics of '* NS/DNAME' in a [AI]XFR zone transfer.
3) Defining the semantics of '* NS/DNAME' in a dynamic update request.
4) Convincing anyone who make use of a '*' zone to give it up.

The discussion ranged as far as whether rejecting a zone was an 
interoperability concern.  More or less yes, as it would be good to 
have masters and slaves behave consistently even if they are 
different implementations.

What I've listed here are just the recommendations, not the 
rationale.  E.g., I still need to figure out why this applies to 
DNAME, but I'm willing to suspend disbelief for the moment while 
gathering these comments.

PS - I would like to personally thank Mr. Ihren for showing restraint 
when it came to the use of fruit in the meeting.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Achieving total enlightenment has taught me that ignorance is bliss.

--
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/>