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

["John R Levine" <[e-mail]>]

I don't want to rathole on MUST vs. SHOULD because the more I think about 
it the less I understand the difference.

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

Sort of.  Everything interoperated fine in the sense that we ignored x- 
headers that we didn't understand but the number that were created by one 
system and parsed by another is pretty small.  I can only think of x-face 
which worked because there was a clear spec even though it never made it 
to IANA.

> 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.

No, it's that standards are about interoperating with people you don't 
know.  That was the point of the two-implementation rule.  This particular 
situation is unusually squishy because we have a list of protocol names 
and a list of enumservice types that aren't in the registry but in 
practice it'd work fine if someone used one of them because none of the 
names currently conflict.

> 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.

Except that in reality people violate MUST all the time, often for good 
reasons.  This is why I don't understand the difference any more.

>>  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...)

Then it should be more than a sentence or two, long enough to explain it. 
It needs to be clear people who might register future names that if _foo 
on SRV and _foo on TXT mean different things, that's not a problem.

> You appear to have quote the portion introduced with:

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

Oops, never mind.

>>  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 ...

> 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?

I suppose that's OK.  Do we have any idea of what the handful of URIs in 
the wild actually use?

Regards,
John Levine, [e-mail], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly