Subject: [Arcing] A bit more on the problem statement

From: Ted Hardie <[email-masked]>
Date: Wed, 3 Feb 2016 10:56:10 -0800

In the draft I posted on resolution contexts, I called the overarching set
of names "Internet names", following RFC 891.  Clearly things have moved on
from then no little, but I wanted to get back to that terminology because I
wanted to stress the internetworking aspect of the problem.

For names or identifiers to be meaningful in multiple contexts (like
different networks or administrative domains), those contexts have to see
them as part of the same namespace.  That doesn't mean that there must be
one unitary namespace for every use, but it does mean that each context
that uses a name must share the same idea of what the namespace context
is.

You can resolve that problem by having all names in a single namespace
context.  You can also resolve that by having context markers.

The issue with the first approach is that it is trivial for people to mint
new names.  If those are presumed to be within a single context, that also
means that it is trivial for those new names to conflict either with each
other or established names.  The only available point of control we have at
the moment is in resolution using a specific set of resolution protocols.
That is, a policy body may decline to allow a particular name to be
resolved with the DNS, but anything that doesn't use that set of resolution
protocols can still conflict.  I don't personally see any way to create a
point of control on the minting of the names themselves without a complete
architectural re-write of the entire Internet, so I don't think we can
change the point of control.  That leaves this approach with a pretty big
gap--any name that doesn't use the DNS as a resolution protocol is subject
to squatting, collision, or confusion.

The second approach, using context markers, is approximately where we are
today, but we are using an implicit set of context marker rather than an
explicit one.  But we're not using it particularly well.  As it stands, the
context marker (pseudo-gTLDs) requires a priori knowledge to establish
resolution context *and it doesn't allow you to mark namespaces that don't
share the syntax of the DNS*.  If what we want is a single Internet
namespace, with a marker for which resolution protocol is meant, this could
be refined a bit to work. But every single name delegation in any of the
resolution contexts will remain a source of potential collision, squatting
or confusion, because we still won't control the ability to mint names.

If we shift to an explicit set of markers, we get the following
advantages:  we can use syntax different from the syntax of the DNS; we can
avoid collision at the level of the tuple of namespace, name; we can avoid
conflating resolution context and namespace.  (Note that resolution context
is not a one-to-one mapping with protocol.  As David Conrad has been
pointing out for years, having a cryptographically signed DNS root (or
other zone) means the distribution channel for the information can change;
the resolution context does not).

The disadvantage is that every protocol that works across namespaces must
now be updated to recognize both the explicit markers and the namespaces
themselves.  That's a lot of work and, as IPv6 taught us, the network
effects run against you the whole way.  It may, however, be something that
is significantly easier to deploy incrementally than the core IP layer is.

My first question to this group is:  do folks agree with this
characterization?  If not, what's wrong?

If they do agree with the characterization of the problem, does this sketch
of solution spaces look right?

And, most importantly, which level of the problem do we think we can
solve:  the multiple namespaces one or the unitary namespace/multiple
resolution contexts one?

regards,

Ted

---

From: Douglas Otis <[email-masked]>
Date: Wed, 3 Feb 2016 16:46:52 -0800

On 2/3/16 10:56 AM, Ted Hardie wrote:
> The only available point of control we have at the
> moment is in resolution using a specific set of
> resolution protocols. That is, a policy body may decline
> to allow a particular name to be resolved with the DNS,
> but anything that doesn't use that set of resolution
> protocols can still conflict.  I don't personally see any
> way to create a point of control on the minting of the
> names themselves without a complete architectural
> re-write of the entire Internet, so I don't think we can
> change the point of control.  That leaves this approach
> with a pretty big gap--any name that doesn't use the DNS
> as a resolution protocol is subject to squatting,
> collision, or confusion.

Dear Ted,

A practical approach would carefully consider name overlays
carved out using specific “Special Use” TLDs generated
locally by resolvers able to access both DNS and local
namespace. This avoids creation of subtly different
namespaces based on protocol selectors such as
<proto-foo>://<domain-name> versus
<proto>://<domain-name>.<foo> that can make use of differing
cryptographic assurances.

The latter maps into current security and url practices and
only requires pro-active standards bodies to insure
available “Special Use” TLDs are made available to fulfill
essential needs. Otherwise users would then need to
carefully examine hffp://<domain-name> as opposed to
http://<domain-name>

.home is already being usurped and should be excluded from
DNS as representing “Special Use” for local non-multicast
naming. TLD carve-outs have been working fairly well until
debates about whether basically money should determine TLDs use.

Regards,
Douglas Otis

---

From: Dan York <[email-masked]>
Date: Thu, 4 Feb 2016 02:07:58 +0000

Ted,

Hmmm... I wrote the message as a draft and then went looking to finish it up... and seem to have sent it!  Sorry for filling your inboxes with an incomplete message!  Picking up where I left off...

On Feb 3, 2016, at 1:56 PM, Ted Hardie <[email-masked]<mailto:[email-masked]>> wrote:

If we shift to an explicit set of markers, we get the following advantages:  we can use syntax different from the syntax of the DNS; we can avoid collision at the level of the tuple of namespace, name; we can avoid conflating resolution context and namespace.

Can you give a more

Can you give an example of what you are thinking about with regard to an "explicit set of markers"?

I ask because...

The disadvantage is that every protocol that works across namespaces must now be updated to recognize both the explicit markers and the namespaces themselves.  That's a lot of work and, as IPv6 taught us, the network effects run against you the whole way.  It may, however, be something that is significantly easier to deploy incrementally than the core IP layer is.

... I think deployment of any solutions may be a huge issue, but I'm not clear about what you are thinking about as a solution.  I'm guessing you have *some* idea of how you might like to see it work.

If we think of different kinds of namespace identifiers, we have the example of the URI/URL/URN kind of notation with a protocol first.  And certainly in the earlier days of the Internet that was one mechanism we've had.  And yes, it still works today... BUT... today we're seeing so much of Internet traffic going over HTTP(S) ... and devices and applications *assuming* traffic will be going over HTTP(S)... that we can't rely as much on the protocol portion of the URI.  Thus in a world of HTTP/HTTPS it's not surprising that people are overloading existing systems (TLDs) to identify different namespaces (ex. .onion).

Another examples that occurs to me is the separate namespaces used in XML with the xmlns attribute and appropriate prefixes before elements.  But that's obviously within an XML *document* versus a network protocol.

And, most importantly, which level of the problem do we think we can solve:  the multiple namespaces one or the unitary namespace/multiple resolution contexts one?

I guess a more basic question is - are you suggesting we try to solve this problem for ALL protocols?  for just a select set of protocols (HTTP, HTTPS?)?  Or something else?

Dan

--
Dan York
Senior Content Strategist, Internet Society
[email-masked]<mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked]<mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 4 Feb 2016 13:55:36 +1100

Hi Ted,

Trying to work through this, please be patient with my potentially limited understanding / context.

> On 4 Feb 2016, at 5:56 am, Ted Hardie <[email-masked]> wrote:
> 
> In the draft I posted on resolution contexts, I called the overarching set of names "Internet names", following RFC 891.  Clearly things have moved on from then no little, but I wanted to get back to that terminology because I wanted to stress the internetworking aspect of the problem.  
> 
> For names or identifiers to be meaningful in multiple contexts (like different networks or administrative domains), those contexts have to see them as part of the same namespace.  That doesn't mean that there must be one unitary namespace for every use, but it does mean that each context that uses a name must share the same idea of what the namespace context is.  
> 
> You can resolve that problem by having all names in a single namespace context.  You can also resolve that by having context markers.  
> 
> The issue with the first approach is that it is trivial for people to mint new names.  If those are presumed to be within a single context, that also means that it is trivial for those new names to conflict either with each other or established names.  The only available point of control we have at the moment is in resolution using a specific set of resolution protocols.
> 
> That is, a policy body may decline to allow a particular name to be resolved with the DNS, but anything that doesn't use that set of resolution protocols can still conflict.  I don't personally see any way to create a point of control on the minting of the names themselves without a complete architectural re-write of the entire Internet, so I don't think we can change the point of control.  That leaves this approach with a pretty big gap--any name that doesn't use the DNS as a resolution protocol is subject to squatting, collision, or confusion.
> 
> The second approach, using context markers, is approximately where we are today, but we are using an implicit set of context marker rather than an explicit one.  But we're not using it particularly well.  As it stands, the context marker (pseudo-gTLDs) requires a priori knowledge to establish resolution context

If applications don't (somewhere) have the ability to perform resolution in that context, they're not going to work anyway, and if they do, they have the a priori knowledge necessary. 

So, I think the problem here is largely what we saw with .onion -- if your application / resolver / etc. don't recognise it as a special name, it falls back to DNS resolution, and that may have various undesirable side effects (besides not working). 

Arguably the downsides of those side effects for .onion -- given its use cases -- are pretty extreme, and so it's very interesting to me that despite that limitation, its very privacy- and security-sensitive community still decided to go in that direction.

> *and it doesn't allow you to mark namespaces that don't share the syntax of the DNS*.

How big of a problem is this? There are issues with i18n and DNS names, of course, but I don't hear people in this space saying that a big driver for them is "names that don't look like hostnames." There's a LOT of shared understanding behind DNS-style names.

> If what we want is a single Internet namespace, with a marker for which resolution protocol is meant, this could be refined a bit to work.

Are you thinking of something like a DNS record on the root zone of these domains, so that resolvers can check to see if it's meant for them?

> But every single name delegation in any of the resolution contexts will remain a source of potential collision, squatting or confusion, because we still won't control the ability to mint names.

I'm not sure how you got here, or why our (the IETF's?) control over the ability to mint names is important here. Each resolution context is going to need to control its own destiny (assuming it has a distinct name space of its own, a la .onion .home etc.)...

> If we shift to an explicit set of markers, we get the following advantages:  we can use syntax different from the syntax of the DNS; we can avoid collision at the level of the tuple of namespace, name; we can avoid conflating resolution context and namespace.  (Note that resolution context is not a one-to-one mapping with protocol.  As David Conrad has been pointing out for years, having a cryptographically signed DNS root (or other zone) means the distribution channel for the information can change; the resolution context does not).
> 

I'm not really sure what direction you're thinking of going here, but I am reminded somewhat of previous discussions to define how to transport DNSSEC-signed records inside HTTP/2 frames, thereby establishing an independent (albeit syntactically and semantically very similar) resolution protocol for the same context. That hasn't gone anywhere, but it's still lurking out there as a possibility, AIUI.

> My first question to this group is:  do folks agree with this characterization?  If not, what's wrong?
> 
> If they do agree with the characterization of the problem, does this sketch of solution spaces look right?
> 

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Ted Hardie <[email-masked]>
Date: Thu, 4 Feb 2016 10:24:01 -0800

On Wed, Feb 3, 2016 at 6:07 PM, Dan York <[email-masked]> wrote:

> Ted,
>
> Hmmm... I wrote the message as a draft and then went looking to finish it
> up... and seem to have sent it!  Sorry for filling your inboxes with an
> incomplete message!  Picking up where I left off...
>
>
> On Feb 3, 2016, at 1:56 PM, Ted Hardie <[email-masked]> wrote:
>
> conflating resolution context and namespace.
>
>
> Can you give a more
>
>
> ... I think deployment of any solutions may be a huge issue, but I'm not
> clear about what you are thinking about as a solution.  I'm guessing you
> have *some* idea of how you might like to see it work.
>
>
​I don't think there is any obvious way forward here; there are a lot of
trade-offs in adopting specific approaches or syntax.  The problem isn't
insoluble:  both URNs and Handles have multiple disjoint namespaces and a
way to disambiguate among them.  But getting the markers correct at this
point to allow new namespaces in existing, common protocol slots would
require a lot of analysis and work.​

> If we think of different kinds of namespace identifiers, we have the
> example of the URI/URL/URN kind of notation with a protocol first.  And
> certainly in the earlier days of the Internet that was one mechanism we've
> had.  And yes, it still works today... BUT... today we're seeing so much of
> Internet traffic going over HTTP(S) ... and devices and applications
> *assuming* traffic will be going over HTTP(S)... that we can't rely as much
> on the protocol portion of the URI.  Thus in a world of HTTP/HTTPS it's not
> surprising that people are overloading existing systems (TLDs) to identify
> different namespaces (ex. .onion).
>
> ​
So, I believe we could develop a common URL sysntax that permit a nested
URN/handle/other-identified-namespace, as you could stretch a point to
assert that those are reg​istered names and that any syntax that fell under
regname was fair game.  RFC 3986 says:

 This specification does not mandate a particular registered name
   lookup technology and therefore does not restrict the syntax of reg-
   name beyond what is necessary for interoperability.  Instead, it
   delegates the issue of registered name syntax conformance to the
   operating system of each application performing URI resolution, and
   that operating system decides what it will allow for the purpose of
   host identification.

But most approaches would upend every parser out there at the moment, which
is a big, hairy deal.  We'd have to be convinced that this was useful,
deployable, and the right choice before we did that, and, perhaps more
importantly, that the failures that would inevitably occur would be limited
to the new namespaces.

 ​

> Another examples that occurs to me is the separate namespaces used in XML
> with the xmlns attribute and appropriate prefixes before elements.  But
> that's obviously within an XML *document* versus a network protocol.
>
> ​​

> I guess a more basic question is - are you suggesting we try to solve this
> problem for ALL protocols?  for just a select set of protocols (HTTP,
> HTTPS?)?  Or something else?
>
>
​I think the nature of these names is that the ones that move from protocol
context to protocol context are the ones that present the real problem.  So
I'm not sure that the size of the ocean to be boiled can be restricted much
by limiting only to "successful, widely deployed protocols".  But I'm
certainly willing to listen if someone else has another way forward here.

regards,

Ted​

> [email-masked]   +1-802-735-1624
> Jabber: [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Thu, 4 Feb 2016 11:44:20 -0800

Howdy,

Replies, but not necessarily answers, in-line.

On Wed, Feb 3, 2016 at 6:55 PM, Mark Nottingham <[email-masked]> wrote:

> > In the draft I posted on resolution contexts, I called the overarching
> set of names "Internet names", following RFC 891.  Clearly things have
> moved on from then no little, but I wanted to get back to that terminology
> because I wanted to stress the internetworking aspect of the problem.
> >
> that uses a name must share the same idea of what the namespace context is.
> >
> > The issue with the first approach is that it is trivial for people to
> mint new names.  If those are presumed to be within a single context, that
> also means that it is trivial for those new names to conflict either with
> each other or established names.  The only available point of control we
> have at the moment is in resolution using a specific set of resolution
> protocols.
> >
> > The second approach, using context markers, is approximately where we
> are today, but we are using an implicit set of context marker rather than
> an explicit one.  But we're not using it particularly well.  As it stands,
> the context marker (pseudo-gTLDs) requires a priori knowledge to establish
> resolution context
>
> If applications don't (somewhere) have the ability to perform resolution
> in that context, they're not going to work anyway, and if they do, they
> have the a priori knowledge necessary.
>
> ​So, it doesn't have to be a priori.  If there were a protocol slot for
resolution context, they could derive the context from that protocol slot;
maybe that fails (without the knock-on effect you list below, since there
is no default), maybe it doesn't (if the context given uses a protocol
known to the resolution subsystem).  Several of the systems have methods
for determining how to resolve a name without a priori knowledge; they just
haven't scaled to the full Internet scale.​

> So, I think the problem here is largely what we saw with .onion -- if your
> application / resolver / etc. don't recognise it as a special name, it
> falls back to DNS resolution, and that may have various undesirable side
> effects (besides not working).
>
> Arguably the downsides of those side effects for .onion -- given its use
> cases -- are pretty extreme, and so it's very interesting to me that
> despite that limitation, its very privacy- and security-sensitive community
> still decided to go in that direction.
>
>
> How big of a problem is this? There are issues with i18n and DNS names, of
> course, but I don't hear people in this space saying that a big driver for
> them is "names that don't look like hostnames." There's a LOT of shared
> understanding behind DNS-style names.
>
>
​There is a lot of shared understanding behind hostname-style names, but
there are also names that don't work in that context because of label
length restrictions or other DNS restrictions (names in ASCII distinguished
by case etc.).

>
> > If what we want is a single Internet namespace, with a marker for which
> resolution protocol is meant, this could be refined a bit to work.
>
> Are you thinking of something like a DNS record on the root zone of these
> domains, so that resolvers can check to see if it's meant for them?
>
>
​Warren Kumari and Andrew Sullivan proposed a pseudo-TLD, alt, which would
function this way; names under .alt would indicate the resolution context
in the delegations from .alt, and the names under that would use it (
draft-ietf-dnsop-alt-tld
<https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-03>)​.  You could
also do this other ways (special prefix like the Punycode prefix, etc.).
It partitions the single namespace into DNS context resolution and non-DNS
context resolution, but it remains a unitary namespace other than that.

> > But every single name delegation in any of the resolution contexts will
> remain a source of potential collision, squatting or confusion, because we
> still won't control the ability to mint names.
>
> I'm not sure how you got here, or why our (the IETF's?) control over the
> ability to mint names is important here. Each resolution context is going
> to need to control its own destiny (assuming it has a distinct name space
> of its own, a la .onion .home etc.)...
>
>
​If we get broad agreement to use a particular signal, like .alt, then
folks minting new namespaces in .alt can avoid collision with a simple FCFS
registry.  If everyone plays nice, there is no collision and you have no
big issues.  But we have no way of making that so, and we have seen in the
pseudo-TLD case that people mint these, use them, and then require updates
of others to deal with the collisions.  Depending on the usage of .alt or a
similar signal, that could remain a concern (at least version of the
proposal had no registry at all, just the reserved top label).

> > The disadvantage is that every protocol that works across namespaces
> must now be updated to recognize both the explicit markers and the
> namespaces themselves.  That's a lot of work and, as IPv6 taught us, the
> network effects run against you the whole way.  It may, however, be
> something that is significantly easier to deploy incrementally than the
> core IP layer is.
>
> I'm not really sure what direction you're thinking of going here, but I am
> reminded somewhat of previous discussions to define how to transport
> DNSSEC-signed records inside HTTP/2 frames, thereby establishing an
> independent (albeit syntactically and semantically very similar) resolution
> protocol for the same context. That hasn't gone anywhere, but it's still
> lurking out there as a possibility, AIUI.
>
>
​That's a different protocol, but the same resolution context, at least in
my view.  If I sent a web server dns: URLs and it responded with the
appropriate records, I am still get DNS resolution (and demonstrably
correct resolution, with DNS​SEC), just not using the DNS protocol.  That's
the point I was making when I mentioned David Conrad's long history of
comments on this topic.

> ​regards,

Ted​

---

From: Douglas Otis <[email-masked]>
Date: Thu, 4 Feb 2016 15:00:44 -0800

On 2/4/16 11:44 AM, Ted Hardie wrote:
> If we get broad agreement to use a particular signal, 
> like .alt, then folks minting new namespaces in .alt can 
> avoid collision with a simple FCFS registry.  If everyone
> plays nice, there is no collision and you have no big
> issues.  But we have no way of making that so, and we
> have seen in the pseudo-TLD case that people mint these,
> use them, and then require updates of others to deal with
> the collisions.  Depending on the usage of .alt or a
> similar signal, that could remain a concern (at least
> version of the proposal had no registry at all, just the
> reserved top label).

Dear Ted,

Why assume .home should be converted to .home.alt? Is this
to ensure .alt gains inertia with its namespace containing
definitions similar to those found with
https://tools.ietf.org/html/draft-cheshire-homenet-dot-home-02?

Open-ended FCFS registration will encourage an explosion of
variant namespaces having any number of resolution methods
and context. It seems safer to keep .home as defined by
draft-cheshire-homenet-dot-home-02, and let .alt develop
independently. In the goodness of time resource assessments
and related risks assessments can then be made.

Small home CPE devices offer limited storage and need
simplistic access methods to limit vulnerabilities and
coding complexity. As such, offering a highly extensible
resolution structure as a first step seems ill considered.
Otherwise, assessing security risks will provide resulting
extensibility APIs likely to make Java and Flash defense
seem trivial in comparison and will do nothing to limit the
leakage of .home.

Regards,
Douglas Otis

---

From: Ted Hardie <[email-masked]>
Date: Thu, 4 Feb 2016 15:12:31 -0800

> https://tools.ietf.org/html/draft-cheshire-homenet-dot-home-02?
​For what it is worth, I think you missed the fact I was citing
someone else's work, not advocating .alt myself.  That said,
I believe the draft you cite has a method that covers this:
​

> _______________________________________________
> Arcing mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/arcing
>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 4 Feb 2016 15:15:39 -0800

Sorry, I mis-licked and this went out early.

​

   For residential home networks, Zero Configuration [ZC
<https://tools.ietf.org/html/draft-cheshire-homenet-dot-home-02#ref-ZC>]
operation is
   desirable, without requiring any manual configuration from the user.
   A client device learns about its network environment in a variety of
   ways.  It builds a list of network-recommended DNS search domains
   using DHCP options 15 (Domain Name option [RFC2132
<https://tools.ietf.org/html/rfc2132>]) and 119 (Domain
   Search option [RFC3397 <https://tools.ietf.org/html/rfc3397>]).  It
builds a list of network-recommended
   DNS-SD browsing domains by sending domain enumeration queries
   [RFC6763 <https://tools.ietf.org/html/rfc6763>].

​

>> and context.
​This is possible, but unless these are deemed a valuable commodity,
it seems somewhat unlikely.  Registry policy can certainly be tweaked
to "expert review" or something so that a dictionary attack on .alt
fails.

But that's a good bit further along than we are.

regards,

Ted​

> It seems safer to keep .home as defined by

---

From: Douglas Otis <[email-masked]>
Date: Thu, 4 Feb 2016 20:41:33 -0800

On 2/4/16 3:15 PM, Ted Hardie wrote:
> For what it is worth, I think you missed the fact I was 
> citing someone else's work, not advocating .alt myself. 
> That said, I believe the draft you cite has a method that
> covers this:

Dear Ted,

The draft
https://tools.ietf.org/html/draft-cheshire-homenet-dot-home-02
describes a Special-Use domain but it does not overcome the
need for a domain. There are no valid justifications not to
allow .home as a Special-Use domain. Homenet protocols
require a domain to publish DNS-SD resources to avoid
multicast normally blocked by typical router bridges.

To avoid multicast, DNS-SD resources must not be published
below the Special-Use domain .local. Unfortunately, there
are no Special-Use local non-multicast defined domains where
access can be safely constrained. The alternative use of an
Internet domain necessitates administration of services
exposed to the Internet. Such exposure will necessitate far
greater resources defending against Internet access. Such
increased exposure may also cause private and possibly
critical resources needed locally to become compromised or
made inaccessible.

>> Open-ended FCFS registration will encourage an 
>> explosion of variant namespaces having any number of 
>> resolution methods and context.
> 
> ​This is possible, but unless these are deemed a valuable
> commodity, it seems somewhat unlikely.  Registry policy
> can certainly be tweaked to "expert review" or something
> so that a dictionary attack on .alt fails.

Why impose the burden of needing to support public domains
on home networks as an aspect of an array of .alt
definitions? A direct singular definition prefaced at the
outset as offering only a private namespace greatly
simplifies and advances homenet development.

This is not advocating for a new TLD.  Rather this is
advocating for the elimination of a Special-Use TLD from DNS
altogether to simplify much needed protection of information.

Regards,
Douglas Otis

---

From: Edward Lewis <[email-masked]>
Date: Sat, 13 Feb 2016 20:31:34 +0000

Replying to this, having at least skimmed, if not read the followups...

>characterization?  If not, what's wrong?

I agree fully, FWIW.

>sketch of solution spaces look right?

Yep.

>solve:  the multiple namespaces one or the unitary namespace/multiple

One solution is to define a single namespace, complimentary to as much
de-jure use that now exists.  Defining what protocols "support" the
namespace can be left to the protocol's discretion.  What I mean is, I
tried for a while to define the scope of protocols that I wanted to have
Domain Names apply to, but calling the set something like "IETF protocols"
turned out to be inaccurate.  So I began to think of - just define a name
space and see what protocols "come" to it.

There's a lot to discuss.  I think markers approach is currently the most
appealing, but, you never can tell at this stage.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 19 Feb 2016 16:24:35 -0800

On 2/13/16 12:31 PM, Edward Lewis wrote:
>> My first question to this group is:  do folks agree
>> with this characterization?  If not, what's wrong?
> 
> I agree fully, FWIW.
> 
>> If they do agree with the characterization of the
>> problem, does this sketch of solution spaces look
>> right?
> 
> Yep.
> 
>> And, most importantly, which level of the problem do we
>> think we can solve:  the multiple namespaces one or the
>> unitary namespace/multiple resolution contexts one?
> 
> One solution is to define a single namespace,
> complimentary to as much de-jure use that now exists.
> Defining what protocols "support" the namespace can be
> left to the protocol's discretion.  What I mean is, I 
> tried for a while to define the scope of protocols that I
> wanted to have Domain Names apply to, but calling the set
> something like "IETF protocols" turned out to be
> inaccurate.  So I began to think of - just define a name 
> There's a lot to discuss.  I think markers approach is
> currently the most appealing, but, you never can tell at
> this stage.

Dear Edward,

This is likely my last comment.

Developing a grand scheme to identify how future namespace
resolution is to be handled should be balanced against the
specific solution of a non-global .home TLD offering a
concise and safe method made available early in the homenet
process as a means to avoid delay and security risks
incumbent with any future grand multipurpose scheme.

Homenet offers homes multi-router environments based on IPv6
with services found using DNS-SD. In nearly every possible
deployment of typical home networks generally lacking key
security components, publishing DNS-SD within global DNS
namespace will expose a tremendous level of device
vulnerabilities likely to include those discovered over the
last few years or more.

Don't insist adoption of draft-cheshire-homenet-dot-home-02
must follow some grander scheme that might make use of an
alternate root or URL modification. Any such approach
doubtlessly precludes essential compatibilities needing
consideration for Homenet deployment.

Regards,
Douglas Otis

---

From: Edward Lewis <[email-masked]>
Date: Sat, 20 Feb 2016 02:43:56 +0000

>This is likely my last comment.

Apparently something said touched a nerve.  If it's frustration over
repeatedly making a point, I'll use this old reply of mine: It might be
the 10th time you've said "it" but this is the first time I've heard "it."
 If there's something else, I'll just state that I haven't been closely
following the homenet wg in the past few years, nor the dnssd wg for that
matter, so perhaps there's a boatload of context buried in mail archives.

>consideration for Homenet deployment.

Due to what I read as exasperation, I looked at previous messages on the
mail list and see you've mentioned this draft in each of your posts.  So,
I looked it up and gave a quick scan.

Before I'd comment on it, I would need to read it more thoroughly and I'm
not sure this mail list is the appropriate place to make comments.
(Perhaps it is, it's not a draft-ietf-homenet-...)  You mention "Don't
insist adoption of" - what does that mean?  E.g., Adoption as a WG item in
homenet, adoption as an IETF standard, adoption by the ARCING mail list,
or something else?

Still, the use case raised seems rather significant, obviously akin to the
IPv4 address ranges that by convention are not advertised to the open
Internet (inter-enterprise is the term used in "Address Allocation for
Private Internets").  The trouble is that unlike routers, DNS elements
don't have an innate notion of "internal" and "external" interfaces.
(There are de jure definitions of "views", multiple implementations of the
concept but no protocol standards-track document has ever been produced.)
So, we can't straight up look to how IPv4 addressing and routing for a
solution to the use case covered in the draft cited.

Beyond that I do see that this use case is interesting to bring into any
discussion on the nature of Domain Names or a general namespace.  The
string "home" could qualify as a resolution switch.  Like "onion" the
process for resolving is different from traditional means.  Unlike onion,
the process for "home" uses the protocol already spoken over port 53
(i.e., the DNS protocol).  I can see this as fertile ground for work.