Re: [homenet] Homenet Mission accomplished ?

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

Re: [homenet] Lars Eggert's Abstain on draft-ietf-homenet-naming-architecture-dhc-options-22: (with COMMENT)

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

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

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 >

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

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

[homenet] SNAC BoF and mailing list

[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

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

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

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

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

Re: [homenet] homenet naming drafts "terminology"

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 Richardso

Re: [homenet] homenet naming drafts "terminology"

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

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

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),

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

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 CP

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

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: >

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

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

Re: [homenet] agenda planning

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

Re: [homenet] IETF 110 and homenet

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

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

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

Re: [homenet] auto-passthrough from ISP routers

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

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

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

Re: [homenet] homenet agenda planning

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

Re: [homenet] biggest L2 domain

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

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

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

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

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

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

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

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

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.

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

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?

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

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

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

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

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

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: > ___

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

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

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

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

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

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

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

(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

Re: [homenet] DNCP/HNCP Revisited

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

Re: [homenet] DNCP/HNCP Revisited

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 >>

Re: [homenet] DNCP/HNCP Revisited

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.

Re: [homenet] DoH??

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??

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

Re: [homenet] DNCP/HNCP Revisited

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

Re: [homenet] DNCP/HNCP Revisited

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?

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.

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

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

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

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

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

> 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

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

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

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

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

Re: [homenet] homenet notes

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

Re: [homenet] homenet notes

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

Re: [homenet] final planning for not formally meeting

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. :)

Re: [homenet] final planning for not formally meeting

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

Re: [homenet] final planning for not formally meeting

ers 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 ch

Re: [homenet] final planning for not formally meeting

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

Re: [homenet] final planning for not formally meeting

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

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

Re: [homenet] primary / secondary configuration

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

Re: [homenet] primary / secondary configuration

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

Re: [homenet] primary / secondary configuration

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

Re: [homenet] webauthn for routers

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

Re: [homenet] webauthn for routers

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

Re: [homenet] webauthn for routers

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

Re: [homenet] webauthn for routers

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 > <mailt

Re: [homenet] webauthn for routers

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

Re: [homenet] webauthn for routers

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

Re: [homenet] webauthn for routers

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.

Re: [homenet] webauthn for routers

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

Re: [homenet] securing zone transfer

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

Re: [homenet] [EXT] securing zone transfer

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

Re: [homenet] [EXT] securing zone transfer

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,

Re: [homenet] securing zone transfer

ael 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, doin

Re: [homenet] securing zone transfer

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.

Re: [homenet] Montreal homenet activities

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 >

Re: [homenet] Montreal homenet activities

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

Re: [homenet] Montreal homenet activities

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

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

tps://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 c

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

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

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

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

[homenet] Homenet market gap analysis...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

g 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 look

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

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

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

om/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 n

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

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 c

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

age> > - 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

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

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.

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

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.

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

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

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

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

Re: [homenet] Reminder: homenet call

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

Re: [homenet] Reminder: homenet call

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:* STA

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 B

Re: [homenet] Reminder: homenet call

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

Re: [homenet] Reminder: Call on Tuesday 11:00-12:30 EDT

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 Go

[homenet] Commentable version of the document is available.

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

Re: [homenet] Home Networking (homenet) WG Virtual Meeting: 2018-09-04

I believe that this meeting was originally scheduled for 1500 UTC, which would be 1600 Dublin time, not 1100 Dublin time. A time change the day before the meeting is (a) not enough notice and (b) I suspect not what was intended. :) On Mon, Aug 20, 2018 at 12:21 PM, IESG Secretary wrote: > The

Re: [homenet] standard way of configuring homenets

On Wed, Jul 25, 2018 at 1:47 PM, STARK, BARBARA H wrote: > > From: Ted Lemon > > Hm, possibly there's been some miscommunication here: we aren't talking > about using tools developed for managed networks for amateurishly-managed > networks. We are talking about the

  1   2   3   4   5   6   7   >