The Role of Wildcards in the Domain Name System
draft-ietf-dnsext-wcard-clarify-11

[Note]: 'The PROTO shepherd for this document is Olaf Kolkman .  2/10/06:  The author wants to do an update based on IESG comments.  Waiting for new version with updates.' added by Margaret Wasserman

[Ballot comment]
I was very close to putting a DISCUSS on this document after my own review, the comments that I read by other ADs and the reviews that I received from Pekka Savola frm the Ops Directorate.

I don't believe any of the issues that are brought up are blocking from an indvidual point of view, but the collection of issues is large enough that I would very much appreciate an update to this document before sending it to the rfc editor although I will not require it.

Please see below for the comments that I received from Pekka Savola from the Ops Directorate:

This seems to be in an OK shape, though personally I'd probably have           
organized it in a slightly more different way.  But there is one thing         
I don't understand from the closest encloser spec and example.  Maybe         
someone (Rob?) can explain whether the closest encloser definition is         
lacking or I'm just not getting something?                                     
                                                                               
section 3.3.1 says:                                                           
                                                                               
      The closest encloser is, by definition, an existing name in the         
      zone.  The closest encloser might be an empty non-terminal or even       
      be a wild card domain name itself.  In no circumstances is the           
      closest encloser to be used to synthesize records for the current       
      query.                                                                   
                                                                               
.. section 2.2.1 has,                                                         
                                                                               
        host1.example.          3600    A    192.0.4.1                     
        _ssh._tcp.host1.example. 3600    SRV                       
        _ssh._tcp.host2.example. 3600    SRV                       

.. and section 3.3.2 says:                                                     
                                                                               
      QNAME                      Closest Encloser    Source of Synthesis     
      host3.example.              example.            *.example.               
      _telnet._tcp.host1.example. _tcp.host1.example. no source               
      _telnet._tcp.host2.example. host2.example.      no source               
      _telnet._tcp.host3.example. example.            *.example.               
...                                                                           
                                                                               
==> I don't understand why the closest encloser of                             
'_telnet._tcp.host2.example.', using the definition above, is not             
_tcp.host2.example.com. -- the definition says that it can be an empty         
non-terminal which '_tcp.host2.example.com.' as well as                       
'host2.example.com.' seem to be unless I'm mistaken.                           
                                                                               
Did I miss something?  If not, should the definition of the closest           
encloser be more restricted (if the example is correct), or the               
example changed?   

mostly editorial comments                                                     
-------------------------                                                     
                                                                               
..................                                                             
                                                                               
==> the ID-nits tool says:                                                     
                                                                               
  * There are 5 instances of too long lines in the document, the longest       
    one being 2 characters in excess of 72.                                   
                                                                               
==> multiple times, you use both 'wild card' and 'wildcard'.  If there is no   
specific reason for this, I'd pick one and apply it consistently.             
                                                                               
      of wild card domain names, but the restriciton as stated still           
                                                                               
==> s/restriciton/restriction/                                                 
                                                                               
        host1.example.          3600    A    192.0.4.1                     
                                                                               
==> s/192.0.4.1/192.0.2.1/ (so it's a valid RFC3330 address..)

          The domain name space is a tree structure.  Nodes in the tree           
      either own at least one RRSet and/or have descendants that               
      collectively own at least one RRSet.  A node may exist with no           
      RRSets only if it has descendents that do, this node is an empty         
      non-terminal.                                                           
                                                                               
==> the last sentence might read better with slight rewording after ',' or     
replacing "," with a ";".                                                     
                                                                               
      Comments on this document can be sent to the editor or the mailing       
      list for the DNSEXT WG, namedroppers@ops.ietf.org.                       
                                                                               
==> remove?  This probably won't be relevant 10 years from now, and I don't   
think this kind of info has typically been put in RFCs (though it has been     
recommended for I-D's)                                                         
                                                                               
      E.g.,  If an SRV record is:                                             
        _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.

      *.example is a wild card domain name and although it is the Name         
      of the SRV RR, it is not the owner (domain name).  The owner             
      domain name is "_foo._udp.*.example." which is not a wild card           
      domain name.                                                             
                                                                               
==> it might be useful to actually spell out what the answer would be for a   
query such as '_foo.udp_.bar.example. SRV' -- you're not saying it             
right out.                                                                     
                                                                               
9. Others Contributing to the Document                                         
                                                                               
      This document represents the work of a large working group.  The         
      editor merely recorded the collective wisdom of the working group.       
                                                                               
==> is this an 'Acknowledgements' or a 'Contributors' section?  In any         
case, both courtesy and legalese *) IMHO call for a bit more explicit         
list of contributors and/or acknowledgees.                                     
                                                                               
*) RFC3978 says:                                                               
3.4.  Representations and Warranties 

  With respect to each Contribution, each Contributor represents that         
  to the best of his or her knowledge and ability:                           
                                                                               
  a. The Contribution properly acknowledges all major Contributors.  A       
      major Contributor is any person who has materially or                   
      substantially contributed to the IETF Contribution.

[Ballot comment]
In the example on page 8, I See:
        host1.example.          3600    A    192.0.4.1
The IP address probably better be in the range reserved for
examples (as per RFC3330), nameley something like 192.0.2.1

[Ballot comment]
Non-blocking comment from Gen-ART review by Harald Alvestrand.
This could be considered if the draft is revised for some
other reason:

There is a slight logical inconsistency between section 4.2, which says it can't forbid NS records at a wildcard name because it's not clear what "forbidding" a record in the DNS is, and section 4.4, which (justifiably) says that DNAME records at wildcards shold be outlawed, without going into the same details found troublesome in section 4.2.1. But I believe the recommendations are operationally reasonable, and that's the most important thing to me.