Re: [apps-discuss] Review of draft-ietf-appsawg-rfc3536bis-04

[John C Klensin <[e-mail]>]

--On Friday, July 01, 2011 12:24 -0400 Andrew Sullivan
<[e-mail]> wrote:

> Dear colleagues,
> 
> As usual, a day late and a dollar short, but I have reviewed
> draft-ietf-appsawg-rfc3536bis-04.  I support its publication.
> I have some items that might conceivably be addressed, but I
> don't think any of them is a show-stopper.  I sent nits I
> observed directly to the WG draft editors.

Thanks for the nits.  A few comments on your comments below,
with the understanding that we are waiting for detailed feedback
from the IESG at this stage (and that Paul has the pen on this
cycle).

> First, in section 1.1, we have this:

>    The definitions here should be used by IETF standards that
> want to    use them.  IETF standards that explicitly want to
> create different    definitions for the terms defined here can
> do so, but the terms    here should be considered the default
> for IETF standards after the    time of publication of this
> document.  
> 
> Obviously, the draft can't constrain what other documents
> might do. But it would be nice to encourage other documents,
> if they're going to come up with different definitions, to use
> different words.  If someone decided to re-define SHOULD at
> the beginning of their standards document, we would quite
> justifiably complain, & I think the same goes here.  I suggest
> the following additional sentence: 
 
>     IETF standards that want different definitions are
> encouraged, for     clarity's sake, to find terms different to
> the ones defined here.

In drafts of this document up this stage, we have tried to
preserve the informative/ descriptive/ persuasive tone of RFC
3536 while pushing in the direction I think you are encouraging.
Some IESG members have pointed out that the document doesn't
sound normative enough to be a BCP.  In retrospect, trying to
circle around the issue (for which I am more to blame than Paul)
was probably unwise.  Depending on what the IESG has to say
(i.e., what Pete tells us), we are contemplating rewriting that
explanation into RFC 2119 language and simply saying that these
definitions SHOULD be used in IETF documents and that, if people
choose to not use them, they MUST define the terms they are
using exactly and preferably use terminology that does not
overlap.

Your thoughts on whether that is a good strategy would be
welcome.

> Second, why isn't "LDH label" in section 7 instead of section
> 6, especially since LDH is also mentioned at the beginning of
> section 7?

Sort of a judgment call.   Remember that "LDH label" and its
variants have been used pretty extensively in non-IDN DNS
terminology to describe labels that meet the "preferred name
syntax" criteria of RFC 1034, i.e., to distinguish those
preferred-syntax strings from binary labels and ASCII labels
that contain spaces, symbols, or C0 characters.   The term was
invented when it became clear that "hostname" was sometimes used
as a synonym for the preferred name syntax, sometimes to refer
to the first label component of an FQDN, and sometimes to refer
to an FQDN that was associated with certain RR types.   "LDH
label" is at least clear about which of those cases is intended.

Speaking personally (I haven't consulted Paul), my preference
for this term and a few others would be to take the definition
out of this document entirely, instead referring to a document
that provide normative definitions for terminology used with the
DNS.  If such a document existed, those terms in this document
could be reduced to a list and a reference, much like the list
in Section 7.1.   I can only offer my condolences on the state
of that document, but holding 3536bis (or anything else) up
waiting for it seems unwise.

> The last sentence of the first paragraph of section 8 says,
> "It is likely that additional terms will be added as this
> document matures." Presumably, if the draft is published that
> sentence should be removed.

Although it could be read as anticipating further revisions to
this document over the long term, I agree that it is confusing
at best.

best,
    john