Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-fix-00.txt

[Dave Crocker <[e-mail]>]

On 5/11/2018 7:41 PM, John Levine wrote:
>     I'd change all of the SHOULD to MUST, as in
> you have to do this if you want to interoperate.  

The working group should consider the choice of normative level, but 
where I landed is that a MUST is not needed and actually could be 
counterproductive.

Having an entry in the registry probably does facilitate 
interoperability at scale, but it isn't (always) required for it.  What 
it /is/ required for is avoiding naming collisions.

Consider the long history of email header fields that weren't registered 
but which interoperated quite nicely...

 >                               (You don't have to
 > do it if you have a private agreement, but private agreements are out
 > of the scope of standards.)


I don't see the basis for saying that private agreements are out of 
scope, on the matter of registration.

The best I can guess is that there is an underlying assumption that 
normative language only applies to formally published specifications, 
but there's nothing in the current draft language to support that.

Note that SHOULD really is the same as MUST, except it allows for a 
'unless you really know what you are doing'.  That, it seems to me, is 
exactly right, for this issue.


> In section 1 you might want to add a sentence or two pointing out that
> every rrtype has its own _name namespace, something that took a lot of
> us quite a while to figure out.

I'll urge not doing that.  Yes, it's a mathematical truth, but it's one 
that I believe some/many other folk will find confusing in practical 
terms.  (I know I certainly did...)


> In section 3.1 on SRV it says about Proto "any name defined by
> Assigned Numbers or locally may be used (as for Service)."  Urrgh.
> I'd say that any protocol whose name is in the attrleaf registry is

You appear to have quote the portion introduced with:

    "The text of that specification is hereby updated from:"

which is taken from the existing SRV specification, and appear to have 
missed the 'from', rather than focusing on the next set of text, 
introduced with:

    "The updated text is:"

which does not contain the text you find problematic.


> For URIs, I'd add all of the existing enumservice type names to the
> draft-ietf-dnsop-attrleaf initial name list in section 3.1, and in

I'll guess that you mean the existing entries in the 'type' column of:

    https://www.iana.org/assignments/enum-services/enum-services.xhtml

which appears to be:

    acct
    email
    ems
    fax
    ft
    h323
    iax
    ical-access
    ical-sched
    ifax
    im
    mms
    pres
    pstn
    pstn
    sip
    sms
    unifmsg
    vcard
    videomsg
    voice
    voicemsg
    vpim
    web
    xmpp

which seems quite a lot of pre-loading, for an RR that has almost no 
use, so far.  I would instead suggest pre-loading only those 'type' 
values we know to be already in use and press for additional entries 
when they will get used.

This is what we've done for Proto, so why not the same approach for 
enumservice?


> this draft add a note that any new enumservice types added MUST be
> added to this registry if URIs can refer to them.  There's currently
> 24 type names.  It happens that none of them collide with other top
> level names but since they only apply to URI it wouldn't matter if
> they did.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net