Re: [art] draft-ietf-dnsop-attrleaf

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

Cullen,

IIR, we introduced the concept of a "recognized standards
organization" (note "recognized", which is important) with media
types, deliberately left it vague, and did so for one primary
reason.  At least in the media type case, there were issues of
probably-legitimate registrations in which it was clear that the
IETF had absolutely no expertise as to the substance or subject
matter of such a request.  As an extreme example, if an
international body responsible for chemical names or plant
taxonomy wanted to establish a media type to be consistent with
the terminology rules they were setting, having amateurs (at
best) in the IETF try to second-guess their decisions was a
rather strange idea and probably an unprofessional and insulting
one.  Sadly, experience indicates that we might try, possibly
proving the value of adages such as a little knowledge being a
dangerous thing.  Our (quite explicit) assumption was that the
IESG would need to figure out who was and was not a recognized
SDO.  More on that below.

An important part of the idea is that "recognized SDO" was an
alternative to another, IETF-centric process.   While I don't
think we ever documented it (perhaps deliberately --- I don't
remember), the IESG can always say "no" on the basis that the
IETF is fully qualified to evaluate a particular request or
family of requests and should do so.   At the same time, we
understood and recognized that, if some standards body out there
was well-established and more recognized in it own field and
area of expertise, IETF decisions that were inconsistent with
theirs were likely to be ignored or, worse, lead to inconsistent
and competing standards used by different sub-communities.  All
a matter of tradeoffs.   Whether the IESG can get them right or
not, we don't have any body or mechanism that would be likely to
consistently do much better.

Whether we got the principle and its expression right is another
question -- it is a bit of a subjective notion and the IETF and
IANA should probably have some input into whether the
request/application conforms to whatever we have decided is
needed for a request to be complete.   We also concluded, after
considerable discussion, that what was and was not to be
"recognized" should be left to IESG discretion on a case-by-case
basis rather than descending into the rathole of trying to lay
out criteria and cover even most of the edge cases.   Perhaps
not a perfect solution, but we had the expectation that the IESG
could do, or arrange to have done, a certain amount of due
diligence and make an acceptable (and conservative) decision.
One of the important properties of most identifiers or type
encodings is stability and we were also aware of the potential
for DoS attacks in this area.  We thought it was reasonable to
trust the IESG to distinguish between established bodies that
were likely to be around and ad hoc arrangements and between
legitimate bodies and, e.g., the Fraternal Order of Trolls or
other potentially-hostile parties and even to sort out
situations in which there were multiple claimants to be the
recognized international standards body in some particular area.
It did not appear to us that debating those issues on the IETF
list would be helpful, especially given that possibility of DoS
attacks and the ease with which conversations on the IETF list
in which there is little expertise but many opinions converse on
N/S ratios with near-infinite values.

All of these differs from "specification required" because it is
expected that some authoritative and consensus body take
responsibility for (and be accountable for) the substantive
content of that specification.   If it isn't working that way,
that is a problem with the IESG's implementation of the
principle, not the principle itself.

Whether that principle, and rules derived from it, are
appropriate for a particular case is another issue.  We used it
very recently in RFC 8141 and I don't recall significant
concerns.  I don't have an opinion as to whether it is
appropriate for this particular draft, just that we should not
abandon the concept of recognizing work by other standards
bodies in their area of expertise because of a perception that
it doesn't work.  It has worked in a number of important cases
and continues to do so.

    john



--On Friday, July 28, 2017 08:56 -0600 Cullen Jennings
<[e-mail]> wrote:

> The IANA registration policy of  "or are documented by a
> specification published by another    standards organization"
> seems very undefined to me and hard for IANA to execute. Could
> you give specific advice on what is a standards organization? 
> 
> I have seen previous efforts to to this and eventually it
> comes up looking more or less the same as our usual
> "specification required".