Re: Minor editorial change to draft-ietf-dnsop-sutld-ps

[Suzanne Woolf <[e-mail]>]

(not sure which hat. Probably doc shepherd.)

> On Jul 4, 2017, at 9:23 AM, Ted Lemon <[e-mail]> wrote:
> 
> On Jul 4, 2017, at 3:39 AM, Randy Bush <[e-mail]> wrote:
>> is there a companion document with the list of benefits/advantages?  or
>> is thins just one of those ietf documents from on high meant to kill
>> something?

> 
> This is a very good question. We weren’t asked to answer that question, so we didn’t.  It is assumed throughout the document that various proponents of special use domains have good reasons for wanting them, and further that it is already accepted in principle that if their reason for wanting them is valid, they can have them (modulo technical constraints like delegation). So we didn’t delve into that. But perhaps we should have. 

I’d go a step further: RFC 6761 alludes to some general reasons, but assumes people who’d go through the IETF standards process or an IESG approval process to get an entry in the special use names registry have good enough reasons that the special handling requested should be accepted as part of the DNS protocol. (I’m one of the people who isn’t comfortable with this assertion, but we’re living with what RFC 6761 says, not what I think it should have said.) 

That is, RFC 6761 leaves to other processes to assess the value of the request and the reasons offered, but strictly speaking doesn’t require them to be documented or evaluated; required documentation for the registry entry consists mostly of assessing how it interacts with the DNS, not its primary use. (Sec. 4 starts by saying “If it is determined that special handling of a name is required in order to implement some desired new functionality,” the registry entry policy applies, but openly avoids describing how that determination should be made.)

This isn’t really strange— plenty of registries don’t require any particular discussion of the merits of an entry; ISTM that “standards action” presumes such evaluation as part of IETF consensus. But it does seem like a significant part of the observed problem— there are only subjective and ad hoc bases for evaluation for a request that’s not otherwise justified by a standards track document, leading to endless repetitions of discussions like whether a new CLASS would be a “better” way to solve a problem that isn’t actually documented in the request.

I think the observation that people aren’t really required to document what problem they are trying to solve with their special use name is in the draft, but perhaps could be more explicit. 

Some few people already have been convinced that there should be some general guidance available for making the determination that a domain name requires special handling in the DNS. But that also seems to be a different document.



Suzanne