Re: [homenet] Homenet Mission accomplished ?

[Ted Lemon]

Wow. I’m pretty sure I started as AD after the first version of this draft,
and that was when dinosaurs still roamed. Congratulations on getting this
done!

Op wo 1 feb. 2023 om 06:11 schreef Daniel Migault 

> I (and probably with all co-authors) would like to thank Eric and the
> chairs Kiran and Stephen for their constant support in moving this work
> forward.  We also thank the numerous reviewers for their careful reviews.
>
> Yours,
> Daniel
>
> On Wed, Feb 1, 2023 at 9:00 AM Kiran Makhijani 
> wrote:
>
>> Hi Eric,
>> I am very happy to see that both the documents are now approved. Kudos to
>> the authors - I noticed they worked quite diligently in past few months to
>> bring the documents to approval level, addressing comments as they came in.
>> Thank you to you as well, for your continuous involvement in the process.
>>
>> With the naming architecture and dhc-options out, the WG has indeed
>> reached its logical conclusion.
>> Congratulations to the authors!
>>
>> —Kiran
>>
>> On February 1, 2023 at 1:07:22 AM, Eric Vyncke (evyncke) (
>> evyncke=40cisco@dmarc.ietf.org) wrote:
>>
>> Dear Homenet,
>>
>>
>>
>> As you may have read on
>> https://datatracker.ietf.org/wg/homenet/documents/ the last WG documents
>> have been approved for publication:
>>
>> - draft-ietf-homenet-front-end-naming-delegation-26 had a major rewrite
>> end of 2022 and the intended status is now experimental per IESG request
>>
>> - draft-ietf-homenet-naming-architecture-dhc-options-24 was approved
>> mid-2022 but I was delaying its approval until the main I-D was finally
>> approved, the change of status in the main document has created a downref
>> (i.e., a formal reference to an experimental I-D), but this downref was
>> accepted by the IESG
>>
>>
>>
>> All in all, it seems that the Homenet WG can now be closed. As the
>> responsible AD for Homenet, I will discuss with the chairs when to close
>> this long-lasting WG ;-) Of course, the mailing list will be kept active.
>>
>>
>>
>> Note: the perimeter security item of the charter will not be completed.
>>
>>
>>
>> As usual, comments are welcome.
>>
>>
>>
>> Regards and thanks for all the hard work done in Homenet
>>
>>
>>
>> -éric
>> ___
>> 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
>>
>
>
> --
> Daniel Migault
> Ericsson
> ___
> 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] Lars Eggert's Abstain on draft-ietf-homenet-naming-architecture-dhc-options-22: (with COMMENT)

[Ted Lemon]

On Thu, Oct 20, 2022 at 7:45 AM Lars Eggert via Datatracker <
nore...@ietf.org> wrote:

> I agree with the Discusses and Comments on this document - this simply
> isn't
> implementable as described.
>

I have no opinion on this per sé, but...


> My main reason for abstaining is something else though. This document has
> been
> worked on for almost ten years. While in the beginning, we might have
> expected
> or at least hoped that a solution in the shape that this document tries to
> describe would see adoption, it's become very clear that dynamic DNS
> services
> as described in Section 4 have won out here. These services are far from
> perfect, but at least some of the limitations in Section 4 have been
> addressed,
> and others are arguably a feature and not a limitation.


I'm deeply frustrated by this response. I think it's good to pay attention
to whether there could be market pressure for a given protocol, but when
the market has solved a related problem badly, this doesn't seem like a
good reason to say no to an actual solution to the problem. If you think
the document isn't any good, ask the authors to fix it, and don't publish
it until they do.

What the market has produced is a way for a user to subscribe to a service
that lets them keep a single domain name current with their external IP
address. It doesn't let them populate a DNS zone that they control with
arbitrary records. There exists no solution to that problem in the market
other than setting up your own DNS server and getting a delegation through
a registrar (which many of us who participate in the IETF do) or paying
somebody like godaddy to do it for you (which is mostly what non-experts
do).

Making it easier seems like a good thing. That's what this document
proposes to do. If it does it badly, or the wrong way, then you should be
able to criticize it on that basis. Not on the basis that, for a
substantial monthly fee, I can maintain the association between a single
name not of my choosing and the very-much-not-stable single IPv4 address
that my ISP provides to me.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [IANA #1240631] Expert Review for draft-ietf-homenet-naming-architecture-dhc-options

[Ted Lemon]

These all look fine to me.

On Mon, Oct 3, 2022 at 2:40 PM David Dong via RT <
drafts-expert-review-comm...@iana.org> wrote:

> Dear Ted, Bernie, Tomek (cc: homenet wg),
>
> As the designated experts for the Option Codes registry, can you review
> the proposed registration in
> draft-ietf-homenet-naming-architecture-dhc-options for us? Please see
>
>
> https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/
>
> The due date is 17 Oct 2022.
>
> If this is OK, when the IESG approves the document for publication, we'll
> make the registration at
>
> https://www.iana.org/assignments/dhcpv6-parameters/
>
> We'll wait for all three reviewers to respond unless you tell us otherwise.
>
> Thank you,
>
> David Dong
> IANA Services Specialist
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [Snac] summary of Gateway 2 Gateway side meeting

[Ted Lemon]

Makes sense. Interesting topic, but significantly different. Might converge
at some point, but not now.

On Mon, Aug 8, 2022 at 21:54 Michael Richardson 
wrote:

>
> Marc Blanchet  wrote:
> >> Also, because ICN does not involve making active (in the TCP sense)
> >> connections to the sensors, it means that there is no inherent trust
> >> that must be created in the sensors in order for them to
> communicate:
> >> they simply announce their state and allow the network to do its
> >> thing.
>
> > I’m getting concerned that we are trying to boil the ocean. We should
> > reduce the scope of this work to what is achievable. The proponents
> > seemed to suggest a more narrow use case.
>
> I think that I should have also reported that nobody in the side meeting
> through that it belonged as part of the SNAC work.
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> ___
> 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] SNAC BoF and mailing list

[Ted Lemon]

[If you see this a lot of times, I really apologize—I think it's relevant to 
all the mailing lists I'm sending it to, but I know that that's a lot. Please 
reply to s...@ietf.org, not here.]

You may have seen an announcement yesterday for the s...@ietf.org mailing list. 
The point of this mailing list is, first, to discuss the possible creation of a 
working group to work on specifications relating to the problem of stub 
networks, and secondly, assuming the working group forms, to do that actual 
work.

The point of this work area is to make it possible to automatically attach a 
stub network (that is, an IPv6 network that does not provide transit) to 
existing infrastructure networks. So in a sense, you can think of this work as 
being largely about operational practices. However, because these practices 
need to be automatic (that is, we can't assume that the user knows how to set 
up a stub network), we need to document in some detail how stub network routers 
behave, so that we can get consistent, reliable automatic behavior.

At present, the stub networks work relies on existing IPv6 protocols such as 
neighbor discovery to function. The goal of the Stub Network AutoConfiguration 
work is not to invent new protocol, but rather to say how to use existing 
protocols to accomplish the goal of automatically integrating stub networks 
into infrastructure. It's reasonable to expect that there might be some actual 
protocol extension work to do, but at least at present it doesn't look like 
there's a need to invent new protocols.

An example of protocol extension work might be an extension to DHCPv6 prefix 
delegation to specifically support stub networks, or an extension to DNS-SD to 
support service discovery on stub networks. I'm not saying the working group 
would actually work on this sort of thing, but simply giving examples of the 
sort of thing the working group might find itself doing.

Information about the SNAC BoF is available here: 
https://datatracker.ietf.org/doc/bofreq-lemon-stub-network-auto-configuration-for-ipv6/00/
There are several drafts available at that link that will give you a better 
idea of the problem.

One key example where SNAC is useful is in the connection of constrained 
networks to infrastructure networks. E.g., an 802.15.4 mesh network like 
Thread. Existing products actually already do stub-network-like things, e.g. 
the Apple HomePod Mini and the most recent Apple TV. Because we are simply 
leveraging existing protocols, we didn't need to develop anything new in the 
IETF to do this, however it's our opinion that it would be useful for the IETF 
to think carefully about this problem and quite likely tweak the 
recommendations in the current stub network document.

As an example, early on I added some code to do something called "vicarious 
router discovery," where if the stub router notices a device doing router 
discovery and doesn't see it succeed, it will reach out to that host. Not being 
an expert on ND or router discovery, I got this implementation quite wrong, and 
it didn't behave well.

So when I say that the point of this working group is to work on this problem, 
I do not mean that the point is to get a rubber stamp on the existing solution. 
The point is rather to get real review of the work, fix any issues that are 
discovered, and do things differently if the way we are doing them now isn't 
ideal.

FYI, I've set the reply-to on this email to the s...@ietf.org mailing list. If 
you really want to reply to all four mailing lists to which I've sent this, I 
can't stop you, but I would suggest that that might be taken poorly by the 
folks on those mailing lists, so please if possible join the s...@ietf.org 
mailing list before replying, and then I really look forward to the discussion. 
You can subscribe here: https://www.ietf.org/mailman/listinfo/snac

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

Re: [homenet] Looking for a Homenet co-chair

[Ted Lemon]

FWIW, I think there's further work after stub networks for HomeNet to do.
We now have Babel and Source-Specific routing, but I suspect that setting
it up will involve some innovation, and that ought to be documented. And we
might be getting close to ready to talk about how to integrate the dnssd
naming work into a HomeNet.

On August 27, 2021 at 7:05:06 AM, Michael Richardson (m...@sandelman.ca)
wrote:


Michael Richardson  wrote:
>> progress the stub networks draft because I've been too busy doing
>> dnssd work, but that would be an example. I'd really like to progress
>> that draft /somewhere/, and it seems a /bit/ off-topic for dnssd. It
>> could go in v6ops, but it's pretty off-topic for v6ops. Same with
>> intarea.

>> But of course the stub networks document isn't what Homenet set out to
>> do. It's just a building block that might lead there. The original
>> work of homenet doesn't seem to have caught on in the market, and I
>> think it's because we didn't have an adoption strategy. Personally I
>> think stub networks is a good bottom-up beginning to a strategy that
>> could ultimately produce an adoptable version of what we originally
>> tried to do. But again, only if people here want to pursue that.

> I thought that you *wanted* to go to INTAREA with this document. I
> agree that it's an important document.

If we need to keep HOMENET open to do stub networks, then let's do that.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Looking for a Homenet co-chair

[Ted Lemon]

I think it's pretty clear that there's more work to do; the question is
whether the homenet working group has a quorum to do it. A fair amount of
the work we were trying to do in homenet has wound up happening in dnssd
instead, which seems fine—there was a pretty clear overlap there.

There is still work to do that I think is homenet-relevant, but only if
there are people in homenet who want to do it. I haven't had time to
progress the stub networks draft because I've been too busy doing dnssd
work, but that would be an example. I'd really like to progress that draft
/somewhere/, and it seems a /bit/ off-topic for dnssd. It could go in
v6ops, but it's pretty off-topic for v6ops. Same with intarea.

But of course the stub networks document isn't what Homenet set out to do.
It's just a building block that might lead there. The original work of
homenet doesn't seem to have caught on in the market, and I think it's
because we didn't have an adoption strategy. Personally I think stub
networks is a good bottom-up beginning to a strategy that could ultimately
produce an adoptable version of what we originally tried to do. But again,
only if people here want to pursue that.

On August 24, 2021 at 8:37:24 PM, Stephen Farrell (stephen.farr...@cs.tcd.ie)
wrote:


Hiya,

On 24/08/2021 08:59, Eric Vyncke (evyncke) wrote:
> Dear all,
>
> As you are probably aware, Barbara Stark is retiring from her WG
> chair position after IETF-112

I'd also like to thank Barbara for all her fine work for this
WG, and everything else in IETF-land too!

> and I now have ‘mission impossible n++’
> to find a new WG chair to assist Stephen Farrel.
>
> As Stephen is an experimented WG chair, having a ‘junior’ co-chair
> would be welcome (of course ‘senior’ as well!), i.e., even if you are
> new at the IETF and if you have never been a WG chair, then feel free
> to reply unicast[1] to me: we can then have a chat about the job and
> the motivation. The job itself is not a big chunk of time outside the
> IETF weeks but requires human skills (herding cats !) and of course
> good technical knowledge.
>
> Looking forward to reading your email about you or about any
> suggestion

So, (having checked with Eric and Barbara) I'd also like
to know whether (or not) participants consider that the
homenet WG may now have reached the time when it's more
appropriate to close the WG. That might (or might not)
make a search for a new co-chair moot.

If closing the WG were the better option then we'd want
to have a discussion about how to handle ongoing work
(e.g. see if there's a better venue), but that's a
separate discussion.

Cheers,
S.

PS: FWIW, I'd be just as happy if there's consensus to
continue or to call it a day - either is a fine outcome
if it matches reality.

>
> Regards
>
> -éric
>
> [1] unicast is preferred but not required
>
___
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] homenet naming drafts "terminology"

[Ted Lemon]

Or “Distribution Primary?” I think given this chart that “Distribution 
Authority” is less clear, since the real authority is the stealth primary.

> On May 5, 2021, at 3:09 PM, Michael Richardson  wrote:
> 
> 
> Ted Lemon  wrote:
>> On May 5, 2021, at 11:51 AM, Michael Richardson 
>> wrote:
>>> 3) We would be happy to go with another term, but we don't want to
>>> invent another term.  So, if the DNS anycast operator has another
>>> term, then I'd go with it.
> 
>> Authority database?
> 
> I thought that you were asking who was an authoritive database of operators.
> Then I understood that you are suggesting "authority database" as the term.
> 
> Some ascii art, (so pick a sensible mono-spaced font, or use the archive 
> link):
> 
> .-.  .-.
> | S P | ---> | D M |\---\--\
> `-'  `-'|   |  |
>V   V  V
> .-. .. ..
> | Sec | | Sec| |Sec |
> `-' `' `'
> 
> S.P. = Stealth Primary
> Sec  = Secondary
> D M  = Distribution M*
> 
> Note that the "DM" is usually not listed as an NS, but rather,
> two or more "Sec" are what is listed.
> 
> So, maybe "Distribution Authority" would make us both happy.
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>   Sandelman Software Works Inc, Ottawa and Worldwide

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

Re: [homenet] homenet naming drafts "terminology"

[Ted Lemon]

On May 5, 2021, at 11:51 AM, Michael Richardson  wrote:
> 3) We would be happy to go with another term, but we don't want to invent
>   another term.  So, if the DNS anycast operator has another term, then
>   I'd go with it.

Authority database?

RFC 8499 appears to have deprecated the term “master” to some extent, although 
it’s not perfect. “Master server” just says “see Primary Server.”

The server on the home router really is the primary authoritative server for 
the zone from a DNS perspective, even if it doesn’t show up in a public NS 
record.

FWIW I fully support using different terminology.

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

Re: [homenet] [dhcwg] WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12

[Ted Lemon]

On May 5, 2021, at 11:44 AM, Michael Richardson  wrote:
> The end user might suffer slightly by having locally served
> reverse names that are no longer connected: they should obsolete that zone
> when they realize that their PD hasn't been renewed, until such time,
> (if it was a flash renumber), they would be right to think that they
> legitimately control them.

In practice I don’t think this is an issue. The reverse lookup is usually 
triggered by receipt of a message from an IP address, so as long as the IP 
address is still in use internally, the presence of the reverse zone is wanted. 
When the address changes, the old zone becomes obsolete whether it continues to 
be served or not. The likelihood of the zone being re-allocated to some other 
network for which the original network will then do a reverse lookup is very 
small, so I don’t think there’s any reason to be concerned about this.

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

Re: [homenet] Ted's stub network document: draft-lemon-stub-networks{, -ps}

[Ted Lemon]

Since I’m updating the document...

> On Feb 26, 2021, at 12:01 PM, Ted Lemon  wrote:
>> On Feb 26, 2021, at 11:24 AM, Michael Richardson  
>> wrote:
> 
>> 2) There is advice about monitoring the RAs from the infrastructure router
>>  (which is probably the home CPE router), and soliciting them regularly.
>>  In effect, the Stub Router can't depend that the CPE router will remain
>>  alive for it's lifetime.
>>  That is, the RA lifetimes tell the client how long it may use the
>>  resource, but not how to determine if the router is alive.  Of course,
>>  power can disappear at any time.
>>  Ted: it seems that maybe neigh-cache entries already have all the timers
>>  and rechecks needed, and maybe the Stub Router can just watch for
>>  the NCE going Stale?
> 
> That would work, but depends on the stub router implementation being able to 
> get a notification that this has happened, which means it’s running in the 
> kernel. I don’t think that’s a likely scenario. Also, NCEs have lifetimes, so 
> they will also outlive on-link routers.

I’ve added this, but please suggest better wording:

As an alternative to the vicarious router discovery process 
described here, the stub router could monitor the presence
of the router advertising the on-link prefix in the neighbor cache. 
If the neighbor cache entry becomes stale, this
could be an indication that the prefix is also stale. If the 
neighbor cache entry goes stale, the router would need to
try to refresh it, and if that fails, then the stub router must 
begin advertising its own on-link prefix on the stub
network.


>> 4) I'd like to add a state machine diagram to 3.1.1/3.1.2.
> 
> I think that’s a good idea, although I am not really a fan of state machine 
> *diagrams* — I’d maybe rather just describe the state machine. Diagrams are 
> easy to misread. There are actually several state machines, and each I think 
> is fairly simple, so writing out a list of states, events and state 
> transitions may be practicable.

This is noted, and on the to-do list, but not today. :)


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

Re: [homenet] Review of draft-lemon-stub-networks-00

[Ted Lemon]

Thanks for the review, Jonathan! I’ve applied your changes to the document 
where appropriate (will publish an update when posting re-opens). I’ve also 
called out some discussion points where I don’t yet know what to add to the 
text.

> On Feb 26, 2021, at 2:07 PM, Jonathan Hui 
>  wrote:
> Section 3.1
> - "In this case, the stub router SHOULD NOT provide addressability on the 
> adjacent infrastructure link." - I wonder if there are scenarios where the 
> existing addressing is not stable (e.g. when provided by an external entity). 
> Constrained devices would rather avoid having to determine that an existing 
> IPv6 address is unreachable and discover the new IPv6 address. Having the 
> stub router guarantee stable IPv6 addressing can reduce overhead on stub 
> network devices. For example, I'm wondering if it's useful for the stub 
> router to provide a ULA prefix if only a GUA prefix is being advertised and 
> no ULA prefix exists.

This is an interesting point. I would expect the home router to be providing a 
ULA in this case, for just this reason. You are also assuming that the stub 
network device is relying on address stability, which perhaps it shouldn’t be. 
Just because I got address A during service discovery doesn’t mean that address 
A is still valid a half hour later. If address A suddenly stops working, that’s 
probably a signal to refresh the DNS Lookup that returned address A to see if 
it’s now returning address B. Obviously if this is a constrained device we’d 
prefer it do as little work as possible, but I think it needs to be able to do 
this or it’s not a functioning device. So if we make this scenario less likely, 
is that actually a good outcome?

In principle, I think events of this sort can be expected to be infrequent, and 
so I’m not convinced that hardening the network is a good approach—hardening 
the node may produce a more resilient service.

> Section 3.1.1
> - "router discovery" - Should we capitalize and explicitly reference RFC 4861?
> - "a usable prefixes" -> "a usable prefix"

Yes, there are a lot of places in the document where [citation needed] applies. 
I’ve fixed this one.

> Section 3.1.2 
> - "IP addressability becomes present on adjacent infrastructure link" - was 
> more text intended here?

I’ve deleted this fragment—I think it was the beginning thought for the next 
paragraph, and then got forgotten.

> Section 3.1.3
> - This section describes how to avoid creating duplicate on-link prefixes. 
> Should we also discuss how to avoid deprecating multiple on-link prefixes 
> simultaneously in the case that duplicates do occur? In particular, how do we 
> ensure convergence on one prefix?

This is a good point. I’d worried about this but concluded that it was unlikely 
and also not deadly, but there’s no harm in accounting for it.

I’ve made two changes to the document to address this. First, I emphasized in 
the existing text that a prefix only triggers deprecation if it has a non-zero 
preferred lifetime. Secondly, I’ve added the following text:

It is also possible that all routers on the link that are capable 
of advertising prefixes might be following the same
protocol of deprecating their own prefix when a valid prefix shows 
up. To prevent a situation where all routers
deprecate their prefix and wait until there are no valid prefixes 
being advertised before advertising a prefix, each
stub router must detect the situation where, having deprecated its 
own prefix, all of the other prefixes being
advertised on the link have also been deprecated.

When this situation occurs, each router on the link MUST compare 
the valid lifetimes of all the prefixes that have been
seen. If the router's own prefix expires last, then that router 
should immediately resume publishing its prefix as a
preferred prefix.

If a router observes this situation and its prefix is not the one 
that expires last, it MUST set a timer for
UNDEPRECATE_WAIT seconds, while continuing to observe prefix 
advertisements on the link. If, when the timer expires, the
prefix that expires last has not been re-published as a preferred 
prefix, then that prefix is marked as 'really
deprecated', and no longer considered a candidate for 
de-deprecation.

Using the remaining list of prefixes, the router should then apply 
the same algorithm. It should continue to apply this
algorithm until either its prefix becomes the one to re-publish as 
preferred, or some other router has re-published its
prefix as preferred.

> 
> Section 3.3
> - "Stub routers MUST advertise reachability to stub network OSNR prefixes on 
> any AIL to which they are connected." Should we consider limiting which stub 
> routers advertise reachability if there are a large number of stub routers?

We could. I don’t know what the number should be,

Re: [homenet] Ted's stub network document: draft-lemon-stub-networks{, -ps}

[Ted Lemon]

On Feb 26, 2021, at 11:24 AM, Michael Richardson  wrote:

Thanks for the comments, Michael!

> I think that this is a key architectural document on connecting IoT networks,
> although there is some resistance to putting such a specific use case into
> the title.

The reason for this is that I think it’s a perfectly reasonable thing to do 
when you just want to connect a router to a pre-existing network so that you 
can use services on that network. So I really don’t want to constrain the use 
case to IoT. That is certainly the primary driving use case, though.
> 1) Perhaps "Stub Router" should be in the terminology.
>   The terms: AIL, NAIL, NAL and OSNR are introduced but aren't really used.
>   They aren't really that pneumonic.
>   If anything, I'd like a cool TLA for "Stub Router"

SNR?  But that confuses OSNR. The reason for all those TLAs is that “Adjacent 
infrastructure link” is a lot to type, and so is off-stub-network-routable 
prefix. :]

> 2) There is advise about monitoring the RAs from the infrastructure router
>   (which is probably the home CPE router), and soliciting them regularly.
>   In effect, the Stub Router can't depend that the CPE router will remain
>   alive for it's lifetime.
>   That is, the RA lifetimes tell the client how long it may use the
>   resource, but not how to determine if the router is alive.  Of course,
>   power can disappear at any time.
>   Ted: it seems that maybe neigh-cache entries already have all the timers
>   and rechecks needed, and maybe the Stub Router can just watch for
>   the NCE going Stale?

That would work, but depends on the stub router implementation being able to 
get a notification that this has happened, which means it’s running in the 
kernel. I don’t think that’s a likely scenario. Also, NCEs have lifetimes, so 
they will also outlive on-link routers.

> 3) _Adjacent infrastructure link (AIL)_  that's the home LAN, right?
>   Maybe it would clearer if it was just called that?

The problem is that “home lan” presupposes a very limited use model, and this 
is not intended to address just that use model. Stub network routers are 
expected to be useful in building infrastructure deployments as well.

> 4) I'd like to add a state machine diagram to 3.1.1/3.1.2.

I think that’s a good idea, although I am not really a fan of state machine 
*diagrams* — I’d maybe rather just describe the state machine. Diagrams are 
easy to misread. There are actually several state machines, and each I think is 
fairly simple, so writing out a list of states, events and state transitions 
may be practicable.

> 5) _IP addressability not present on adjacent infrastructure link_ (AIL)
>   When the Stub router finds no IPv6 on the "LAN" link, then it advertises
>   one.  I think that this prefix should be advertised as being _off-link_.

If it’s advertised as off-link, will hosts use it on-link as a source address 
for communications? That’s the point of advertising this prefix. We advertise a 
route to the stub network’s prefix, but we need a prefix on the adjacent 
infrastructure link in order for IPv6 communication to happen.

>   To clarify for others: the stub router will have a ULA, and it might
>   advertise ULA:0002::/64 on the AIL ("LAN"), and will number it's stub
>   network with ULA:0001::/64.  It will do this with a PIO that does not
>   include a default route.

To be clear, it will advertise an RA that has a router lifetime of zero, which 
indicates “not a default router.” The on-link prefixes on the stub network and 
the infrastructure network are advertised using PIOs. Reachability from the 
stub network to the infrastructure network and vice versa are advertised using 
Route Information Options (RIOs).

>   On the AIL, where there is also an IPv6 prefix (but not DHCPv6-PD),
>   then it just seems like not putting a second ULA on top of the LAN
>   for the purpose of communicating within the LAN seems better.
>   While the off-link prefix can be used for e2e communications on the
>   LAN, I think that the on-link prefix will be preferred.

If there’s already an on-link prefix on the AIL, the stub router doesn’t 
advertise an additional prefix—there’d be no point to this. This adds some 
complexity to the stub router implementation, but I think makes its presence on 
the network a bit less heavy. Particularly if you have multiple stub routers 
(e.g., a HomePod Mini stereo pair in several rooms in the house).

>   Perhaps this messes with DNS-SD discovery.

That’s not the issue, although we do have to be careful not to propagate 
addresses that won’t be reachable from off-link.

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

Re: [homenet] agenda planning

[Ted Lemon]

On Feb 23, 2021, at 2:20 PM, STARK, BARBARA H  wrote:
> draft-ietf-homenet-front-end-naming-delegation-12 and 
> draft-ietf-homenet-naming-architecture-dhc-options-08 were posted towards the 
> end of last year. There was some discussion on the list. We'll put them on 
> the agenda; but we also want to discuss how best to progress them -- ensuring 
> they get the review they deserve. 
> 
> Ted L: You had said maybe wanting to talk about stub resolvers. Do you still 
> want time for that?

Stub networks, not stub resolvers. Yes, I would like time for that. The 
relevant drafts are:

https://datatracker.ietf.org/doc/draft-lemon-stub-networks/ 


and

https://datatracker.ietf.org/doc/draft-lemon-stub-networks-ps/ 


Weirdly, I submitted a -01 for the problem statement draft prior to the 
deadline last night, but it doesn’t seem to have been published.

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

Re: [homenet] IETF 110 and homenet

[Ted Lemon]

On Jan 19, 2021, at 4:14 PM, STARK, BARBARA H  wrote:
> Since there were some WG draft updates published at the end of last year, 
> we've decided to have a joint session with dnssd WG during IETF 110 so we can 
> try to get some feedback on the drafts but also discuss how best to progress 
> them and ensure they get the review they need/deserve.

I’m likely to want to do a presentation on stub networks as well—I should have 
a document for the wg to look at shortly. Not sure if homenet is the right 
place, but I think the group should get right of first refusal.

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

Re: [homenet] [Editorial Errata Reported] RFC8375 (6378)

[Ted Lemon]

It’s nonsense. We put the dots on the end on purpose—it’s not an FQDN 
otherwise. :/

> On Jan 2, 2021, at 9:33 AM, Stephen Farrell  wrote:
> 
> 
> Any opinions on this from authors/list? My take would be that
> this can be rejected as inclusion of full stops within quotes
> is stylistically correct and that there's no technical issue
> with including the root's dot in a DNS name. But maybe some
> other convention has been followed for DNS RFCs in the past?
> 
> Cheers,
> S.
> 
> On 02/01/2021 08:27, RFC Errata System wrote:
>> The following errata report has been submitted for RFC8375,
>> "Special-Use Domain 'home.arpa.'".
>> --
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid6378
>> --
>> Type: Editorial
>> Reported by: Kulvinder Matharu 
>> Section: GLOBAL
>> Original Text
>> -
>> "home.arpa."
>> Corrected Text
>> --
>> "home.arpa"
>> Notes
>> -
>> The domain "home.arpa." is used throughout the document. The domain should, 
>> instead, be "home.arpa".
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>> --
>> RFC8375 (draft-ietf-homenet-dot-14)
>> --
>> Title   : Special-Use Domain 'home.arpa.'
>> Publication Date: May 2018
>> Author(s)   : P. Pfister, T. Lemon
>> Category: PROPOSED STANDARD
>> Source  : Home Networking
>> Area: Internet
>> Stream  : IETF
>> Verifying Party : IESG
> 

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

Re: [homenet] auto-passthrough from ISP routers

[Ted Lemon]

On Jul 24, 2020, at 07:04, otr...@employees.org wrote:
>>> 
>>> Cause it's architecturally "challenged"?
>> 
>> The working group or the solution?
> 
> Not sure how you could interpret that as pointing to the working group.
> 
> The solution obviously.
> IPv4 "pass through" implies sharing the IPv4 address among multiple nodes.
> Creating all sorts of tricky problems.
> Which of the nodes gets an ICMP error message for example.

Thanks for clarifying. It really was ambiguous and I really was confused—sorry!

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

Re: [homenet] auto-passthrough from ISP routers

[Ted Lemon]

On Jul 24, 2020, at 04:48, otr...@employees.org wrote:
>> On 23 Jul 2020, at 18:58, Michael Richardson  wrote:
>> 
>> This is very cool.
>> Is it written up as a specification somewhere?  What is the signal that the
>> device behind is a router, and not a PC?
>> 
>> Why isn't homenet standardizing this?
> 
> Cause it's architecturally "challenged"?

The working group or the solution?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled

[Ted Lemon]

I’m working on getting clearance to get a couple of documents published, one of 
which I think will be of interest to homenet, although its main target is 6man. 
 The delay works well for me—I only just came off a pretty intense development 
project, so I wasn’t able to get the document ready in time for IETF.  It’s not 
the best reason for a schedule improvement, but I’d appreciate being able to 
discuss that if I’m able to get it out in time for an interim hopefully 
sometime a bit after the original scheduled time.

Sent from my iPad

> On Mar 10, 2020, at 4:26 PM, Stephen Farrell  
> wrote:
> 
> 
> Hi all,
> 
> Many of you will have seen this but we'll not be meeting
> f2f in Vancouver this time. Hopefully things will have
> improved by the timeframe of IETF108.
> 
> In the meantime, we'd like to know if WG participants
> would like to hold a virtual interim for homenet. If
> you think that would be useful, please let the chairs
> or the list know.
> 
> The IESG have asked for a bit of time to do some scheduling
> that they need to do before WGs start to schedule such
> virtual interims. So if we do want a virtual interim please
> bear with us for a bit and we'll get back with a poll for
> a timeslot as soon as we can.
> 
> Cheers,
> S.
> 
> 
>  Forwarded Message 
> Subject: IETF 107 Vancouver In-Person Meeting Cancelled
> Date: Tue, 10 Mar 2020 12:10:27 -0700
> From: The IESG 
> Reply-To: i...@ietf.org
> To: IETF Announcement List 
> CC: irtf-annou...@irtf.org, i...@ietf.org, 107...@ietf.org
> 
> The IESG and the IRTF Chair have decided to cancel the in-person IETF
> 107 Vancouver meeting. This decision is based on input we gathered from
> Working Group (WG) and Research Group (RG) chairs about our ability to
> hold productive WG and RG sessions at IETF 107. Our assessment of this
> feedback is that a majority of sessions would not be viable if we were
> to hold the in-person IETF meeting. On this basis, we believe we cannot
> hold an effective in-person meeting.
> As a result of this cancellation, the in-person Hackathon, Code Sprint,
> all other in-person events planned for the weekend of March 21-22, the
> chairs training scheduled for March 20, and all other in-person sessions
> during the week are cancelled.
> 
> The IESG is working on an alternative all-virtual agenda for the week of
> March 21-27 with a limited schedule adapted to accommodate the time
> zones of as many participants as possible. We are also planning to
> support an increased volume of virtual interim meetings during the weeks
> that follow. We will send another update to the community soon with more
> information about these plans. The Hackathon organizers are also
> considering plans for virtual Hackathon support.
> 
> We have re-opened Internet-Draft submissions, which had been closed on
> March 9 in anticipation of the in-person meeting. Internet-Drafts may be
> submitted at .
> 
> A separate announcement from the IETF Executive Director will follow
> with details about registration cancellations and refunds.
> These are unusual times given the circumstances created by the spread of
> COVID-19.  We hope that everyone remains safe and healthy.
> 
> Regards,
> The IESG and the IRTF Chair
> 
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
> 
> <0x5AB2FAF17B172BEA.asc>
> ___
> 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] homenet agenda planning

[Ted Lemon]

I am planning to give a presentation on the problem of attaching stub networks 
to flat networks which may be of interest to Home net as well. 

> On Mar 5, 2020, at 05:06, STARK, BARBARA H  wrote:
> 
> The joint dnssd+homenet session is currently scheduled for Thursday morning, 
> 10:00-12:00 PDT.
> It is scheduled against cbor, gaia, icnrg, bmwg, spring, taps, and 
> privacypass (BOF; looking at a new protocol).
> 
> I've seen a flurry of activity in GitHub from Michael and Daniel on the 
> Outsourcing Home Network Authoritative Naming Service draft.
> https://github.com/ietf-homenet-wg/ietf-homenet-hna, if you're curious.
> 
> Are there any requests for homenet agenda time from anyone (especially Daniel 
> and Michael)?
> Barbara
> 
> ___
> 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] biggest L2 domain

[Ted Lemon]

On Dec 13, 2019, at 12:26 PM, Gert Doering  wrote:
>> On Fri, Dec 13, 2019 at 09:54:08AM -0500, Michael Richardson wrote:
>> In testing, we have found a device that does not put it's 5-"LAN" ports into
>> a bridge.  That's probably a missing configuration, but in the meantime, we
>> have an interesting HNCP and naming setup!
> 
> My understanding of "homenet" and "HNCP" devices has always been "every 
> single hole in the box is a routed port".  Now that's my understanding and
> not necessarily written down somewhere.
> 
> Magically grouping ports into a common L2 network and then un-grouping
> them in case one of them turns out to have another HNCP device connected
> sounds like an interesting challenge, to say the least :-)

Homenet in general is an interesting challenge—that was kind of a given when we 
started.   It’s definitely true that at least some substantial part of the 
Homenet effort, specifically the CeroWRT work, assumed one link per port.

Unfortunately, what we’ve seen is that multi-router vendors are _all_ assuming 
a flat link layer: bridging rather than routing.   This isn’t ideal in some 
ways, but it does give much better UX than having e.g. every WiFi AP on a 
different link, because the latter case results in routine connection dropping.

If we want to do better than the current state of the art in the market, we 
need to not adopt solutions that provide worse UX.   So one-link-per-port and 
one-link-per-AP is probably not a good direction to go.   If we want to 
accomplish whatever that accomplishes, we should figure out how to do it in a 
way that doesn’t reduce usability.

As for the HNCP case, there’s actually no reason why we need to assume that 
because two routers are plugged into the same link, it’s a point-to-point link. 
  If there’s more than three stations plugged into the “link” and two of them 
are routers, then the two routers can use the link for transit, and the other 
stations can use it for connectivity.

If it turns out that there is some performance benefit to making a 
port-to-port, point-to-point link for the router pair, then we can do that 
adaptively..   That’s an optimization: it need not be where we start, and 
indeed back when we were initially working on this, I don’t think there was any 
assumption that we would try to constrain links to being either point-to-point 
or multi-station.

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

Re: [homenet] Support for RFC 7084 on shipping devices...

[Ted Lemon]

On Oct 7, 2019, at 10:58 AM, Pascal Thubert (pthubert)  
wrote:
> As you indicate, a single mesh can approach 10^4. A depth can be al lot more 
> than the 10 hops that we imagined initially. Yet it keeps working.

How frequently do things change in the mesh?   Does this require any management 
to set up?

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

Re: [homenet] Support for RFC 7084 on shipping devices...

[Ted Lemon]

On Oct 7, 2019, at 10:16 AM, RayH  wrote:
> If the ISP is on the hook for support, then “their network” includes your 
> home network.
> 

What I mean is that the ISP gets phone calls from customers whether it’s their 
fault the network is broken or not.  So they aren’t going out of their way to 
make the home network more complicated.  Although we have seen ISP 
participation in Homenet, I do not expect them to be the drivers for this 
functionality.   I’d love to be proven wrong, but I don’t think it’s realistic 
to assume otherwise.

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

Re: [homenet] Support for RFC 7084 on shipping devices...

[Ted Lemon]

On Oct 7, 2019, at 10:00 AM, RayH  wrote:
> Why does an ISP have to add complexity to their network in order to support 
> Homenet?

If the ISP is on the hook for support, then “their network” includes your home 
network.



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

Re: [homenet] Support for RFC 7084 on shipping devices...

[Ted Lemon]

On Oct 7, 2019, at 9:15 AM, RayH  wrote:
> My preferred path would be to look at why Homenet hasn't been rolled out.
> 
> If it's because manufacturers aren't updating boxes at all, or even ipv6 at 
> all as per my local internet non-service provider, another standard ain't 
> going to solve that.
> 
> So is there concensus on what's broken? And what needs fixing?

I think it’s a lot simpler than that: they don’t have to do it, so they don’t.  
 There’s no upside for them in adding complexity to the network, and that’s 
what this looks like.   In order for homenet to see widespread adoption, there 
has to be a problem it solves that lots of home users have.

TBH, one of the reasons that I am not in favor of ND proxy is precisely that it 
kicks this can even father down the road.   IoT network transit and similar 
applications are a clear use case for Homenet; building a solution that’s going 
in entirely the wrong evolutionary direction seems like an unfortunate plan.

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

Re: [homenet] Support for RFC 7084 on shipping devices...

[Ted Lemon]

On Oct 7, 2019, at 3:37 AM, Pascal Thubert (pthubert)  
wrote:
> Too bad then... I still fail to see why the model cannot be generalized to 
> more powerful nodes.

Because it is maximally complex?   :]

You say that RPL has scaled to millions of nodes.   Where is this deployed in 
production?   What are the leaf nodes doing?   With what are they communicating?

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

Re: [homenet] Support for RFC 7084 on shipping devices...

[Ted Lemon]

On Oct 7, 2019, at 2:33 AM, Alexandre Petrescu  
wrote:
> If somebody makes a good solution and easily deployed for the topology
> in the above figure, then I am willing to consider it for vehicular
> networks as well.  In them, the CE Router is a Mobile Router in the car
> and the Internal Router is one of many other routers in the car.  The
> ISP is a cellular network and, potentially, an 802.11-OCB network.

Would ULAs work for your use case, or do you need routing to the Internet from 
the leaf network?

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

Re: [homenet] Support for RFC 7084 on shipping devices...

[Ted Lemon]

On Oct 6, 2019, at 11:36 PM, Ole Troan  wrote:
> I believe HNCP has solved the technical problem it set out to do. Allow for 
> an automatically configured, arbitrary topology network with multiple exits.
> The deployment challenge of that is that every router must support HNCP and 
> must support SADR.

The question I have about this is: if nobody is shipping this, how do we know 
that the problem is solved?   We have zero operational experience for the 
intended use case.   HNCP experts setting it up for themselves or people they 
know is not the target use case.  At present everybody who’se tried seriously 
to use this stuff has looked at the source code.

>>> I know why I haven't implemented HNCP on software I work on... and I also 
>>> know that there aren't any very realistic alternatives either.
>> 
>> Can you say why that is?
> 
> Quite a few reasons, some which might be not relevant to your case of course.
> - the pendulum between distributed algorithms and centralized controllers is 
> for the problems I'm working on largely towards the centralized side

This makes sense.

> - it's quite a lot of work. it requires a new routing protocol, it requires a 
> changed forwarding paradigm, and it requires integration with a lot of 
> features

Yes.   This is a big problem.

> - it does not support the case "permissionless extensions of the network".

That seems to contradict your first point—if you want permissionless extension, 
isn’t that by definition not centralized?

>>> RA guard isn't applicable in a RFC7084 context. RFC7078 talks about routing 
>>> and routers. I.e. what happens at the network layer.
>> 
>> You mean at the “internet layer,” I assume?
> 
> No, I mean the network layer. RA guard operates as a layer violating feature 
> at the data-link layer.

Hm, okay, fair point.   But I think that we need to say how RA guard works on 
home networks if we don’t want to have to guess.   Possibly this is not 6man 
work, but it feels relevant to me.

>>> If you are talking about what happens at the often integrated bridge CE 
>>> devices have, then sure, they could implement RA Guard.
>>> But having your additional router sending RAs across the homenet might not 
>>> be a particularly good idea anyway.
>> 
>> Why not?   What would be a better idea?   I don’t mean to say that using RAs 
>> in this way is ideal, but what’s the alternative that doesn’t involve the 
>> vast complexity of per-host routing?
> 
> I don't understand how it would work. Add another router with it's own link. 
> How would you get addresses for that link? Make them up from ULA? And then 
> advertise that in an RA upstream with the MSR option?
> That would put a lot of responsibility on the hosts of getting things "right".
> And what if you added two of your routers, or connected them differently?
> 
> Per-host routing is in itself trivial and likely scales orders of magnitude 
> further than you need. But there are problems with MLSR that are unsolved / 
> not solved to my liking yet there.

If you’re adding this to an RFC 7084 network, there are things that you can do 
that can work as long as RA guard isn’t present, and that achieve the limited 
goal of being able to have devices on one network communicate with devices on 
the other.   Indeed, a ULA would work well for this use case.   Allocate a 
single ULA, and then allocate prefixes out of it for the various networks.

I think that if you want to add more than one router, HNCP+Babel is a sensible 
way to do it.   But this is only required for leaf-to-leaf communication.   A 
device on the home network will have an RA advertising transit to each leaf 
prefix, and will either have IPv6 connectivity from RFC 7084, or from another 
prefix advertised on the link.

The problem with per-host routing is that it means I have to implement and 
deploy per-host routing, which I never want.   And as you add leaf networks, 
the number of routes being propagated starts to snowball.   I believe that this 
can be made to work for use cases I care about, but it’s in no way a “good” 
solution.  The main problem with it is that it means I have to write code to do 
it.   I’d rather not write that code if I don’t have to.

> for "permissionless extensions of the network" there isn't much else than NAT.
> Your other likely option is an ND proxy. If you are very sure that nothing 
> else can be added to the network (we don't want to build a spanning tree 
> protocol out of ND).

Yeah.  That is the exact situation I would most like to avoid, so I don’t want 
to be walking in that direction.

> Because you don't like the mechanisms for automated subnet assignment? ;-)

On the contrary, if HNCP were widespread, that’s what I’d be using.   HNCP 
would be my first choice for this.   I’d still like that to be the long-term 
solution.   But what can I build into a leaf router _today_ to make this work 
when the edge router doesn’t run HNCP?  :)

> And no, I'm not suggesting we should do MLSRv2 as a comp

Re: [homenet] Support for RFC 7084 on shipping devices...

[Ted Lemon]

What you’ve proposed doesn’t seem like it would make things better. 7084 give 
us working ipv6 on the home network. What you’re proposing would take that 
away. Let’s not go in that direction. 

> On Oct 6, 2019, at 23:05, Gyan Mishra  wrote:
> 

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

Re: [homenet] Support for RFC 7084 on shipping devices...

[Ted Lemon]

On Oct 6, 2019, at 17:46, Michael Thomas  wrote:
> If the protocol is not truly plug and play in reality... wasn't that the 
> entire premise? That doesn't sound like an ops problem. I understand that 
> openwrt is a wonk box, but still if there isn't default configuration that 
> would make it truly plug and play for most situations, that sounds really 
> problematic.
> Can you confirm or not that openwrt could be set up by default in a way that 
> met the charter's requirements for operations (ie, like what you might expect 
> in a commercial home router)?
> 

I think it can be, but the openwrt work never went that far.  We’re working on 
it again now, but even if we get it working nicely in openwrt, that doesn’t get 
it to where I can assume it will be working on some arbitrary home network 
anytime in the next five years. ___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Support for RFC 7084 on shipping devices...

[Ted Lemon]

On Oct 6, 2019, at 10:58 AM, Ole Troan  wrote:
> Are you saying there might be gaps in HNCP? Or things we could do to make it 
> more deployable?
> If it's just a matter of running code missing, I'm not sure defining anything 
> else new in the IETF would help that problem.

There are definitely missing features from the protocol that I’d like to add.   
But I think the fact that the protocol isn’t deployed on a _single_ 
commercially available router, and is not really usable on OpenWRT by a 
non-expert, is an indication that there is substantial remaining work to do.   
Operations work is not out of scope for IETF; maybe I should have asked this on 
v6ops.   We have historically said “not our problem,” but I don’t agree that 
that’s the right answer.   If HNCP had really convincingly solved the problem, 
we would not be seeing what we are seeing.

> I know why I haven't implemented HNCP on software I work on... and I also 
> know that there aren't any very realistic alternatives either.

Can you say why that is?

> RA guard isn't applicable in a RFC7084 context. RFC7078 talks about routing 
> and routers. I.e. what happens at the network layer.

You mean at the “internet layer,” I assume?

> If you are talking about what happens at the often integrated bridge CE 
> devices have, then sure, they could implement RA Guard.
> But having your additional router sending RAs across the homenet might not be 
> a particularly good idea anyway.

Why not?   What would be a better idea?   I don’t mean to say that using RAs in 
this way is ideal, but what’s the alternative that doesn’t involve the vast 
complexity of per-host routing?

> Sounds like you need to set it up as a NAT.

I really hope you are just making a funny joke here.   But it’s not very funny. 
  What I want is something that’s operationally simple, not something with lots 
of moving parts that have to be kept track of.   NATs in particular suck for 
any UDP-based protocol.

> I wasn't thinking of doing it exactly like the 6lowpan does it.
> Regardless I don't see why scaling should be problematic, are you planning to 
> have millions of rapidly moving hosts on your shared /64 network?

If you have N devices on a single link on the other side of the router, then 
when using either RA or a routing protocol, the amount of information you need 
to propagate to get things working is very small: just a prefix and a router.   
If you can’t do that, then the amount of information you need to propagate is 
at a minimum N units, and possibly K*N, for some not insignificant factor K.

To be clear, the reason I’m concerned about this is that I’ve looked at 
implementing it on OpenWRT, and it’s at least roughly doubling the complexity 
of the work required, even if you can depend on using IPv6.   If you have to 
use IPv4 on one side, then it’s even more complexity.   And it’s utterly stupid 
complexity—it adds no value over subnetting.   Why add that to the network?

This is why I’m asking people if they have knowledge of what is actually 
deployed.   I think this is the right place to ask, but if you disagree, I’m 
open to suggestions.


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

Re: [homenet] Support for RFC 7084 on shipping devices...

[Ted Lemon]

On Oct 4, 2019, at 6:28 AM, Ole Troan  wrote:
>>> Homenet has solved the problem of self-configuring networks in arbitrary 
>>> topologies.
>> 
>> If that were true, I wouldn’t be asking this question.  We’re still chugging 
>> along, but we don’t have something that nay router vender could even 
>> consider shipping right now. There isn’t enough participation in homenet 
>> anymore for us to really iron out the kinks.  Certainly if I could count o 
>> homenet being present in routers in the home, we wouldn’t be having this 
>> conversation! :)
> 
> Since this was sent to an IETF list I assumed you were focused on standards. 
> (And presumably also running code). :-)

It’s the running code that’s the problem.  What I’m hunting around for is 
whether there are some things we need to do that we haven’t yet done.   I wish 
I could say “just turn on Homenet and everything will be fine,” but we aren’t 
in a position to say that yet.   If people are feeling satisfied that homenet 
is “done,” we (the IETF, and the Internet community in general) have a problem.

We’d been tempted to punt on this because there are perfectly good commercial 
solutions that solve this problem with L2 bridging, but those don’t work when 
you need to route between WiFi and e.g. 6lowpan networks.

>>> - single router and bridging (7084)
>> 
>> If it doesn’t filter RA, and I control the second router, I’m okay, right?
> 
> Well, yes it isn't a router at that point, it's a bridge.

The reason I mentioned this particular problem is that I’ve heard reports of 
7084 routers implementing RA guard, which sort of makes sense, but it totally 
breaks this use case.

>>> - arbitrary topology plug and play (homenet)
>> 
>> Yes, that’s homenet.   It would really help if folks who think homenet is 
>> done would try to deploy it in their home using OpenWRT and see how it goes. 
>>   Seriously.   This is not a solved problem.   We’re maybe 50-60% of the way 
>> there at this point.   I’ve been trying to make progress on this ever since 
>> HNCP was declared done, and occasionally get collaboration, and indeed we 
>> may be begining to make progress agan, but we could definitely use more 
>> participation if there are folks in 6man who want this to work and imagine 
>> that it already does.
> 
> The notion of "permissionless extensions of the network" is still somewhat 
> unresolved. HNCP allows for that, but as we know it's not well 
> supported/deployed. I had some hopes for multi-link subnet routing 
> (implemented how it was originally intended, not as spanning tree in ND). But 
> I have never gotten around to flesh that out in detail. Pascal has done 
> various stuff in this space for lowpan, which may be something to build on.
> 
> The MLSR idea is basically a /64 shared across all links. Hosts register with 
> routers using ARO (or DHCP). Routers advertise host routes in a routing 
> protocol between themselves. The tricky parts are of course detecting when 
> hosts go away, detecting movement and so on.

I’ve seen this.   It’s how the 6lowpan folks seem to have defined their 
“routing."   But scalability is horrible, and when I’ve looked at doing an 
implementation, it’s obviously ridiculously harder than just publishing an RA.  
 And it’s particularly hard if there’s no IPv6 on North Network.So if 
there’s a way to get IPv6 to work in this case, that seems like a better option.

> A side meeting in Singapore perhaps?

I’m not going to be in Singapore—I just can’t justify the carbon footprint.   I 
do think we ought to have a deeper discussion about this, though.   Maybe a 
“virtual interim”?   If there’s interest, I’d be happy to organize this.   I’d 
also be happy to attend a side meeting in Singapore remotely, but our 
experience with that thus far has been pessimal, and I don’t think a fix is 
planned for Singapore (unless I just haven’t heard about it).

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

Re: [homenet] Support for RFC 7084 on shipping devices...

[Ted Lemon]

On Oct 4, 2019, at 5:10 AM, Ole Troan  wrote:
> Homenet has solved the problem of self-configuring networks in arbitrary 
> topologies.

If that were true, I wouldn’t be asking this question.  We’re still chugging 
along, but we don’t have something that nay router vender could even consider 
shipping right now.  There isn’t enough participation in homenet anymore for us 
to really iron out the kinks.  Certainly if I could count o homenet being 
present in routers in the home, we wouldn’t be having this conversation! :)

> Unless someone goes to lengths describing exactly how this is supposed to 
> work, the idea of "simplifying" the homenet solution sounds like a recipe for 
> failure.

I tend to agree, but wasn’t proposing that.   I was really just trying to solve 
the very specific problem of how I do IPv6 routing in the case I described, 
given the hardware that is likely to be present in the home.

> How are you going to tell the customers that you can only plug in devices in 
> particular topologies and in particular ways.

The customer already has a router.   Suppose I want to add a router with a 
bunch of devices behind it, and  I know the router I’m adding will never have a 
second layer behind it.   Can I get it to work?   That’s the problem.

> - single router and bridging (7084)

If it doesn’t filter RA, and I control the second router, I’m okay, right?

> - arbitrary topology plug and play (homenet)

Yes, that’s homenet.   It would really help if folks who think homenet is done 
would try to deploy it in their home using OpenWRT and see how it goes.   
Seriously.   This is not a solved problem.   We’re maybe 50-60% of the way 
there at this point.   I’ve been trying to make progress on this ever since 
HNCP was declared done, and occasionally get collaboration, and indeed we may 
be begining to make progress agan, but we could definitely use more 
participation if there are folks in 6man who want this to work and imagine that 
it already does.

> - manually configured (meaning ansible, scripts or whatever automation 
> solution external to the routers themselves).

Yech.   That’s not an option.  :]

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

[homenet] Support for RFC 7084 on shipping devices...

[Ted Lemon]

(If you got this as a Bcc, it’s because I am hoping you can contribute to the 
discussion, but might not be on the mailing list to which I sent the question, 
so please answer on-list if you are willing.)

I’ve been involved in some discussions recently where the question has come up: 
how good is support for RFC7084 in shipping routers?   And what gaps exist in 
RFC7084 that could cause problems?   And in cases where RFC7084 support either 
isn’t present, or isn’t useful because no IPv6 or because ISP is delegating a 
/64, what things might work and what things might not, if we want bidirectional 
reachability between two separate network links in the home.

So for example, suppose we have "CE Router," which supports RFC7084, including 
prefix delegation.  And we have "Internal Router" on that network requests a 
delegation, and gets a prefix from the CE router.  Presumably that prefix is 
out of a larger prefix that CE Router got from the ISP.  Great so far.  Let’s 
call the network on the southbound interface of Internal Router “South 
Network”. Let’s call the network on its northbound interface, which is also the 
network on CE router’s southbound interface, “North Network.”

viz:

ISP
 |
 CE Router
 |
North Network
|---+--+-|
 |  |
   Internal Router  + Node A
 |
South Network
|---+---+|
 |
   Node B ---+


If I want hosts on South Network to communicate with hosts on North Network, 
what do I have to do?   Should Internal Router publish an RA on its northbound 
interface?   What is the likelihood of that being filtered by the network?   If 
packets for South Network are forwarded through CE Router, will it forward them 
on to Internal Router, forward them north, or drop them?

Similarly, suppose we have a network where unfortunately PD Isn’t available 
internally, but IPv6 is present on the northbound interface of the internal 
node and southbound interface of the CE router.   Suppose further that Internal 
Router allocates itself a ULA prefix and advertises that as reachable and 
on-link on its southbound interface, and as reachable but not on-link on its 
northbound interface.   Will that be blocked at layer 2 by CE Router?   I’m 
sort of assuming here that the CE router is managing the North Network link, 
which is probably WiFi.

Okay, now what if there’s no IPv6 support on CE Router or being provided by CE 
router on North Network.   Suppose Internal Router allocates a ULA and 
allocates two /64s out of the ULA, one of which is advertised as reachable on 
its northbound interface and on-link on its southbound interface, and a second 
of which is advertised as on-link on its northbound interface and reachable on 
its southbound interface.

Fourth possibility: Node A is manually configured with an IPv6 address on a 
prefix that Internal router is advertising as reachable on its southbound 
interface, but which is not advertised on South Network because of filtering.  
Node B has an address on a prefix that Internal Router is advertising as 
on-link on its southbound interface.   Node A has a static route configured 
through Internal Router to the second prefix.   Is there any reason to think 
that traffic between Node A and Node B will be filtered at layer 2 by CE 
Router, assuming that traffic on North Network is all going through CE Router?

The goal here is to have bidirectional reachability between the two nodes on 
IPv6 using either a global prefix or a ULA.  The concern is that something 
could prevent each of these cases from working.   What I’m really curious about 
is whether people have experience with doing communications of this type using 
actual routers that ISPs are shipping.   Is this “internal network” scenario 
part of acceptance testing for these routers?  Is this all a big question mark? 
  In principle this should all work, unless RA guard is hyperactive in CE 
Router.   But what about in practice?


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

Re: [homenet] DNCP/HNCP Revisited

[Ted Lemon]

On Sep 19, 2019, at 7:51 PM, Juliusz Chroboczek  wrote:
> Because HNCP allows aggregating multiple TLVs in a single packet, to the
> implementation's discretion.  Section 4.2 of RFC 7787.

Thanks, Juliusz.  This and your previous message were quite helpful.

I think there does need to be some hacking done on HNCP, but I agree with you 
that it’s a heavy lift.

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

Re: [homenet] DNCP/HNCP Revisited

[Ted Lemon]

Yes, of course. We can never change a standards track protocol. That would be 
wrong. :)

What I’m trying to understand is how bad a problem this is. 

> On Sep 19, 2019, at 04:56, Juliusz Chroboczek  wrote:
> 
> 
>> 
>> This still doesn’t address the problem that the HNCP packet needs to be
>> fragmented.  Fragmented Multicast doesn’t scale well.
> 
> HNCP doesn't fragment multicast, it only uses fragmentation for (link-local)
> unicast.  This is way less severe than what you incorrectly claim.
> 
> At any rate, the right time to discuss that was 2015, not now.  HNCP is
> a standards track protocol, and there's nobody left who's willing and
> competent to work on a new revision.
> 
> -- Juliusz

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

Re: [homenet] DNCP/HNCP Revisited

[Ted Lemon]

This still doesn’t address the problem that the HNCP packet needs to be 
fragmented. Fragmented Multicast doesn’t scale well. 

> On Sep 18, 2019, at 19:09, Juliusz Chroboczek  wrote:
> 
> 
>> 
>> If you have a discontinuous L2 MTU, you do not need fragmented packets
>> to see packets disappear.
> 
> Ah, I see.
> 
>> No fragmentation of any sort involved, just incorrectly set up L2 segments.
> 
> Right.  It's an incorrect network setup.
> 
> To fix that, it should be enough to point the tunnel directly at a Homenet
> router rather than relying on bridging.  (A good idea in any case, since
> Babel is able to make better routing decisions if the tunnel is directly
> visible to it.)
> 
> -- 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] DoH??

[Ted Lemon]

Let’s not discuss this here. This is a topic for add. 

> On Sep 18, 2019, at 18:27, Michael Thomas  wrote:
> 

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

Re: [homenet] DoH??

[Ted Lemon]

On Sep 18, 2019, at 6:07 PM, Michael Thomas  wrote:
> So I'm a little unclear about the specifics of Firefox using DNS over HTTP, 
> but wouldn't this affect homenet naming, or any split horizon kind of naming?

In order for DoH to not break lots of things, it has to be implemented in such 
a way that special-use names are not resolved using a global resolver, and that 
VPN-supported names are looked up using the VPN resolver.   It would also be 
nice if there were a way for the homenet to signal that a public domain 
belonging to it is resolved locally, so that split-horizon naming on the 
homenet works correctly.  Similar functionality will be required for corporate 
networks that do split-horizon naming.

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

Re: [homenet] DNCP/HNCP Revisited

[Ted Lemon]

On Sep 18, 2019, at 4:57 PM, Gert Doering  wrote:
>> The problem is, how???d the packet get so big that it was fragmented?
> If you have a discontinuous L2 MTU, you do not need fragmented packets
> to see packets disappear.

That’s kind of a non-sequitur.  The packet would need to be fragmented in this 
case.  The question is, how’d it get that big?  If we’re seeing packets large 
enough to fragment in a normal-sized network, that’s a really big problem 
(pardon the pun).

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

Re: [homenet] DNCP/HNCP Revisited

[Ted Lemon]

On Sep 18, 2019, at 3:39 PM, Juliusz Chroboczek  wrote:
> Is that not a bug?

The problem is, how’d the packet get so big that it was fragmented?

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

Re: [homenet] appropriateness of draft-shytyi-opsawg-vysm-03 to homenet WG?

[Ted Lemon]

That diagram isn’t consistent with what Homenet has been trying to build: it 
appears to be a base assumption of this work that there is a single virtual CPE 
router, and that’s not a homenet problem.

> On Sep 18, 2019, at 4:14 AM, Alexandre Petrescu 
>  wrote:
> 
> 
> 
> Le 17/09/2019 à 15:34, Ted Lemon a écrit :
>> On Sep 17, 2019, at 9:29 AM, Alexandre Petrescu 
>> mailto:alexandre.petre...@gmail.com> 
>> <mailto:alexandre.petre...@gmail.com <mailto:alexandre.petre...@gmail.com>>>
>> wrote:
>>> Thanks for the reply.  As I do not author the draft, and my
>>> colleague is not subscribed to this list, I paste here his reply to
>>> your question:
>>>> It is not really clear if the draft is appropriate to the homenet
>>>> wg. One can state that this draft presents a tool/solution
>>>> (service yang model) for orchestator to manage the different uCPE
>>>> equipment. uCPE eqipment is not regular cpe/homenet device. uCPE
>>>> is a host that hosts guest OSs. uCPE is like PC with virtualbox where the 
>>>> VMs are running (VMs such as homenet router,cisco
>>>> router, firewall, SD-WAN.)
>> Thanks.   The question I would ask here is, is it intended that this
>> uCPE integrate into a multi-subnet, multi-homed homenet?
> 
> Temporary speaking for my colleague, this is what he has to say to the 
> question:
> 
>> If we are talking, for example, about several IPv6 prefixes that are
>> learned from muliple ISPs I could suggest that uCPE is transparent in
>> this case. On the figure below we can see that uCPE connects 2 PHY
>> ports via virtual Links to the Virtual Ports of VNF. So it is the
>> VNF(vRouter) that is doing the job. There is example where the
>> constructor of equipment merges the uCPE NFVIs with router (i find it
>> as a very particular case).
>> If we are talking about implementation of babel in the uCPE please
>> check the figure below. I suppose it is a vRouter that will have this
>> functionality (not uCPE NFVIs).
>> P.S. There is a management of NFVIs that maybe could be integrated.
>> But it is a question if there is an interest to do that.
> 
>   ++
>   |uCPE|
>   ||
>   | ++ |
>   |   |-|vRouter |-|WAN1
> LAN1 --||  | ++ |
>   ||  |  | |
>   ||  |  | |
> LAN2 --||--|  |-|WAN2
>   ||   |
>   ||   |
> LAN3 --||   |
>   ||
>   ||
>   ++

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

Re: [homenet] appropriateness of draft-shytyi-opsawg-vysm-03 to homenet WG?

[Ted Lemon]

On Sep 17, 2019, at 9:29 AM, Alexandre Petrescu  
wrote:
> Thanks for the reply.  As I do not author the draft, and my colleague is not 
> subscribed to this list, I paste here his reply to your question:
> 
>> It is not really clear if the draft is appropriate to the homenet wg.
>> One can state that this draft presents a tool/solution (service yang
>> model) for orchestator to manage the different uCPE equipment. uCPE
>> eqipment is not regular cpe/homenet device.
>> uCPE is a host that hosts guest OSs. uCPE is like PC with virtualbox
>> where the VMs are running (VMs such as homenet router,cisco router,
>> firewall, SD-WAN.)

Thanks.   The question I would ask here is, is it intended that this uCPE 
integrate into a multi-subnet, multi-homed homenet?

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

Re: [homenet] appropriateness of draft-shytyi-opsawg-vysm-03 to homenet WG?

[Ted Lemon]

On Sep 17, 2019, at 7:06 AM, Alexandre Petrescu  
wrote:
> This draft-shytyi-opsawg-vysm-03 describes a YANG model for uCPE.  A Customer 
> Premises Entity is for enterpise and home networks.
> 
> Is this draft appropriate here?
> 
It’s a bit off-charter.  It’s not necessarily a wrong thing to pursue here, but 
you’d need to talk us into doing it, and more importantly there’d need to be 
people here interested in working on it.  It’s likely that most people reading 
this have no idea what the draft is about, so if you want to try to pursue it 
here, the first thing I’d suggest you do is tell the WG what problem you are 
trying to solve.  :)

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

Re: [homenet] IPv6 & firewall config in a home net

[Ted Lemon]

> On Sep 8, 2019, at 07:59, Michael Richardson  wrote:
> 
>> RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)
> 
>> That was done to prevent tracking when people move between wifi
>> hotspots.
> 
> But, a host running a web server that wants to be in the same place could
> keep the same RID once generated.

Since the prefix is changing, keeping the host ID the same makes no difference. 
Presumably the server’s host name will be what’s invariant. 

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

Re: [homenet] IPv6 & firewall config in a home net

[Ted Lemon]

On Sep 2, 2019, at 1:58 PM, Michael Richardson  wrote:
> Question: do PCP messages always go to the default route?  I re-read 6887 and
> that was unclear. RFC7488 did not clarify for me.

PCP requests go to the PCP server the client chooses.   PCP servers can 
currently only be advertised using DHCP.   If there are multiple PCP servers, 
the client has to register with all of them.   A PCP server should know whether 
it makes sense to register a port/address combination with it.

> How does it work if there are multiple layers of router?

I believe that the PCP server on the inner router communicates with the PCP 
server on the outer router, but I’d have to double check.

On 05/09/2019 14:45, Ray Hunter (v6ops) wrote:
> That will likely mean regular renumbering of IA PD by ISP's as the norm
> rather than the exception.

It should be assumed to be the rule, so that if it is the rule, it is handled 
correctly.

On Sep 2, 2019, at 1:47 PM, Michael Richardson  wrote:
> Assuming that the prefix change is make-before-break (which we do not clearly
> know how to do on the WAN side, I think), then the web server should
> configure with the same rfc7212 IID, but a new prefix.

I don’t think there’s any need for the IID to be persistent.   
Make-before-break is accomplished by deprecating the old prefix when the new 
prefix is added.   This is trivial to do; whether it is in fact done is a 
different matter.   I think that at present the client would have to notice 
that it’s happened.

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

Re: [homenet] IPv6 & firewall config in a home net

[Ted Lemon]

Your router should be using PCP to allow servers to open ports and should have 
a GUI to authorize that, or better yet support MUD profiles and use the GUI to 
control that. 

Sent from my iPhone

> On Sep 2, 2019, at 11:55, mal.hub...@bt.com wrote:
> 
> 
> Hey,
>  
> Mal here. IETF attendee since 2012 ;)
>  
> I have a home networking question with respect to IPv6 standards, I’m hoping 
> to use you as a sounding board first before I take it to v6ops.
>  
> The scenario here is a home / soho network situation where the user wants to 
> host a service, lets say its a webserver, but really could be any hosted 
> application, importantly using IPv6. The router is setup to use SLAAC only.
>  
> The ISP offers IPv6 GUA addressing in a non-stable manor, its "sticky" but at 
> some point in the future it might change (BNG reboot for example), so the 
> user will use DynDNS provider to provide a stable name for their service, 
> this sounds OK so far.
>  
> The user has to allow the webserver port, 443 in their router GUI firewall to 
> allow the traffic in, sounds simple enough. Importantly it should be to that 
> webserver device only.
>  
> Now the tricky part….
>  
> Since in this scenario the webserver device is using privacy extensions, it 
> has a bunch of IPv6 GUA addresses and no EUI-64 and
> - It has Temporary addressing (which will regularly change)
> - It has a "Permanent" address (which is the one the webserver will want to 
> use)
>  
> Does this sound reasonable and make sense so far ? Cool.
>  
>  
> In the router GUI the user is presented with a list of "devices" for which 
> the router can open up TCP 443 in the firewall.
>  
> It is reasonable to assume the user does not want to type in the Permanent 
> IPv6 address of the device, as it is poor CX and anyway it will change in the 
> future (possibly due to a network change / BNG restart etc as mentioned)
>  
> Current routers on the market I have come across have either:
>  
> Open the port to the current temporary address only which means that inbound 
> connections on the port usually fails right away (if the webserver is not 
> listening on that address) – or fail after the temporary address changes.
> Opens the port to the correct address (by chance)
> - But then fails at some point in the future when the network prefix changes 
> (as router drops the rule when the prefix changes).
> Opens the port to some or ALL addresses currently (& sometimes historically) 
> associated with the mac address of the device  (not great for security – 
> spoofing? )
> But even that sometimes excludes the permanent address
> Opens the port to all addresses on LAN (not great for security at all)
>  
> Basically the routers firewall config gui doesn’t know reliably which device 
> address is the permanent one.
>  
> Should there exist a mechanism to signal to the router or the router can 
> accurately learn which of the devices addresses should be used for 
> configuration in the firewall ?
>  
> Is this a problem – have I missed something – Is it worth fixing ?
>  
>  
> Thoughts:
> This is probably a strange thing for the user to do (but I have had users 
> trying to do it). Its usually fixed for a customer by switching off privacy 
> extensions / using EUI-64 so basically giving the device a single address for 
> the router gui to identify the device by.
>  
> Mal
>  
> ___
> 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] homenet notes

[Ted Lemon]

On Jul 30, 2019, at 12:31 PM, STARK, BARBARA H  wrote:
> I think it's reasonable to consider the possibility of having an October 
> virtual interim. Perhaps a decision could be made during the August virtual 
> interim?

I would be inclined toward virtual hackathons, personally.   I think we’ve made 
more progress by just getting code running.   Documents spring naturally from 
that work, not vice versa.

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

Re: [homenet] homenet notes

[Ted Lemon]

On Jul 29, 2019, at 8:08 PM, Michael Richardson  wrote:
> It seems like "SRP in homenet" and "service discovery in homenet" might be 
> the same thing.  I can't recall what the distinction was, but I recall that's 
> we'd wind up with five documents.

There’s the stateful service and the stateless service—I think that might have 
been the distinction.   It’s easier to describe the stateless solution, of 
course.

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

Re: [homenet] final planning for not formally meeting

[Ted Lemon]

On Jul 20, 2019, at 5:17 PM, RayH  wrote:
> One question on re-reading this version: why not populate the reserve zone 
> automatically from the data used to update the forward zone?

That’s exactly what we’ve figured out in the Service Registration Protocol 
document. :)


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

Re: [homenet] final planning for not formally meeting

[Ted Lemon]

On Jul 20, 2019, at 9:49 AM, RayH  wrote:
> This (expired) draft?
> 
> https://tools.ietf.org/html/draft-ietf-homenet-simple-naming-03 
> 
Yes.

We decided to get some implementation experience before proceeding, and it 
hasn’t popped to the top of the stack yet (except maybe at this hackathon).

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

Re: [homenet] final planning for not formally meeting

[Ted Lemon]

We have a design for local resolution in the homenet naming architecture doc.. 
I haven’t reviewed the latest front-end naming doc yet but presumably we can 
implement that and see what happens. :)

Sent from my iPhone

> On Jul 20, 2019, at 4:46 AM, RayH  wrote:
> 
> > If anybody is interested in building what I’m building, I can supply some 
> > pointers. 
> 
> Please. A working build chain would save a lot of effort. I'm on vacation 
> now, but I should have some time when I get back.
> 
> > Stuart and I have four AR750S routers between us. The challenge will be 
> > figuring out how to get HNCPd to negotiate naming.
> 
> I think that depends on how the name space, serving, and resolving is going 
> to be structured.
> 
> Do you already have ideas?
> 
> A fully distributed system would need to inform other name servers of the 
> local zones in use, and break ties. A centralised system would need to crown 
> a queen in a similar way to selecting the root bridge in 802.1d.
> 
> Regards,
> 
> 
> On 20 Jul 2019 02:49, Ted Lemon  wrote:
> Stuart and I have four AR750S routers between us. The challenge will be 
> figuring out how to get HNCPd to negotiate naming.
> 
> Sent from my iPhone
> 
> > On Jul 19, 2019, at 7:15 PM, Michael Richardson  
> > wrote:
> > 
> > 
> > STARK, BARBARA H  wrote:
> >> If there are people interested in HNCP integration, I’m happy to
> >> reserve space for that (at a time different from the -naming effort),
> >> and I’m happy to participate in that as well.
> > 
> > I want to do HNCP integration at the hackathon, if we can.
> > If it overflows into the Code Lounge, fine.  But, my idea for Tuesday 
> > morning
> > is that it's about bashing documents, not code.
> > 
> >> I’ll see about reflashing my router to the most current OpenWRT.. It
> >> really needs updating, anyway.
> > 
> > I'm also happy if we get (at the Hackathon) devices that people bring up to 
> > "current"
> > 
> > -- 
> > ]   Never tell me the odds! | ipv6 mesh 
> > networks [ 
> > ]   Michael Richardson, Sandelman Software Works| network architect 
> >  [ 
> > ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails  
> >   [ 
> >   
> 
> ___
> 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] final planning for not formally meeting

[Ted Lemon]

Stuart and I have four AR750S routers between us. The challenge will be 
figuring out how to get HNCPd to negotiate naming. 

Sent from my iPhone

> On Jul 19, 2019, at 7:15 PM, Michael Richardson  wrote:
> 
> 
> STARK, BARBARA H  wrote:
>> If there are people interested in HNCP integration, I’m happy to
>> reserve space for that (at a time different from the -naming effort),
>> and I’m happy to participate in that as well.
> 
> I want to do HNCP integration at the hackathon, if we can.
> If it overflows into the Code Lounge, fine.  But, my idea for Tuesday morning
> is that it's about bashing documents, not code.
> 
>> I’ll see about reflashing my router to the most current OpenWRT. It
>> really needs updating, anyway.
> 
> I'm also happy if we get (at the Hackathon) devices that people bring up to 
> "current"
> 
> -- 
> ]   Never tell me the odds! | ipv6 mesh networks 
> [ 
> ]   Michael Richardson, Sandelman Software Works| network architect  
> [ 
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [ 
>

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

Re: [homenet] final planning for not formally meeting

[Ted Lemon]

I meant that I would like to work on HNCP integration at the Hackathon. I do 
not want to have a theoretical discussion about it. :)

Sent from my iPhone

> On Jul 15, 2019, at 5:48 PM, STARK, BARBARA H  wrote:
> 
> If there are people interested in HNCP integration, I’m happy to reserve 
> space for that (at a time different from the -naming effort), and I’m happy 
> to participate in that as well.
> Just pick a date/time.
> Wherever there’s interest, I’d like to try to help get like-minded people 
> together.
> I’ll see about reflashing my router to the most current OpenWRT. It really 
> needs updating, anyway.
> Barbara
>  
>  
> From: Ted Lemon  
> Sent: Monday, July 15, 2019 3:55 PM
> To: STARK, BARBARA H 
> Cc: Michael Richardson ; homenet 
> Subject: Re: [homenet] final planning for not formally meeting
>  
> On Jul 15, 2019, at 3:42 PM, STARK, BARBARA H  wrote:
> I reserved the Coller room for Tuesday morning (08:30 - 10:00). It says it 
> holds up to 16 people. There are bigger rooms available (and additional 
> times, but I figured you meant before the first session since there's an 
> anima meeting Tuesday first session), but I thought this size might be better 
> because I'm not expecting a lot of people? I can also support remote 
> attendance with this size of room, using an iPad. You'll find the reservation 
> listed at:
> https://trac.ietf.org/trac/ietf/meeting/wiki/105sidemeetings
>  
> This is opposite a “Technology Deep Dive” talk that some folks might want to 
> go to.
>  
> I have an OpenWRT repo set up here that I’m using for the hacking I’m doing, 
> and that we could use as a collaborative space if it seems useful: 
> https://github.com/IETF-Hackathon/openwrt
>  
> Right now the packages I’m working on don’t build out of the box, but I’ll 
> fix that in the next day or so.   If anybody is interested in building what 
> I’m building, I can supply some pointers.   I’m doing my development on the 
> GL-iNet AR-750S router, which builds cleanly out of this repo.   In principle 
> the repo is tracking OpenWRT current, but I haven’t merged in a few days.
>  
> My plan is to hack on homenet stuff—if there are folks who want to do naming, 
> that would be great, but I wouldn’t mind doing some HNCP integration if 
> there’s anyone who’s interested in that.
>  
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] final planning for not formally meeting

[Ted Lemon]

On Jul 15, 2019, at 3:42 PM, STARK, BARBARA H  wrote:
> I reserved the Coller room for Tuesday morning (08:30 - 10:00). It says it 
> holds up to 16 people. There are bigger rooms available (and additional 
> times, but I figured you meant before the first session since there's an 
> anima meeting Tuesday first session), but I thought this size might be better 
> because I'm not expecting a lot of people? I can also support remote 
> attendance with this size of room, using an iPad. You'll find the reservation 
> listed at:
> https://trac.ietf.org/trac/ietf/meeting/wiki/105sidemeetings 
> 

This is opposite a “Technology Deep Dive” talk that some folks might want to go 
to.

I have an OpenWRT repo set up here that I’m using for the hacking I’m doing, 
and that we could use as a collaborative space if it seems useful: 
https://github.com/IETF-Hackathon/openwrt 


Right now the packages I’m working on don’t build out of the box, but I’ll fix 
that in the next day or so.   If anybody is interested in building what I’m 
building, I can supply some pointers.   I’m doing my development on the GL-iNet 
AR-750S router, which builds cleanly out of this repo.   In principle the repo 
is tracking OpenWRT current, but I haven’t merged in a few days.

My plan is to hack on homenet stuff—if there are folks who want to do naming, 
that would be great, but I wouldn’t mind doing some HNCP integration if there’s 
anyone who’s interested in that.

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

Re: [homenet] primary / secondary configuration

[Ted Lemon]

On Jun 18, 2019, at 11:47 AM, Daniel Migault  
wrote:
> The question to the WG is whether this worth being tried, or if we are 
> missing something. Any thoughts, feed back would be appreciated. 

The way such feedback is generated is through experience…

I happen to think that it’s worth at least talking about how this information 
is managed, and talking about what a management API would look like should be 
in scope.   Talking about what the UI should look like that sits on top of that 
API?   Out of scope.

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

Re: [homenet] primary / secondary configuration

[Ted Lemon]

On Jun 18, 2019, at 11:14 AM, Daniel Migault  
wrote:
> I agree, however,  think that we are moving toward what we want to implement, 
> though with various level of integrations. My point was that we come with a 
> description that works for different use cases and extensions. 

We should definitely come up with a list of things to try.  I’m just saying 
that without any experience, these will be pure conjecture, and hence not that 
useful.

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

Re: [homenet] primary / secondary configuration

[Ted Lemon]

On Jun 18, 2019, at 10:56 AM, Daniel Migault  
wrote:
> I am also questioning on whether we should provide some sort of 
> recommendations for the UI. While we are not UI designers, I believe some 
> properties could be interesting for designers, and those may be helpful to be 
> provided. 

The trouble that we have gotten into repeatedly in this working group is that 
we write the specification in anticipation of an implementation, rather than on 
the basis of experience doing an implementation.   We have a fantastic testbed 
for this: OpenWRT.   I am at this point somewhat expert in doing OpenWRT 
builds.   Rather than speculating about what we need to say, why not do an 
implementation, see how it works, and then do a writeup based on what we 
learned?   We’re already talking about doing this at the Hackathon.


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

Re: [homenet] webauthn for routers

[Ted Lemon]

On Jun 13, 2019, at 4:08 PM, Michael Thomas  wrote:
> It would be good to do this on openwrt, that's for sure. I've never tried to 
> hack on it, but it can't be too horrible.
> 
> 
It’s dead easy if you have a Linux VM.   Just build a package, and have a place 
it can be downloaded from.   When you make changes, update the package.   You 
can debug using gdbserver.   Let me know if you need help with this.


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

Re: [homenet] webauthn for routers

[Ted Lemon]

On Jun 13, 2019, at 3:46 PM, Michael Thomas  wrote:
> Possibly, but I think there are hardware based solutions (eg "press to pair") 
> and pure software based ones. The main point is to have something to point 
> vendors at. They are probably clueless that this is a possibility now.
> 
> 
Ah.  I don’t think that would be useful.  The “if we spec it, they will build 
it” approach has been an utter failure thus far.  We should have a clear use 
case and a clear solution that addresses that use case.  We should not specify 
the kitchen sink and let them pick.  If someone has a use case we didn’t 
address, then that’s demand to address another use case, and we can do it, but 
we have to be real about this.  Right now, the only use case that really 
matters is OpenWRT, because that is where _all_ of the running code is.   So a 
solution that works there is the place to start.


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

Re: [homenet] webauthn for routers

[Ted Lemon]

On Jun 13, 2019, at 3:40 PM, Michael Thomas  wrote:
> I don't think this needs to be very involved. I would think that a short bcp 
> which lays out why webauthn is a huge advance, and a set of different 
> enrollment mechanisms that have some vetting would probably be enough.

You mean so that we can pick one?   :)

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

Re: [homenet] webauthn for routers

[Ted Lemon]

TBH I don’t know anything about OBA other than that I heard it discussed.  If 
you want to write up a draft, that can’t hurt.   I’m not promising to support 
it—it depends on what you come up with.   But it’s always good to have a place 
to start, and something to pick apart and fix up.   So by all means, if you are 
willing to proceed on that basis, I think it’s a good idea, and I will read it.

> On Jun 13, 2019, at 3:11 PM, Michael Thomas  wrote:
> 
> 
> 
> On 6/13/19 12:02 PM, Ted Lemon wrote:
>> On Jun 13, 2019, at 2:57 PM, Michael Thomas > <mailto:m...@fresheez.com>> wrote:
>>> The meta-question is whether there is something to be done here, and if 
>>> this wg is the right place to do it. I know there was a security part of 
>>> the charter... it sure would be nice to set an example for all of this IoT 
>>> mischief on how to do a proper web login interface.
>>> 
>>> 
>> This is a general problem, not an IoT problem.  IoT is a good motivating use 
>> case, not the complete problem.   We’ve talked about working on this problem 
>> here before. I think it’s in scope and this is a good place to do it.  Iff 
>> people are willing to participate!
>> 
>> 
> 
> Should I write up a draft? It would be really good that something 
> (convergent) evolved out Stephen, Paul and my rfc 7486, as the first thing I 
> experimented on was something for a home router based application :)
> 
> Mike, who has no idea if the webauth folks had any idea about our hoba stuff.
> 

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

Re: [homenet] webauthn for routers

[Ted Lemon]

On Jun 13, 2019, at 2:57 PM, Michael Thomas  wrote:
> The meta-question is whether there is something to be done here, and if this 
> wg is the right place to do it. I know there was a security part of the 
> charter... it sure would be nice to set an example for all of this IoT 
> mischief on how to do a proper web login interface.
> 
> 
This is a general problem, not an IoT problem.  IoT is a good motivating use 
case, not the complete problem.   We’ve talked about working on this problem 
here before. I think it’s in scope and this is a good place to do it.  Iff 
people are willing to participate!


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

Re: [homenet] webauthn for routers

[Ted Lemon]

On Jun 13, 2019, at 2:40 PM, Michael Thomas  wrote:
> Are we talking about the same thing? I'm not sure what naming has to do with 
> dealing with crappy/default passwords on router web interfaces?
> 
If your router has a name, it can get a cert.  If it doesn’t have a name, it 
can’t.   That cert then becomes a basis for establishing trust.

In the case of devices on the home network establishing trust with the router, 
you have to bootstrap that somehow.   In that case, the easiest thing to do is 
as I suggested: 

you have access to the router’s network
nobody else has established trust yet

This isn’t ideal, but it creates a pathway for further trust establishment: 
once you have one device that has a trusted key, then that device can authorize 
additional devices, which can authorize additional devices.   A device that 
comes onto the network after initial trust establishment can’t get trust 
without being approved.

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

Re: [homenet] webauthn for routers

[Ted Lemon]

On Jun 13, 2019, at 2:33 PM, Michael Thomas  wrote:
> Yeah, the router clearly knows whether something is on the local net, but it 
> doesn't know if it's a visitor. Requiring that you put the visitors on a 
> guest net is not exactly ideal either.
> 
> 
That’s not relevant for front-end naming.   In this case the trust is being 
established between a customer edge router or a service on the customer 
network, and a front end name server operated by the ISP.   A guest device 
would not be able to interpose itself in this process if it were designed 
correctly.


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

Re: [homenet] webauthn for routers

[Ted Lemon]

On Jun 13, 2019, at 11:15 AM, Michael Thomas  wrote:
> All of which require authentication of some form, which the router itself 
> doesn't have the credentials. But home routers do have a few different 
> characteristics: proximity and local addressing. Maybe your work you pointed 
> out might be applicable?

“how you are connected” plus “no conflict” is a fairy effective ad-hoc method 
for establishing trust.

E.g., for a very long time, ISPs have used the fact that you are connected to 
their network as a basis for authorizing your DHCP transaction.   If the ISP is 
doing the front-end naming, then that mechanism could work here as well.   If 
someone else is doing front-end naming, then you probably have to have put a 
credit card in somewhere…

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

Re: [homenet] securing zone transfer

[Ted Lemon]

On Jun 12, 2019, at 10:22 AM, Michael Richardson  wrote:
> There are no passwords.

Yes please.

Juliusz, what you are saying is what you said to me when I did the original 
homenet naming architecture, which you said was too heavyweight.  There seemed 
to be consensus in the room for dropping this, and so we did.   But as time has 
gone by, it’s become more and more clear to me that even though this use case 
does not apply to every device in the home, it is a use case that applies in a 
significant number of cases.

We can of course build this from ad-hoc, non-standardized tools like dyndns.   
We can insist that anyone who wants to address this use case has to either be a 
security expert, or be vulnerable.   Or we can figure out a clean way to do it 
using the building blocks we already have: HNCP, DNS Update, DHCP PD, etc.   
And then we can write a standard that describes how to do that, and see how 
much uptake it gets in the real world.

I would also like to point out that in addition to Ray’s point about DANE, 
being able to publish an external name means that you can get a cert from Lets 
Encrypt.   And _that_ means that we can close the frustrating gap that we have 
now with home network security, which is that the web UI isn’t secure.   And we 
can do this with any browser, not just with browsers that support TLSA (which, 
unfortunately, are rare as hen’s teeth).

I’d like to also point out that one of your objections was that implementing 
something like the Service Registration Protocol would be too hard, and too 
heavy.  It turns out to fit into 12k of code space in a constrained device 
operating over 802.15.4.   The SRP proxy is a bit larger, but quite reasonable. 
  The code for both is on the hackathon github repo, and is under active 
development (but works at present):

https://github.com/IETF-Hackathon/mDNSResponder 


The README file only talks about the Discovery Proxy, but the 
ServiceRegistration subdirectory contains a complete simple service 
registration client: srp-simple.c
It also includes a registration proxy: srp-gw.c

Getting the SRP gateway to talk to a front-end naming primary would be very 
simple.   Getting AXFR to work in either direction would be as well.   It’s 
just a service, after all.

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

Re: [homenet] [EXT] securing zone transfer

[Ted Lemon]

I agree. That’s not my point. I actually put some ideas for how to something 
similar with that piece of the puzzle in one version of the homenet naming 
architecture. I’ll see if I can find it. 

Sent from my iPhone

> On Jun 11, 2019, at 8:48 PM, Michael Richardson  wrote:
> 
> I don't think it will work as the protocol for a homenet to publish a public
> zone to the Internet without some additional security and setup. At least,
> that's my feeling at this point.

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

Re: [homenet] [EXT] securing zone transfer

[Ted Lemon]

On Jun 11, 2019, at 2:59 PM, Jacques Latour  wrote:
> In trying to setup our secure home gateway project to have the external zone 
> & primary DNS server setup and managed on the gateway itself and to XFR back 
> to secondary name servers somewhere turned out not be functional or 
> practical, first, the gateway does not know for sure which external NS are 
> use by the secondary DNS service, second, the IPs of the WAN port might not 
> be the internet facing IPs and this could break inbound connectivity.  We’re 
> looking at using dynamic DNS updates for things that need internet 
> connectivity, and have the primary DNS server on the main land.   TSIG & DNS 
> over TLS look like a good option to look at.

Have you looked at draft-ietf-dnssd-srp 
(https://tools.ietf.org/html/draft-ietf-dnssd-srp-01 
)?

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

Re: [homenet] securing zone transfer

[Ted Lemon]

For dns updates, SIG(0) works fine. I have code you can steal that works with 
mbedtls and ecdsa. Signing and validation.  But I think TLS client certs can 
also work.  Proving the front end servers identity sounds like the hard part. 

Sent from my iPhone

> On Jun 8, 2019, at 6:32 PM, Michael Richardson  wrote:
> 
> 
> Ted Lemon  wrote:
>>> Can we use TLS for authorization, assuming that we have trusted
>>> certificates
>>> at both ends?  Perhaps this is more of a: did anyone implement this?
> 
>> How is trust established?   Sure, doing TSIG over TLS is no problem.
> 
> Certificates are exchanged/created at manufacturing time (IDevID), and then
> optionally updated to LDevID.  The certificate contains the name of the zone
> which the HNA is authoritative for (or a control record pins the
> certificate).
> 
> TSIG requires a shared secret, thus a database of shared secrets available
> online.   I don't want to do TSIG over TLS, I want to not do TSIG, or
> if I have to use TSIG for mechanical reasons, I want to derive the secret
> From the TLS.
> 
> I need to authorize the following:
>  1) DNS update of some data (NS, DS,  that NS points to) by
> Distribution Master (cloud/public system)
>  2) SOA query by Distribution Master by HNA.
>  3) AXFR by Distribution Master by HNA.
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-

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

Re: [homenet] securing zone transfer

[Ted Lemon]

On Jun 7, 2019, at 11:36 PM, Michael Richardson  wrote:
> Can we use TLS for authorization, assuming that we have trusted certificates
> at both ends?  Perhaps this is more of a: did anyone implement this?

How is trust established?   Sure, doing TSIG over TLS is no problem.

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

Re: [homenet] Montreal homenet activities

[Ted Lemon]

On Jun 5, 2019, at 10:26 PM, Sávyo Vinícius  wrote:
> Thanks Ted, I'll calmly check it out, but in a fast reading I found really 
> interesting things to do. So, I saw something about isolation of Things 
> communication and a few days ago I readed a paper 
> (https://dl.acm.org/citation.cfm?id=3323413 
> ) that discribes one 
> implementation of it over OpenWRT (if you dont meet, maybe it's a good idea 
> take a look).
> 
> About Montreal I'm not going, but I'm looking for the ISOC's fellowship 
> program for try attend to Singapore's meeting.

Given that there’s no f2f meeting in Montreal, maybe we can make some progress 
before Singapore.   Thanks for the link!

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

Re: [homenet] Montreal homenet activities

[Ted Lemon]

On Jun 5, 2019, at 11:55 AM, Sávyo Vinícius  wrote:
> Hello homenet. It's sad to me read this when I'm just starting to follow the 
> group, and when my research is starting over IoT security in SOHO networks. 
> Is there some documentation about the current work in progress of the group? 
> Or some list of objectives for homenet to we start working over it?

Welcome!   No need to despair—I think that there is a lot of stuff happening 
right now, just not in the form of presentations to the WG that would justify a 
meeting.

Are you planning to be in Montreal?

You can see some discussion of stuff that’s on my radar here: 
https://tools.ietf.org/html/draft-lemon-homenet-review-00 


I also gave a presentation on this in Prague, which you can find here:

https://datatracker.ietf.org/meeting/104/session/homenet 


There was a good discussion about where to go next after my presentation.   IoT 
security on SOHO was one of the things I mentioned as an important thing to 
work on.

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

Re: [homenet] Montreal homenet activities

[Ted Lemon]

On Jun 4, 2019, at 2:26 PM, STARK, BARBARA H  wrote:
> We encourage people wanting to work on homenet code to self-organize for the 
> hackathon. I'll be happy to bring some OpenWRT devices to test with (and do 
> some testing), if that would be useful. Let me know ...
> If people would like to set a time to have an "unstructured" get-together in 
> Montreal, please let us know. There will be spaces available that can be 
> reserved. We can figure out a time and sign up for such a space. I'm also 
> happy to have a WebEx up and running for anyone who would want to join in 
> remotely to such a get-together.

I think these are both great ideas.   It’s been frustrating to me this year 
working with homenet, because I am actually working full-time on homenet 
technology, but there doesn’t seem to be the kind of interest in the IETF that 
would result in standardization.  E.g., some of the work I’ve been doing to get 
name service going on homenets in the dnssd working group failed last call 
because nobody responded.   Code is written, documents are up to date, but with 
no review and no interest, the only alternative is to send this stuff to the 
ISE.

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

Re: [homenet] Homenet market gap analysis...

[Ted Lemon]

Thanks for clarifying.   I was trying to answer your questions and didn’t get 
that you were suggesting changes to the document; now that’s more clear.   
Regarding “naming interfaces” versus “naming nodes,” you might want to look at 
https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/ 
<https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/> which specifically 
addresses that problem, although it doesn’t say it the way you said it.  :)

> On Mar 14, 2019, at 6:19 AM, Tim Coote  wrote:
> 
> On 14 Mar 2019, at 00:40, Ted Lemon  wrote:
> 
> Tim, it’s pretty clear that in the case of constrained networks, there needs 
> to be subnetting. Homenet is uniquely positioned to make that possible—if you 
> have a regular router that doesn’t support something like HNCP, there’s no 
> way to make it work.
> 
> Agreed. I thought that from a market gap analysis, that it was worth bringing 
> out this weakness for existing (L2 based) approaches, otherwise there will be 
> a tendency for readers to assume the best.
> 
> In the case of a multi-premise homenet, either you have to bond the two 
> homenets together, which we don’t currently support, or you need end-to-end 
> to work, which means IPv6, and you need to make sure that only authorized 
> hosts can talk to devices.
> I see. The usecase wasn’t missing, it’s covered by the 'internet to leaf’ + 
> ‘leaf to internet’ scenarios. Again, for the casual reader, I think that it’s 
> worth pointing this out. But it’s your document, of course.
> 
> Toke and I have been discussing the endpoint roaming problem.   In L2, it’s 
> all handled by the layer 2, so it’s transparent, which doesn’t necessarily 
> mean that it’s any better than the less-transparent way it would need to be 
> handled at L3.   I think we should do a comparison between these two 
> approaches.
> Mapping names to addresses can be done with service discovery; please see the 
> simple homenet naming architecture document for a discussion of this, and 
> also RFC6763.   We will be doing some work on this at hackathon if you want 
> to see it in action.
> Node identity can be managed with DNSSD Service Registration Protocol, which 
> allows a host to claim and defend a name using public key cryptography.   
> Bear in mind that there are privace implications to this, and so it isn’t 
> always the right thing to do.   Your printer should probably do it.   Your 
> phone, perhaps not.   Private service discovery is being seriously discussed 
> in the DNSSD working group.   Because private service discovery necessarily 
> uses public key encryption, unique identifiers aren’t a problem; claiming a 
> unique name remains a problem, but not a very big problem, because the name 
> doesn’t change after pairing.
> I was thinking more of ‘pet names’, ie human invented and associated, rather 
> than names used for well-known services, how these propagate on movement to 
> new networks etc (eg I call my dad’s spO2 meter oxydad, no matter where it is 
> or where he is).
> 
> What concerns me about dns based approaches is that dns knows nothing about 
> nodes, only interfaces. That’s mostly ok in an world with ~1 address per 
> node, but it quickly becomes difficult as that constraint is broken. This is 
> certainly an issue in enterprise environments. otoh, in some circumstances, 
> it may be confidential that specific addresses are associated with the same 
> host, or service on a host.
> 
> I did get a suggestion that nodes are better managed using handle.net’s model.
> 
> I’ll read your suggestions. Thanks.
> 
> IoT meshes are out of scope for homenet.   I agree that there are some 
> interesting problems to contemplate when using them. :)
> I was really showing how bad things get. I am concerned that all mesh 
> networks will go the same way, leading to very large support costs. IMO, 
> there’s a tendency for computer based systems to avoid the engineering 
> principle of fail fast (give up early and raise an alarm), which gives an 
> impression that all is well until there’s a catastrophic failure. Even the 
> original Ethernet wiring exhibited this with workarounds for signal 
> deterioration and fallback to lower performance.
> 
> On Mar 13, 2019, at 6:45 PM, Tim Coote  wrote:
> 
> Ted
> 
> On 13 Mar 2019, at 18:35, Ted Lemon  wrote:
> 
> In Bangkok I gave a talk about what Homenet gets right, what new solutions 
> have emerged in the market since homenet started, and what is better about 
> those solutions, as well as what homenet still adds. I’ve written up a 
> document that discusses this in a bit more depth, and would appreciate 
> feedback. It’s not very long, and should be a pretty easy read—it would be 
> great if we could start talking about this before the meeting, s

Re: [homenet] Homenet market gap analysis...

[Ted Lemon]

Tim, it’s pretty clear that in the case of constrained networks, there needs to 
be subnetting.   Homenet is uniquely positioned to make that possible—if you 
have a regular router that doesn’t support something like HNCP, there’s no way 
to make it work.

In the case of a multi-premise homenet, either you have to bond the two 
homenets together, which we don’t currently support, or you need end-to-end to 
work, which means IPv6, and you need to make sure that only authorized hosts 
can talk to devices.

Toke and I have been discussing the endpoint roaming problem.   In L2, it’s all 
handled by the layer 2, so it’s transparent, which doesn’t necessarily mean 
that it’s any better than the less-transparent way it would need to be handled 
at L3.   I think we should do a comparison between these two approaches.

Mapping names to addresses can be done with service discovery; please see the 
simple homenet naming architecture document for a discussion of this, and also 
RFC6763.   We will be doing some work on this at hackathon if you want to see 
it in action.

Node identity can be managed with DNSSD Service Registration Protocol, which 
allows a host to claim and defend a name using public key cryptography.   Bear 
in mind that there are privace implications to this, and so it isn’t always the 
right thing to do.   Your printer should probably do it.   Your phone, perhaps 
not.   Private service discovery is being seriously discussed in the DNSSD 
working group.   Because private service discovery necessarily uses public key 
encryption, unique identifiers aren’t a problem; claiming a unique name remains 
a problem, but not a very big problem, because the name doesn’t change after 
pairing.

IoT meshes are out of scope for homenet.   I agree that there are some 
interesting problems to contemplate when using them. :)


> On Mar 13, 2019, at 6:45 PM, Tim Coote  wrote:
> 
> Ted
> 
>> On 13 Mar 2019, at 18:35, Ted Lemon  wrote:
>> 
>> In Bangkok I gave a talk about what Homenet gets right, what new solutions 
>> have emerged in the market since homenet started, and what is better about 
>> those solutions, as well as what homenet still adds.   I’ve written up a 
>> document that discusses this in a bit more depth, and would appreciate 
>> feedback.   It’s not very long, and should be a pretty easy read—it would be 
>> great if we could start talking about this before the meeting, so that when 
>> we get to the meeting we can have an informed discussion and maybe decide on 
>> a way forward if that seems warranted.
>> 
>> https://tools.ietf.org/html/draft-lemon-homenet-review-00
>> 
> 
> Some points/questions. Pls excuse my hamfisted articulation/miss an obvious 
> point, I’m no network specialist.
> 
> - IoT isolation for L2: a common scenario is that the IoT network has a 
> vastly different performance profile to other in-home networks. I don’t think 
> that this works well for Flat L2
> - for some IoT scenarios, the scope of a home isn’t one premises, eg wanting 
> to control a camera in one house from a controller in another. There is no 
> general IPv4 solution to this as protocols such as STUN/ICE are too slow, in 
> human reaction time terms, to use to set up the control link.
> - how is an endpoint reconnected if it’s moving about and getting renumbered? 
> Is this done via some naming service?
> - how are human understandable names mapped to addresses, automatically? Is 
> this service discovery?
> - node identity: if a node is moving about and/or has multiple addresses at 
> the same time, how does a human understand that it’s the same thing. For s/w 
> this is quite easy, although non-standard. Is this an application layer 
> concern?
> - a point wrt meshes: although these potentially provide resilience, they can 
> also provide confusion as the end to end service can move up and down over 
> various timescales. I have experienced some very expensive support situations 
> that were caused by (IoT) mesh networks breaking the principle of 
> ‘fail-fast’. In these situations, as the world changes, L2 networks adopt a 
> ’string of pearls’ topology, but do not report the changes. Ultimately there 
> is a network partition, which breaks things in interesting ways from an 
> engineering point of view and confusing ways from the point of view of users.
> 
> I hope that this is useful.
> 
> tc
> 
> 

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

Re: [homenet] Homenet market gap analysis...

[Ted Lemon]

I suppose a point to be investigated is that however roaming happens,
unless all packets are flooded to all links, the layer 2 switch always
triggers a routing change, whether at layer 2 or layer 3.

So it might be worth doing an analysis of the pros and cons of L2 versus L3
roaming. I know Dave Täht has looked into doing it at L3 at the host, but
that isn’t practical and is in any case out of scope for homenet. What is
easier if it’s done at L2?  At L3?

On Wed, Mar 13, 2019 at 17:27 Toke Høiland-Jørgensen  wrote:

> Mikael Abrahamsson  writes:
>
> > I especially agree with the statement on wifi roaming between APs does
> > require shared L2, and there has been discussions about this and how
> > to solve that, and I think it's a requirement for homenet to become a
> > useful solution in that space. This would probably require some kind
> > of tunneling or vlan encapsuatlion between homenet devices to be
> > controlled somehow. There are routing protocols out there that already
> > do this, can perhaps be used as inspiration.
>
> You don't actually need encapsulation or VLANs if all access points
> participate in the routing protocol. You can just announce routes for
> each of the clients' IP addresses on roaming. You'll need some mechanism
> for discovering those IP addresses of course; one option is something
> like l3roamd[0] (which more or less just sniffs the addresses used by
> the client), but others are certainly possible. I remember discussing
> other approaches with Juliusz at some point, but I guess none of us ever
> got around to implementing something.
>
> Either way, I guess this is something homenet could conceivably specify
> a solution for if there was sufficient interest... :)
>
> -Toke
>
> [0] https://github.com/freifunk-gluon/l3roamd
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Homenet market gap analysis...

[Ted Lemon]

In Bangkok I gave a talk about what Homenet gets right, what new solutions have 
emerged in the market since homenet started, and what is better about those 
solutions, as well as what homenet still adds.   I’ve written up a document 
that discusses this in a bit more depth, and would appreciate feedback.   It’s 
not very long, and should be a pretty easy read—it would be great if we could 
start talking about this before the meeting, so that when we get to the meeting 
we can have an informed discussion and maybe decide on a way forward if that 
seems warranted.

https://tools.ietf.org/html/draft-lemon-homenet-review-00 


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

Re: [homenet] homenet: what now? ... next?

[Ted Lemon]

On Mar 8, 2019, at 7:48 AM, Juliusz Chroboczek mailto:j...@irif.fr>> wrote:
>> (a) work on simple naming
> 
> I think that this work should be stalled until we have an implementation
> to play with and make some in vivo experiments.  (Experience shows that
> the best way to break a protocol is to give an implementation to Dave.)

We have a working dnssd discovery proxy and client.   What we don’t have is 
those things connected via hncpd.   That is one of the things I would like to 
work on at the hackathon, if there is interest.

>> (We also have a chartered work item [4] on security that has seen no
>> progress but you can comment on that as item (c) if you like;-)
> 
> Some pointers for the rare people who don't spend most of their leisure
> time reading Internet-Drafts:
> 
> - HNCP is based on DNCP, which includes a security mechanism designed to
>   provide authenticity, integrity and confidentiality of the HNCP data:
> 
>   RFC 7525 Section 8
> 
>   I believe that this is implemented in hnetd.  (Yeah, Markus and
>   Stephen did some remarkable work.)

I had indeed missed this—thanks for pointing it out.   However, I have no idea 
how to configure it with existing software.   This is also something I’d like 
to work on at the hackathon: can we actually use this mechanism?   Can we come 
up with a way to set it up in OpenWRT that people who are not networking grad 
students can deploy?

> - Babel has two security mechanisms:
> 
>   https://tools.ietf.org/html/draft-ietf-babel-hmac 
> 
>   https://tools.ietf.org/html/draft-ietf-babel-dtls 
> 
> 
>   There appear to be no standards-track key distribution and rotation
>   protocols for either of OSPF, IS-IS, BGP or BFD (static keying seems
>   to be the norm), so a natural question is whether HNCP could serve
>   this purpose, or whether it would be better to use a dedicated key
>   distribution and rotation mechanism.
> 
> - RFC 3971 Section 6 says the following:
> 
>  To protect Router Discovery, SEND requires that routers be
>  authorized to act as routers.  This authorization is provisioned in
>  both routers and hosts.
> 
>   Since hosts don't participate in HNCP, it is not clear if HNCP can be
>   used as a SEND trust anchor.  I believe there's the same issue with
>   securing access the DNS stub resolver (DNSCrypt, DNS over TLS, etc.).

HNCP can’t be used by hosts to establish trust, as currently specified.   We 
don’t really have an answer to the host enrollment problem at present, 
unfortunately.___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet: what now? ... next?

[Ted Lemon]

On Mar 8, 2019, at 8:36 AM, Juliusz Chroboczek  wrote:
> I think this protocol has reached the point where any further paper work
> will be counter-productive until somebody tries their hand at implementing
> it.

Which protocol?

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

Re: [homenet] homenet: what now? ... next?

[Ted Lemon]

I do remember that talk. CS grad students are not our target market. Open
source distributions are a great demo, but I want this stuff in Ubiquiti
routers, Eero routers, etc.  it’s clear you aren’t interested in working on
it at the Hackathon, which is perfectly understandable, but I was asking if
anyone *is *interested because i can’t do it all by myself.

On Sun, Mar 3, 2019 at 06:45 Juliusz Chroboczek  wrote:

> >> It should be an easy fix, feel free to go ahead.
>
> > The point of soliciting participation at hackathon is for us to gain
> > collective experience on the easy or difficulty of deploying homenet in
> > practice.
>
> Oh, that's different, and not at all the motivation you give in your
> previous mail.  Experience shows that the best way to make something
> happen is to organise it oneself, and therefore you should feel free to
> organise a Homenet tutorial yourself, just like you should feel free to
> fix yourself the issues you're having with hnetd.
>
> I'm not sure that you'll find much of an audience, though -- as you
> rightly point out, there doesn't appear to be much excitement left around
> Homenet, and the main contributors appear to have moved on with their
> lives.  It's been six years, after all.  (For my part, my IETF funding
> runs out in September.)
>
> On that subject, you might remember the talk I gave about HNCP deployment
> back in 2016.  The conclusions were that a first year student who had
> never done any networking before was able to deploy an HNCP+Babel mesh
> network in two weeks, and most of that time was spent learning to reflash
> off-the-shelf routers from scratch.
>
> https://datatracker.ietf.org/meeting/96/materials/slides-96-homenet-1
>
> -- Juliusz
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet: what now? ... next?

[Ted Lemon]

On Mar 2, 2019, at 8:50 PM, Juliusz Chroboczek  wrote:
> That's an property of the hnetd implementation, not a feature of the
> protocol (and it doesn't apply to shncpd).  See RFC 7788 Section 6.5.

The text:

  An HNCP router MUST create a private IPv4 prefix [RFC1918 
]
  whenever it wishes to provide IPv4 Internet connectivity to the
  network and no other private IPv4 prefix with Internet
  connectivity currently exists.  It MAY also enable local IPv4
  connectivity by creating a private IPv4 prefix if no IPv4 prefix
  exists but MUST NOT do so otherwise.

So it does allow the implementation to use use RFC1918 addresses internally 
when there is no upstream address, but it really does seem to be saying that’s 
not necessary.   Better advice would be that if an IPv4 address is ever 
obtained externally, that internal RFC1918 addressing should remain available 
until some substantial amount of time has passed.   Right now this behavior is 
optional.

>> This is one of the reasons that I would like us to get together and hack on
>> this at the hackathon:
> 
> It should be an easy fix, feel free to go ahead.

The point of soliciting participation at hackathon is for us to gain collective 
experience on the easy or difficulty of deploying homenet in practice.   It’s 
all very well and good to have implementations, but if nobody is able to use 
them, this isn’t really what we want when we talk about having interoperating 
implementations.   This is particularly true when the goal of a body of work is 
automatic operation (as in ops), as opposed to mere protocol interoperation.

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

Re: [homenet] homenet: what now? ... next?

[Ted Lemon]

On Mar 2, 2019, at 11:30 AM, Juliusz Chroboczek  wrote:
> No, they're not.
> 
> Both HNCP and Babel carry their control traffic over link-local IPv6, but
> they support both IPv4 and IPv6 with almost equal functionality.

This is one of the reasons that I would like us to get together and hack on 
this at the hackathon: in fact while what you are saying is technically true, 
in practice IPv4 _is_ treated like a second-class citizen in the sense that if 
your ISP-provided public IP address ever goes away, all of your RFC1918 
addresses on the homenet also go away.

So on a practical level, homenets as currently specified really are, if not 
v6-only, then at least only-v6-reliable.

I think it would actually be better if homenets were IPv6-only, with NAT64 at 
the edge for the case where there is only an IPv4 address, but I imagine that 
this would not be a popular enough view to get consensus.  It would be equally 
good if IPv4 were just assumed to be required to work regardless of whether 
there’s an upstream IPv4 address.   This is something that we should really 
re-think—the way it is now isn’t ideal.

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

Re: [homenet] homenet: what now? ... next?

[Ted Lemon]

On Mar 1, 2019, at 4:21 PM, Stephen Farrell  wrote:
> If one of those positions captures your opinion, feel free to respond
> in shorthand. Otherwise, please tell us where you think we ought be
> going, as a WG, with (a), (b) and/or (c).

For me it’s (1) and (2).

I think there are a few reasons why homenet feels stalled right now.

We are tracking a moving target, and we haven’t adjusted our goals.   This is 
the conclusion I came to as a result of working on the presentation I did in 
Bangkok on Homenet Marketing.   I don’t think this is bad.
I conjecture that one of the reasons that there is good attendance at homenet 
but relatively limited participation is in fact that we are developing 
technology that is interesting to the people who are showing up, but not quite 
addressing their needs.
I don’t actually know what the applicability is for the hidden primary stuff.   
I’ve gotten feedback that there are people who want this, but I have no idea 
what to do with it, given that we don’t want to expose internal DNS to external 
nodes.
No hardware that does homenet.   We have homenet stuff in OpenWRT, but making 
it work in a home isn’t a turnkey operation, and that is, after all, the goal 
of Homenet: a real network that sets itself up without the user having to grok 
how it works.
One of the applications of Homenet that we keep hearing about is the SOHO 
market.   We should target that explicitly and see what gaps exist in 
addressing it.

So I think spending some time re-targeting would be worthwhile, and it’s my 
intention to present a draft that talks about that in Prague.

I also would really like to see if anybody is willing to actually hack on 
Homenet in the hackathon.   There are a couple of projects I’d like to see us 
work on:
Turnkey homenet build of OpenWRT
If the Turris folks are down, it would be nice if they could join us and make 
it work in Turris OS as well.
Homenet-wide service discovery using the DNSSD Discovery proxy we’ve been 
working on, which is fully functional at this point.
Support for DNSSD SRP (this would involve finishing the SRP gateway I’ve been 
working on, and getting it to update Unbound or BIND).
Joining constrained-network edge routers to homenet routing and service 
discovery infrastructure
MUD support for devices that are not on a separate link, but are isolated from 
nodes that don’t have permission to talk to them.   This should be doable in 
OpenWRT.
Automatic IKEv2 tunnels on OpenWRT that use the new split DNS stuff being 
published in IPSECME to allow us to serve home.arpa to VPN clients.

This is an ambitious set of goals, and I don’t expect we’ll work on all of 
them, but these are things that need work, so if there is energy to work on any 
of them, it would be nice to see that happen at hackathon.


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

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation

[Ted Lemon]

What do you mean by a "trivial end to end protocol," Juliusz?


On Wed, Nov 21, 2018 at 1:32 PM Juliusz Chroboczek  wrote:

> Dear Daniel,
>
> > I am planning to update the front end naming delegation draft [1] in the
> next
> > weeks. Before revisiting the draft, I am collecting comments that need
> to be
> > addressed.
>
> After your talk at IETF-102, I asked what is the purpose of this rather
> complex protocol, and why it is preferable to a trivial end-to-end
> protocol.  As instructed during the meeting, I carried my question to the
> list, in a message dated 18 July 2018.
>
> A number of people participated in the ensuing discussion, however, none
> provided a definitive answer to my question.  I may have missed something,
> but as far as I know you did not participate in this discussion.
>
> Daniel, please explain why proxying through a hidden master is needed, and
> what problem this protocol solves that could not be solved with a trivial
> end-to-end protocol.
>
> Thanks for your understanding,
>
> -- 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] writeup of my 2018 homenet experience on openwrt

[Ted Lemon]

I’ll try that. I don’t remember if I did last time. My recollection was
that the log messages were useful, but not sufficient, pretty much for the
reason you’ve stated.

On Fri, Nov 9, 2018 at 5:51 PM  wrote:

> hnetd is actually able to produce quite an insane amount of debug logs
> (e.g. about anything happening on DNCP).
> Those are meant for developers (like trying to debug DNCP protocol).
> I don’t think this is what you want to do, since DNCP is actually fairly
> reliable… But since you ask, here is how to sink under DNCP debug messages.
> - Enable ‘debug’ log level in hnetd.h (HNETD_DEFAULT_L_LEVEL).
> - And then set hnetd runtime log level to debug with --loglevel option (As
> you probably tried already).
>
> - Pierre
>
>
> Le 9 nov. 2018 à 09:32, Ted Lemon  a écrit :
>
> Yes, this is exactly the sort of information I am looking for—thanks.   I
> just did a pass through the code to refresh my memory, and the issue I have
> with it is that there's no architecture document, so you kind of have to
> figure that out by reverse engineering it, and there aren't a lot of
> comments.   hncp_sd.c is actually pretty good—I don't think I'd looked at
> it before.   E.g., one of the modules I looked at before I got this mail
> from you was pa_core.c.   Actually it looks like there are some useful
> comments in the header files.   But an introduction that explains how the
> code basically works would really help.   Not the protocol—just what the
> concepts are and how they fit together.   And debugging messages aimed at
> users would help as well—one of the easiest ways to learn how something
> works is to just run it with debugging maxed and see what it logs.   But
> the log messages appear to be more about hncp than about what has been
> learned through hncp.
>
> Anyway, I'll give it another look—you've already helped me quite a bit.
>
> On Fri, Nov 9, 2018 at 5:21 PM  wrote:
>
>> I guess what you want to do is publish and receive TLVs using DNCP, and
>> probably get a sense of the topology.
>> To do so, there mostly is a single header to look at: dncp.h
>> <https://github.com/sbyx/hnetd/blob/master/src/dncp.h>
>>
>> Here is a simple example of Wifi autoconfig we did for one of IETF’s
>> hackathon: https://github.com/Oryon/hnetd/blob/hackathon/src/hncp_wifi.c
>> As a more advanced example, I think the service discovery part will be
>> relevant to you: https://github.com/sbyx/hnetd/blob/master/src/hncp_sd.c
>>
>> If you want to add configuration parameters available in OpenWrt, I’d
>> recommend you look at platform-openwrt.c
>> <https://github.com/sbyx/hnetd/blob/master/src/platform-openwrt.c>
>>
>> - Pierre
>>
>> Le 9 nov. 2018 à 08:52, Ted Lemon  a écrit :
>>
>> Made out of LEGO bricks. What you’re describing doesn’t match my
>> experience last time I looked at it.  I will look again. This is why I
>> asked: because I need help. This is the most information I’ve gotten about
>> it. I’m sorry my comments come across as saying the software is bad. That’s
>> not what i was trying to communicate.
>>
>> On Fri, Nov 9, 2018 at 4:47 PM Markus Stenberg 
>> wrote:
>>
>>> First off, hnetd was team effort - me, Pierre Pfister and Steven Barth.
>>>
>>> Secondly, I did not particularly want to promote hnetd but 'existing
>>> implementations are bad, boo hoo' argument gets old and I think e.g.
>>> https://github.com/jech/shncpd is also quite sufficient. I use even
>>> https://github.com/fingon/pysyma 'in production' even now (admittedly
>>> not HNCP bits of it, but DNCP + SHSP :->).
>>>
>>> On 09.11.2018, at 2.03, Ted Lemon  wrote:
>>> > The issue with the code (IIRC) is that it requires cmake to compile,
>>> for no obvious reason, and cmake is hard to get working, so e.g. building
>>> it on MacOS X is a major porting task.   And it depends on libraries that I
>>> don't have.   And there's no layering of the configuration system aspect of
>>> the architecture—it just goes and bashes on interfaces and stuff (this is
>>> my recollection—I haven't looked at it in a year or so).
>>>
>>> There's some distinct parts that have well defined interfaces (as far as
>>> those 'well defined' go in C anyway) - DNCP (dncp_*), /HNCP code (hncp_*),
>>> prefix assignment code (pa_*), and operating system (platform_*) are all
>>> pretty loosely coupled.
>>>
>>> I have compiled the DNCP(/partial HCNP) bits on OS X with relatively
>>> minor modifications for my hobby project for example

Re: [homenet] writeup of my 2018 homenet experience on openwrt

[Ted Lemon]

Noted. Good luck with the Babel work!

On Fri, Nov 9, 2018 at 5:44 PM Markus Stenberg 
wrote:

> I may or may not have some architectural/flow diagrams, but I am bit leery
> of putting them anywhere (if I were to have them that is) as they were not
> officially licensed to be distributed (as the code was) and as this was
> Cisco-funded research project back in the day.
>
> I could draw some basic ones from scratch one of these days and stick them
> in the repository if there is sufficient demand :-)
>
> Today's hobby project will be Babel bis draft support for pybabel though.
>
> -Markus
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] writeup of my 2018 homenet experience on openwrt

[Ted Lemon]

Yes, this is exactly the sort of information I am looking for—thanks.   I
just did a pass through the code to refresh my memory, and the issue I have
with it is that there's no architecture document, so you kind of have to
figure that out by reverse engineering it, and there aren't a lot of
comments.   hncp_sd.c is actually pretty good—I don't think I'd looked at
it before.   E.g., one of the modules I looked at before I got this mail
from you was pa_core.c.   Actually it looks like there are some useful
comments in the header files.   But an introduction that explains how the
code basically works would really help.   Not the protocol—just what the
concepts are and how they fit together.   And debugging messages aimed at
users would help as well—one of the easiest ways to learn how something
works is to just run it with debugging maxed and see what it logs.   But
the log messages appear to be more about hncp than about what has been
learned through hncp.

Anyway, I'll give it another look—you've already helped me quite a bit.

On Fri, Nov 9, 2018 at 5:21 PM  wrote:

> I guess what you want to do is publish and receive TLVs using DNCP, and
> probably get a sense of the topology.
> To do so, there mostly is a single header to look at: dncp.h
> <https://github.com/sbyx/hnetd/blob/master/src/dncp.h>
>
> Here is a simple example of Wifi autoconfig we did for one of IETF’s
> hackathon: https://github.com/Oryon/hnetd/blob/hackathon/src/hncp_wifi.c
> As a more advanced example, I think the service discovery part will be
> relevant to you: https://github.com/sbyx/hnetd/blob/master/src/hncp_sd.c
>
> If you want to add configuration parameters available in OpenWrt, I’d
> recommend you look at platform-openwrt.c
> <https://github.com/sbyx/hnetd/blob/master/src/platform-openwrt.c>
>
> - Pierre
>
> Le 9 nov. 2018 à 08:52, Ted Lemon  a écrit :
>
> Made out of LEGO bricks. What you’re describing doesn’t match my
> experience last time I looked at it.  I will look again. This is why I
> asked: because I need help. This is the most information I’ve gotten about
> it. I’m sorry my comments come across as saying the software is bad. That’s
> not what i was trying to communicate.
>
> On Fri, Nov 9, 2018 at 4:47 PM Markus Stenberg 
> wrote:
>
>> First off, hnetd was team effort - me, Pierre Pfister and Steven Barth.
>>
>> Secondly, I did not particularly want to promote hnetd but 'existing
>> implementations are bad, boo hoo' argument gets old and I think e.g.
>> https://github.com/jech/shncpd is also quite sufficient. I use even
>> https://github.com/fingon/pysyma 'in production' even now (admittedly
>> not HNCP bits of it, but DNCP + SHSP :->).
>>
>> On 09.11.2018, at 2.03, Ted Lemon  wrote:
>> > The issue with the code (IIRC) is that it requires cmake to compile,
>> for no obvious reason, and cmake is hard to get working, so e.g. building
>> it on MacOS X is a major porting task.   And it depends on libraries that I
>> don't have.   And there's no layering of the configuration system aspect of
>> the architecture—it just goes and bashes on interfaces and stuff (this is
>> my recollection—I haven't looked at it in a year or so).
>>
>> There's some distinct parts that have well defined interfaces (as far as
>> those 'well defined' go in C anyway) - DNCP (dncp_*), /HNCP code (hncp_*),
>> prefix assignment code (pa_*), and operating system (platform_*) are all
>> pretty loosely coupled.
>>
>> I have compiled the DNCP(/partial HCNP) bits on OS X with relatively
>> minor modifications for my hobby project for example.
>>
>> > These are not bad things that Markus did.   Markus was doing what he
>> needed to do to get it running on OpenWRT.   But these are real issues,
>> which are preventing me from using the code.   For someone who is not an
>> HNCP expert to hack on the code is difficult, and would require substantial
>> work.   I could do it, but I have other things I'm working on.   If the
>> code were more modular, I could experiment with it.   This is the problem I
>> was trying to express.
>>
>> I have used it also unmodified on plain Linux number of times. If you
>> want to use it on something more esotreic, I could bet on OS X port being
>> doable but as lots of HNCP value comes from interfacing with system
>> servers, I do not see anyone writing platform interface for it.
>>
>> I am curious about what 'more modular' code looks like. Separate DLLs?
>> Single function call API between modules? Possibly made out of Lego bricks?
>>
>> Cheers,
>>
>> -Markus
>
> ___
> 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] writeup of my 2018 homenet experience on openwrt

[Ted Lemon]

Made out of LEGO bricks. What you’re describing doesn’t match my experience
last time I looked at it.  I will look again. This is why I asked: because
I need help. This is the most information I’ve gotten about it. I’m sorry
my comments come across as saying the software is bad. That’s not what i
was trying to communicate.

On Fri, Nov 9, 2018 at 4:47 PM Markus Stenberg 
wrote:

> First off, hnetd was team effort - me, Pierre Pfister and Steven Barth.
>
> Secondly, I did not particularly want to promote hnetd but 'existing
> implementations are bad, boo hoo' argument gets old and I think e.g.
> https://github.com/jech/shncpd is also quite sufficient. I use even
> https://github.com/fingon/pysyma 'in production' even now (admittedly not
> HNCP bits of it, but DNCP + SHSP :->).
>
> On 09.11.2018, at 2.03, Ted Lemon  wrote:
> > The issue with the code (IIRC) is that it requires cmake to compile, for
> no obvious reason, and cmake is hard to get working, so e.g. building it on
> MacOS X is a major porting task.   And it depends on libraries that I don't
> have.   And there's no layering of the configuration system aspect of the
> architecture—it just goes and bashes on interfaces and stuff (this is my
> recollection—I haven't looked at it in a year or so).
>
> There's some distinct parts that have well defined interfaces (as far as
> those 'well defined' go in C anyway) - DNCP (dncp_*), /HNCP code (hncp_*),
> prefix assignment code (pa_*), and operating system (platform_*) are all
> pretty loosely coupled.
>
> I have compiled the DNCP(/partial HCNP) bits on OS X with relatively minor
> modifications for my hobby project for example.
>
> > These are not bad things that Markus did.   Markus was doing what he
> needed to do to get it running on OpenWRT.   But these are real issues,
> which are preventing me from using the code.   For someone who is not an
> HNCP expert to hack on the code is difficult, and would require substantial
> work.   I could do it, but I have other things I'm working on.   If the
> code were more modular, I could experiment with it.   This is the problem I
> was trying to express.
>
> I have used it also unmodified on plain Linux number of times. If you want
> to use it on something more esotreic, I could bet on OS X port being doable
> but as lots of HNCP value comes from interfacing with system servers, I do
> not see anyone writing platform interface for it.
>
> I am curious about what 'more modular' code looks like. Separate DLLs?
> Single function call API between modules? Possibly made out of Lego bricks?
>
> Cheers,
>
> -Markus
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] writeup of my 2018 homenet experience on openwrt

[Ted Lemon]

My edge router is an Ubuntu machine. I haven’t been able to get Marcus’
HNCP daemon to build there. It’s possible that that has changed since I
last tried it, but that was what stopped me last time.

On Fri, Nov 9, 2018 at 4:07 PM  wrote:

> Hello Ted,
>
> OpenWrt cross-compilation is quite simple nowadays and works very well on
> Linux.
> You can easily build targets for hardware, VMs, or just get the filesystem
> tar.
>
> From there, you have a couple of options:
> - Flash a router every time you change the code (That is what I was doing
> at the time. OpenWrt on VM or container was not exactly working as expected)
> - Run it on Linux (iirc, Markus was testing in containers)
> - Docker: There has been quite a lot of progress in containers since then..
> If I were you I would try to build and run docker images of OpenWrt.
>   You can tune your DockerFile to put the configuration you want so you
> don’t need to change it every run.
>   Here is a link to get you started:
> https://openwrt.org/docs/guide-user/virtualization/docker_openwrt_image?s[]=docker
> <https://oldwiki.archive.openwrt.org/doc/howto/docker_openwrt_image>
> - VMs: A bit more heavyweight but a bit faster dev cycle than hardware. At
> the time it was not working extremely well, but today it’s probably better.
>
> https://openwrt.org/docs/guide-user/virtualization/virtualbox-vm?s[]=virtualbox
>
> Hope this helps.
>
> - Pierre
>
>
> Le 9 nov. 2018 à 03:01, Ted Lemon  a écrit :
>
> What’s your point?
>
> On Fri, Nov 9, 2018 at 8:23 AM tjw ietf  wrote:
>
>> I heard of some fancy new technology. I think the kids call them
>> “containers”
>>
>> From my high tech gadget
>>
>> On Nov 8, 2018, at 20:07, Ted Lemon  wrote:
>>
>> It doesn’t build or work on Ubuntu either.
>>
>> On Fri, Nov 9, 2018 at 7:58 AM Michael Thomas  wrote:
>>
>>> On 11/8/18 4:03 PM, Ted Lemon wrote:
>>> > The issue with the code (IIRC) is that it requires cmake to compile,
>>> > for no obvious reason, and cmake is hard to get working, so e.g.
>>> > building it on MacOS X is a major porting task.   And it depends on
>>> > libraries that I don't have.   And there's no layering of the
>>> > configuration system aspect of the architecture—it just goes and
>>> > bashes on interfaces and stuff (this is my recollection—I haven't
>>> > looked at it in a year or so).
>>>
>>>
>>> Sometimes the easiest thing to do in these cases is just give in and
>>> create a linux vm. they work really well these days.
>>>
>>> Mike
>>>
>>> ___
>>> 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
>
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] writeup of my 2018 homenet experience on openwrt

[Ted Lemon]

What’s your point?

On Fri, Nov 9, 2018 at 8:23 AM tjw ietf  wrote:

> I heard of some fancy new technology. I think the kids call them
> “containers”
>
> From my high tech gadget
>
> On Nov 8, 2018, at 20:07, Ted Lemon  wrote:
>
> It doesn’t build or work on Ubuntu either.
>
> On Fri, Nov 9, 2018 at 7:58 AM Michael Thomas  wrote:
>
>> On 11/8/18 4:03 PM, Ted Lemon wrote:
>> > The issue with the code (IIRC) is that it requires cmake to compile,
>> > for no obvious reason, and cmake is hard to get working, so e.g.
>> > building it on MacOS X is a major porting task.   And it depends on
>> > libraries that I don't have.   And there's no layering of the
>> > configuration system aspect of the architecture—it just goes and
>> > bashes on interfaces and stuff (this is my recollection—I haven't
>> > looked at it in a year or so).
>>
>>
>> Sometimes the easiest thing to do in these cases is just give in and
>> create a linux vm. they work really well these days.
>>
>> Mike
>>
>> ___
>> 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] writeup of my 2018 homenet experience on openwrt

[Ted Lemon]

It doesn’t build or work on Ubuntu either.

On Fri, Nov 9, 2018 at 7:58 AM Michael Thomas  wrote:

> On 11/8/18 4:03 PM, Ted Lemon wrote:
> > The issue with the code (IIRC) is that it requires cmake to compile,
> > for no obvious reason, and cmake is hard to get working, so e.g.
> > building it on MacOS X is a major porting task.   And it depends on
> > libraries that I don't have.   And there's no layering of the
> > configuration system aspect of the architecture—it just goes and
> > bashes on interfaces and stuff (this is my recollection—I haven't
> > looked at it in a year or so).
>
>
> Sometimes the easiest thing to do in these cases is just give in and
> create a linux vm. they work really well these days.
>
> Mike
>
> ___
> 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] writeup of my 2018 homenet experience on openwrt

[Ted Lemon]

The issue with the code (IIRC) is that it requires cmake to compile, for no
obvious reason, and cmake is hard to get working, so e.g. building it on
MacOS X is a major porting task.   And it depends on libraries that I don't
have.   And there's no layering of the configuration system aspect of the
architecture—it just goes and bashes on interfaces and stuff (this is my
recollection—I haven't looked at it in a year or so).

These are not bad things that Markus did.   Markus was doing what he needed
to do to get it running on OpenWRT.   But these are real issues, which are
preventing me from using the code.   For someone who is not an HNCP expert
to hack on the code is difficult, and would require substantial work.   I
could do it, but I have other things I'm working on.   If the code were
more modular, I could experiment with it.   This is the problem I was
trying to express.

On Fri, Nov 9, 2018 at 6:57 AM Juliusz Chroboczek  wrote:

> > Markus, I tried to be really clear about what I was communicating on the
> > slide about implementations, but probably failed.
>
> Indeed.
>
> A number of your comments about Markus' code were entirely unnecessary.
>
> -- Juliusz
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] writeup of my 2018 homenet experience on openwrt

[Ted Lemon]

Markus, I tried to be really clear about what I was communicating on the
slide about implementations, but probably failed.  I am not saying your
implementation is bad.  I'm saying that it's sufficiently difficult for *me* to
modify that it's a barrier to forward progress.   The point of saying that
was not to insult your implementation, but to point out a problem that is
holding me back from making progress on this work.

One obvious solution to the problem is for us to collaborate on improving
the situation, which is something I'd like to see happen.   But I know that
this would be a hobby project for you right now, and you probably don't
have time.   That's what I was lamenting.

On Fri, Nov 9, 2018 at 2:28 AM Markus Stenberg 
wrote:

> On 08.11.2018, at 19.16, Juliusz Chroboczek  wrote:
> >>> From a user perspective, there are a few problems:
> >> When an interface goes down and then up again, it's renumbered. This
> >> includes reboots.
> > That shouldn't happen as long as there remains at least one Homenet
> router
> > to maintain the prefix (see Section 4.1 point 3 of RFC 7695).
> >
> > I believe that hnetd (but not shncpd) additionally supports some
> mechanism
> > to handle the case where there are no routers left to maintain the
> prefix,
> > but I'm less sure.
>
> In hnetd there are actually two mechanisms fo ensure prefixes come up back
> the same they were before;
>
> - storage of assigned prefixes (if enabled; if use of flash writes is not
> desired this is not used obviously), and
>
> - ~determinstic pseudo-random assignment on interfaces
>
> If both fail, that's probably a bug, although not sure if both options can
> be off if configured so. Fallback is purely random assignment out of prefix.
>
> Anyway, getting back to topic of Ted's passionate speech about bad HNCP
> implementations, I'd love to see him (or someone else) provide better one
> :-)
>
> Cheers,
>
> -Markus
>
> ___
> 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] Reminder: homenet call

[Ted Lemon]

Thanks, Stephen.   The new version of the document is out.

On Tue, Oct 23, 2018 at 12:01 PM Stephen Farrell 
wrote:

>
> Hi all,
>
> And draft minutes are now at [1].
>
> Ted is hoping to get a new simple-naming I-D out today
> before the cutoff, so you may be as well to wait a bit
> and read that vs. the text referenced in those minutes.
>
> Cheers,
> S.
>
> [1]
>
> https://datatracker.ietf.org/meeting/interim-2018-homenet-11/materials/minutes-interim-2018-homenet-11-201810231100
>
> On 22/10/2018 18:45, STARK, BARBARA H wrote:
> > Hi homenet,
> > I just wanted to remind everyone we have a call scheduled tomorrow to
> progress the simple-naming draft.
> >
> > Time: 11:00-12:00 EDT
> > Place:
> https://ietf.webex.com/ietf/j.php?MTID=mca447be3b15845189801f00cf05f1d21
> > Agenda:
> https://datatracker.ietf.org/doc/agenda-interim-2018-homenet-11-homenet-01/
> >
> > Join Webex meeting
> > Meeting number (access code): 642 133 910
> > Meeting password: G7ShuHYV
> >
> > Join by phone
> > 1-650-479-3208 Call-in toll number (US/Canada)
> >
> > Barbara
> >
> > ___
> > 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] Reminder: homenet call

[Ted Lemon]

By the way, if you are planning to come to the homenet meeting in a half
hour, it would be worthwhile to read the latest github version of the
Homenet Naming Architecture document, which is on github:
https://github.com/ietf-homenet-wg/simple-naming

At this point I believe that the document talks about nearly everything
that we need to talk about, although it needs more detail in a number of
different places.   So reading over it now, before the (new) publication
deadline, and pointing out anything that's missing, would be very useful.

On Tue, Oct 23, 2018 at 9:33 AM STARK, BARBARA H  wrote:

> Indeed. I’m constantly amazed at Github’s usefulness. Who knew it could be
> used to extend submission cutoff.
>
> For those of you who didn’t get the memo ...
>
> In light of the GitHub outage and the fact that many participants rely on
> GitHub to author drafts, we have extended the I-D submission cut-off by 24
> hours. The new deadline is 23:59 UTC on October 23. Sorry for not being
> able to give earlier notice about this.
>
>
>
> Barbara
>
>
>
> *From:* Ted Lemon 
> *Sent:* Monday, October 22, 2018 5:39 PM
> *To:* STARK, BARBARA H 
> *Cc:* HOMENET 
> *Subject:* Re: [homenet] Reminder: homenet call
>
>
>
> Okay, actually it's not before the submission cutoff.   So I guess we
> might as well meet.   Life is strange.   :]
>
>
>
> On Mon, Oct 22, 2018 at 4:05 PM Ted Lemon  wrote:
>
> I'm realizing that this is after the submission cutoff.   Would it make
> more sense to just have the conversation in Bangkok?
>
>
>
> On Mon, Oct 22, 2018 at 3:37 PM STARK, BARBARA H  wrote:
>
> Hi homenet,
> I just wanted to remind everyone we have a call scheduled tomorrow to
> progress the simple-naming draft.
>
> Time: 11:00-12:00 EDT
> Place:
> https://ietf.webex.com/ietf/j.php?MTID=mca447be3b15845189801f00cf05f1d21
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__ietf.webex.com_ietf_j.php-3FMTID-3Dmca447be3b15845189801f00cf05f1d21&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=WB2LfiIt07RucckmDQ_Z8kadiXjHucJoyXaUOfvwOLY&s=CQx93mzHwCGKnxmfFmOkWxvzs5BcGxzo-hZ8pnWHdHM&e=>
> Agenda:
> https://datatracker.ietf.org/doc/agenda-interim-2018-homenet-11-homenet-01/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_agenda-2Dinterim-2D2018-2Dhomenet-2D11-2Dhomenet-2D01_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=WB2LfiIt07RucckmDQ_Z8kadiXjHucJoyXaUOfvwOLY&s=n5VmI-9UvLzaPFvNxXTqr3ZE3XOXVpSrbKfP1falEEM&e=>
>
> Join Webex meeting
> Meeting number (access code): 642 133 910
> Meeting password:   G7ShuHYV
>
> Join by phone
> 1-650-479-3208 Call-in toll number (US/Canada)
>
> Barbara
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_homenet&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=WB2LfiIt07RucckmDQ_Z8kadiXjHucJoyXaUOfvwOLY&s=nf6E3reSZk6-J_DC7uyIoHrMfagDmJrsMA8FgIo96vs&e=>
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Reminder: homenet call

[Ted Lemon]

Okay, actually it's not before the submission cutoff.   So I guess we might
as well meet.   Life is strange.   :]

On Mon, Oct 22, 2018 at 4:05 PM Ted Lemon  wrote:

> I'm realizing that this is after the submission cutoff.   Would it make
> more sense to just have the conversation in Bangkok?
>
> On Mon, Oct 22, 2018 at 3:37 PM STARK, BARBARA H  wrote:
>
>> Hi homenet,
>> I just wanted to remind everyone we have a call scheduled tomorrow to
>> progress the simple-naming draft.
>>
>> Time: 11:00-12:00 EDT
>> Place:
>> https://ietf.webex.com/ietf/j.php?MTID=mca447be3b15845189801f00cf05f1d21
>> Agenda:
>> https://datatracker.ietf.org/doc/agenda-interim-2018-homenet-11-homenet-01/
>>
>> Join Webex meeting
>> Meeting number (access code): 642 133 910
>> Meeting password:   G7ShuHYV
>>
>> Join by phone
>> 1-650-479-3208 Call-in toll number (US/Canada)
>>
>> Barbara
>>
>> ___
>> 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] Reminder: homenet call

[Ted Lemon]

I'm realizing that this is after the submission cutoff.   Would it make
more sense to just have the conversation in Bangkok?

On Mon, Oct 22, 2018 at 3:37 PM STARK, BARBARA H  wrote:

> Hi homenet,
> I just wanted to remind everyone we have a call scheduled tomorrow to
> progress the simple-naming draft.
>
> Time: 11:00-12:00 EDT
> Place:
> https://ietf.webex.com/ietf/j.php?MTID=mca447be3b15845189801f00cf05f1d21
> Agenda:
> https://datatracker.ietf.org/doc/agenda-interim-2018-homenet-11-homenet-01/
>
> Join Webex meeting
> Meeting number (access code): 642 133 910
> Meeting password:   G7ShuHYV
>
> Join by phone
> 1-650-479-3208 Call-in toll number (US/Canada)
>
> Barbara
>
> ___
> 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] Reminder: Call on Tuesday 11:00-12:30 EDT

[Ted Lemon]

On Sep 17, 2018, at 6:12 PM, STARK, BARBARA H  wrote:
> We have a call Tuesday, scheduled for 11:00 – 12:30 EDT (though we’ve been 
> just doing 1 hour). We’ll be continuing the review of simple-naming. You can 
> ask Ted Lemon for access to the most up-to-date version on Google docs. The 
> mostly up-to-date version is on the homenet github at 
> https://github.com/ietf-homenet-wg/simple-naming 
> <https://github.com/ietf-homenet-wg/simple-naming>.

At this point the version on github is not really mostly-up-to-date, so I would 
not recommend reading it.

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

[homenet] Commentable version of the document is available.

[Ted Lemon]

We had our first interim meeting on the homenet naming architecture today.
 The chairs took good notes, so I assume they will summarize, but one of
the action items was to convert the document to markdown and share it as a
Google Doc, which I have done.   If you are interested in reading the
document that way and commenting on it, please send me email privately and
I'll send you a link.   I'm not going to send the link to the list because
then it'll be in the archive and might get mobbed by spambots.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet