Re: [DNSOP] .arpa

[John Levine]

In article <04dea363-80f3-46e2-9f22-1d6fa3d31...@gmail.com> you write:
>IETF is making a request of ICANN.  It seems to me homenet-dot should be 
>revised:
>
>* take the relevant text out of the IANA considerations section
>* add a section that
>  - motivates and explicitly defines the desired entry in the root zone
>  - suggests that a request be made directly to ICANN 
>  - explicitly points out that no process for such a request exists, and it 
> might be necessary for IETF and ICANN to develop a mutually
>acceptable process before the request from .homenet can be considered
>  - asks for IETF advice on this plan

Don't forget

  - waits many, many years while ICANN does what ICANN does about anything new

At this point I see the only plausible options as choose .homenet and
require all validating resolvers to special-case it, or choose
.homenet.arpa and put whatever DNSSEC magic we need into .arpa.

While I don't think that the technical issues are particularly complex
around changing the rules to put a .homenet stub or opt-out in the
root, I can absolutely guarantee that if ICANN considers it, there
will be a long queue of opportunists insisting that their particular
awful root hacks are just like .homenet and ICANN has to do them, too.
They are wrong, but ICANN is poorly defended against people with a
mission and a lot of free time.

R's,
John

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

Re: [DNSOP] Validating stubs? Was: Re: WG review of draft-ietf-homenet-dot-03

[Ted Lemon]

On Mar 22, 2017, at 7:08 PM, Brian Dickson  
wrote:
> Establish a trust anchor for homenet (whatever name is used), AND publish the 
> private keys.

Homenet is not a globally unique namespace.   No such trust anchor can be 
established.

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

Re: [DNSOP] Validating stubs? Was: Re: WG review of draft-ietf-homenet-dot-03

[George Michaelson]

Your question is well timed. with DNSSEC keyroll happening, the
question: "what level of 5011 deployement" exists is unanswerable with
authority because the architects did not consider signalling of
capability sufficiently trustable. So we have no direct measure of
capability, and a weak, indirect sense of deployment from other
signals of capabilities which would imply post-5011 capable code, but
cannot say if a locally maintained hand-installed TA is in use.

So the question "is it assumed" is a good one. I think the answer is
"yes, we design for the assumption DNS now is enabled for 5011, or
else is owning its problems"

-G

On Thu, Mar 23, 2017 at 9:08 AM, Brian Dickson
 wrote:
> I was thinking about the DNSSEC validation by stubs, with respect to the
> homenet discussion.
>
> And, I was wondering about various trust anchor options (other than ICANN's
> current root trust anchor).
>
> It occurred to me, that any non-ICANN trust anchor, would possibly require
> 5011 key rolls under certain circumstances.
>
> Which begs the question: are validating stub resolvers presumed to be
> 5011-capable?
>
> But, I realize, the issue of 5011 capability also exists for the root trust
> anchor.
>
> So, the dilemma is:
>
> Can we assume 5011 stub support regardless?
> If not, does this make the DNSSEC issue for homenet moot, since the root KSK
> will be rolled in the near future (for some value of "near future"), and
> break stub validation?
>
> On the other hand, if 5011 support by stubs is assumed, there is one
> interesting option:
>
> Establish a trust anchor for homenet (whatever name is used), AND publish
> the private keys.
>
> This creates the ability to have a master DNS authority server, in any given
> homenet instance, sign the data in the homenet zone. The default software
> could/would need to ship with the trust anchor, and the private key. The
> out-of-the-box behavior would just work, and would verify/validate properly
> for validating stubs that ship with the homenet trust anchor.
>
> There would then be the ability for users running their own homenet
> networks, to do the equivalent of changing the default password -- they
> would be able to do a 5011 key roll, which would cause the default trust
> anchor to be replaced with a unique trust anchor for that specific homenet.
>
> It's not part of the homenet standard (yet), but might be worth thinking
> about.
>
> Again, the main question is, has an assumption about 5011 support in stubs
> been made, and is it a valid assumption?
>
> If not, to re-emphasize, then the "unsigned delegation" thing isn't even
> necessary, since the stub resolvers won't be able to validate ANYTHING.
>
> Brian
>
> ___
> 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] Validating stubs? Was: Re: WG review of draft-ietf-homenet-dot-03

[Brian Dickson]

I was thinking about the DNSSEC validation by stubs, with respect to the
homenet discussion.

And, I was wondering about various trust anchor options (other than ICANN's
current root trust anchor).

It occurred to me, that any non-ICANN trust anchor, would possibly require
5011 key rolls under certain circumstances.

Which begs the question: are validating stub resolvers presumed to be
5011-capable?

But, I realize, the issue of 5011 capability also exists for the root trust
anchor.

So, the dilemma is:

   - Can we assume 5011 stub support regardless?
   - If not, does this make the DNSSEC issue for homenet moot, since the
   root KSK will be rolled in the near future (for some value of "near
   future"), and break stub validation?

On the other hand, if 5011 support by stubs is assumed, there is one
interesting option:

Establish a trust anchor for homenet (whatever name is used), AND publish
the private keys.

This creates the ability to have a master DNS authority server, in any
given homenet instance, sign the data in the homenet zone. The default
software could/would need to ship with the trust anchor, and the private
key. The out-of-the-box behavior would just work, and would verify/validate
properly for validating stubs that ship with the homenet trust anchor.

There would then be the ability for users running their own homenet
networks, to do the equivalent of changing the default password -- they
would be able to do a 5011 key roll, which would cause the default trust
anchor to be replaced with a unique trust anchor for that specific homenet.

It's not part of the homenet standard (yet), but might be worth thinking
about.

Again, the main question is, has an assumption about 5011 support in stubs
been made, and is it a valid assumption?

If not, to re-emphasize, then the "unsigned delegation" thing isn't even
necessary, since the stub resolvers won't be able to validate ANYTHING.

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

Re: [DNSOP] .arpa

[Ralph Droms]

> On Mar 22, 2017, at 1:11 PM, Andrew Sullivan  wrote:
> 
> Hi,
> 
> On Wed, Mar 22, 2017 at 09:19:24AM -0700, Ray Bellis wrote:
>> Arguably I'm not "typical", but IMHO we shouldn't be designing for the
>> lowest common denominator.
> 
> That argument is absurd on the face of it, because anyone sufficiently
> clueful about systems to be using ssh or hand-entering domain names is
> also sufficiently clueful to recognize that maybe they should use the
> google search result that pertains to networking rather than the US
> DoD.  (Presumably these are the same people who have figured out that
> iab.org and iab.com are not the same organizations.)  Therefore,
> homenet.arpa would work just fine for such people, there'd be no
> design for LCD, and also we'd get something that would work and
> wouldn't involve a constitutional crisis for IANA.
> 
>> Either way, the Homenet WG has reached its consensus decision to request
>> ".homenet" rather than ".homenet.arpa".
> 
> Since the point of this discussion is to inform IETF consensus,
> HOMENET's consensus is not the only thing that counts.  It is entirely
> possible that HOMENET's consensus will not be the IETF consensus.
> 
>> To those that say "no insecure delegations in the root zone" because
>> "DNSSEC is good"
> 
> I don't think anyone is saying anything about that.  The point is that
> _someone else_ gets to decide.  The IETF has literally no say in the
> decision about what goes in the root zone itself, and hasn't since the
> IETF signed its MoU with ICANN.  (Some argue that for this reason the
> IETF must never allocate a top-level label.  I do not agree with them,
> but there is absolutely no question about whether we are in a position
> to decide actual registrations in the root zone.)
> 
> The plain fact is that the IETF IANA considerations in
> draft-ietf-homenet-dot-03 makes a request of IANA that the IETF has no
> business making, because we are requesting an entry in a registry
> whose policy is controlled by someone else.  It's clear that the
> weasel words "arrange for" are there to pretend we're not making such
> a request it, but the MUST NOT be signed is an attempt to specify
> protocol operation in a registry where we have no business working.
> If this proceeds as IETF consensus, it will be apparent that it is the
> IETF, not ICANN, that threatens the stability of the IANA
> arrangements.  I hope we do not have to explore that rathole in my
> lifetime.

I agree that the request is misdirected toward IANA and misplaced in an "IANA 
Considerations" section.  If the IETF consensus is to find a way to instantiate 
the appropriate entry in the root zone, such an instantiation should 
acknowledge several realities and recognize that IETF is making a request of 
ICANN.  It seems to me homenet-dot should be revised:

* take the relevant text out of the IANA considerations section
* add a section that
  - motivates and explicitly defines the desired entry in the root zone
  - suggests that a request be made directly to ICANN 
  - explicitly points out that no process for such a request exists, and it 
might be necessary for IETF and ICANN to develop a mutually acceptable process 
before the request from .homenet can be considered
  - asks for IETF advice on this plan

- Ralph

> 
> Best regards,
> 
> A (speaking, of course, for myself)
> 
> -- 
> Andrew Sullivan
> a...@anvilwalrusden.com
> 
> ___
> 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] WG review of draft-ietf-homenet-dot-03

[Andrew Sullivan]

On Wed, Mar 22, 2017 at 02:00:08AM +1100, Mark Andrews wrote:
> 
> What is the point of having a MoU that names may need to be assigned
> in the root namespace if there cannot be a entry added to the root
> namespace if there is a technical need to it?

You are conflating "root namespace" and "root zone of the DNS".  We
have in fact created the former.  But this draft asks for the latter,
which is different.  We have an MoU, and it says that we won't meddle
in that zone.

Best regrds,

A

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

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

Re: [DNSOP] .arpa

[Andrew Sullivan]

Hi,

On Wed, Mar 22, 2017 at 09:19:24AM -0700, Ray Bellis wrote:
> Arguably I'm not "typical", but IMHO we shouldn't be designing for the
> lowest common denominator.

That argument is absurd on the face of it, because anyone sufficiently
clueful about systems to be using ssh or hand-entering domain names is
also sufficiently clueful to recognize that maybe they should use the
google search result that pertains to networking rather than the US
DoD.  (Presumably these are the same people who have figured out that
iab.org and iab.com are not the same organizations.)  Therefore,
homenet.arpa would work just fine for such people, there'd be no
design for LCD, and also we'd get something that would work and
wouldn't involve a constitutional crisis for IANA.

> Either way, the Homenet WG has reached its consensus decision to request
> ".homenet" rather than ".homenet.arpa".

Since the point of this discussion is to inform IETF consensus,
HOMENET's consensus is not the only thing that counts.  It is entirely
possible that HOMENET's consensus will not be the IETF consensus.

> To those that say "no insecure delegations in the root zone" because
> "DNSSEC is good"

I don't think anyone is saying anything about that.  The point is that
_someone else_ gets to decide.  The IETF has literally no say in the
decision about what goes in the root zone itself, and hasn't since the
IETF signed its MoU with ICANN.  (Some argue that for this reason the
IETF must never allocate a top-level label.  I do not agree with them,
but there is absolutely no question about whether we are in a position
to decide actual registrations in the root zone.)

The plain fact is that the IETF IANA considerations in
draft-ietf-homenet-dot-03 makes a request of IANA that the IETF has no
business making, because we are requesting an entry in a registry
whose policy is controlled by someone else.  It's clear that the
weasel words "arrange for" are there to pretend we're not making such
a request it, but the MUST NOT be signed is an attempt to specify
protocol operation in a registry where we have no business working.
If this proceeds as IETF consensus, it will be apparent that it is the
IETF, not ICANN, that threatens the stability of the IANA
arrangements.  I hope we do not have to explore that rathole in my
lifetime.

Best regards,

A (speaking, of course, for myself)

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

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

[DNSOP] draft-mglt-dnsop-dnssec-validator-requirements

[Daniel Migault]

Hi,

Please find an update of our draft on DNSSEC Validator Requirements [xml - txt].

DNS resolvers hardly enable DNSSEC as 1) resolvers are not robust too DNS 
authoritative operations - like KSK roll over, signing errors - and 2) 
network administrators have little control on these resolvers to recover such 
situations.
The draft describes how invalid DNSSEC related RRsets may be considered by the 
resolver. The listed requirements aim at designing mechanisms as well as 
interactions with network managers can easily solve/avoid these situations. 
Such mechanisms are expected to encourage DNSSEC deployment on resolvers.

Comments are welcome!

Yours,
Daniel

[txt] 
https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob/master/draft-mglt-dnsop-dnssec-validator-requirements-05.txt
[xml] 
https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob/master/draft-mglt-dnsop-dnssec-validator-requirements-05.xml


[Ericsson]

DANIEL MIGAULT
Researcher
Research

Ericsson
8500 Boulevard Decarie
H4P 2N2 Montreal, Canada
Phone +1 514 345 7900 46628
Mobile +1 514 452 2160
daniel.miga...@ericsson.com
www.ericsson.com


[http://www.ericsson.com/current_campaign]

Legal entity: Ericsson Canada Inc., registered office in Montreal. This 
Communication is Confidential. We only send and receive email on the basis of 
the terms set out at 
www.ericsson.com/email_disclaimer
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Ray Bellis]

On 22/03/2017 08:11, Tim Chown wrote:

> I’d like to think such uses are largely all GUI/icon driven.  Or perhaps
> increasingly voice driven, like Alexa. How often will foo.homenet.arpa,
> or foo.homenet be used in typical cases? 

I use ".local" to access several devices in my home network that are not
hidden behind a UI "discovery client", including my ADSB receiver and my
NAS.

I also use it for SSH access to devices that announce that service via
Bonjour rather than having to put their IPs in /etc/hosts everywhere.

Arguably I'm not "typical", but IMHO we shouldn't be designing for the
lowest common denominator.

Either way, the Homenet WG has reached its consensus decision to request
".homenet" rather than ".homenet.arpa".

I personally don't mind if it takes longer for the requested insecure
delegation to happen than for the special-use reservation to happen -
the former shouldn't be a blocker for the latter.

To those that say "no insecure delegations in the root zone" because
"DNSSEC is good", my argument is that in this particular case blocking
the request would *inhibit* use of DNSSEC in edge networks and on stub
resolvers.  The whole point of the insecure delegation is to
*facilitate* correct use of DNSSEC within Homenets.

Ray (no hat)

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

Re: [DNSOP] .arpa

[Ted Lemon]

On Mar 22, 2017, at 11:11 AM, Tim Chown  wrote:
> Well, when I print, it’s by selecting a printer by a name (that I or someone 
> gave it) from a list of printers I’ve already discovered (or configured).
> When I throw a movie from my phone to the TV, it’s by hitting an icon on the 
> video player.
> If I play from a music collection, it’s listed as an icon in Finder on my 
> Mac, as are NAS devices.

Sorry, I meant how often do users access the web ui of their internet gateway.  
 I agree that all of the above uses are generally preferably done using a GUI.  
 Even the web UI might be done with a GUI, but you will see the address in the 
address bar.

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

Re: [DNSOP] .arpa

[Tim Chown]

> On 22 Mar 2017, at 14:53, Ted Lemon  wrote:
> 
> On Mar 22, 2017, at 10:50 AM, Tim Chown  > wrote:
>> Interesting question then as to how often a typical home user would need to 
>> do so, if there’s GUI-driven service discovery on top?
> 
> How often do end users access the web ui of their browser?
> 
> (I don't know, just curious if you do.)


Well, when I print, it’s by selecting a printer by a name (that I or someone 
gave it) from a list of printers I’ve already discovered (or configured).
When I throw a movie from my phone to the TV, it’s by hitting an icon on the 
video player.
If I play from a music collection, it’s listed as an icon in Finder on my Mac, 
as are NAS devices.

I’d like to think such uses are largely all GUI/icon driven.  Or perhaps 
increasingly voice driven, like Alexa. How often will foo.homenet.arpa, or 
foo.homenet be used in typical cases? 

Is the explicit .arpa use case around using the service or device/service 
management?  Perhaps the latter is when I’m more likely to do web-based or 
ssh/CLI management. 

Tim

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

Re: [DNSOP] .arpa

[Ted Lemon]

On Mar 22, 2017, at 10:50 AM, Tim Chown  wrote:
> Interesting question then as to how often a typical home user would need to 
> do so, if there’s GUI-driven service discovery on top?

How often do end users access the web ui of their browser?

(I don't know, just curious if you do.)


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

Re: [DNSOP] .arpa

[Tim Chown]

> On 22 Mar 2017, at 12:51, Ted Lemon  wrote:
> 
> On Mar 22, 2017, at 7:50 AM, Tim Chown  > wrote:
>> Surely the people who would make comments about (say) homenet.arpa are 
>> already making comments about in-addr.arpa and ip6.arpa?  So is there really 
>> that great a harm in using .arpa for additional things (that make many lives 
>> easier in many other ways)?
> 
> How often do you type a reverse name into a URL bar or an ssh command?   
> These are different use cases.

Interesting question then as to how often a typical home user would need to do 
so, if there’s GUI-driven service discovery on top?

Tim

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

Re: [DNSOP] .arpa

[Ted Lemon]

On Mar 22, 2017, at 7:50 AM, Tim Chown  wrote:
> Surely the people who would make comments about (say) homenet.arpa are 
> already making comments about in-addr.arpa and ip6.arpa?  So is there really 
> that great a harm in using .arpa for additional things (that make many lives 
> easier in many other ways)?

How often do you type a reverse name into a URL bar or an ssh command?   These 
are different use cases.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Tim Chown]

> On 22 Mar 2017, at 11:40, Suzanne Woolf  wrote:
> 
>> On Mar 22, 2017, at 3:05 AM, Jim Reid  wrote:
>> 
>>> On 21 Mar 2017, at 14:53, Suzanne Woolf  wrote:
>>> 
>>> RFC 3172 was written in 2001…
>> 
>> RFC 3172 was an attempt to rewrite history and contrive an acronym: Address 
>> and Routing Parameter Area - really?
> 
> Well, no. I thought it wasn’t rewriting anything, but setting a future 
> direction. (The backronym was cute or annoying, depending on your POV, but 
> ultimately not that important.)
> 
>>> Respectfully, I’ve always wondered who has this problem (US or non-US) 
>>> besides network infrastructure geeks Of a Certain Age (yes, including 
>>> myself, and many IETF participants).
>> 
>> It's a convenient tool for those hostile to USG "control" of the Internet: 
>> ie the US military is responsible for everything under .arpa, the US 
>> military's ARPA has still got some special status in the 
>> operation/development/control of the Internet, etc, etc. 
> 
> So the answer to “Why not actually use it where it’s technically suitable” is 
> essentially “installed base”? 
> 
> I don’t mean to sound flippant— I’m just trying to understand the view that 
> there’s a bigger obstacle to using .arpa than there is to asking ICANN for a 
> root zone entry and engaging with all of the resulting complexities.

Surely the people who would make comments about (say) homenet.arpa are already 
making comments about in-addr.arpa and ip6.arpa?  So is there really that great 
a harm in using .arpa for additional things (that make many lives easier in 
many other ways)?

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

Re: [DNSOP] .arpa

[Suzanne Woolf]

> On Mar 22, 2017, at 3:05 AM, Jim Reid  wrote:
> 
>> On 21 Mar 2017, at 14:53, Suzanne Woolf  wrote:
>> 
>> RFC 3172 was written in 2001…
> 
> RFC 3172 was an attempt to rewrite history and contrive an acronym: Address 
> and Routing Parameter Area - really?

Well, no. I thought it wasn’t rewriting anything, but setting a future 
direction. (The backronym was cute or annoying, depending on your POV, but 
ultimately not that important.)

> 
>> Respectfully, I’ve always wondered who has this problem (US or non-US) 
>> besides network infrastructure geeks Of a Certain Age (yes, including 
>> myself, and many IETF participants).
> 
> It's a convenient tool for those hostile to USG "control" of the Internet: ie 
> the US military is responsible for everything under .arpa, the US military's 
> ARPA has still got some special status in the operation/development/control 
> of the Internet, etc, etc. 

So the answer to “Why not actually use it where it’s technically suitable” is 
essentially “installed base”? 

I don’t mean to sound flippant— I’m just trying to understand the view that 
there’s a bigger obstacle to using .arpa than there is to asking ICANN for a 
root zone entry and engaging with all of the resulting complexities.


thanks,
Suzanne

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

Re: [DNSOP] [dns-privacy] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

[Paul Vixie]

Lanlan Pan wrote:
> ... Because ECS is also based on the map of
> "*client subnet -> geolocation*" information.

Paul Vixie 于2017年3月22日周
> wait, what?

Lanlan Pan wrote:
> Hi Paul,

hi.

> https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/

this web page is factually incorrect in that it presupposes that geo-ip
is used. i have added a comment there to this effect.

the original ECS web site
(http://www.afasterinternet.com/howitworks.htm) is somewhat
marketing-oriented, but says only that "With this more intelligent
routing, customers will have a better Internet experience with lower
latency and faster speeds." in other words, it expects that a CDN will
apply its server-selection logic on an address basis, but using the
truncated client subnet rather than to the DNS request source address.
it does not dictate what the CDN's server-selection logic has to be or do.

in RFC 7871 (http://www.afasterinternet.com/ietfrfc.htm) we see this
definition:

> Topologically Close:  Refers to two hosts being close in terms of the
>   number of hops or the time it takes for a packet to travel from
>   one host to the other.  The concept of topological distance is
>   only loosely related to the concept of geographical distance: two
>   geographically close hosts can still be very distant from a
>   topological perspective, and two geographically distant hosts can
>   be quite close on the network.

there is an error on page 22 which is directly on-point:

>o  Recursive Resolvers implementing ECS should only enable it in
>   deployments where it is expected to bring clear advantages to the
>   end users, such as when expecting clients from a variety of
>   networks or from a wide geographical area.  Due to the high cache
>   pressure introduced by ECS, the feature SHOULD be disabled in all
>   default configurations.

from context, it's clear that they meant "topological area".

actual CDN technology, from as far back as Cisco Distributed Director in
the mid-1990's, has usually ignored geography, for the reasons i gave
up-thread: overlapping and incoherent topology within a geo-ip region
means that geo-location is a very poor predictor of per-path performance.

let me state (again) for the record that i was and remain opposed to ECS
because it's an obviously bad idea and the apparent need for it merely
proves that Stupid DNS Tricks
(http://queue.acm.org/detail.cfm?id=1647302) did not and could not solve
their chosen problem in the first place. it's architectural
cost-shifting, which is a form of both intellectual conversion and
economic compulsion. sad!

however, if you're going to propose a replacement for ECS, you should
correctly describe how it works. < geolocation*">> is not a correct description. if
EIL is geo-based, then it is completely different from ECS.

-- 
P Vixie

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

Re: [DNSOP] [dns-privacy] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

[Lanlan Pan]

Hi Paul,

https://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/

Paul Vixie 于2017年3月22日周三 下午4:00写道：

>
>
> Lanlan Pan wrote:
> > ... Because ECS is
> > also based on the map of  "*client subnet -> geolocation*" information.
>
> wait, what?
>
> --
> P Vixie
>
> --
致礼  Best Regards

潘蓝兰  Pan Lanlan
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] .arpa

[Patrik Fältström]

On 22 Mar 2017, at 8:05, Jim Reid wrote:

>> On 21 Mar 2017, at 14:53, Suzanne Woolf  wrote:
>>
>> RFC 3172 was written in 2001…
>
> RFC 3172 was an attempt to rewrite history and contrive an acronym: Address 
> and Routing Parameter Area - really?
>
>> Respectfully, I’ve always wondered who has this problem (US or non-US) 
>> besides network infrastructure geeks Of a Certain Age (yes, including 
>> myself, and many IETF participants).
>
> It's a convenient tool for those hostile to USG "control" of the Internet: ie 
> the US military is responsible for everything under .arpa, the US military's 
> ARPA has still got some special status in the operation/development/control 
> of the Internet, etc, etc. [And say things like "if .arpa isn't for US 
> military control, why can't the string be changed?" or ".arpa hasn't been 
> renamed since the Internet started 25-30 years ago. That proves ARPA/DoD is 
> in charge of the Internet.".] It's utter nonsense of course. But that doesn't 
> stop government officials and policymakers from making these arguments. I 
> have seen them do this many times. Sigh. RFC3172 didn't make things better.

The important thing in RFC3172 is Appendix A, the letter by which US Government 
(via Karen Rose), that was then in charge, set the scope for the IANA and use 
of .ARPA.

The next big step was the end of the contract(s) between US Gov and ICANN Oct 1 
2016.

Many steps of course remain, but it is important to separate facts from rumors, 
while at the same time not ignore the need for proper and correct information 
and informed discussions.

   paf


signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [dns-privacy] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

[Paul Vixie]

Lanlan Pan wrote:
> ... Because ECS is
> also based on the map of  "*client subnet -> geolocation*" information.

wait, what?

-- 
P Vixie

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

[DNSOP] .arpa

[Jim Reid]

> On 21 Mar 2017, at 14:53, Suzanne Woolf  wrote:
> 
> RFC 3172 was written in 2001…

RFC 3172 was an attempt to rewrite history and contrive an acronym: Address and 
Routing Parameter Area - really?

> Respectfully, I’ve always wondered who has this problem (US or non-US) 
> besides network infrastructure geeks Of a Certain Age (yes, including myself, 
> and many IETF participants).

It's a convenient tool for those hostile to USG "control" of the Internet: ie 
the US military is responsible for everything under .arpa, the US military's 
ARPA has still got some special status in the operation/development/control of 
the Internet, etc, etc. [And say things like "if .arpa isn't for US military 
control, why can't the string be changed?" or ".arpa hasn't been renamed since 
the Internet started 25-30 years ago. That proves ARPA/DoD is in charge of the 
Internet.".] It's utter nonsense of course. But that doesn't stop government 
officials and policymakers from making these arguments. I have seen them do 
this many times. Sigh. RFC3172 didn't make things better.

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