On Tue, Jul 14, 2015 at 1:53 PM, Ted Lemon
<ted(_dot_)lemon(_at_)nominum(_dot_)com> wrote:
On 07/14/2015 01:28 PM, Ted Hardie wrote:
Given that the point of IETF Last Call is to determine if there is IETF
consensus on the working group's analysis and proposal, I find
"inappropriate" an odd choice of words here. The IETF as a whole may have
a different sense of the trade-offs here.
It's certainly appropriate for people who aren't DNSOP participants to
weigh in here, and for DNSOP participants to raise new issues that the
working group missed. But it seems bogus to me for DNSOP participants to
raise the same issue here that they raised in DNSOP and that didn't get
consensus. I believe you are a DNSOP participant,
Not generally, no. I have commented on specific issues in the past, but I
certainly did not on this issue.
but perhaps I am mistaken. I think you and at least one other person
read my comment as saying that once the working group has consensus, that's
the end of it, but that wasn't my point. My point is simply that it would
be useless and harmful to the IETF for DNSOP participants to waste the
collective attention of the IETF re-arguing points that already got
consensus in DNSOP.
I think George's post, assuming he is a DNSOP participant, was along the
lines "In the working group, I am in the rough, and I am not appealing
that. Here, however, is my reasoning so that the broader IETF understands
it".
If we didn't allow that, we would never allow positions that were discussed
in the working group to be aired on the IETF list, which requires
non-participants to discover them independently. While that would be a
great signal when it happened, I think saying only the consensus position
should be represented to the IETF is wrong. It just should not claim to be
either un-addressed by the working group if has been or to be the consensus
when it is not.
This is a perennial problem in the IETF. Of course, now we will have a
long argument about the appropriateness of my interjection here instead,
but I'm not convinced that that's worse.
I have a great deal of respect for the folks in DNSOP, and a similar
amount for those who created and TOR. But I believe that this approach to
segmenting the namespace for protocol resolution does not scale well. I
would far prefer a notation that onion addresses can appear in the
authority section of URIs without them being DNS names, something that RFC
3986 allows with the registered name syntax.
I don't see how that helps: if they can appear in URIs, then we still need
to mark that special-use TLD as in use.
Not necessarily; if you minted a URI scheme for them, you could use
something like the overlay-node-id
<https://www.ietf.org/archive/id/draft-hardie-p2psip-p2p-pointers-01.txt>
proposal (forgive me for posting an expired draft that I authored, but
it's the quickest example for me to find). I'm not arguing for that,
though; I'm saying that using the TLD slot for protocol processing
instructions scales badly and we should not do it.
Stephane argues that we did once, with .local, and the die is thus cast,
but I don't think that was the Rubicon, and I know we are not Caesar.
Ted