Subject: [homenet] What I really meant by option 5

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Jul 2016 15:44:51 +0200

The document as written causes some harm, but less harm than updating it.
The text in the document as written as to how domain names are resolved is
not very good, and really really needs to be clarified with a detailed
document that explains how name resolution works on the homenet.

But I think we all accept that there's going to have to be a special-use
top-level name allocated.   That name is either going to be '.home' or
'.homenet' as far as I can tell.

Andrew made a very good case for why it shouldn't be .home.   I agree with
him, but not strongly enough that I would kick up a fuss of the consensus
was to allocate .home anyway.    I also don't mind the two-stage process if
IETF leadership is willing to do what I asked at the mic and actively keep
the debate on track.

But it's really a three-stage process: do the erratum as an update, then do
the 6761 allocation of either .home or .homenet, then do the document that
explains how it all works.   We need step two to happen _soon_ or we are in
trouble.   Step 1 may be necessary and highly motivating because of the
layer 9 problems that this mistake caused, but if we only do step 1 and
then trail off on step 2, the effect in the market is either going to be
that everybody uses .home anyway, or else that everybody uses something
different.   Neither of these outcomes are good outcomes.

---

From: Terry Manderson <[email-masked]>
Date: Mon, 18 Jul 2016 14:53:11 +0000

Thank you for clarifying what you meant Ted.

Cheers
Terry

On 18/07/2016, 11:44 PM, "Ted Lemon" <[email-masked]> wrote:

>  The text in the document as written as to how domain names are resolved
>is not very good, and really really needs to be clarified with a detailed
>document that explains
> how name resolution works on the homenet.
>
>
>Andrew made a very good case for why it shouldn't be .home.   I agree
>with him, but not strongly enough that I would kick up a fuss of the
>consensus was to allocate .home anyway.    I also don't mind the
>two-stage process if IETF leadership is willing
> to do what I asked at the mic and actively keep the debate on track.
>
>
>But it's really a three-stage process: do the erratum as an update, then
>do the 6761 allocation of either .home or .homenet, then do the document
>that explains how it all works.   We need step two to happen _soon_ or we
>are in trouble.   Step 1 may be
> necessary and highly motivating because of the layer 9 problems that
>this mistake caused, but if we only do step 1 and then trail off on step
>2, the effect in the market is either going to be that everybody uses
>.home anyway, or else that everybody uses something

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Jul 2016 16:56:34 +0200

Sure.   Sorry if that was a bit of a shocking comment--I just feel like
we're at risk of backing off a cliff because we're looking in the wrong
direction.   Obviously we need to do something, but we have to be careful
that we don't create collateral damage in the process.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 18 Jul 2016 17:04:51 +0200

> On Jul 18, 2016, at 3:44 PM 7/18/16, Ted Lemon <[email-masked]> wrote:
> 
> The document as written causes some harm, but less harm than updating it.   The text in the document as written as to how domain names are resolved is not very good, and really really needs to be clarified with a detailed document that explains how name resolution works on the homenet.

I agree with Ted 100% about the text in the document regarding name resolution.  In my opinion, the proper organization for the specifications here would be to ensure that the details of name resolution in homenet are correctly specified in Ted's document or another separate document, with text in the HNCP document the specifies how the requisite configuration information is carried in HNCP.

> But I think we all accept that there's going to have to be a special-use top-level name allocated.   That name is either going to be '.home' or '.homenet' as far as I can tell.
> 
> Andrew made a very good case for why it shouldn't be .home.   I agree with him, but not strongly enough that I would kick up a fuss of the consensus was to allocate .home anyway.    I also don't mind the two-stage process if IETF leadership is willing to do what I asked at the mic and actively keep the debate on track.
> 
> But it's really a three-stage process: do the erratum as an update, then do the 6761 allocation of either .home or .homenet, then do the document that explains how it all works.   We need step two to happen _soon_ or we are in trouble.   Step 1 may be necessary and highly motivating because of the layer 9 problems that this mistake caused, but if we only do step 1 and then trail off on step 2, the effect in the market is either going to be that everybody uses .home anyway, or else that everybody uses something different.   Neither of these outcomes are good outcomes.

I agree with Ted 100% here, as well.  We need to solve immediately the specific problem that .home was either delegated as a DNS TLD without appropriate process, or was designated as a Special Use Name without an associated entry in the registry.  (In my opinion, RFC 7788 is not clear about which of those two buckets ".home" falls into.)  Then we need to specify the behavior of the new label, which I assume will be a Special use name, and add it to the Special Use Names registry as quickly as possible.

- Ralph

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 23 Jul 2016 23:17:01 +0200

> '.homenet' as far as I can tell.

Ted,

Is this domain meant to be specific to HNCP, or is it a generic site-local
domain for home networks?  If the former, then I'm mostly okay with .homenet.
If the latter, then I amn't.

(Do you think we could get .tbd?  That would be the best way to confuse
implementers.)

-- Juliusz

---

From: Ralph Droms <[email-masked]>
Date: Sat, 23 Jul 2016 20:51:22 -0400

> On Jul 23, 2016, at 5:17 PM 7/23/16, Juliusz Chroboczek <[email-masked]> wrote:
> 

Good question.  Seems like we need to come to consensus on a reasonably formal definition of the desired behavior for ".new-label", and then we can decide whether that definition is just appropriate for a home network or for other scenarios, as well.

For example, if the scope of the "site" used for site-local evaluation depends on the network edge definition from HNCP, then ".new-local" might only be appropriate for deployment scenarios that include HNCP.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Sun, 24 Jul 2016 08:46:44 +0200

.LSD would be the obvious choice (local service discovery). However, it
would be confusing to users. .LAN would be another good alternative except
that it's already a bit polluted, and the meaning isn't widely understood.
I think in the general case what we want is a global name. In the cases
where .HOMENET would be wrong, a global name would be more appropriate
anyway. The motivating used case for .HOMENET really is the homenet. The
problem we have in 7788 is that the hncp doc really wasn't the right place
to make that choice in the first place. So trying to fit the choice to all
possible uses of hncp, for which I know you have great ambitions, is
probably the wrong thing to do.

On Jul 24, 2016 02:51, "Ralph Droms" <[email-masked]> wrote:

> Good question.  Seems like we need to come to consensus on a reasonably
> formal definition of the desired behavior for ".new-label", and then we can
> decide whether that definition is just appropriate for a home network or
> for other scenarios, as well.
>
> For example, if the scope of the "site" used for site-local evaluation
> depends on the network edge definition from HNCP, then ".new-local" might
> only be appropriate for deployment scenarios that include HNCP.
>
> - Ralph
>
> >

---

From: Mark Andrews <[email-masked]>
Date: Tue, 26 Jul 2016 20:11:37 +1000

In message <[email-masked]>, Ralph Droms writes:
> > The document as written causes some harm, but less harm than updating
> > it.   The text in the document as written as to how domain names are
> > resolved is not very good, and really really needs to be clarified with a
> > detailed document that explains how name resolution works on the homenet.
>
> I agree with Ted 100% about the text in the document regarding name
> resolution.  In my opinion, the proper organization for the
> specifications here would be to ensure that the details of name
> resolution in homenet are correctly specified in Ted's document or
> another separate document, with text in the HNCP document the specifies
> how the requisite configuration information is carried in HNCP.
>
> > But I think we all accept that there's going to have to be a
> > special-use top-level name allocated.   That name is either going to be
> > '.home' or '.homenet' as far as I can tell.
> >
> > two-stage process if IETF leadership is willing to do what I asked at the
> > mic and actively keep the debate on track.
> >
> > But it's really a three-stage process: do the erratum as an update,
> > then do the 6761 allocation of either .home or .homenet, then do the
> > document that explains how it all works.   We need step two to happen
> > _soon_ or we are in trouble.   Step 1 may be necessary and highly
> > motivating because of the layer 9 problems that this mistake caused, but
> > if we only do step 1 and then trail off on step 2, the effect in the
> > market is either going to be that everybody uses .home anyway, or else
> > that everybody uses something different.   Neither of these outcomes are
> > good outcomes.
>
> I agree with Ted 100% here, as well.  We need to solve immediately the
> specific problem that .home was either delegated as a DNS TLD without
> appropriate process, or was designated as a Special Use Name without an
> associated entry in the registry.  (In my opinion, RFC 7788 is not clear
> about which of those two buckets ".home" falls into.)  Then we need to
> specify the behavior of the new label, which I assume will be a Special
> use name, and add it to the Special Use Names registry as quickly as
> possible.
>
> - Ralph

The behaviour needs to be similar to that of the RFC 1918 in-addr.arpa
suffixes.  There needs to be a insecure DNSSEC delegation to servers
that return NXDOMAIN for all names below the chosen label.  This
way validating clients do not get BOGUS as validation result when
handed a foo.<TBD> lookup result.  Additionally validating clients
do not need special knowledge for .<TBD>.

The root servers will return a authoritative NOERROR NODATA for
DS/<TBD>.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 27 Jul 2016 09:44:02 +0200

Yes, this would be a "locally-served domain."