Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)
draft-daigle-unaptr-02

IANA Last Call Comment:

As stated in the IANA Considerations section, IANA understands
this document to have no IANA registry creation or registration
actions.

However, IANA further understands that this document provides
the basis upon which U-NAPTR-using services can make use of
the existing IANA registries for application service tags and
application protocol tags. The IANA understands that the rules
for registration of application service tags and application
protocol tags has already been specified in RFC3958. Upon
approval of this document, the registry located at:

http://www.iana.org/assignments/s-naptr-parameters

will be updated to reflect the registration requirements
outlined in RFC3958 and in section 5 of the approved document.

[Ballot comment]
Section 1., paragraph 2:
>    Although defined as a new DDDS application, dubbed U-NAPTR, this is
>    effectively an extension of the Straightforward NAPTR (S-NAPTR)
>    application, specified in [3].

  Does it update [3]? If so, add to the first page boilerplate.

[Ballot discuss]
Section 8.1., paragraph 6:
>    [5]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
>        One: The Comprehensive DDDS", RFC 3401, October 2002.

  DISCUSS: Is a DOWNREF (PS->Informational).

[Ballot comment]
I wonder how many times you have to repeat that 'U-NAPTR is effectively an extension of S-NAPTR' before the reader gets it ;-):

In 'Abstract':

Although defined as a new DDDS application, dubbed
U-NAPTR, this is effectively an extension of the Straightforward
NAPTR (S-NAPTR) DDDS application.

In 'Introduction':

Although defined as a new DDDS application, dubbed U-NAPTR, this is
effectively an extension of the Straightforward NAPTR (S-NAPTR)
application, specified in [3].

...

This U-NAPTR is effectively a modest extension to S-NAPTR, to
accommodate the use of URIs as targets, without allowing the full
range of possible regular expressions in NAPTR records.


And in section '2.2.  Permitted Regular Expressions':

With this limited form of regular expression, applications using
U-NAPTR need not implement full regular expression parsers.

I might would have nearly shipped my implentation with a complete regular expression library! I am glad the following text explains that a limited form of regular expressions means that I only have to implement
a limited form of regular expressions ;-).

[Ballot discuss]
Please add explicit references in the security considerations to the
  S-NAPTR security considerations described in RFC 3958 Section 8 as
  well as URI security considerations included in RFC 3404 Section 8.

[Ballot comment]
1. The text in the Introduction section seems to indicate that this document updates RFC 3858. If this is accurate, the header of the document should indicate 'Updates RFC 3858 (if approved)

2. I could not find in the docunent any use of capitalized keywords although the introduction mentions RFC 2119, and the Normative References section includes it