Subject: Re: [dnsext] [dane] TLSA == RRtype 52

From: Andrew Sullivan <[email-masked]>
Date: Mon, 16 Apr 2012 15:59:34 -0400

This is really a discussion about an issue for the DNSEXT WG, so it's
cc:d there.  Follow ups should go there, too, unless they're linked
tightly to the DANE issue.  I didn't adjust the Followup header
because in my experience that never works.

On Mon, Apr 16, 2012 at 03:24:22PM -0400, Olafur Gudmundsson wrote:
> But the application in this case referenced a particular version of an
> Internet draft:

Yes.  This is why some people have objected to the difficulty of
getting the approved templates.  The template as in the application is
not necessarily what was approved.  I think in this case it is, but as
we see the registry does not actually preserve the link.

> If there are changes in the registries that are created by the ID
> that is fine.
> Type codes are cheap, interoperability problems are not.

Yes.  Which is rather a good reason to hesitate to ship code that
doesn't have a stable refernence in the registry, if you ask me.

> There is code range for experimentations, see RFC6195 section 2.3
> 	   0x0F01 - 0x0FFF     Private Use

Yes, I'm perfectly aware of that.  The complaint has been that people
want to be able to ship things with what they regard as minor
differences without having to go through the DNS mafia again.  Like it
or not (I'm in the "not" camp), people are engineering around our
community's intransigence.

> Andrew I hate to correct you, the whole point of early allocation
> was to avoid having to publish an standards track RFC in order to
> get
> an RR type code.

That could be better achieved by "specification required".  Expert
review allows us to allocate a type code without any guarantee that
the wire format will remain stable.  There is exactly one way to
guarantee that such a wire format will remain stable, and that is to
publish something in an archival series.  We have a way to do that:
publish an RFC.  Requiring conformance with RRTYPE application
templates or anything else is nonsense, because the references aren't
stable.  This is in fact a much more serious example of the same fight
we had when we tried to be clever with the registry in the
registry-fixes attempt some time ago.  (In that case, I happened to
think we were right, but the objection rested on the same foundation:
if you want a stable reference, put it in an RFC.)

> what is wrong with using 0xf?? values for that ?
> 
> all you need to do is to send a email to the wg mailing list saying
> "I want to do an experiment and we will use code X here is my format."
> the private RRtype either contains version number or you roll the
> code each time there are wire format changes. In this case only
> consenting implementations are at risk.

Nothing, of course.  I have no idea why people even want RRTYPE
assignments prior to publishing an RFC with the specification, but
people do.

> If a simple building block like DNS record format needs to change
> during IESG review, the whole WG effort is suspect and it should be
> sent to back to the drawing board.

I fully agree.  But it is one thing to say, "This sure hadn't better
change.  If it does, something is really wrong," and quite another to
say, "This can't possibly change."

Best,

A

-- 
Andrew Sullivan
[email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 Apr 2012 14:55:53 -0700

>> But the application in this case referenced a particular version of an

We applied in good faith, assuming that our application was for the protocol, not a single draft. If the DNSEXT WG chairs felt that we should wait until the draft could not have any wire changes, the DNSEXT WG chairs should have told us that at the time of the application.

The registration at IANA does not name the draft; it lists the name for the DANE WG chair who applied for code point. A sensible interpretation of that is "the person who is named gets to decide what the code point means", not "go ask that person which draft he applied for". If given a choice between what one co-chair and IANA thinks, versus the other co-chair, I hope most people pick the former.

This would not be an issue if a DNSEXT co-chair (Olafur) had not exhorted people to implement using the assigned code point even though the spec is not stable. In that message, he (wisely) did not say "implement only the -18 draft, and we might screw you over later if the spec changes". Most developers care about implementing a stable spec. The spec will be stable when the IESG sends it to the RFC Editor, hopefully in a few weeks. If a developer wants, they can use the code point now; nothing stops them other than the desire to ship stable code.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 16 Apr 2012 19:07:42 -0400

A small process nit

> We applied in good faith, assuming that our application was for the protocol, not a single draft. If the DNSEXT WG chairs felt that we should wait until the draft could not have any wire changes, t…

The management of RRTYPE allocation is not up to the DNSEXT chairs,
perhaps surprisingly.  The expert review and assignment rules happen
to use an expert panel that involves one of us (me) for administrative
convenience, and happen to use this mailing list for discussion.  But
as a formal matter, the WG's opinion about a draft is not taken into
consideration, and there is no formal process link to the WG.  We
picked the dnsext WG's list in the past on the general principle that
the WG's list is likely the place where people interested in these
things can be found.  Indeed, had we not completely lost access to
moderation and so on, we might well have left the list name as
[email-masked].

Again, I think this is all a formal matter.  Naturally, if a large
number of people on this list expressed reservations about an
allocation, the expert would no doubt take that into consideration.
(For similar reasons, I do not actually believe that there will be any
change in the wire format of the RRTYPE when it goes through the
IESG.  As a practical matter, the wire format is almost certainly
stable.  As a formal matter, though, we cannot assume that.)

Best,

A

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 17 Apr 2012 01:17:40 +0200

> because in my experience that never works.

<dane chair hat on>
Yes, please keep the further discussion off this list.  And everybody
please cool down before responding, or rather do not respond here at all.
</dane chair hat off>

<personal hat on>
Feel free to do whatever you want, but please be aware, that we have
not reached the RFC status yet.  So same rules applies as when you were
using "experimental" allocations in your code.  E.g. if you have tools
which used TYPE655xx, then feel free to use TYPE52, but clearly mark
that as experimental feature, which can change.
</personal hat on>

O.
--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------