I'm a little confused, since I see a message from Warren on 6 Dec saying
that the call would be extended until tomorrow. I admit that I have not
been following this discussion closely, though.
In case the window for comments / proposals is still open, my only insight
here is that usages 0/1 are very much like the "pinning" work being done in
draft-ietf-websec-key-pinning, so it might be helpful to re-use that term
here. For 2/3, it seems like people I've talked to understand the verbs
"assert" (since that's what the domain holder is doing) or "trust" (since
that's what the recipient is being asked to do).
0 - PIN-CA
1 - PIN-EE
2 - ASSERT-CA or TRUST-CA
3 - ASSERT-EE or TRUST-EE
So that's my favorite color for the bike shed.
--Richard
On Tue, Dec 10, 2013 at 2:42 PM, Viktor Dukhovni
<[email protected]>wrote:
> On Tue, Dec 10, 2013 at 10:37:50AM -0500, Warren Kumari wrote:
>
> > We understand that these names are not perfect and do not please
> > everyone. Despite that, there is sufficient value in the document
> > and we believe it will aid discussion and (hopefully) deployment.
> > This will also allow us to move on and discuss things of more
> > substance.
> >
> > If you are still concerned that this document might cause the
> > sky to fall, mail the list, and our AD will review when doing the
> > AD review. There is also IETF LC, so we have another chance to
> > discuss this, this time in a more public setting? :-P
>
> So long as server operators understand that PKIX-TA is not a TA,
> and DANE-TA actually employs PKIX, and are not mislead into publishing
> incorrect records, all is well. The names could equally well be
> "Chico, Harpo, Groucho and Zeppo".
>
> I also hope that future implementors will have read the standard
> thoroughly and will have thought carefully about how to validate
> each of the four usages and will not be misled by the acronyms'
> false dichotomy.
>
> This said, the names are reasonably memorable, so I guess we can
> hope that their use will promote ease of discussion without creating
> confusion. I am too steeped in the details now to know whether I
> would have been confused initially.
>
> --
> Viktor.
> _______________________________________________
> dane mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dane
>
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
