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

From: Dave Crocker <[email-masked]>
Date: Fri, 11 May 2018 12:57:18 -0700

Folks,

G'day.

The latest wg's agreed approach for the Attrleaf specification is to 
have a clean-sheet document that does /not/ reflect the problematic 
history, with a companion specification that does.  That is, the first 
document is to specify the registry as if there were no history of 
independent _underscored names (other than creating registry entries for 
those existing node names.)  The current draft-ietf-dnsop-attrleaf 
specification provides the clean-sheet approach.  I think it is within 
epsilon of doing what we've agreed it should do.

That leaves the messiness of dealing with the many documents that 
created that _underscored history and the requisite cleanup of it, for a 
companion document.  The document just announced (attrleaf-fix, cited 
below) serves that purpose.

I tried to make the document complete in terms of structure AND detail. 
While I think the structural approach of the draft is reasonable, I 
don't believe for all the detail that's needed is there.

For working group review, I suggest folk consider the draft in terms of 
3, basic concerns:

    Clarity:  Does the draft adequately explain its purpose and
              adequately explain its approach for satisfying that purpose
              (separate from its whether it achieves that goal well
              enough?)

    Efficacy: Does the draft's approach seem sufficient to it's task?

    Completness:  Does the draft have all of the necessary detail and is
              all that detail correct?

I'm quite sure the document is /not/ complete and strongly encourage 
careful commentary on-list or off, so we can remedy this.

But please also consider the first two points, especially for a reader 
who does not already have deep background in this topic.

Thanks.

d/

-------- Forwarded Message --------
...
A new version of I-D, draft-ietf-dnsop-attrleaf-fix-00.txt
has been successfully submitted by Dave Crocker and posted to the
IETF repository.

Name:		draft-ietf-dnsop-attrleaf-fix
Revision:	00
Title:		DNS Attrleaf Changes: Fixing Specifications with _Underscored 
Node Name Use
Document date:	2018-05-03
Group:		dnsop
Pages:		13
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-dnsop-attrleaf-fix-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/
Htmlized:       https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-fix-00
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-fix

Abstract:
    Original uses of an _underscore character as a domain node name
    prefix, which creates a space for constrained interpretation of
    resource records, were specified without the benefit of an IANA
    registry.  This produced an entirely uncoordinated set of name-
    creation activities, all drawing from the same namespace.  A registry
    now has been defined.  However the existing specifications that use
    _underscore naming need to be modified, to be in line with the new
    registry.  This document specifies those changes.  The changes
    preserve existing software and operational practice, while adapting
    the specifications for those practices to the newer _underscore
    registry model.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Warren Kumari <[email-masked]>
Date: Fri, 11 May 2018 18:28:00 -0400

> epsilon of doing what we've agreed it should do.

​I'm going to be rude and not answer any of the below questions -- instead,
I'm going to mention "SMTP MTA Strict Transport Security (MTA-STS)
draft-ietf-uta-mta-sts" (which completed IETF LC, etc a while back).

This document uses the label _mta_sts:
The MTA-STS TXT record is a TXT record with the name "_mta-sts" at
the Policy Domain.  For the domain "example.com", this record would
be "_mta-sts.example.com".

I'm mentioning it so that, when we have a registry, just
like _acme-challenge is mentioned in draft-ietf-dnsop-attrleaf/, we can add
it.

W

> ....
> https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-fix-00
> Htmlized:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 May 2018 15:48:08 -0700

On 5/11/2018 3:28 PM, Warren Kumari wrote:
> I'm going to be rude and not answer any of the below questions -- 
> instead, I'm going to mention "SMTP MTA Strict Transport Security 
> (MTA-STS) draft-ietf-uta-mta-sts" (which completed IETF LC, etc a while 
> back).
> 
> the Policy Domain.  For the domain "example.com <http://example.com>", 
> this record would
> be "_mta-sts.example.com <http://mta-sts.example.com>".
> 
> like _acme-challenge is mentioned in draft-ietf-dnsop-attrleaf/, we can 
> add it.

Warren,

As rudenesses go, that was entirely too constructive.  Try harder.

While it doesn't have an RFC number yet, we are far enough from 
publication for our document to make me think it will have a number by 
then.  As such, it merely needs to get added to the 'updates' set.

And as such, it means that you responded to the third question.

So yeah, try harder.

Oh, and thanks for the quick attention!

d/

---

From: "John Levine" <[email-masked]>
Date: 11 May 2018 22:41:23 -0400

>    Completness:  Does the draft have all of the necessary detail and is

I think it's pretty good.  I'd change all of the SHOULD to MUST, as in
you have to do this if you want to interoperate.  (You don't have to
do it if you have a private agreement, but private agreements are out
of the scope of standards.)  

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.

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
valid.  If you want to use SRV records for a different protocol, you
have to register its name.  The registry is "Protocol Numbers" rather
than Assigned numbers, and you might want to add a pointer to it,
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

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

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sat, 12 May 2018 11:21:18 -0700

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

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.

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

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

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

d/

---

From: "John R Levine" <[email-masked]>
Date: 12 May 2018 16:01:11 -0400

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.

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

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

Oops, never mind.

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

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

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

---

From: Dave Crocker <[email-masked]>
Date: Sat, 12 May 2018 21:48:55 -0700

On 5/12/2018 1:01 PM, John R Levine wrote:
> 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.

Avoiding naming collisions is a form of interoperating.  Perhaps 
unfortunately, we have extensive experience that failing to coordinate 
across independent efforts -- ie, failing to have a common registry -- 
does not cause immediate failure.

My current thought is that the draft's language should direct a MUST for 
'published' specifications.  This would implicitly leave private, 
developmental efforts free to experiment without registration.

> reasons.  This is why I don't understand the difference any more.

Oh?  They do?  And it isn't because the MUST should have been a SHOULD? 
And it isn't because those good reasons aren't really all that good? 
And it isn't because...

You offer your summary assessment without any detail, but apparently 
intend it to negate the clearly-defined semantic distinction and usage 
intent behind the two normative choices.

It's entirely possible that some specification writers or working groups 
have been sloppy.  And there are are other possibilities.  None of which 
justify ignoring the meaning and purpose of the normative choices.

I suggest, instead, that the working group should consider what the 
force and import of a MUST would be, versus the force and import of a 
SHOULD, and that it do that on the assumption that the terms mean what 
they are defined to mean and should be used as they are intended to be used.

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

OK, but absent your suggesting specific text, I don't know what will 
satisfy.

> I suppose that's OK.  Do we have any idea of what the handful of URIs in 

I don't.

Does anybody in the working group know the details of current URI RRset 
usage?

d/

---

From: "John R Levine" <[email-masked]>
Date: 13 May 2018 11:27:15 -0400

> developmental efforts free to experiment without registration.

Sure.  Like I said, private arrangements don't count.

> I suggest, instead, that the working group should consider what the force and 
> import of a MUST would be, versus the force and import of a SHOULD, and that 
> it do that on the assumption that the terms mean what they are defined to 
> mean and should be used as they are intended to be used.

As best as I can tell, MUST means you have to do this to interoperate with 
strangers.  SHOULD means the same thing except that if you're an expert, 
there might be places you can cheat and interoperate with strangers 
anyway.

> OK, but absent your suggesting specific text, I don't know what will satisfy.

The natural place to put it is at the top of section 2, before the 
descriptions of the different meainings of underscore names for various 
rrtypes.

I don't know how philosophical to get here.  As far as I can tell there 
are three models of _name use.

1.  The contentious one, instead of a new rrtype, _dmarc and _acme-challenge.

2.  To import a different namespace into the DNS as in SRV, URI, TLSA, and
    badly in SMIMEA and OPENPGPKEY.

3.  To delimit a sub-namespace for _domainkey and _vouch.  Think of how
    foo.bar._domainkey.example.com differs from
    foo._domainkey.bar.example.com.

I don't think we need to put any of that in the draft.  I'd suggest adding 
this at the top of section 2, before the section header 2.1:

The interpretation of an underscore label is specific to the RRTYPE that 
it names, and a name such as _example might or might not be used the same 
way with different RRTYPEs.  The sections below describe the way that 
existing underscore labels are used with the RRTYPEs that they name.

R's,
John