date:20160718

Dear all,

We only confirmed the yo-yo issue on Sunday, which caused me to send the
latest version of my slides at the very latest moment.  I therefore cannot
blame the chairs for forcing me to work with an older version of my talk
which didn't contain the explanation -- oh, what the heck, yes, I can ;-)
Please bear with me while I lecture a little.

It has been known since at least the early noughts that in a wireless mesh
network, no matter how well designed, persistently lossy links are
unavoidable.  Consider the following topology, where A, B and C are
wireless routers:

. . . . .
   . .
  A --- B --- C

By design, A and B are neighbours, as are B and C.  A and C are not
supposed to be neighbours (they are out of range of each other), but it is
unavoidable that once in a while C will hear a packet coming from A.

In the current version of HNCP, as soon as C receives a multicast
NETWORK-STATE from A, it inserts A in its list of peers, and, MS-Trickle
permitting, floods a new long NODE-STATE throughout the network.  Since it
no longer receives anything from C, it times out A from its list of
neighbours, and floods again.  The result is two long NODE-STATES flooded
across the network for every packet that manages to cross a highly
marginal link.  In a dense mesh, the number of such highly marginal links
is roughly quadratic in the number of routers -- the effect is that with
just 7 routers, we see one spurious reflooding every few seconds.  (Please
see the end of this message for a packet trace.)

HNCP, however, has a number of features that prevent the spurious topology
changes and associated refloodings from having any serious consequences.
First, the "ad-hoc" interface type (Section 5.1 of RFC 7788) is designed
so that a spurious topology change doesn't cause any renumbering -- since
the set of Common Links doesn't change, the PA algorithm is never invoked.
Second, even if the links are mis-configured, the PA algorithm is stable
enough to avoid renumbering outside of the affected link in most cases.
And last, reflooding is controlled by MS-Trickle (an algorithm that is
almost, but not quite, exactly unlike Trickle), which prevents refloodings
from happening too often.

I'm not sure what to do about this.  We could of course ignore the
issue -- after all, it's just a few hundred bytes per second extra control
traffic -- but I'm a little uncomfortable with that, I fear that it might
get us into trouble at some later stage.  Markus has a suggestion that
consists in tweaking the parameters of MS-Trickle.  My intuition is that
it's the wrong level at which to tackle the problem, but I have been wrong
about MS-Trickle before.

Appended below for your enjoyment is a fragment of a packet trace.  At
time 25.897 node ef:36:04:89 floods its node state.  At time 31.359, it
floods its state again, which is almost identical -- the only change is
the addition of the neighbour 9b:18:b7:26.

-- Juliusz

16:21:25.897046 IP6 (hlim 64, next-header UDP (17) payload length: 1396) 
fe80::e246:9aff:fe4e:912a.8231 > fe80::e246:9aff:fe4e:91e4.8231: [udp sum ok] 
hncp (1388)
Node endpoint (12) NID: ef:36:04:89 EPID: 0004
Node state (1376) NID: ef:36:04:89 seqno: 72968 2.11s hash: 
c97a0c0c205d9de1
Peer (16) Peer-NID: 24:1f:49:aa Peer-EPID: 0002 Local-EPID: 
0004
Peer (16) Peer-NID: 24:1f:49:aa Peer-EPID: 0003 Local-EPID: 
0003
Peer (16) Peer-NID: 75:05:c4:15 Peer-EPID: 0002 Local-EPID: 
0003
Peer (16) Peer-NID: 90:d1:74:28 Peer-EPID: 0003 Local-EPID: 
0004
Peer (16) Peer-NID: 90:d1:74:28 Peer-EPID: 0004 Local-EPID: 
0003
Peer (16) Peer-NID: 9b:18:b7:26 Peer-EPID: 0002 Local-EPID: 
0004
HNCP-Version (22) M: 0 P: 4 H: 4 L: 4 User-agent: hnetd/cda52dc
Assigned-Prefix (18) EPID: 0001 Prty: 2 Prefix: 
fd1f:f88c:e207:65::/64
Assigned-Prefix (18) EPID: 0002 Prty: 2 Prefix: 
fd1f:f88c:e207:47::/64
Assigned-Prefix (18) EPID: 0004 Prty: 2 Prefix: 
fd1f:f88c:e207:61::/64
Assigned-Prefix (20) EPID: 0001 Prty: 2 Prefix: 
2001:660:3301:9209:1e::/80
Assigned-Prefix (20) EPID: 0002 Prty: 2 Prefix: 
2001:660:3301:9209:41::/80
Assigned-Prefix (20) EPID: 0004 Prty: 3 Prefix: 
2001:660:3301:9208:61::/80
Assigned-Prefix (25) EPID: 0001 Prty: 2 Prefix: 
10.219.152.0/24
Assigned-Prefix (25) EPID: 0002 Prty: 2 Prefix: 
10.191.218.0/24
Assigned-Prefix (25) EPID: 0004 Prty: 2 Prefix: 10.0.97.0/24
Node-Address (24) EPID: 0001 IP Address: 10.219.152.5
Node-Address (24) EPID: 0001 IP Address: 
2001:660:3301:9209:1e::5
Node-Address (24) EPID: 0001 IP Address: 
fd1f:f88c:e207:65::5
Node-Address (24) EPID: 0002 IP

Re: [homenet] My comment about Ted's naming draft

I think it's should in the sense that there may be done reason not to do it
on some case and we don't want to preclude that because there is no
protocol reason to do so, but we expect that it will be allocated unless
there is some good reason. We talked about this at length a couple of years
ago and captured the intent in the architecture doc, but maybe not in
enough detail?

On Jul 18, 2016 23:28, "Juliusz Chroboczek" 
wrote:

> Why wouldn't you allocate one?

I would.  ULAs are a goodness.  Probably.  I'm planning to add ULA
generation to shncpd at some future date, and perhaps even enable it by
default.

The question is about the level of MUSTiness.  I only see two reasonable
possibilities:

  1. ULA is SHOULD, and we cannot rely on their existence;
  2. ULA is MUST, which puts an additional requirement on implementations,
 but allows us to rely on their existence except during reconvergence.

No compromise between these two positions is possible.  It is not reasonable
to say that ULA is SHOULD while simultaneously relying on their existence,
which is what we're apparently trying to do.

-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] My comment about Ted's naming draft

> Why wouldn't you allocate one?

I would.  ULAs are a goodness.  Probably.  I'm planning to add ULA
generation to shncpd at some future date, and perhaps even enable it by
default.

The question is about the level of MUSTiness.  I only see two reasonable
possibilities:

  1. ULA is SHOULD, and we cannot rely on their existence;
  2. ULA is MUST, which puts an additional requirement on implementations,
 but allows us to rely on their existence except during reconvergence.

No compromise between these two positions is possible.  It is not reasonable
to say that ULA is SHOULD while simultaneously relying on their existence,
which is what we're apparently trying to do.

-- Juliusz

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

Re: [homenet] My comment about Ted's naming draft

Why wouldn't you allocate one?

On Jul 18, 2016 22:57, "Juliusz Chroboczek" 
wrote:

> >> (4) Is there WG consensus on requiring a ULA?
>
> > I believe that this is.
> > a) it's in rfc7084 (so they are there even before homenet existed)
> > b) it's in rfc7368 (it's in our architecture)
>
> RFC 7084 Section 4.3 says:
>
> The IPv6 CE router SHOULD be capable of generating a ULA prefix
> [RFC4193].
>
> RFC 7368 Section 2.4 says:
>
> A home network running IPv6 should deploy ULAs
>
> RFC 7788 Section 6.5 says:
>
> An HNCP router SHOULD create a ULA prefix if there is no other
> IPv6 prefix with a preferred time greater than 0 in the network.
> It MAY also do so if there are other delegated IPv6 prefixes
>
> I do not believe that there is WG consensus that ULA generation should be
> a MUST.
>
> -- Juliusz
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] My comment about Ted's naming draft

>> (4) Is there WG consensus on requiring a ULA?

> I believe that this is.
> a) it's in rfc7084 (so they are there even before homenet existed)
> b) it's in rfc7368 (it's in our architecture)

RFC 7084 Section 4.3 says:

The IPv6 CE router SHOULD be capable of generating a ULA prefix [RFC4193].

RFC 7368 Section 2.4 says:

A home network running IPv6 should deploy ULAs

RFC 7788 Section 6.5 says:

An HNCP router SHOULD create a ULA prefix if there is no other
IPv6 prefix with a preferred time greater than 0 in the network.
It MAY also do so if there are other delegated IPv6 prefixes

I do not believe that there is WG consensus that ULA generation should be
a MUST.

-- Juliusz

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

Re: [homenet] My comment about Ted's naming draft

> Right now HNCP doesn't actually seem to have a TLV for advertising
> resolvers.

That's exactly what I was trying to get at.

> How does this work now?

Not very well.

HNCP announces *external* resolvers in the DHCPv4- and DHCPv6-DATA
sub-TLVs of the EXTERNAL-CONNECTION TLV.  Hnetd uses this data to set up
a recursive DNS server which has all the usual smarts for selecting the
server to forward to, and also acts as an authoritative server for some
local zones (I'm shaky on the exact details).  Shncpd is much dumber, it
just merges all the EXTERNAL-CONNECTIONs' data and pushes the result to
the client using RA and DHCPv4 (shcnpd has no support for DHCPv6 yet).

There is no provision for advertising a DNS server that's not associated
with an external connection, i.e. that's within the Homenet.

> I think the election process is probably the hardest thing in this
> solution, and I am hoping someone already knows how to do it... :)

HNCP does perform a number of link-local elections, and uses two different
mechanisms:

  - for advertising assigned prefixes, it uses an OSPF-like election
mechanism, but with no pre-elected backup;
  - for choosing e.g. DHCPv4 servers, it uses an ISIS-like election
mechanism, which I happen to believe is a bad choice.

It should be possible to add a Homenet-local election mechanism to HNCP in
order to pick a recursive DNS server, but this would constitute a non-trivial
change to the protocol.  (Elections are fun, except in the UK, so I'd be
quite willing to help.)

-- Juliusz

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

Re: [homenet] My comment about Ted's naming draft

2016-07-18 Thread Michael Richardson


Juliusz Chroboczek  wrote:
> (4) Is there WG consensus on requiring a ULA?

I believe that this is.
a) it's in rfc7084 (so they are there even before homenet existed)
b) it's in rfc7368 (it's in our architecture)

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] My comment about Ted's naming draft

Ah, thanks.  So, this could be used, but would give limited functionality
to links served only by router b.

The right solution will involve using hncp, I hope, to elect the primary
server for the network, and all updates would be sent to that server. Other
router could act as secondaries, or just forward DNS messages to the
nearest (or any) primary or secondary.

I think the election process is probably the hardest thing in this
solution, and I am hoping someone already knows how to do it...  :)

On Jul 18, 2016 20:33, "Markus Stenberg"  wrote:

> > On 18.7.2016, at 19.55, Ted Lemon  wrote:
> > Right now HNCP doesn't actually seem to have a TLV for advertising
> resolvers.   How does this work now?
>
> DHCP options have also DNS server options (for v4 and v6).
>
> -Markus
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] My comment about Ted's naming draft

2016-07-18 Thread Markus Stenberg

> On 18.7.2016, at 19.55, Ted Lemon  wrote:
> Right now HNCP doesn't actually seem to have a TLV for advertising resolvers. 
>   How does this work now?

DHCP options have also DNS server options (for v4 and v6).

-Markus
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] My comment about Ted's naming draft

Right now HNCP doesn't actually seem to have a TLV for advertising
resolvers.   How does this work now?

On Mon, Jul 18, 2016 at 5:24 PM, Juliusz Chroboczek <
j...@pps.univ-paris-diderot.fr> wrote:

> > I don't think the document is proscribing speaking HNCP without speaking
> > DNS.
>
> Then I've misunderstood something, my bad.
>
> Suppose you have routers A and B on a link, and A implements DNS while
> B doesn't.  How does B find out that it should advertise A's DNS server in
> RA, DHCPv4 and DHCPv6?
>
> -- Juliusz
>
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] RFC 7788 and ".home"

2016-07-18 Thread Brian E Carpenter

On 19/07/2016 04:40, Andrew Sullivan wrote:
> On Tue, Jul 19, 2016 at 03:22:57AM +1200, Brian E Carpenter wrote:
>> I don't get that. There's nothing about that in RFC 6761, which is mainly
>> very boring stuff that could be written up for this case, regardless
>> of the actual domain name. It's our own self-imposed bureaucracy.
> 
> Question 7 asks how registries and registrars should react to this
> name.  Given that the home TLD is in-process in the ICANN delegation
> procedures from the root zone, it is logically possible that at any
> moment ICANN could change its administrative procedures and home would
> get delegated.
> 
> So the answer to question 7 cannot be but ambiguous under these
> circumstances.  To me, that means that the requirements of 6761 can't
> possibly be met by home, and therefore home can't be allocated under
> special use.

Oh, I didn't interpret q7 quite that way. I would have answered
it with virtually the same text as q7 for localhost in RFC6761.
In fact several of the answers for localhost would serve for this case,
I think.

> This is the point that Jari made and that I was going to make at the
> mic: this isn't a mere political problem, but an actual functional one
> under our own procedures.  There is just no way we could allocate home
> under 6761 right now, without a very strong statement from ICANN that
> it would be ok.

I agree, but I see that as a meta-issue rather than an RFC6761 issue.

> I also argue (see my note from yesterday) that generalizing from
> "people seem to be doing somehting like this with this name, because I
> talked to a guy from $vendor and he said so" to "using this as a
> protocol switch in a protocol will not have a problem" seems to me to
> require a pretty big leap.

I agree. A brand new name with no known usage is a safer path.

>> RFC 6761 is one thing, but RFC 2860 is another. Under note (a)
>> to clause 4.3 of that MoU, the IETF can direct IANA to reserve
>> .$WHATEVER$. for technical use.
> 
> I strongly agree -- that part is the very reason why 6761 was even
> possible, in my opinion.
>  
>> Doing so for .home. would be entertaining, of course. Doing so
>> for .homenet. seems plausible.
> 
> I know it can be entertainment to watch those films where someone
> foolishly got into a car that was then swept over Niagara Falls.

As long as it isn't your own car.

   Brian

> 
> A
> 

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

Re: [homenet] RFC 7788 and ".home"

On Mon, Jul 18, 2016 at 06:14:56PM +0200, Wouter Cloetens wrote:
> Am I to interpret that response as a "no" to the question whether anyone has
> spoken to ICANN?

You may interpret it as you wish, but it's worth noting that the IETF
has a liaison to the ICANN board.

Nevertheless, as I said upthread, this is not merely a political problem.

Best regards,

A

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

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

Re: [homenet] RFC 7788 and ".home"

On Mon, Jul 18, 2016 at 05:40:01PM +0200, Mikael Abrahamsson wrote:
> It seems to already be used for that, and as said before, ICANN has refused
> all applications for .home already.

No, it has not.  If it had, it would have refunded all those
applicants' money and so on.  It has not formally decided anything as
a permanent matter.

> .home is tainted by ad-hoc use. The ad-hoc use seems to be exactly the same
> use as RFC7788 uses it for.

How exactly do you determine this "exactly the same" use among a large
swathe of unknown people all over the Internet?  

Best regards,

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

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

Re: [homenet] RFC 7788 and ".home"

On Tue, Jul 19, 2016 at 03:22:57AM +1200, Brian E Carpenter wrote:
> I don't get that. There's nothing about that in RFC 6761, which is mainly
> very boring stuff that could be written up for this case, regardless
> of the actual domain name. It's our own self-imposed bureaucracy.

Question 7 asks how registries and registrars should react to this
name.  Given that the home TLD is in-process in the ICANN delegation
procedures from the root zone, it is logically possible that at any
moment ICANN could change its administrative procedures and home would
get delegated.

So the answer to question 7 cannot be but ambiguous under these
circumstances.  To me, that means that the requirements of 6761 can't
possibly be met by home, and therefore home can't be allocated under
special use.

This is the point that Jari made and that I was going to make at the
mic: this isn't a mere political problem, but an actual functional one
under our own procedures.  There is just no way we could allocate home
under 6761 right now, without a very strong statement from ICANN that
it would be ok.

I also argue (see my note from yesterday) that generalizing from
"people seem to be doing somehting like this with this name, because I
talked to a guy from $vendor and he said so" to "using this as a
protocol switch in a protocol will not have a problem" seems to me to
require a pretty big leap.

> RFC 6761 is one thing, but RFC 2860 is another. Under note (a)
> to clause 4.3 of that MoU, the IETF can direct IANA to reserve
> .$WHATEVER$. for technical use.

I strongly agree -- that part is the very reason why 6761 was even
possible, in my opinion.

> Doing so for .home. would be entertaining, of course. Doing so
> for .homenet. seems plausible.

I know it can be entertainment to watch those films where someone
foolishly got into a car that was then swept over Niagara Falls.

A

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

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

Re: [homenet] RFC 7788 and ".home"

2016-07-18 Thread Wouter Cloetens

Am I to interpret that response as a "no" to the question whether anyone
has spoken to ICANN? Which would mean that the rejection of .home is
based on an assumption?

bfn, Wouter

On 18/07/16 18:03, Ted Lemon wrote:

It could be seen as collusion. Remember, lawyers are much more
creative in finding vulns than all but the most paranoid of security
geeks. :)

On Jul 18, 2016 17:49, "Wouter Cloetens"
> wrote:

On 18/07/16 17:01, Ted Lemon wrote:

Yup. In terms of minimizing risk to the IETF, switching to
.homenet is expedient--that's why I put it in the Homenet
Naming/Service Discovery Architecture doc. Perhaps some homenet
participants aren't aware of the issues surrounding this.
The reason we are getting so much top-down push from IETF
leadership on this is not that IETF leadership are being
political--it's that there's a real cost to the IETF if one of
the GTLD people decides that we have taken a name for which they
paid an application fee. I apologize for glossing over this in
my earlier response.

I'm a bit confused about this. Although Dothome Ltd. paid an
application fee, they failed the initial evaluation. ICANN
ultimately concluded in 2013 that .home was high risk, or "dead"
in the terminology used in an article to which ICANN links.

I can't reach this at the moment:
https://icannwiki.com/.home
So here's the Google cache:

https://webcache.googleusercontent.com/search?q=cache:OdSc1uEzj_cJ:https://icannwiki.com/.home+=1=en=clnk=de

So, why would ICANN's gTLD people not be open to declaring .home
to be off their list, and open for redefinition by IETF?

If people are interested in better understanding this problem, I
encourage you to read this:
https://tools.ietf.org/html/draft-tldr-sutld-ps-02#section-3

" o IETF and ICANN independently have remit to assign names out of
the namespace that Internet Names represent; a formal coordination
process does not exist."

Can't that be fixed? Has anyone tried to speak to / negotiate with
ICANN?

You can get more background by reading section 4 as well. Bear
in mind, s/.local/.home/ in section 4.2.4.

On Mon, Jul 18, 2016 at 4:16 PM, Andrew Sullivan
> wrote:

On Mon, Jul 18, 2016 at 03:33:28PM +0200, Mikael Abrahamsson
wrote:
>
> .HOME has not been handed out by ICANN yet

There are several applications for home in the root zone. To
my mind,
that means that home has been claimed as being inside the
global DNS
context, and therefore is not available under RFC 6761.

Best regards,

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

--
Chief Home Gateway Architect SoftAtHome http://www.softathome.com/
https://www.linkedin.com/in/wcloetens Vaartdijk 3/B701, B-3018 Wijgmaal
Tel: +32-16-852010 Mobile: +32-492-277790 Conf. phone: +32-16-852097

This message and any attachments are confidential, intended solely for
the addressees and are SoftAtHome’s ownership.
Any unauthorized use or dissemination is prohibited. If you are not the
intended addressee of this message, please cancel it immediately and
inform the sender.

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

Re: [homenet] RFC 7788 and ".home"


On Tue, 19 Jul 2016, Brian E Carpenter wrote:

Doing so for .home. would be entertaining, of course. Doing so for 
.homenet. seems plausible.


It seems to already be used for that, and as said before, ICANN has 
refused all applications for .home already.


.home is tainted by ad-hoc use. The ad-hoc use seems to be exactly the 
same use as RFC7788 uses it for.


Why not formalise it?

--
Mikael Abrahamssonemail: swm...@swm.pp.se

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

Re: [homenet] RFC 7788 and ".home"

It could be seen as collusion. Remember, lawyers are much more creative in
finding vulns than all but the most paranoid of security geeks. :)

On Jul 18, 2016 17:49, "Wouter Cloetens" 
wrote:

> On 18/07/16 17:01, Ted Lemon wrote:
>
> Yup.   In terms of minimizing risk to the IETF, switching to .homenet is
> expedient--that's why I put it in the Homenet Naming/Service Discovery
> Architecture doc.   Perhaps some homenet participants aren't aware of the
> issues surrounding this.
> The reason we are getting so much top-down push from IETF leadership on
> this is not that IETF leadership are being political--it's that there's a
> real cost to the IETF if one of the GTLD people decides that we have taken
> a name for which they paid an application fee.   I apologize for glossing
> over this in my earlier response.
>
> I'm a bit confused about this. Although Dothome Ltd. paid an application
> fee, they failed the initial evaluation. ICANN ultimately concluded in 2013
> that .home was high risk, or "dead" in the terminology used in an article
> to which ICANN links.
>
> I can't reach this at the moment:
>  https://icannwiki.com/.home
> So here's the Google cache:
>
> https://webcache.googleusercontent.com/search?q=cache:OdSc1uEzj_cJ:https://icannwiki.com/.home+=1=en=clnk=de
>
> So, why would ICANN's gTLD people not be open to declaring .home to be off
> their list, and open for redefinition by IETF?
>
>
> If people are interested in better understanding this problem, I encourage
> you to read this:
> https://tools.ietf.org/html/draft-tldr-sutld-ps-02#section-3
>
> " o IETF and ICANN independently have remit to assign names out of the
> namespace that Internet Names represent; a formal coordination process does
> not exist."
>
> Can't that be fixed? Has anyone tried to speak to / negotiate with ICANN?
>
>
> You can get more background by reading section 4 as well.   Bear in mind,
> s/.local/.home/ in section 4.2.4.
>
> On Mon, Jul 18, 2016 at 4:16 PM, Andrew Sullivan 
> wrote:
>
>> On Mon, Jul 18, 2016 at 03:33:28PM +0200, Mikael Abrahamsson wrote:
>> >
>> > .HOME has not been handed out by ICANN yet
>>
>> There are several applications for home in the root zone.  To my mind,
>> that means that home has been claimed as being inside the global DNS
>> context, and therefore is not available under RFC 6761.
>>
>> Best regards,
>>
>> A
>>
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] RFC 7788 and ".home"

2016-07-18 Thread Wouter Cloetens

On 18/07/16 17:01, Ted Lemon wrote:
Yup. In terms of minimizing risk to the IETF, switching to .homenet
is expedient--that's why I put it in the Homenet Naming/Service
Discovery Architecture doc. Perhaps some homenet participants aren't
aware of the issues surrounding this.
The reason we are getting so much top-down push from IETF leadership
on this is not that IETF leadership are being political--it's that
there's a real cost to the IETF if one of the GTLD people decides that
we have taken a name for which they paid an application fee. I
apologize for glossing over this in my earlier response.
I'm a bit confused about this. Although Dothome Ltd. paid an application
fee, they failed the initial evaluation. ICANN ultimately concluded in
2013 that .home was high risk, or "dead" in the terminology used in an
article to which ICANN links.

I can't reach this at the moment:
https://icannwiki.com/.home
So here's the Google cache:
https://webcache.googleusercontent.com/search?q=cache:OdSc1uEzj_cJ:https://icannwiki.com/.home+=1=en=clnk=de

So, why would ICANN's gTLD people not be open to declaring .home to be
off their list, and open for redefinition by IETF?

If people are interested in better understanding this problem, I
encourage you to read this:
https://tools.ietf.org/html/draft-tldr-sutld-ps-02#section-3
" o IETF and ICANN independently have remit to assign names out of the
namespace that Internet Names represent; a formal coordination process
does not exist."

Can't that be fixed? Has anyone tried to speak to / negotiate with ICANN?

You can get more background by reading section 4 as well. Bear in
mind, s/.local/.home/ in section 4.2.4.

On Mon, Jul 18, 2016 at 4:16 PM, Andrew Sullivan
> wrote:

On Mon, Jul 18, 2016 at 03:33:28PM +0200, Mikael Abrahamsson wrote:
>
> .HOME has not been handed out by ICANN yet

There are several applications for home in the root zone. To my mind,
that means that home has been claimed as being inside the global DNS
context, and therefore is not available under RFC 6761.

Best regards,

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

Re: [homenet] RFC 7788 and ".home"

2016-07-18 Thread Brian E Carpenter

On 19/07/2016 03:40, Mikael Abrahamsson wrote:
> On Tue, 19 Jul 2016, Brian E Carpenter wrote:
> 
>> Doing so for .home. would be entertaining, of course. Doing so for .homenet. 
>> seems plausible.
> 
> It seems to already be used for that, and as said before, ICANN has refused 
> all applications for .home already.
> 
> .home is tainted by ad-hoc use. The ad-hoc use seems to be exactly the same 
> use as RFC7788 uses it for.
> 
> Why not formalise it?

To be blunt, because ICANN and possibly the IETF would get sued for many M$.

   Brian

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

Re: [homenet] RFC 7788 and ".home"

2016-07-18 Thread Tim Chown

Hi Ted,

On 18 Jul 2016, at 15:03, Ted Lemon > 
wrote:

Zero.   See the discussion in draft-tldr-sutld-02 on this topic (search for 
.home).

I don’t see “home” explicitly cited in 
https://tools.ietf.org/html/draft-tldr-sutld-ps-02, but it’s an interesting 
read nonetheless.

Tim


On Mon, Jul 18, 2016 at 3:33 PM, Mikael Abrahamsson 
> wrote:

The option 4 mentioned updating RFC7788. It's not clear to me what this update 
would be.

.HOME has not been handed out by ICANN yet, what's the odds that RFC6761 
process reserving .HOME for special use would succeed?

--
Mikael Abrahamssonemail: swm...@swm.pp.se


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

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

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

Re: [homenet] My comment about Ted's naming draft

>> From my perspective, though, there is nothing technically hard about
>> what we're talking about here; the main issue is that it's a
>> substantial amount of work.

You're possibly right, I don't know, but I'm worried about implementability.
I'm very worried that you're apparently proscribing speaking HNCP without
speaking DNS.

> And something that your grad students might be able to get some valuable
> experience with! :)

All of the students working on HNCP are undergrads.  Some of them first years.
So ease of implementation is essential ;-)

-- Juliusz

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

Re: [homenet] My comment about Ted's naming draft

I don't think the document is proscribing speaking HNCP without speaking
DNS.   A homenet router that doesn't support cross-link naming at all is
not useless.   It's just not as useful as one that does.

I think you are overestimating the complexity of implementing this, but
your undergrads can help us to test that theory.   :)

On Mon, Jul 18, 2016 at 5:01 PM, Juliusz Chroboczek <
j...@pps.univ-paris-diderot.fr> wrote:

> >> From my perspective, though, there is nothing technically hard about
> >> what we're talking about here; the main issue is that it's a
> >> substantial amount of work.
>
> You're possibly right, I don't know, but I'm worried about
> implementability.
> I'm very worried that you're apparently proscribing speaking HNCP without
> speaking DNS.
>
> > And something that your grad students might be able to get some valuable
> > experience with! :)
>
> All of the students working on HNCP are undergrads.  Some of them first
> years.
> So ease of implementation is essential ;-)
>
> -- Juliusz
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

2016-07-18 Thread Ralph Droms

> On Jul 18, 2016, at 3:44 PM 7/18/16, Ted Lemon  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
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

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

Re: [homenet] My comment about Ted's naming draft

On Mon, Jul 18, 2016 at 4:49 PM, Ted Lemon  wrote:

> From my perspective, though, there is nothing technically hard about what
> we're talking about here; the main issue is that it's a substantial amount
> of work.
>

And, furthermore, we've built a lot of fairly complex and wonderful
technology at the IETF, and figuring out ways to automate deploying it is a
really useful exploration.   And something that your grad students might be
able to get some valuable experience with!   :)
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] My comment about Ted's naming draft

I wrote the ULA text because I thought there was already consensus, but
obviously whether or not there is consensus will come out if the document
is adopted by the WG, since if people object to the ULA, we can take it
out.   Personally I think that would be a mistake, and probably ideally the
ULA shouldn't be in the naming architecture since it's got little to do
with naming.

I would like to caution people against the idea that being less ambitious
will be a shortcut to success.   Andrew made this point at the mic, and it
is a really important point: a partial solution will become an obstacle to
a complete solution.   There are ways of diving this problem into chunks
that make sense, but we should have in mind the complete solution, even if
we approach it in a stepwise manner.   Otherwise we may wind up creating
problems that will be difficult to clean up later.

Of course, if we really don't care about all the things that the
architecture describes, that's another question entirely.   From my
perspective, though, there is nothing technically hard about what we're
talking about here; the main issue is that it's a substantial amount of
work.

On Mon, Jul 18, 2016 at 4:14 PM, Juliusz Chroboczek <
j...@pps.univ-paris-diderot.fr> wrote:

> This is to repeat the comment that I made at the mike about
> draft-lemon-homenet-naming-architecture-01.
>
> Among other things, this draft suggests:
>
>1. having a new ND option (Section 3.5);
>2. defining a RESTful management API (Section 3.6);
>3. the use of a local resolver (Section 4.5);
>4. the use of a ULA (Section 5.5).
>
> These are some fairly ambitious requirements, and I believe that they
> deserve discussion separately from the naming issue.  More precisely:
>
> (1) Are wo to go to the effort of specifying and deploying a new ND option?
>
> (2) Defining a management API goes against the Homenet tradition, which
> is to negotiate things over HNCP rather than defining new APIs.
>
> (3) HNCP does not currently mandate using a local resolver, and neither
> does it define a means to advertise the address of a local resolver to
> HNCP routers.  Are we requiring a full DNS server with DNSsec support
> on each HNCP node, including an HNCP speaker that is not a router?
> (Note that I'd be strongly opposed to requiring that every HNCP
> speaker must be a router, and I think my opinion on putting a DNS
> forwarder on every HNCP node is similar.)
>
> (4) Is there WG consensus on requiring a ULA?
>
> I don't have a definite opinion yet, but these requirements certainly make
> me nervous.
>
> -- Juliusz
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] use of .home

2016-07-18 Thread Stephane Bortzmeyer

On Mon, Jul 18, 2016 at 01:50:25PM +,
 Tim Chown  wrote 
 a message of 69 lines which said:

> There are articles online that suggest 500M hits/day to the roots
> for .home,

L-root alone receives 180 Mhits/day so it is possible. (Source:
http://stats.dns.icann.org/hedgehog/ )

> and that .home is the heaviest used unallocated TLD.

No, it is .local. (Source: the same)

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

Re: [homenet] RFC 7788 and ".home"

Wow.   Apparently my freudian slip at the microphone today is a trend: the
place where I should have said ".home" in sutldr-ps, I said ".local"
instead.   Thanks for indirectly pointing this out to me!   :}

On Mon, Jul 18, 2016 at 4:17 PM, Mikael Abrahamsson 
wrote:

> On Mon, 18 Jul 2016, Ted Lemon wrote:
>
> Zero.  See the discussion in draft-tldr-sutld-02 on this topic (search for
>> .home).
>>
>
> I guess you mean https://tools.ietf.org/html/draft-tldr-sutld-ps-02 ?
>
> I can't find any mention of .home in it.
>
>
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] RFC 7788 and ".home"


On Mon, 18 Jul 2016, Ted Lemon wrote:

Zero.  See the discussion in draft-tldr-sutld-02 on this topic (search 
for .home).


I guess you mean https://tools.ietf.org/html/draft-tldr-sutld-ps-02 ?

I can't find any mention of .home in it.

--
Mikael Abrahamssonemail: swm...@swm.pp.se

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

Re: [homenet] RFC 7788 and ".home"

On Mon, Jul 18, 2016 at 03:33:28PM +0200, Mikael Abrahamsson wrote:
> 
> .HOME has not been handed out by ICANN yet

There are several applications for home in the root zone.  To my mind,
that means that home has been claimed as being inside the global DNS
context, and therefore is not available under RFC 6761.

Best regards,

A

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

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

[homenet] My comment about Ted's naming draft

This is to repeat the comment that I made at the mike about
draft-lemon-homenet-naming-architecture-01.

Among other things, this draft suggests:

   1. having a new ND option (Section 3.5);
   2. defining a RESTful management API (Section 3.6);
   3. the use of a local resolver (Section 4.5);
   4. the use of a ULA (Section 5.5).

These are some fairly ambitious requirements, and I believe that they
deserve discussion separately from the naming issue.  More precisely:

(1) Are wo to go to the effort of specifying and deploying a new ND option?

(2) Defining a management API goes against the Homenet tradition, which
is to negotiate things over HNCP rather than defining new APIs.

(3) HNCP does not currently mandate using a local resolver, and neither
does it define a means to advertise the address of a local resolver to
HNCP routers.  Are we requiring a full DNS server with DNSsec support
on each HNCP node, including an HNCP speaker that is not a router?
(Note that I'd be strongly opposed to requiring that every HNCP
speaker must be a router, and I think my opinion on putting a DNS
forwarder on every HNCP node is similar.)

(4) Is there WG consensus on requiring a ULA?

I don't have a definite opinion yet, but these requirements certainly make
me nervous.

-- Juliusz

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

Re: [homenet] RFC 7788 and ".home"

Zero.   See the discussion in draft-tldr-sutld-02 on this topic (search for
.home).

On Mon, Jul 18, 2016 at 3:33 PM, Mikael Abrahamsson 
wrote:

>
> The option 4 mentioned updating RFC7788. It's not clear to me what this
> update would be.
>
> .HOME has not been handed out by ICANN yet, what's the odds that RFC6761
> process reserving .HOME for special use would succeed?
>
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] use of .home

2016-07-18 Thread Tim Chown

Hi,

I was going to say two things at the mic before we ran out of time.

First, that I agree with Ralph on his comments about requirements.

Second, as Stuart pointed out, use is already being made of .home, e.g. it’s 
used by BT in the UK. There are articles online that suggest 500M hits/day to 
the roots for .home, and that .home is the heaviest used unallocated TLD. Which 
I assume is in no small part why ICANN chose to not allocate the TLD, instead 
marking it (and .corp) as a “high risk” TLD, due to existing use. For an 
example, see 
http://domainincite.com/13773-home-gets-half-a-billion-hits-a-day-could-this-put-new-gtlds-at-risk.
  Of course *how* .home is being used is another question, but it’s effectively 
not allocatable elsewhere.

Tim



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

[homenet] What I really meant by option 5

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.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] RFC 7788 and ".home"


On Mon, 18 Jul 2016, Mikael Abrahamsson wrote:



The option 4 mentioned updating RFC7788. It's not clear to me what this 
update would be.


.HOME has not been handed out by ICANN yet, what's the odds that RFC6761 
process reserving .HOME for special use would succeed?


Let me just clarify. Updating RFC7788 to remove ".home", then do RFC6761 
process to reserve .home for special use, succeeding in that, then 
updating RFC7788 again. This seems silly.


I propose fast-tracking RFC6761 process for ".home" reservation for 
special-use, and not touch RFC7788 unless this process fails.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

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

Re: [homenet] RFC 7788 and ".home"



The option 4 mentioned updating RFC7788. It's not clear to me what this 
update would be.


.HOME has not been handed out by ICANN yet, what's the odds that RFC6761 
process reserving .HOME for special use would succeed?


--
Mikael Abrahamssonemail: swm...@swm.pp.se

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

Re: [homenet] New version of homenet naming architecture...

Thanks for the review!

I agree that we need to make sure we get the global/local bit right.   Bear
in mind that the "flatness" is intended to be the only thing that is ever
seen by a resolver.   The per-link hierarchy is simply a hack to make
hybrid mDNS work without requiring the user to see multiple link names.
>From a database perspective, think of the presented host namespace as being
a view that represents the join of the link-specific mDNS tables and the
internal host namespace.   Of course it's not quite that simple, but that's
the basic idea.

There are definitely some tricks to that that aren't documented in the
architecture document, and indeed I didn't even make clear the idea that
the presented namespace is a view; unfortunately I didn't fully realize
that I'd failed to do that until just now.   :)


On Mon, Jul 18, 2016 at 11:31 AM, Andrew Sullivan 
wrote:

> Dear colleagues,
>
> On Sun, Jul 10, 2016 at 11:57:28AM -0700, Ted Lemon wrote:
> > I made the document quite a bit more definite, since I didn't hear any
> > strenuous objections when I presented it last time.   I'd like to propose
> > adopting the document as a working group work item.   Thoughts?   Do
> people
> > think this is a good direction, or did the lack of objection last time
> > indicate shocked horror rather than acquiescence?
>
> I've read this draft.  I've got some various reservations and comments
> that I'll want to make in more detail, but on the basic question of
> whether this is a good foundation for the WG's efforts, I think it
> obviously is.
>
> One very large architectural issue in here is the flat namespace
> and its correspondence to a hierarchical namespace.  This seems
> to me to be a potentially very tricky mechanism with potential for
> inconsistency, and it makes me deeply nervous, particularly since
> we're talking about basically using the same names only sometimes in a
> local and sometimes in a global context, with different authorities.
> My inner database weenie is cringing.  So I want to be clear that
> support for adopting the document does not mean that I think even very
> fundamental notions in the document can't be thrown over later.  But I
> think the WG ought to have change control over such decisions.
>
> Best regards,
>
> A
>
> --
> Andrew Sullivan
> a...@anvilwalrusden.com
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New version of homenet naming architecture...