Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/15/2015 03:55 PM, David Conrad wrote:
> 
> I'm intrigued how you derived an insult from my statement
> that it was squatting.
>

I guess that's the proximity of "blunt" and "squatting" that gave me
this impression.

> 
> You're wrong.
> 

I stand corrected.

> 
>> Indeed .onion can
>> do without caring about the DNS, but this is not the point. The point
>> is to recognize the variety of techniques within the scope of DNS so
>> that future implementations can rely on the DNS as a correct source
>> for global information about namespaces.
> 
> So, I'm now confused.
> 
> I thought the point of putting ONION in the Special Names Registry
> was to ensure that it did NOT rely on the DNS.
>

Sorry for being unclear. I meant: to recognize, within the scope of DNS,
a variety of alternate techniques (not using DNS but potentially
conflicting with it because from a user's perspective, there's hardly a
difference between this.example.sucks and facebookcorewwwi.onion)

Regards,

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVp0GzXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9MMsP+wYSAvO6FEq6ewPKQr8oSO8e
gZ+Xo6G0rV3oxmMBoDHCsjzs8ODZK5DxIhRNVpzAym9L9RGyRjMWD/iOq+X5hUMi
/9Miu6tln+TyT/fsa5Wq7IIyy3fWTLPdVikfbPx3+wFYKjb8dQOFYjPjKtC6p4g4
w8RzFeimzOKEDGhjfS5N1G45/A1jK3iFHVhjiSrYVo7W503BGByechTg+hsoB9qc
HheVWanwi25K9fdbl6XNoTt6NR0q7IeUlEmmYaNP08FeG31NS2GXP9goWsd8vjIn
zuP4m4kg/tFwbU2Sa/JWTik62cdzpTJDZrvvDFoKrL8lVzIM+2CWx69s7wPcWS65
tBTxy1RuED3Ky+7oiml2evSMOB5sQlOqjsqt9Gdv5ZssLkRVuY26XDEy20y5VxK6
1BwPRCUkoOfynT+cM12E+2ixGlVCcGNtDBQidAgeo6Jsz6iI7MgQbZXo9Sj76jVC
WMoxkqznlu2SGVSKzEhMVhtH8nsWRL4+rf2z/05ddHbIMfTLLGgf1iqY1T0OOYlZ
tLc8FSdA2P/W/ffNAYfFDJ86CZZJVwXX5VLDe04YjEEW+Fq+YLHmvUsp/u7R1a4n
ghGn33spuObvT9+2dZlCw2s82czAtOI9aig5BqNWccCVQ4vONda6MGlIohNAJ0eh
Xi8J1T4hvCmzD0uYOPqP
=VUOf
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03

[Tim Wicinski]

On 7/15/15 10:15 PM, Paul Hoffman wrote:



Not only do you agree and acknowledge that, *so does the document*.
Based on the contention and lack of consensus for some of the
definitions, the Introduction now says:

During the development of this document, it became clear that some
DNS-related terms are interpreted quite differently by different DNS
experts. Further, some terms that are defined in early DNS RFCs now have
definitions that are generally agreed to that are different from the
original definitions. Therefore, the authors intend to follow this
document with a substantial revision in the not-distant future. That
revision will probably have more in-depth discussion of some terms as
well as new terms; it will also update some of the RFCs with new
definitions.

If there is something more that can be said in the document, by all
means let us know.

--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop



Also, the document took the approach early on of documenting what 
existing RFCs said in one place.  When it became clear that what the 
RFCs say may not be how people currently use the term, the consensus in 
the working group was to document the existing definition, and flag it 
as in disagreement.  Once this document was pushed out, *then* the 
revised draft could actually update old RFCs.


As chair, I also felt that once this draft is published (and all 
contention removed), it would become something that would be part of the 
document shepherding process - to make sure new RFCs actually used 
accurate terminology.  But that may be a pipe dream.


I do think the authors have done an impressive job considering the scope 
of the document and the depth and breath of comments.


tim


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03

[Paul Hoffman]

On 15 Jul 2015, at 17:33, Andrew Sullivan wrote:


Hi,

On Tue, Jul 14, 2015 at 03:43:12PM -0400, Casey Deccio wrote:
I am also concerned about the apparent urgency to get the initial 
document
out with points that admittedly remain contentious and/or where there 
isn't
WG consensus.  I don't think it needs perfection, but it seems 
unnecessary
to get the document published without further explicitly identifying 
and

considering the standing issues.  We've haven't had this document
before--I'm not sure what the rush is now.


Just on this issue, and speaking only for myself (but as one of the
people behind this document), my view is that this WG has historically
been one of the places where documents go to die, and I am unwilling
to go through the exercise of proving again how great an enemy of the
good the perfect can be.  I'd be much more inclined to remove the
contentious definitions and publish that document than to try to get
things perfect.

I agree and acknowledge that there remain some definitions in there
that are contentious.


Not only do you agree and acknowledge that, *so does the document*. 
Based on the contention and lack of consensus for some of the 
definitions, the Introduction now says:


During the development of this document, it became clear that some 
DNS-related terms are interpreted quite differently by different DNS 
experts. Further, some terms that are defined in early DNS RFCs now have 
definitions that are generally agreed to that are different from the 
original definitions. Therefore, the authors intend to follow this 
document with a substantial revision in the not-distant future. That 
revision will probably have more in-depth discussion of some terms as 
well as new terms; it will also update some of the RFCs with new 
definitions.


If there is something more that can be said in the document, by all 
means let us know.


--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03

[Andrew Sullivan]

Sorry for the top-post. As I understand things, this is more than a "choice". 
RFC 2181 requires it, I think, no?

-- 
Andrew Sullivan 
Please excuse my clumbsy thums. 

> On Jul 15, 2015, at 06:00, John Dickinson  wrote:
> 
> 
> 
>> On 14/07/2015 17:26, Casey Deccio wrote:
>> On Tue, Jul 14, 2015 at 12:00 PM, Paul Hoffman > > wrote:
>> 
>>On 13 Jul 2015, at 14:20, Casey Deccio wrote:
>> 
>> 
>>4. In the definition of RRset, the bit about TTLs needing to be
>>the same
>>seems out of place for this terminology document.  That is an
>>operational
>>requirement.
>> 
>> 
>>Disagree. To some people, TTLs are operational, to others they are
>>part of the master file format. For the latter, this sameness
>>applies to the definition.
> 
> No, the zone file can contain different TTLs. As far as I know most 
> implementations choose to reduce the TTLs for all RRs in an RRSet to the 
> lowest value.
> 
>> 
>> What I am saying is that whether the TTLs are the same (correct) or the
>> TTLs are different (incorrect), it doesn't change the definition of
>> RRset, which is the set of RRs with the same name/class/type.  Therefore
>> the requirement that the TTL be the same is not a useful statement for
>> the definitions doc, whether it's operational or standards-based.
> 
> I agree.
> John
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03

[Andrew Sullivan]

Hi,

On Tue, Jul 14, 2015 at 03:43:12PM -0400, Casey Deccio wrote:
> I am also concerned about the apparent urgency to get the initial document
> out with points that admittedly remain contentious and/or where there isn't
> WG consensus.  I don't think it needs perfection, but it seems unnecessary
> to get the document published without further explicitly identifying and
> considering the standing issues.  We've haven't had this document
> before--I'm not sure what the rush is now.

Just on this issue, and speaking only for myself (but as one of the
people behind this document), my view is that this WG has historically
been one of the places where documents go to die, and I am unwilling
to go through the exercise of proving again how great an enemy of the
good the perfect can be.  I'd be much more inclined to remove the
contentious definitions and publish that document than to try to get
things perfect.

I agree and acknowledge that there remain some definitions in there
that are contentious.

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Joe Hildebrand]

On 15 Jul 2015, at 5:37, David Conrad wrote:

I try to be pragmatic. Given I do not believe that refusing to put 
ONION in the special names registry will stop the use of .ONION, the 
size of the installed base of TOR implementations, and the 
implications of the use of that string in certificates, I supporting 
moving ONION to the special names registry.  I really (really) wish 
there was more concrete, objective metrics (e.g., size of installed 
base or some such), but my gut feeling is that TOR is pretty well 
deployed and given the CAB Forum stuff, I see no particular reason to 
delay (after all, it's not like the deployed base of TOR is likely to 
get smaller).


I don't see any mention of the CAB Forum stuff in the draft.  Has anyone 
done the analysis to see if CAB Forum members really will issue certs to 
.onion addresses if we do this?  Do they issue certs for .example or 
.local today?


If certificate issuance is one of the key drivers for this work, there 
needs to be information in the draft that shows that this approach will 
work.


--
Joe Hildebrand

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Francisco Obispo]

Ok, good!.

In this case all we need is something that does not encourage the 
creation of these names by not following published, transparent 
guidelines.


It doesn’t feel right to me rewarding bad behavior.

Thanks again.



On 07/15/2015 02:22 PM, Francisco Obispo wrote:

Perhaps we need a registry to manage this list… IANA perhaps? with 
a process on how to manage it that runs in coordination between IETF 
and ICANN.


We already have a registry, called the special-use domain names 
registry:


http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml


Well, even worse, what happens if  decides 
to create a new dns-like protocol that uses .foo, does that mean that 
we should automatically block it?



No.   We can add it to the special-use domain name registry if the 
IETF has consensus to do so, but there's nothing automatic about it, 
as Christian Grothoff can testify.


—
Francisco Obispo
Uniregistry Inc.
On 15 Jul 2015, at 14:32, Ted Lemon wrote:

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Ted Lemon]

On 07/15/2015 02:22 PM, Francisco Obispo wrote:
Perhaps we need a registry to manage this list… IANA perhaps? with a 
process on how to manage it that runs in coordination between IETF and 
ICANN. 

We already have a registry, called the special-use domain names registry:

http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

Well, even worse, what happens if  decides 
to create a new dns-like protocol that uses .foo, does that mean that 
we should automatically block it? 


No.   We can add it to the special-use domain name registry if the IETF 
has consensus to do so, but there's nothing automatic about it, as 
Christian Grothoff can testify.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Francisco Obispo]

On 07/15/2015 01:11 PM, Francisco Obispo wrote:
Well do they want a TLD but they don’t have the money? or don’t 
want a TLD? perhaps the problem is in how the TLD program treats 
them, in which case the answer should be on the ICANN side.
As I said in the previous message, they do not want a TLD allocated by 
ICANN.   They want a special use name in the IETF RFC 6761 special-use 
name registry.




They want an entry in a reserved-list in this, case. This is similar to 
when a registry adds ‘ICANN’ or ‘WPAD’ in the reserved list so 
that no-one can register it.


Perhaps we need a registry to manage this list… IANA perhaps? with a 
process on how to manage it that runs in coordination between IETF and 
ICANN.



I don’t like setting things in stone forever, I agree with the 
assessment on “what happens if TOR ceases to exist”, but the 
answer can’t be, lets put it in an RFC where we run the risk of 
being black listed in code potentially forever. Quoting Paul Vixie on 
the 100-year cycle, in 100 years, we’ll have to wait 100 more years 
for it to be released, that will certainly create more potential 
problems.

Would you make the same point about .local?


Well, even worse, what happens if  decides to 
create a new dns-like protocol that uses .foo, does that mean that we 
should automatically block it?


What if they decide to use .local, and then there isn’t 
interoperability with mDNS. These issues are solved by namespaces, but 
in order to make them work we need to have a registry for them, where 
corporations or individuals meet a certain criteria, they apply, and if 
granted, they get an entry that gives them right of use of a name.


IETF as far as I know is not a registry.




Having this mechanism for reserving special use names, creates two 
different authorities managing the same namespace, this will require 
tight coordination as well as clear and transparent guidelines to 
make it work.
RFC 6761 already specified this.   The tight coordination of which you 
speak has occurred in this case, and will continue: the IESG is keenly 
aware of the situation, based on discussions that I was privy to and 
comments I've witnessed since I stopped being privy to such 
discussions.




Thanks



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop





—
Francisco Obispo
Uniregistry Inc.
On 15 Jul 2015, at 13:59, Ted Lemon wrote:

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Ted Lemon]

On 07/15/2015 01:11 PM, Francisco Obispo wrote:
Well do they want a TLD but they don’t have the money? or don’t want a 
TLD? perhaps the problem is in how the TLD program treats them, in 
which case the answer should be on the ICANN side. 
As I said in the previous message, they do not want a TLD allocated by 
ICANN.   They want a special use name in the IETF RFC 6761 special-use 
name registry.


I don’t like setting things in stone forever, I agree with the 
assessment on “what happens if TOR ceases to exist”, but the answer 
can’t be, lets put it in an RFC where we run the risk of being black 
listed in code potentially forever. Quoting Paul Vixie on the 100-year 
cycle, in 100 years, we’ll have to wait 100 more years for it to be 
released, that will certainly create more potential problems. 

Would you make the same point about .local?

Having this mechanism for reserving special use names, creates two 
different authorities managing the same namespace, this will require 
tight coordination as well as clear and transparent guidelines to make 
it work. 
RFC 6761 already specified this.   The tight coordination of which you 
speak has occurred in this case, and will continue: the IESG is keenly 
aware of the situation, based on discussions that I was privy to and 
comments I've witnessed since I stopped being privy to such discussions.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt

[Casey Deccio]

Hi,

Some thoughts below, strictly on the NSEC/NSEC3 algorithm.  They're quite
rough, but hopefully they're useful.

Cheers,
Casey

On Tue, Jul 7, 2015 at 5:20 AM,  wrote:

> Please check this algorithm.


Several times, the phrase "query as usual" is used.  However, something
might need to be said about the resolver modifying "query as usual" to save
NSEC/NSEC3 records associated with wildcard and negative responses in a way
that they can be used by the algorithm.

For example, the following indexes could be maintained:

Indexes:
NSEC_TABLE = a canonically ordered mapping of NSEC owner names to NSEC
records, grouped by corresponding SOA name
NSEC3_TABLE = a canonically ordered mapping of NSEC3 owner names to NSEC3
records, grouped by corresponding SOA name and NSEC3 parameters
NSEC3_NAMES = a canonically ordered mapping of names to their corresponding
NSEC3-hashed names (or records)

QNAME = the query name;
> if (QNAME name entry exists in the cache) {
> resolve the query as usual;
> // if RRSet (query name and query type) exists in the cache,
> // the resolver responds the RRSet from the cache
> // Otherwise, the resolver needs to iterate the query.
> }
>
> // Find closest enclosing NS RRset in the cache.
> // The owner of this NS RRset will be a suffix of the QNAME
> //- the longest suffix of any NS RRset in the cache.
> SIGNER = closest enclosing NS RRSet of QNAME in the cache;
>

You should now find the SOA record corresponding to SIGNER.  If there is no
SOA record in cache, then there are no previously cached negative
responses, so you can resolve the query as usual.

if (SIGNER zone does not have a special NSEC/NSEC3 data structure) {
> Resolve the query as usual;
> }
>

I'm not sure what this means.


> if (SIGNER zone is not signed or not validated) {
>Resolve the query as usual;
> }
>

You mean here: if the SOA record is not validated (signed is implied by
validated).

While colloquially we talk about zones being signed, in this case, you want
an actual RRset--one that matters at that.  The SOA record fits the bill
here because of its role with negative responses.


> if (SIGNER zone is signed with NSEC) {
>

While in theory a zone is signed with either NSEC or NSEC3, in practice all
that matters is the NSEC or NSEC3 proofs provided in individual responses.
While not necessarily desirable, it is entirely possible that subsequent
responses could different NSEC/NSEC3 results.  Therefore, for algorithm
robustness, checking whether a zone is signed with NSEC or NSEC3 is less
useful than simply looking at both NSEC and NSEC3 records in the cache.

I would eliminate "if SIGNER zone is signed with NSEC" and its
corresponding "else"/"else if" altogether.  You should really check both
NSEC and NSEC3.

BEGIN NSEC SECTION

 if (covering NSEC RR of QNAME at SIGNER zone
>doesn't exist in the cache) {
> Resolve the query as usual.
> }
>

s/Resolve the query as usual/Go to NSEC3 SECTION/


>
> TEST = Find the longest existing domain name of QNAME
>from the covering NSEC RR;
>

You could use the term "closest encloser"/CLOSEST_ENCLOSER instead of
"longest existing domain name"/TEST.

if (*.TEST name entry exists in the cache) {
> the resolver can generate positive response
> or resolve the query as usual;
> }
>

s/resolve the query as usual/Go to the NSEC3 SECTION

It could be a NODATA response (which is a negative response), if the type
doesn't exist.  Although, I think that's what you mean by "positive
response or resolve the query as usual".


> if covering NSEC RR of "*.TEST" at SIGNER zone exists
>  in the cache {
> the resolver can generate negative response;
> }
>

s/resolver can generate negative response/Return synthesized negative
response/


> // Lack of information, need to resolve the query as usual
>

No. move on to NSEC3 now.


> } else
>
if (SIGNER zone is signed with NSEC3 and does not use Opt-Out) {
>

Eliminate this "else if SIGNER zone is signed with NSEC3 and does not use
Opt-out" check too.

BEGIN NSEC3 SECTION

TEST = SIGNER;
>

Again, I would look for closest encloser (CLOSEST_ENCLOSER) here (e.g.,
using the NSEC3_NAMES table).  There might be multiple NSEC3 records for a
single closest encloser if multiple sets of NSEC3 parameters are used
across different responses, but really all you need is one.  In this case,
you would need to iterate through the different sets of NSEC3 parameters.

Once you have the closest encloser, the algorithm looks more (but not
entirely) like the NSEC portion above, but with NSEC3 instead.  I'm not
sure I follow the logic in the previously written NSEC3 section.  I've made
some modifications below.

   if (no CLOSEST_ENCLOSER is found) {
Go to FALLBACK SECTION
}

NEXT_CLOSEST_ENCLOSER_PROOF_FOUND = False
 for each set of parameters corresponding to NSEC3 names in the appropriate
zone {
if (there is a NSEC3 RR covering 

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Francisco Obispo]

This was proposed in the working group.   It obviously doesn't work, 
first because TOR can't come up with that kind of money, but second 
because TOR doesn't want a TLD (hellekin's erroneous statements 
notwithstanding).   What they want is a special-use name.   A domain 
name does not accomplish the intended purpose, because it has to be 
resolved by sending a query to a DNS server.   A third objection was 
one Ed raised earlier for an unrelated reason: we can't assume that 
the TOR project will continue to exist as an entity that can own a 
delegation.   What happens when that stops?   Does the Church of 
Anatman get to buy the domain and start snooping on TOR connections?




Well do they want a TLD but they don’t have the money? or don’t want 
a TLD? perhaps the problem is in how the TLD program treats them, in 
which case the answer should be on the ICANN side.


If they are using the string ‘onion’ as a TLD, within the global 
DNS, then they DO want a TLD, how they use it is similar to what 
corporates are doing with .BRANDs.


I don’t like setting things in stone forever, I agree with the 
assessment on “what happens if TOR ceases to exist”, but the answer 
can’t be, lets put it in an RFC where we run the risk of being black 
listed in code potentially forever. Quoting Paul Vixie on the 100-year 
cycle, in 100 years, we’ll have to wait 100 more years for it to be 
released, that will certainly create more potential problems.



A fourth objection which I don't think was raised is that this doesn't 
work for .local or any of the other special-use names, and if it 
doesn't work for them, it doesn't make sense to try to make it work 
specifically for .onion.   Why is .onion special?   Should Apple or 
Microsoft be asked to pay $200k to reserve the .local TLD?


Having this mechanism for reserving special use names, creates two 
different authorities managing the same namespace, this will require 
tight coordination as well as clear and transparent guidelines to make 
it work.


If we are talking about private namespaces, they should be treated as 
such and we’ll have to come up with another way of dealing with name 
collisions.


—
Francisco Obispo
Uniregistry Inc.
On 15 Jul 2015, at 12:59, Ted Lemon wrote:

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Ted Lemon]

On 07/15/2015 12:35 PM, Francisco Obispo wrote:
We are trying to mitigate against unknowns and perhaps the best 
solution is to have the TOR folks apply for .ONION on the next round 
of TLD application and get a fully qualified delegation. 
This was proposed in the working group.   It obviously doesn't work, 
first because TOR can't come up with that kind of money, but second 
because TOR doesn't want a TLD (hellekin's erroneous statements 
notwithstanding).   What they want is a special-use name.   A domain 
name does not accomplish the intended purpose, because it has to be 
resolved by sending a query to a DNS server.   A third objection was one 
Ed raised earlier for an unrelated reason: we can't assume that the TOR 
project will continue to exist as an entity that can own a delegation.   
What happens when that stops?   Does the Church of Anatman get to buy 
the domain and start snooping on TOR connections?


A fourth objection which I don't think was raised is that this doesn't 
work for .local or any of the other special-use names, and if it doesn't 
work for them, it doesn't make sense to try to make it work specifically 
for .onion.   Why is .onion special?   Should Apple or Microsoft be 
asked to pay $200k to reserve the .local TLD?


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Ted Lemon]

On 07/15/2015 11:46 AM, Edward Lewis wrote:

What if I copied the onion draft, changed all of the uses of onion to
carrot, and then threw in some supporting documents to describe some other
system that used carrot as it's base identifier?  On the heels of onion's
admission to the Special Use Domain Names registry, could I expect to have
carrot admitted too?
1. Do you seriously think DNSOP would have had consensus to advance such 
a draft?
2. If DNSOP did have consensus to advance such a draft, what would your 
objection be?


I think that DNSOP would not advance such a draft unless a lot of 
reasonable people decided that they believed that .carrot was needed.   
And if DNSOP did indeed advance such a draft, I think that it would be 
the right thing to do to go to ICANN and say "what do you guys think 
about this?"   I don't think we would be in a position to make demands, 
but we should be able to have the conversation.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Ted Lemon]

On 07/15/2015 11:42 AM, John Levine wrote:

But there is also a faction that believes that every reserved name
will prevent them from making a million bajillion dollars.  History
suggests that they are mistaken, but that doesn't seem to help.
That "faction" is aware that there are problems, and that not all names 
can be monetized in this way.   This discussion is orthogonal to that 
discussion: this particular name is already acknowledged not to be 
monetize-able.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Francisco Obispo]

+1.

I don’t think IETF should be chasing around widely used TLDs and 
trying to block them, it will be a never ending chase.


We are trying to mitigate against unknowns and perhaps the best solution 
is to have the TOR folks apply for .ONION on the next round of TLD 
application and get a fully qualified delegation.


Basically saying: If you need a globally unique identifier in the DNS, 
you must register it with the competent entity. If noy, you run the risk 
of having your users leak their queries and possibly connect to the 
wrong service. This should make a better proposal for standard, 
basically reinforcing the one DNS one Internet message, and not the 
“Make sure you are leaking enough queries so that the IETF can then 
reserve the name for you”.


Who are we trying to protect with this remedy? TOR users? have they 
shown any interest in being protected?


—
Francisco Obispo
Uniregistry Inc.
On 15 Jul 2015, at 12:24, Rubens Kuhl wrote:


Em 15/07/2015, à(s) 16:21:000, hellekin  escreveu:

On 07/15/2015 03:46 PM, Edward Lewis wrote:


What if I copied the onion draft, changed all of the uses of onion 
to

carrot, and then threw in some supporting documents to describe some
other system that used carrot as it's base identifier?  On the heels
of onion's admission to the Special Use Domain Names registry, could
I expect to have carrot admitted too?



Do you have running code for carrot?




The ToR source code, with all occurrences of onion replaced by carrot.


Rubens



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Rubens Kuhl]

> Em 15/07/2015, à(s) 16:21:000, hellekin  escreveu:
> 
> On 07/15/2015 03:46 PM, Edward Lewis wrote:
>> 
>> What if I copied the onion draft, changed all of the uses of onion to
>> carrot, and then threw in some supporting documents to describe some
>> other system that used carrot as it's base identifier?  On the heels
>> of onion's admission to the Special Use Domain Names registry, could
>> I expect to have carrot admitted too?
>> 
> 
> Do you have running code for carrot?



The ToR source code, with all occurrences of onion replaced by carrot. 


Rubens



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[hellekin]

On 07/15/2015 03:46 PM, Edward Lewis wrote:
> 
> What if I copied the onion draft, changed all of the uses of onion to
> carrot, and then threw in some supporting documents to describe some
> other system that used carrot as it's base identifier?  On the heels
> of onion's admission to the Special Use Domain Names registry, could
> I expect to have carrot admitted too?
>

Do you have running code for carrot?

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[David Conrad]

Hellekin,

On Jul 15, 2015, at 8:02 AM, hellekin  wrote:
> > To put it bluntly, from a certain perspective, 6762 and
> > dnsop-onion are essentially about the same thing: they are
> > formalizing squatting on namespace (by Apple in the first
> > instance and by TOR in the second).
> >
> 
> This is blunt in more than one aspect. That you consider squatting as a
> negative is insulting for those people who actually need to rely on
> squatting not to be excluded from society.

I'm intrigued how you derived an insult from my statement that it was squatting.

> But the argument that this is about, correct my paraphrase if I'm wrong,
> "taking over by force part of the namespace" is in my opinion misguided.

You're wrong.

I was noting that the strings were obtained outside of formal process. In my 
view, RFC 6761 was a post-facto effort to formalize that squatting. In the 
sense that post-facto probably isn't the best way of doing things, I suggested 
6762 wasn't a particularly good precedent.

> Indeed .onion can
> do without caring about the DNS, but this is not the point. The point is
> to recognize the variety of techniques within the scope of DNS so that
> future implementations can rely on the DNS as a correct source for
> global information about namespaces.

So, I'm now confused.

I thought the point of putting ONION in the Special Names Registry was to 
ensure that it did NOT rely on the DNS.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Edward Lewis]

On 7/15/15, 14:12, "Ted Lemon"  wrote:

>On 07/15/2015 11:04 AM, Edward Lewis wrote:
>>Keep in mind - I'm saying the document, the internet-draft, doesn't
>> contain all that it could or should to be a convincing use case.
>>Perhaps
>> it ticked off all the check boxes of RFC 6761, but I think it lacks what
>> it needs to be convincing as well as stand the test of time.

>Argh.   I won't belabor the point, but the criteria established in 6761
>are criteria for the IETF to evaluate, not criteria that need to be
>documented in the specification.   The specification says what to do,
>and the working group considered that sufficient.   I do too.   Can you
>explain why it is beneficial for the document to try to make some
>statement about how widespread use of TOR is?   It's pretty easy for the
>working group to look at the situation and say "looks like enough."
>It's a lot harder to quantify it in a way that makes sense to put in an
>RFC, and I don't think it would be appropriate to do so.   I guess we
>could say "it is the consensus of the DNSOP working group that use of
>.onion is sufficiently widespread to justify publishing this document,"
>but I think we are already saying that by requesting its publication.

(The annoying what if... question:)

What if I copied the onion draft, changed all of the uses of onion to
carrot, and then threw in some supporting documents to describe some other
system that used carrot as it's base identifier?  On the heels of onion's
admission to the Special Use Domain Names registry, could I expect to have
carrot admitted too?

I hope the answer is no, because the WG would likely not reach a consensus
on the document.  So, what I'm am asking is for the document to record why
onion is to be accorded this treatment.  WG consensus?  Document it!

(Aside from me thinking the draft's contents about name servers and
operators, criteria 4,5,6, is not a good approach.  E.g., my ISP's
recursive server does look for NS records where 6761 says it shouldn't,
but what they do works.)


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[John Levine]

>If we want to avoid future instances of squatting, it behooves us to 
>avoid applying too much process friction onto documents of this type.   

Well, there's the problem.  Personally, I entirely agree with you, and
I would prefer we err on the side of caution to prevent collsions
between special use names and the DNS.

But there is also a faction that believes that every reserved name
will prevent them from making a million bajillion dollars.  History
suggests that they are mistaken, but that doesn't seem to help.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Ted Lemon]

On 07/15/2015 11:17 AM, Edward Lewis wrote:

URLs are nice for giving a reference, but there's still a need to curate
the data.  In particular, what if the torproject.org name registration
expires and is bought by someone else?
This is a problem whenever we reference a non-IETF specification. 
Actually, in principle it's even a problem when we reference an IETF 
specification, although of course we all no doubt hope the IETF will 
persist into the long now.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Edward Lewis]

On 7/15/15, 11:38, "DNSOP on behalf of hellekin"  wrote:

>I agree that the URL could be use more foresight, e.g.
>https://torproject.org/spec/protocol,
>https://torproject.org/spec/naming, etc. I already suggested this form
>to the Tor people without response. That said, an URL is the right thing
>to do, as long as it does not change. Once the URL makes it to an RFC,
>it is the responsibility of the domain operators to keep it running.
>When the Tor specifications are updated to RFC status, then the .onion
>tld RFC can be updated as well to point to the new references.

".onion tld RFC" - minor point, but all along we are trying to avoid a TLD
for ".onion".

URLs are nice for giving a reference, but there's still a need to curate
the data.  In particular, what if the torproject.org name registration
expires and is bought by someone else?

>*** Are you suggesting then that only 7. is kept?

No, 2, 3 have roles as well as 7.  Not sure about 1.  But I really see
4,5,6 as not desirable.

>In any case I recommend reading the original proposal for .onion in the
>P2PNames draft 04 for an alternate view. Maybe some of the questions
>there can be useful here.

This is the last call for the doc in the subject line.  If text there
helps, it should be worked into the draft in the subject line.


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Ted Lemon]

On 07/15/2015 11:04 AM, Edward Lewis wrote:

That "Ted".

Yup, Ted pointed that out to me privately--sorry.   :)

Keep in mind - I'm saying the document, the internet-draft, doesn't
contain all that it could or should to be a convincing use case.  Perhaps
it ticked off all the check boxes of RFC 6761, but I think it lacks what
it needs to be convincing as well as stand the test of time.
Argh.   I won't belabor the point, but the criteria established in 6761 
are criteria for the IETF to evaluate, not criteria that need to be 
documented in the specification.   The specification says what to do, 
and the working group considered that sufficient.   I do too.   Can you 
explain why it is beneficial for the document to try to make some 
statement about how widespread use of TOR is?   It's pretty easy for the 
working group to look at the situation and say "looks like enough."   
It's a lot harder to quantify it in a way that makes sense to put in an 
RFC, and I don't think it would be appropriate to do so.   I guess we 
could say "it is the consensus of the DNSOP working group that use of 
.onion is sufficiently widespread to justify publishing this document," 
but I think we are already saying that by requesting its publication.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Edward Lewis]

On 7/15/15, 13:16, "DNSOP on behalf of Ted Lemon"  wrote:

>On 07/15/2015 05:42 AM, Edward Lewis wrote:
>
>No, it's not independent, because .onion sites won't be able to get PKI
>certs if we don't do the allocation.

That's what I meant by "(to some extent)".  If not being able to get the
certs kills Tor, then failing to get some special designation would be a
show stopper.  But that isn't in the document (and you'll see I keep
coming back to the document's content).

>We discussed this at length in the working group

The discussion in the WG is not reflected in the document.

>It is clearly understood that TOR is effectively an SDO
>that has defined a standard using their own system of publication and
>their own standardization methodology, which is different than the
>IETF's methodology for very good reasons. Requiring another SDO to
>follow IETF process in order to get an allocation of this type doesn't
>make sense and isn't required by the governing standard.

Until I read this, I wasn't aware that Tor (TOR?) was even an organized
thing.  I don't follow what you mean by requiring another "standards
development organization" to follow the IETF process.  I thought that for
Tor to get certificates from CA/B forum members there was a need to have
"onion" be a specially designated identifier and that the IETF's Special
Use Domain Names registry seems like an apt approach.

>Are you claiming that there is not widespread deployment of TOR? There
>was no controversy in the working group on this question: nobody there
>claimed that TOR wasn't sufficiently widely deployed to justify
>allocation.

To answer your question, no.  I'm not making a claim about its deployment.
 OTOH, I have never seen any first hand evidence of it (I do live in a
cave perhaps).  None of my friends, family, etc., seem to know about and
so on.  But that doesn't matter - the document, as it stands, does not
give any indication that there is a widespread deployment of it.  I.e.,
I'm challenging the document preparers to include text that gives some
estimation of the scale of deployment.  Document it.

>I think this is a reasonable position to take, with one exception. I
>think it's fine for the document to make recommendations about what name
>servers and the root should do, but it's not our place to make
>requirements, nor do I think it's necessary.   However, it would be very
>beneficial for host implementations to special case .onion, as some
>hosts do for .local now.   When hosts fail to apply appropriate special
>case handling for .local, it creates operational annoyances, to no
>benefit.   In the case of .onion, it creates a privacy problem.   So I
>don't mind this text as much as you do, but I do wonder if we'll
>actually see widespread implementation of such requirements.

I didn't see the exception you had in mind.  From what little I apparently
understand about Tor/onion, applications need to behave in a way that
enhances privacy and it would be cool if DNS servers weren't configured to
return conflicting data.  The DNS protocol doesn't need to be changed,
much like .local isn't special to a general purpose DNS server despite
behaving in a certain fashion in a host.

>>Ed: I'm agreeing with Ted in that this application is insufficient.
>
>Whoa there, cowboy!   I didn't say it was insufficient.

http://www.ietf.org/mail-archive/web/ietf/current/msg93849.html

That "Ted".

>And also, please don't call it an application.   It is an internet
>draft, which has passed working group last call, and is in IETF last
>call.   An application would be something that would be handled by the
>IESG, through the instrumentality of the IANA.

Ted called it a "request."  (Just sayin'.)

Keep in mind - I'm saying the document, the internet-draft, doesn't
contain all that it could or should to be a convincing use case.  Perhaps
it ticked off all the check boxes of RFC 6761, but I think it lacks what
it needs to be convincing as well as stand the test of time.


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Richard Barnes]

On Wed, Jul 15, 2015 at 5:52 PM, Hugo Maxwell Connery  wrote:
> Or to re-quote Paul Vixie:
>
> what the internet should be doing is defining escape mechanisms for
> non-internet systems, rather than saying "we are the only thing you can
> use"
>
> RFC 6761 is that mechanism for DNS.

Nice summary.

I have read this document, and sent comments on earlier drafts.  I
think the current version clearly expresses the requirements on DNS
actors to make .onion labels safe to use in DNS-like slots (e.g.,
URLs).  Especially given that there are a good number of sites already
using URLs with .onion names, and the PKI requirement for the status
of these names to be clarified, I strongly support the publication of
this document.

--Richard


>
> /Hugo
> 
> From: DNSOP [dnsop-boun...@ietf.org] on behalf of hellekin [helle...@gnu.org]
> Sent: Wednesday, 15 July 2015 17:02
> To: dnsop@ietf.org
> Subject: Re: [DNSOP] Last Call:  (The 
> .onion Special-Use Domain Name) to Proposed Standard
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 07/14/2015 11:37 PM, David Conrad wrote:
>>
>> To put it bluntly, from a certain perspective, 6762 and
>> dnsop-onion are essentially about the same thing: they are
>> formalizing squatting on namespace (by Apple in the first
>> instance and by TOR in the second).
>>
>
> This is blunt in more than one aspect. That you consider squatting as a
> negative is insulting for those people who actually need to rely on
> squatting not to be excluded from society.
>
> But the argument that this is about, correct my paraphrase if I'm wrong,
> "taking over by force part of the namespace" is in my opinion misguided.
>
> The Domain Name System is *one way* of managing *a* global namespace.
> That it is the canonical way of naming things chosen for the Internet
> does not exclude that it's only one only way. Special-Use Domain Names
> exemplify this point, and particularly P2PNames such as .onion
> demonstrate the viability of other techniques than the hierarchical tree
> of DNS to manage global namespaces.
>
> The objective of this registration is convergent with the idea that the
> DNS is the canonical global namespace of the Internet. Indeed .onion can
> do without caring about the DNS, but this is not the point. The point is
> to recognize the variety of techniques within the scope of DNS so that
> future implementations can rely on the DNS as a correct source for
> global information about namespaces.
>
> I regret not to have mentioned this before, and hope that it frames the
> problematic beyond territorial claims, operational issues, and security
> issues.
>
> ==
> hk
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQJ8BAEBCgBmBQJVpnXeXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
> ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9r5QP/i6bE5b7u5M4JrIN+98GS8HS
> SG0wcDwVX13SWZujJ92ZFGy7lHDfG9wQr8WO/AoAlWT0vMzyfixMpWJZ66gxxthA
> F0fdZtI4N4nfjwolpQUnBnY/39yW1sumYg50AsS5dmX026F+wkjqidIV2s5PiZQr
> D4GC+6XvvYMvsYmLKwv8JeK1+wqkRw9nl2YSX6Wt/U0EwaI/VpIgjYkaT0VIFjw+
> c5OBkRfdaY4pFZ/NMfjiIvcYQp7MQhFPjvpsRMFtvtwpn+ZiJKoB4e3dOPCeL1S2
> dANLyutiodFTMGYGWn9W6Zcfv9SckSOiblH5qvNpkMcAumQe09fTQGxNX14OQXWr
> g6qV8oeNc2k1DsmPHM9UsDYSJmEy4zikGKLCcjpOC3Y4h+6aqyvBsby43dJfr7Fy
> tajr8nh1IcA8VZtM/K5+rqMZabg0EPIPujkchdrJTZ8+jiT0uT8pEDR4VammAcOz
> 9sMufzxdv30yYDYuFpTeTAf27z8h1232yhKOHaBaueDsZmva/IccHyHiw4ZQg/6Y
> NEoZ87UJa1lXWqJ7+XeyOfwJp1adPwXWb2IiNDIjXndXwt94yBPinAL/3E/2gnfw
> /XSKMTaeGBtixhllwidAtBSX7EeWTGQl7kWlH8MsvoLvpcZmuTTHpuWZ9k5VEcTe
> rn6UM1/Ooyjp2i90Gz7q
> =jn7Y
> -END PGP SIGNATURE-
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Ted Lemon]

On 07/15/2015 08:02 AM, hellekin wrote:

This is blunt in more than one aspect. That you consider squatting as a
negative is insulting for those people who actually need to rely on
squatting not to be excluded from society.
To expand on this ever so slightly, the reason why things like this 
happen is because the process for approving special-use allocations is 
perceived as too heavyweight, so people don't bother to do it in 
anticipation of an experiment.   Later, when the experiment proves a 
success, it's too late, and that is characterized as squatting, when in 
fact nobody had any intention of doing anything wrong, but were just 
following the path of least resistance.


If we want to avoid future instances of squatting, it behooves us to 
avoid applying too much process friction onto documents of this type.   
Granted, it's hard to tell how much is too much, but this particular 
discussion was kicked off in November of 2013, and here it is July of 
2015, and we are still talking about it.   That's a pretty heavy process.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Ted Lemon]

On 07/15/2015 05:42 AM, Edward Lewis wrote:

As David says, .onion-names use is independent (to some extent) on whether
"onion" is registered in the Special Use Domain Names registry.  What I am
writing here isn't a statement about whether "onion" is to registered, but
about the document applying for registration.


No, it's not independent, because .onion sites won't be able to get PKI 
certs if we don't do the allocation.

The document defines the use of the name by referring to a couple of
references, none of which appears to be published in a way that can be
referenced except by URL.  Not to say that the documents seen are poorly
written, still there's no evidence of peer review nor stable reference
point.
We discussed this at length in the working group, in which I believe you 
participate.   It is clearly understood that TOR is effectively an SDO 
that has defined a standard using their own system of publication and 
their own standardization methodology, which is different than the 
IETF's methodology for very good reasons. Requiring another SDO to 
follow IETF process in order to get an allocation of this type doesn't 
make sense and isn't required by the governing standard.



The document also shows no evidence of the deployment of the use of the
names below "onion."  In David's email, and in others, there are comments
regarding an "installed base".
Are you claiming that there is not widespread deployment of TOR? There 
was no controversy in the working group on this question: nobody there 
claimed that TOR wasn't sufficiently widely deployed to justify allocation.

I really believe that for DNS elements, there should be no change.  By
intent, the onion names are not to be presented to the DNS by what's in
category 2 and 3 (Applications and Name Resolution API's respectively).  I
see placing any requirement on DNS elements - and by that I mean the
software used to implement the DNS standard - as a bad idea, under the
heading of "permanent fix to a temporary situation."  (I.e., Tor may not
be permanent, if it is, as software matures onion names will not be in DNS
queries.)


I think this is a reasonable position to take, with one exception. I 
think it's fine for the document to make recommendations about what name 
servers and the root should do, but it's not our place to make 
requirements, nor do I think it's necessary.   However, it would be very 
beneficial for host implementations to special case .onion, as some 
hosts do for .local now.   When hosts fail to apply appropriate special 
case handling for .local, it creates operational annoyances, to no 
benefit.   In the case of .onion, it creates a privacy problem.   So I 
don't mind this text as much as you do, but I do wonder if we'll 
actually see widespread implementation of such requirements.

I'm agreeing with Ted in that this application is insufficient.


Whoa there, cowboy!   I didn't say it was insufficient.   I proposed 
changes to the text that I think would result in it better expressing 
what I think was intended.


And also, please don't call it an application.   It is an internet 
draft, which has passed working group last call, and is in IETF last 
call.   An application would be something that would be handled by the 
IESG, through the instrumentality of the IANA.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] terminology, additional language for bailiwick

[Wiley, Glen]

The draft-ietf-dnsop-dns-terminology draft will be helpful in normalizing
language in documentation and
for folks new to the industry, I like where it is heading.  I¹d like to
recommend adding a few sentences to in the paragraphs on bailiwick.  I
think the original text is pretty close but the additions below would make
it more helpful to a less familiar reader as bailiwick is particularly
confusing to some folks (as was noted in earlier exchanges on this list).

The current text reads:

In-bailiwick:

  (a) An adjective to describe a name server whose name is either
  subordinate to or (rarely) the same as the zone origin.  In-
  bailiwick name servers require glue in their parent zone.

  (b) Data for which the server is either authoritative, or else
  authoritative for an ancestor of the owner name.  This sense of
  the term normally is used when discussing the relevancy of glue
  records in a response.  For example, the server for the parent
  zone example.com might reply with glue records for
  ns.child.example.com.  Because the child.example.com zone is a
  descendant of the example.com zone, the glue records are in-
  bailiwick.

   Out-of-bailiwick:  The antonym of in-bailiwick.




Id like to suggest something like this:

(a) An adjective to describe a name server whose name is either
subordinate to or (rarely) the same as the zone origin. In-
bailiwick name servers require glue in their parent zone. For
example if the com. name server refers a query for a.example.com
to ns.example.com the resolver would consider ns.example.com
in-bailiwick.
--
Glen Wiley
Principal Engineer
Verisign, Inc.
(571) 230-7917

http://vbsdcon.com

A5E5 E373 3C75 5B3E 2E24
6A0F DC65 2354 9946 C63A
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Hugo Maxwell Connery]

Or to re-quote Paul Vixie:

what the internet should be doing is defining escape mechanisms for
non-internet systems, rather than saying "we are the only thing you can
use"

RPC 6761 is that mechanism for DNS.

/Hugo

From: DNSOP [dnsop-boun...@ietf.org] on behalf of hellekin [helle...@gnu.org]
Sent: Wednesday, 15 July 2015 17:02
To: dnsop@ietf.org
Subject: Re: [DNSOP] Last Call:  (The .onion 
Special-Use Domain Name) to Proposed Standard

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/14/2015 11:37 PM, David Conrad wrote:
>
> To put it bluntly, from a certain perspective, 6762 and
> dnsop-onion are essentially about the same thing: they are
> formalizing squatting on namespace (by Apple in the first
> instance and by TOR in the second).
>

This is blunt in more than one aspect. That you consider squatting as a
negative is insulting for those people who actually need to rely on
squatting not to be excluded from society.

But the argument that this is about, correct my paraphrase if I'm wrong,
"taking over by force part of the namespace" is in my opinion misguided.

The Domain Name System is *one way* of managing *a* global namespace.
That it is the canonical way of naming things chosen for the Internet
does not exclude that it's only one only way. Special-Use Domain Names
exemplify this point, and particularly P2PNames such as .onion
demonstrate the viability of other techniques than the hierarchical tree
of DNS to manage global namespaces.

The objective of this registration is convergent with the idea that the
DNS is the canonical global namespace of the Internet. Indeed .onion can
do without caring about the DNS, but this is not the point. The point is
to recognize the variety of techniques within the scope of DNS so that
future implementations can rely on the DNS as a correct source for
global information about namespaces.

I regret not to have mentioned this before, and hope that it frames the
problematic beyond territorial claims, operational issues, and security
issues.

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVpnXeXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9r5QP/i6bE5b7u5M4JrIN+98GS8HS
SG0wcDwVX13SWZujJ92ZFGy7lHDfG9wQr8WO/AoAlWT0vMzyfixMpWJZ66gxxthA
F0fdZtI4N4nfjwolpQUnBnY/39yW1sumYg50AsS5dmX026F+wkjqidIV2s5PiZQr
D4GC+6XvvYMvsYmLKwv8JeK1+wqkRw9nl2YSX6Wt/U0EwaI/VpIgjYkaT0VIFjw+
c5OBkRfdaY4pFZ/NMfjiIvcYQp7MQhFPjvpsRMFtvtwpn+ZiJKoB4e3dOPCeL1S2
dANLyutiodFTMGYGWn9W6Zcfv9SckSOiblH5qvNpkMcAumQe09fTQGxNX14OQXWr
g6qV8oeNc2k1DsmPHM9UsDYSJmEy4zikGKLCcjpOC3Y4h+6aqyvBsby43dJfr7Fy
tajr8nh1IcA8VZtM/K5+rqMZabg0EPIPujkchdrJTZ8+jiT0uT8pEDR4VammAcOz
9sMufzxdv30yYDYuFpTeTAf27z8h1232yhKOHaBaueDsZmva/IccHyHiw4ZQg/6Y
NEoZ87UJa1lXWqJ7+XeyOfwJp1adPwXWb2IiNDIjXndXwt94yBPinAL/3E/2gnfw
/XSKMTaeGBtixhllwidAtBSX7EeWTGQl7kWlH8MsvoLvpcZmuTTHpuWZ9k5VEcTe
rn6UM1/Ooyjp2i90Gz7q
=jn7Y
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[hellekin]

On 07/15/2015 09:42 AM, Edward Lewis wrote:
> 
> The document defines the use of the name by referring to a couple of
> references, none of which appears to be published in a way that can be
> referenced except by URL.
>

I agree that the URL could be use more foresight, e.g.
https://torproject.org/spec/protocol,
https://torproject.org/spec/naming, etc. I already suggested this form
to the Tor people without response. That said, an URL is the right thing
to do, as long as it does not change. Once the URL makes it to an RFC,
it is the responsibility of the domain operators to keep it running.
When the Tor specifications are updated to RFC status, then the .onion
tld RFC can be updated as well to point to the new references.

> 
> Drilling into the criteria that are presented.  Not all of them.
> 
> 1. Users.  The draft states "human users are expected to recognize .on
ion
> names as..."  How are users supposed to recognize them as (special)?  
In
> as much as the document says nothing about evidence of deployment and
> adoption, how can an expectation be developed?  If I hadn't been readi
ng
> the thread on DNSOP, I wouldn't have thought "onion" was special - but
 I
> live in a cave, so what I think isn't important.
>

The original P2PNames draft use:

"Users can use these names as they would other domain names, entering
them anywhere that they would otherwise enter a conventional DNS domain
name.

Since there is no central authority necessary or possible for assigning
.onion names, and those names correspond to cryptographic keys, users
need to be aware that they do not belong to regular DNS, but are still
global in their scope."

> 4. Caching DNS Servers and
> 5. Authoritative DNS Servers
>
*** Well, isn't it the point of this draft that "as software matures
onion names will not be in DNS queries"?  These points are to minimize
the consequences on privacy when misconfigured systems leak queries, and
to minimize the number of bogus requests hitting the DNS tree.

> 6. DNS Operators
>
*** Again, this is not about enforcing, but about establishing best
practice. People can rely on RFC documentation and conscientious
operators will apply what's written there.

> 7. DNS Registrars/Registries
> 
> This is the place where a case should be made for the registering "oni
on"
> as a Special Use Domain Name.  Given the story to date, that "onion" i
s
> not to be in the DNS, then don't change the protocol (5,6 above) but t
hen
> set up barriers to putting it in the DNS (7 here).  If you do that, th
en
> Name Resolution libraries (3 above) will return "name error" or NXDOMA
IN
> to all queries in the onion domain of names.  I see this as where
> registry policy documents can "point" (by reference) to a list of name
s
> that are specially reserved or restricted.

> 
> My concern is that, if this application proceeds as documented,
> the precedent being set could be regrettable.
> 
*** Are you suggesting then that only 7. is kept?

In any case I recommend reading the original proposal for .onion in the
P2PNames draft 04 for an alternate view. Maybe some of the questions
there can be useful here.

https://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-names-04
#section-4.3.1

==
hk

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Edward Lewis]

On 7/15/15, 10:32, "Stephane Bortzmeyer"  wrote:

>First, RFC 6761 is silent about the characteristics of the
>documentation to include in such a draft. RFC 6761 is very specific
>about "in each of the seven categories below, what special treatment,
>if any, is to be applied" but never mandated a specific type of
>external references.

Never said that the draft did not fulfill the requirements of RFC 6761.  I
opined that it contained little information enabling an informed opinion.

An aside to all this (not meant to derail the application of "onion"),
when a process is as loosely defined as what is in RFC 6761, decisions
made according to it will build up a set of precedents that following
applications will be judged by.  One could argue that RFC 6761 is too
loose in specification or one can accept that it lays an open process
which will be defined by cases later on.  For the latter, merely meeting
the requirements of the process-setting document is not enough.

>Second, I much prefer an URL (a few seconds after, I have the document
>and I can read it) to... (incoming troll) a DOI or other kind of
>reference that I may or may not be able to dereference.

To give a data point, the ATMA resource record type was originally defined
by a document resting on the ATM Forum site.  That was absorbed by
SomeOther Forum and then again by YetAnother Forum.  I had been tracking
the documentation of RR types since the days of DNSSEC's development and
thus was aware of the document's movement.  Eventually I made a request to
have the document "escrowed" (if that's the right term) with IANA so we
didn't lose it altogether - even if for historical purposes.

If we are going to rely on prior cases to build RFC 6761's process, we
need to be able to find the historical record.  URL's don't ensure that.


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/14/2015 11:37 PM, David Conrad wrote:
> 
> To put it bluntly, from a certain perspective, 6762 and
> dnsop-onion are essentially about the same thing: they are
> formalizing squatting on namespace (by Apple in the first
> instance and by TOR in the second).
>

This is blunt in more than one aspect. That you consider squatting as a
negative is insulting for those people who actually need to rely on
squatting not to be excluded from society.

But the argument that this is about, correct my paraphrase if I'm wrong,
"taking over by force part of the namespace" is in my opinion misguided.

The Domain Name System is *one way* of managing *a* global namespace.
That it is the canonical way of naming things chosen for the Internet
does not exclude that it's only one only way. Special-Use Domain Names
exemplify this point, and particularly P2PNames such as .onion
demonstrate the viability of other techniques than the hierarchical tree
of DNS to manage global namespaces.

The objective of this registration is convergent with the idea that the
DNS is the canonical global namespace of the Internet. Indeed .onion can
do without caring about the DNS, but this is not the point. The point is
to recognize the variety of techniques within the scope of DNS so that
future implementations can rely on the DNS as a correct source for
global information about namespaces.

I regret not to have mentioned this before, and hope that it frames the
problematic beyond territorial claims, operational issues, and security
issues.

==
hk

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVpnXeXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9r5QP/i6bE5b7u5M4JrIN+98GS8HS
SG0wcDwVX13SWZujJ92ZFGy7lHDfG9wQr8WO/AoAlWT0vMzyfixMpWJZ66gxxthA
F0fdZtI4N4nfjwolpQUnBnY/39yW1sumYg50AsS5dmX026F+wkjqidIV2s5PiZQr
D4GC+6XvvYMvsYmLKwv8JeK1+wqkRw9nl2YSX6Wt/U0EwaI/VpIgjYkaT0VIFjw+
c5OBkRfdaY4pFZ/NMfjiIvcYQp7MQhFPjvpsRMFtvtwpn+ZiJKoB4e3dOPCeL1S2
dANLyutiodFTMGYGWn9W6Zcfv9SckSOiblH5qvNpkMcAumQe09fTQGxNX14OQXWr
g6qV8oeNc2k1DsmPHM9UsDYSJmEy4zikGKLCcjpOC3Y4h+6aqyvBsby43dJfr7Fy
tajr8nh1IcA8VZtM/K5+rqMZabg0EPIPujkchdrJTZ8+jiT0uT8pEDR4VammAcOz
9sMufzxdv30yYDYuFpTeTAf27z8h1232yhKOHaBaueDsZmva/IccHyHiw4ZQg/6Y
NEoZ87UJa1lXWqJ7+XeyOfwJp1adPwXWb2IiNDIjXndXwt94yBPinAL/3E/2gnfw
/XSKMTaeGBtixhllwidAtBSX7EeWTGQl7kWlH8MsvoLvpcZmuTTHpuWZ9k5VEcTe
rn6UM1/Ooyjp2i90Gz7q
=jn7Y
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Bob Harold]

On Tue, Jul 14, 2015 at 3:24 PM, The IESG  wrote:

>
> The IESG has received a request from the Domain Name System Operations WG
> (dnsop) to consider the following document:
> - 'The .onion Special-Use Domain Name'
>as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> i...@ietf.org mailing lists by 2015-08-11. Exceptionally, comments may be
> sent to i...@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
> This document uses the Special-Use Domain Names registry to register the
> '.onion' Top Level Domain (TLD) for the Tor Network. This is deemed
> necessary
> for hosts on the ToR network to apply for and receive legitimate SSL
> Certificates.
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/ballot/
>
>
(Speaking for myself)

I support this document.  This seems to be one of the cases that the
special use registry should be used for.

I would note that the SSL cert is incorrect for the
https://www.onion-router.net/Publications/tor-design.pdf link, so it would
be good if either the cert or the URL could be corrected.  (Cert is for the
name torproject.org and *.torproject.org)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Stephane Bortzmeyer]

On Wed, Jul 15, 2015 at 12:42:23PM +,
 Edward Lewis  wrote 
 a message of 202 lines which said:

> The document defines the use of the name by referring to a couple of
> references, none of which appears to be published in a way that can
> be referenced except by URL.

First, RFC 6761 is silent about the characteristics of the
documentation to include in such a draft. RFC 6761 is very specific
about "in each of the seven categories below, what special treatment,
if any, is to be applied" but never mandated a specific type of
external references.

Second, I much prefer an URL (a few seconds after, I have the document
and I can read it) to... (incoming troll) a DOI or other kind of
reference that I may or may not be able to dereference.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Stephane Bortzmeyer]

On Tue, Jul 14, 2015 at 07:37:01PM -0700,
 David Conrad  wrote 
 a message of 60 lines which said:

> I really (really) wish there was more concrete, objective metrics
> (e.g., size of installed base or some such),

Most of the current RFC6761 requests are for projects devoted to
privacy, which, by construction, make statistics difficult :-}

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03

[Stephane Bortzmeyer]

On Wed, Jul 15, 2015 at 10:55:19AM +0100,
 John Dickinson  wrote 
 a message of 47 lines which said:

> I wouldn't call it a turkey, but I do agree with Tony that deferring
> anything contentious to a -bis is a bad way forward,

It's harsh to say that "everything contentious" have been deferred. A
lot of complicated issues (with strong disagreements) were solved in
this working group and I would sadly regret that we lose this work
because other issues are not yet solved.

> especially for a draft that is only 3 months old (since the -00).

7.5 months (since draft-hoffman-dns-terminology-00)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-huang-dnsop-synchronization-resolver-server-00.txt

[Stephane Bortzmeyer]

On Wed, Jul 15, 2015 at 09:43:36AM +0800,
 wang.c...@zte.com.cn  wrote 
 a message of 98 lines which said:

>   Thanks a lot for your comments.

By the way, my message was *not* distributed on dnsop, for unknown
reasons (I've pinged the chairs).

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

[Edward Lewis]

On 7/14/15, 15:24:

>The IESG has received a request from the Domain Name System Operations WG
>(dnsop) to consider the following document:
>- 'The .onion Special-Use Domain Name'
>   as Proposed Standard

Having read the document plus Ted Hardie's and David Conrad's (who happens
to be my boss in real life) comments, I see the documentation as
insufficient.

As David says, .onion-names use is independent (to some extent) on whether
"onion" is registered in the Special Use Domain Names registry.  What I am
writing here isn't a statement about whether "onion" is to registered, but
about the document applying for registration.

The document defines the use of the name by referring to a couple of
references, none of which appears to be published in a way that can be
referenced except by URL.  Not to say that the documents seen are poorly
written, still there's no evidence of peer review nor stable reference
point.  (One reference is a well prepared PDF, loaded on Jan 23, 2013 with
many other documents to a website that itself has this blurb at the
bottom: "Historical page reflecting onion-router.net as of 2005, not
regularly maintained. Address questions to...")  This is not a critique of
the content of the PDF, just the ability to rely on it for a decision.

The document also shows no evidence of the deployment of the use of the
names below "onion."  In David's email, and in others, there are comments
regarding an "installed base".  I've only seen any discussion about an
installed base in email, this is not in the documents.  In (say) 50 years,
what matters is what is in the published RFC, not the mailing lists.
Presence in the documents being put forward is important.

(E.g., has anyone consulted the annual DNS-OARC DITL data to measure how
often "onion" names are seen at root servers during that collection?)

Drilling into the criteria that are presented.  Not all of them.

1. Users.  The draft states "human users are expected to recognize .onion
names as..."  How are users supposed to recognize them as (special)?  In
as much as the document says nothing about evidence of deployment and
adoption, how can an expectation be developed?  If I hadn't been reading
the thread on DNSOP, I wouldn't have thought "onion" was special - but I
live in a cave, so what I think isn't important.

4. Caching DNS Servers and
5. Authoritative DNS Servers

I really believe that for DNS elements, there should be no change.  By
intent, the onion names are not to be presented to the DNS by what's in
category 2 and 3 (Applications and Name Resolution API's respectively).  I
see placing any requirement on DNS elements - and by that I mean the
software used to implement the DNS standard - as a bad idea, under the
heading of "permanent fix to a temporary situation."  (I.e., Tor may not
be permanent, if it is, as software matures onion names will not be in DNS
queries.)

6. DNS Operators

Having had experience with that field, I don't see this being a reliable
"rule."  In general, when a customer loads a zone into a system, there's
no way to check whether they have the "right" to use the name.  This is
more an issue I have with RFC 6761 and in general how the documents are
used in operations than a comment on the "onion" application.
Nevertheless, I wouldn't rely rule on operators, given that anyone can set
up a name server (the code is free and privileged user accounts are easy
on laptops), to be an effective means to enforce name restrictions.

7. DNS Registrars/Registries

This is the place where a case should be made for the registering "onion"
as a Special Use Domain Name.  Given the story to date, that "onion" is
not to be in the DNS, then don't change the protocol (5,6 above) but then
set up barriers to putting it in the DNS (7 here).  If you do that, then
Name Resolution libraries (3 above) will return "name error" or NXDOMAIN
to all queries in the onion domain of names.  I see this as where
registry policy documents can "point" (by reference) to a list of names
that are specially reserved or restricted.

I'm agreeing with Ted in that this application is insufficient.  I'm
agreeing with David in that designating "onion" in such a way as to fix
the "CAB Forum" stuff is acceptable.  My concern is that, if this
application proceeds as documented, the precedent being set could be
regrettable.


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt

[fujiwara]

Thanks to Jinmei, Shumon and Mark.

> From: 神明達哉 
> While I see what it tries to say and don't disagree with it, I think
> this is not very accurate.  In fact, NXDOMAIN for "a.example.com" says
> there is no such name *or any subdomain of it*.  So it would still be
> usable to suppress unnecessary external query for, e.g.,
> foo.a.example.com.

I will add some text in next revision.

> From: Shumon Huque 
> That's indeed the literal meaning of NXDOMAIN, but it turns out most
> current resolver implementations don't treat it that way. The wording in
> RFC2308, Section 5 is not entirely precise, but it seems to say that
> negative answers should be cached only for the exact qname, and not
> (necessarily) for anything below it.

> From: Mark Andrews 
> Because the consensus at the time was not to support nxdomain
> synthesis from signed zone (speaketh the author of RFC 2308).

I will add texts to update RFC 2308.

> Extreme care needs to be taken with nxdomain synthesis. You need
> to choose the correct NSEC records especially for qnames which are
> the subdomain of the NSEC owner name.  The NS bit MUST NOT be set
> in this case as the presence of the NS bit indicates a delegation.
> 
> NSEC3 is even more complicted.

YES.

> DLV is only defined to use NSEC signed zones as I wasn't interested
> in having to working out all the rules for NSEC3.

I think the procedure is the same as NSEC3 validation.

# and qname minimization discussion is interesting.
# It may be listed in draft-ietf-dnsop-root-loopback 
# as a different approach.

--
Kazunori Fujiwara, JPRS 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-huang-dnsop-synchronization-resolver-server-00.txt

[wang . cui1]

Dear Stephane,

  Thanks a lot for your comments.

  Please see inline.

BRs
Linda

Stephane Bortzmeyer  写于 2015-07-04 04:22:43:

> Stephane Bortzmeyer  
> 2015-07-04 04:22
> 
> 收件人
> 
> wang.c...@zte.com.cn, 
> 
> 抄送
> 
> suzworldw...@gmail.com, tjw.i...@gmail.com, 
> huang.sunli...@zte.com.cn, meng.w...@zte.com.cn, dnsop@ietf.org
> 
> 主题
> 
> Re: New Version Notification for  draft-huang-dnsop-synchronization-
> resolver-server-00.txt
> 
> On Fri, Jul 03, 2015 at 10:14:50AM +0800,
>  wang.c...@zte.com.cn  wrote 
>  a message of 143 lines which said:
> 
> > I have just submitted a new draft which tries to work out how to
> > synchronize the RRs information between resolvers and DNS servers.
> 
> I have two serious concerns with this draft. The most important one is
> that I do not see an use case. DNS is and has always been "loosely
> consistent". It was never envisioned that a change in the
> authoritative name servers would be reflected "instantaneously" in
> every resolver. If someone wants faster changes, he can always use
> (reasonable) short TTLs. So, you really should add a section
> explaining what is the use case.
//Linda: Yes, I agree with you. Next version, we plan to add one or two 
use cases to 
highlight the issue proposed in this draft. Then we can continue our 
discussion 
whether the solution is OK.
> 
> The second concern comes from the observation that authoritative name
> servers are fast and very resilient because they don't keep
> state. Asking them to memorize all their clients, in order to notify
> them later of a change in the data, is a sure way to weaken them.
//Linda: If we can confirm this issue is sure to exist. There should be a 
feasible solution to leverage it and then we can work out it.
> 

Thanks a lot:)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03

[John Dickinson]

On 14/07/2015 17:26, Casey Deccio wrote:

On Tue, Jul 14, 2015 at 12:00 PM, Paul Hoffman mailto:paul.hoff...@vpnc.org>> wrote:

On 13 Jul 2015, at 14:20, Casey Deccio wrote:


4. In the definition of RRset, the bit about TTLs needing to be
the same
seems out of place for this terminology document.  That is an
operational
requirement.


Disagree. To some people, TTLs are operational, to others they are
part of the master file format. For the latter, this sameness
applies to the definition.



No, the zone file can contain different TTLs. As far as I know most 
implementations choose to reduce the TTLs for all RRs in an RRSet to the 
lowest value.




What I am saying is that whether the TTLs are the same (correct) or the
TTLs are different (incorrect), it doesn't change the definition of
RRset, which is the set of RRs with the same name/class/type.  Therefore
the requirement that the TTL be the same is not a useful statement for
the definitions doc, whether it's operational or standards-based.



I agree.
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03

[John Dickinson]

On 14/07/2015 18:15, Tim Wicinski wrote:


On 7/14/15 12:26 PM, Tony Finch wrote:

Paul Hoffman  wrote:


This is still contentious, and I think it really should be deferred
to the
-bis document for longer discussion and hopefully consensus.


As far as I can tell from the last few months there is a fairly clear
consensus that the current draft is not good enough. Brushing off
suggestions by saying that we'll publish a turkey then fix it up later is
not a good way to encourage people to contribute.

Tony.




Tony

I would have to disagree with you on the consensus.  There was many
comments on the draft, and the authors did an admirable job addressing
them and attempting to find common ground.

The decision was made to first document all existing terminology in one
place, regardless of how accurate it is to the world today; and then
take time to generate a revised document where many definitions would be
updated, and other documents partially obsoleted.  But I would not call
it a turkey.



Tim,

After a quick read of -03 I would saay the draft is in much better shape 
than last time I read it. I wouldn't call it a turkey, but I do agree 
with Tony that deferring anything contentious to a -bis is a bad way 
forward, especially for a draft that is only 3 months old (since the -00).


regards
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop