Thanks Ray. I agree that the routing protocol discussion has been interesting,
but that we really need to take a more disciplined approach if we're ever going
to get consensus on what the correct technology solutions are.
I think that starting with the architecture is a good idea. This will let
The subset of tree topology where a consumer places ones router behind
another router is *extremely* common. Statistics I saw several years ago
suggested that probably about 60% of ADSL customers in the US use this
topology. The most common cause for this topology is where the service
provider
Incorrect.
It's my experience that router manufacturers don't have people sitting around
twiddling their thumbs wondering how to spend their precious work hours.
The Internet ecosystem is best served by CE routers that have rock-solid
native IPv6 implementations. Given the relatively large
Chiming in as a consumer... [the views represented are 100% my own, individual,
consumer perspective]
I'm a consumer of wireless service. I hear people engaged in wireless networks
saying things like Prefix delegation isn't till 3GPP release 10; the best a
device can do till then is assume that
Chances are that part of the reason you had to go to a multi-homed
connection was that your router configuration was suffering from
bufferbloat, and so despite you having a decent connection to your ISP, you
were experiencing congestion. This is, unfortunately, very typical of home
routers
But when (single stack) IPv6 gets offered on that tether, that router will
only have a single /128 address. Hmm.
http://tools.ietf.org/html/draft-byrne-v6ops-64share-03 is one proposal.
Which, I suspect, is how the router would get that single /128 address. That
works nice for the 3GPP
There are somewhat limited options in my understanding with 3gpp release
7 networks, this sounds like a relatively good idea given the limitations but
it's
use generally seems like kind of a bad idea. That said I'm in favor of bad
options over no options, and I think it's heartening to see
If your ISP only supplies a /64 then switch ISP. Truly this is the only way
to
stop such stupidity. If they only supply a /64 via 6rd run away from them
because they are incompentent. It is not rocket science to run multiple 6rd
domains.
IPv6 prefixes are not scarse. They are less
and available.
- Mark
On Mar 6, 2013, at 3:54 AM, Lorenzo Colitti wrote:
On Wed, Mar 6, 2013 at 7:03 AM, STARK, BARBARA H
bs7...@att.commailto:bs7...@att.com wrote:
As a home user who currently gets a /64 (via 6rd) from my ISP, I find this
recommendation insufficient.
Who is the ISP? Do you know why
Just to provide a pointer to a way that another org decided to handle a similar
problem (and I'm not suggesting this is the right approach -- I'm just trying
to provide food for thought):
http://upnp.org/specs/gw/deviceprotection1/
UPnP Device Protection uses X.509 certificates (which can be
UPnP Device Protection uses X.509 certificates (which can be self-signed,
and in order not to assume a WAN connection, really should be self-signed)
and TLS.
I think that something like this, in combination with the promiscuous
registration mechanism that I think Michael described earlier,
Self-signed certs bring only confusion, IMO: they are nothing more than a
raw key with an unsubstantiated claim to another name, along with a whole
lot more ASN.1 baggage beyond what is needed to parse the modulo and
exponent.
And you don't get usage or policy restrictions without a CA that
Unless you have really old stacks your device will pick the new GUA first to
talk to your jukebox when you are on your neighbor's network and the ULA to
talk to it when you are on your own.
No, it won't. It will pick GUA-GUA both times.
Per the table in
On Oct 16, 2014, at 9:18 AM, Lorenzo Colitti lore...@google.com wrote:
So every time a new prefix comes in, hosts should restart DHCPv6? That
seems pretty dubious (and expensive). I don't think any DHCP
implementation works that way.
How do they work, then? And why would you describe
FYI. I made sure they were aware of IETF mif and homenet activities in this
area. I intend to try to prevent having to track efforts that try to do the
same thing in two different ways. But some of the BBF effort may be focused on
what can be done around bonding of multiple interfaces that are
One other thing I forgot to mention about firewalls vis-à-vis the CE router, is
that not all CE routers have firewalls.
Some ISPs provide their customers with an option of receiving a basic (single
LAN Ethernet port, no Wi-Fi) CE router that has no firewall. The expectation is
that most users
Why can't we make a similar assumption that a homenet can get a dns
delegation from some upstream provider as well, be it an ISP, or some other
DNS serving entity? There is no requirement that I have my own vanity
domain and pay a registrar to get a delegation in somebody else's name
space,
I'm saying: pick a GUA if you are a device which should be
discoverable/reachable by default. That's not to say what your ACL
should be. I presume that these devices do not otherwise use
resources the way that my phone or laptop does when I interact with it.
Okay, so what devices
On Nov 13, 2014, at 1:50 PM, STARK, BARBARA H bs7...@att.com wrote:
If it does some form of multicast advertising of its services, or is
discoverable through a multicast discovery mechanism, over IP.
So to address this use case you'd want to say if this is a device that
provides
There are good proposal how to do servicce discovery in homenets or the
like with DNS-SD (/mDNS), but i think we should still worry about
compatibility with UPnP. Both of these requirements (UPnP and DNS-SD) are
IMHO better solved with router-level proxy
solutions than with ASM IP multicast.
So what I want to see is a proposal for a routing protocol that specify link
metrics for a set of commonly used link types in homes. This spec could be
BCP.
Does it need to be a routing protocol? Just to throw another possible protocol
into the mix being tossed around (like we don't have
Yup. Are you aware of similar issues with changing the IAID? If the ISP
has a
limit to how many prefixes can be assigned on a particular customer port,
that could cause issues, but if it's a supported feature as it would be in
Mikael's case, I think it should be OK. Do you know the
Since there is no interest in this working group in actually testing it's own
effluent, in what exists as running code so far, and prefers instead to
re-raise
old debates, and come up with unworkable alternatives, and otherwise
waste my time - and openwrt chaos calmer is going freeze in a
I can understand why this is done in IPv4 (not enough address space) but this
does not apply to IPv6.
Just as one point where it does apply: 6rd deployments experience
fate-sharing of the IPv6 address prefix with the IPv4 address. In PPPoE-based
architectures, the IPv4 address is known to
I don't know. Homenet multicast is an open issue. But I don't think this
use case represents a serious problem, because as far as I can tell streaming
video is not done using multicast in practice anyway.
Sorry, bad assumption. I just finished working on a TV streaming project for
an
Lets hope UPnP/DLNA are starting to consider to cooperate with IETF on
service discovery.
Cooperate is such a strong word. :) They are aware of the issue, they will be
kept informed as to how the issue is progressing and what homenet and dnsext
are doing to tackle the issue, and they know
Does it need to be a routing protocol? Just to throw another possible
protocol into the mix being tossed around (like we don't have enough),
I don't think current protocols used by ISPs or enterprises fits our plugplay
requirements. Also, there is a lot more wireless in homes. That doesn't
I mentioned a couple of weeks ago that IEEE 1905.1 might be something
interesting to look at to see if it might be a useful component of a holistic
homenet solution. It can do PHY and MAC layer topology discovery and PHY-layer
metrics, for all Ethernet MAC-based PHYs (including Wi-Fi, HomePlug,
How do Homenet routers configure NTP? Just use the pool?
Either use the pool or use one from an SNTP DHCP option an edge router
received from an ISP and published in HNCP.
+1
Default (e.g., in open source implementations) should be to use the pool, in
the absence of DHCP option info.
Either use the pool or use one from an SNTP DHCP option an edge
router received from an ISP and published in HNCP.
Ah, silly me. Yes, of course, we're already publishing DHCP(v6) options.
RFC 7084 recommends support for NTP option. If NTP is supported, the
router is required to
Hi Hemant,
Thanks for the reply, but...
There was a claim that IS-IS provides diagnostics.
What sort of diagnostics?
http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4
3/routing/configuration/guide/b_routing_cg43xasr9k/b_routing_cg43xasr9k
Much will depend if the ISP is offering their customer a ‘graceful’
renumbering event. If they do, then the principle applied in RFC4192 could
be applied, and you will have a period where both prefixes (old and new) co-
exist, before the old prefix is removed. In that case, the older
Actually RFC 6204 (and its successor 7084) have a requirement that enforces
keeping it in the RA for at least 2h. HNCP makes following 7084 mandatory
atm.
If you're referring to RFC 7084's:
L-13: If the delegated prefix changes, i.e., the current prefix is
replaced with a new
Why don't you set the valid lifetime to 0 as well?
If a new host is connecting to the network while you're advertising the
max(old valid lft, 2h) valid lifetime, it will actually auto-configure
itself with an address from the withdrawn prefix. If you set valid
lifetime to 0, it won't.
My point was simply that the IETF has multiple of … pretty much everything
else … the reason why things work is that somebody (an operator group, an
industry alliance/forum, …) figure out what is MTI — for their context — and
then do that.
I am simply wondering out loud why that would
to be considered,
then I think they’d better propose it fast, so the Design Team can consider it.
Barbara
From: Pierre Pfister [mailto:pierre.pfis...@darou.fr]
Sent: Wednesday, July 29, 2015 10:14 AM
To: STARK, BARBARA H
Cc: Hemant Singh (shemant); homenet@ietf.org
Subject: Re: [homenet] some
If you have code that detects a PoE adapter and that comes with a license
that I can use, I'm interested. (Barbara mentioned an IEEE standard that aims
at doing that, but I don't think it's being deployed yet.)
Yes, I'd mentioned IEEE 1905.1a. IEEE 1905 (which includes support for HomePlug
Given some of the discussion last week, I found that I had some questions about
what is or isn't already defined somewhere within the set of IS-IS specs *and*
is already implemented in a load suitable for a homenet router. I've read the
Babel specs, so I have a good idea of what's in Babel.
> (2) SHOULD RFC 6126, IPv4 subset;
Why not MUST? Given the massive embedded base (and continued deployment of new)
IPv4-only devices, I think the homenet architecture will be less than
successful if IPv4 isn't mandatory to implement. It's ok for vendors to ship
with IPv4 disabled by
> SHOULD is actually pretty strong. It doesn't mean, "implement if you like"
> (that's MAY). It means, implement it, unless you have a serious reason why
> you can't.
>
> For instance, an IPv6 only IoT gateway probably has no interest in IPv4 if it
> can get IPv6. MUST would make that gateway
> > Maybe conditionally mandatory? If the router can be used for routing
>
> That's what SHOULD is *for*
> If you are concerned it won't get implemented, then any weasel room you
> leave will be exploited. At that point, the market gets to decide.
No, SHOULD and conditionally mandatory are
All I'm saying, Steven, is that no host changes is no excuse -- if we deply
easy to implement protocols that provide desirable functionality, the host
changes will follow.
Perhaps mDNS proxying solves all the naming issues with no host changes
required -- if so, that's excellent. Should we
> Automating zone delegation and glue record insertion with zeroconf seems
> quite a hole in current standards.
and that is also not covered in DNS-SD AFAICS.
As a potential end user of homenet (i.e., within my personal home network), I
very much do *not* want any of my IoT devices,
> Homenet, the issue we're dealing with is that babeld performs badly when
> there is a transparent wireless bridge connected to a wired interface: the
> interface is treated as a lossless wired interface, and if it suffers packet
> loss,
> there is repeated link flapping.
I've had a lot of
> The draft states:
> "The top-level domain name '.homenet.' is to be used for naming within
>a home network. Names ending with '.homenet.' MUST refer to
>services that are located within a home network (e.g., a printer, or
>a toaster)."
>
> Which I think is more correct and
> >I could be wrong, but I believe that Dyn was DDoSed by the Mirai
> >botnet, which propagates by exploiting devices configured with default
> credentials.
> >This has nothing to do with outdated firmwares.
>
> The problem is that you cannot realistically update those firmwares.
Many companies
I have moved the doc to the adopted state. Ted/Daniel, you should be able to
upload a WG revision as your next rev.
Barbara
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
> From: Ted Lemon
> Barbara, I seem to recall that you were enthusiastic about the work when it
> was discussed in the meeting. You're allowed to be one of the people who's
> in favor of it, despite being chair. Indeed, as > chair, you can just adopt
> it by fiat if you want. I actually
With one day left in CFA for draft-tldm-simple-homenet-naming, here is my
summary of what I think I've read.
Exactly 3 people have expressed support for adoption (Daniel [author], Michael
R, James). Hmm. That's not a lot.
Juliusz expressed opposition to adoption, but Ray and Michael said the
Hi homenet,
Thanks to all of you for your well-wishes and congratulations (and condolences)
for my new role as a homenet chair.
As my first official act, under the excellent tutelage of Ray, I'm launching a
2 week Call for Adoption on draft-tldm-simple-homenet-naming. The call will end
August
> In order for a PKI solution to work, it has to be possible for any given cert
> to apply to a unique name, the ownership of which can be defended somehow.
> The CABF has spoken unequivocally on this topic:
> https://www.digicert.com/internal-names.htm
> The point of having PKI in the homenet
Thanks Daniel. And you’re not too late. The call ends this coming Friday. So if
anyone else wants to chime in, please do. I’ll try to create a summary Thursday
describing what I think I’ve heard so far. That should give everyone a brief
chance to tell me how badly I’ve misinterpreted their
> > Currently, there is no host that expects to use .home.arpa (or any other
> domain) inside the premises.
>
> I don't think the "or any other domain" claim is true. At the very least,
> _lots_
> of hosts are already using local. in homenets -- indeed, that's how we got to
> this pass.
Yes. I
No hat.
I'm proposing something radical here. Let the tomatoes fly.
I'd like to question whether we really need to maintain the "no changes to the
host" assumption when it comes to architecting homenet DNS.
Currently, there is no host that expects to use .home.arpa (or any other
domain) inside
> This suggests to me that the next step in HOMENET, which I think the naming
> architecture could lead, is to provide for (automatic) collection of
> statistics for
> diagnostics purposes.
> i.e. Homenet OAM.
Not as chair...
I disagree this has anything to do with the naming architecture.
I
One of the most frequent comments I see for drafts post-WGLC is "why did you
choose status x for your draft?". So I'd like for the WG to consciously agree
on the status to be used for homenet-babel-profile.
Currently the draft has intended status of "Experimental".
Given the intended status of
Hi Juliusz,
Not as chair
I have a question about the following requirement:
REQ6: a Homenet implementation of Babel SHOULD distinguish between
wired and wireless links ; if it is unable to determine whether a link
is wired or wireless, it SHOULD make the worst-case hypothesis that
> >> draft-chouasne-babel-tos-specific-00 may also cause issues, even
> >> though it is just informational. You may want to consider removing
> >> the reference so it doesn't create issues.
>
> > Ok.
>
> Does the same apply to [BABEL-Z]?
I see the Style Guide does allow you to reference work in
> > If you choose to go with a friendly name for the 6126(bis) reference,
> > consider also friendly-naming RFC 7788 to something like [HNCP] and
> > RFC
> > 7298 to [BABEL-HMAC].
>
> I've previously been chastised for the opposite (using friendly names instead
> of the RFC numbers), so I'm
Here is a set of comments related just to references in homenet-babel-profile.
Barbara
The first 4 references to the "Babel routing protocol" spec are to
[RFC6126bis]. All subsequent mentions are to RFC 6126. RFC 6126 is not included
as a reference in the References section. I find this
As chair...
I think it would be useful for homenet to discuss how to propagate its
protocols into general purpose home network routers (that people may use at the
edge or interior) and also what may or may not be good to include in
requirements specifically targeting routers at the customer's
Hi Alvaro,
Thanks for the comments. I agree we need to make sure the community is
comfortable with the decision. I've inserted my comments in-line.
Barbara
> I would like to DISCUSS about the Intended Status of this document -- with
> the Chairs and AD.
>
> I have to confess that I haven't been
Congratulations to Ted, Pierre, homenet, et al for completion of another
milestone. Now if we only had a naming architecture to make good use of this
domain ...
Barbara
-Original Message-
From: rfc-edi...@rfc-editor.org
A new Request for Comments is now available in online RFC
Hi homenet,
There was great conversation about homenet-simple-naming a couple of weeks ago.
I wanted to see if I could summarize where that ended up.
Main points discussed were device (friendly? pretty?) name and/or identity
(public key?) and basic end user management (like giving devices
Hi homenet,
The recently released "subject to change" IETF agenda has homenet at
15:20-16:50 on Wednesday.
It looks like a pretty good time with not a lot of contention.
So what should we talk about?
Clearly we want homenet-simple-naming on the agenda. In fact, it probably makes
sense to give
Hi Denis,
You appear to have perceived events and statements different from how others'
have perceived these.
I don't find this thread accusing Juliusz of bad behavior to be an appropriate
way of addressing your perceptions.
As chair of homenet (your email was sent to homenet and babel), I would
Hi homenet,
As agreed in Prague, we're starting WGLC on draft-ietf-homenet-babel-profile,
now that it has been updated.
I've set the duration for 3 weeks so it will last through the IETF meeting.
Even though Juliusz won't be there, we can still discuss, if we want.
It might even be more fun
Hi homenet,
I've posted a draft agenda for homenet at IETF 100.
https://datatracker.ietf.org/doc/agenda-100-homenet/
Please bash.
Barbara
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Hi homenet,
Since there has been no objection raised to changing the status of this draft
from Informational to Proposed Standard, the change has been made.
If you do have a strong objection, though, I'd like to hear it.
The reasons in favor of the change are:
- the main reference,
Hi homenetters,
As Stephen mentioned, the homenet session for IETF 101 in London is tentatively
scheduled for Friday morning, session 1, 9:30-11:30.
We haven't heard anyone complain.
I'm working on the homenet agenda, now.
Please let the chairs (homenet-cha...@ietf.org) know if you would like to
> > Perhaps I could suggest something in the vein of "very important" or
> > "much desired feature"
>
> This is not the notion that I tried to express, probably badly. It's not
> necessarily the important feature, it's the one that will make people
> implement and deploy the protocol stack in
> From: Kennedy, Smith
> My work has recently exposed me to IEEE 1905.1. I am still learning about
> 1905.1, but I began wondering whether there was anything in the IETF that
> extended access to the 1905.1 ecosystem above the 1905.1 abstracted MAC
> layer? I found an old thread on this
omponents of the homenet solution cannot be used for DDoS attacks. I would
prefer for homenet solutions to be natively incapable of being used in DDoS
attacks.
Barbara
On Wed, Jul 25, 2018 at 12:40 PM, STARK, BARBARA H <mailto:bs7...@att.com>
wrote:
> > Since homenet is supposed
I’ve now finished the repository for -dhc-options, too. I saw the commits from
Tomek were very old.
I think everything looks ok at
> On Fri, 29 Jun 2018 17:46:35 +0100 STARK, BARBARA H
> wrote > Hi Denis, > You appear to have perceived
> events and statements different from how others' have perceived these.
> > I don't find this thread accusing Juliusz of bad behavior to be an
> appro
Daniel: Thanks for doing this.
Just to add more change (no that’s not really the reason – the reason is to
formalize things with official Note Wells and integrated IETF tools and such),
we have an official homenet-wg github site
(https://github.com/ietf-homenet-wg). I’ve put the
Thx Ted, for noticing. Looks like someone was having fun with time zones.
BTW, the messed up meeting times were for September 4 and beyond. Tomorrow’s
was ok.
It’s late-ish for Stephen, now. So I’ve decided to go ahead and take care of
this stuff. Hopefully Stephen doesn’t try to also fix
Thanks, Ted. I’ve also put this draft version on the homenet github site (I
noted a few nit changes I had to make on the Google drafts page). I think what
we said is the authors would periodically push a new version from what’s in
Google docs onto the github page. Ted, Stuart, and Daniel should
Hi homenet,
There've been some agenda changes, to let Daniel be in 2 places at once, and
make the total allocated time add up to 90 minutes. I'll see y'all this
afternoon.
Barbara
IETF 102 - Homenet Agenda
0. Administrivia (5m)
1. WG Status Update - Chairs (2 min)
2. Outsourcing Home Network
> > You're concerned with the homenet losing state when the master is
> > unplugged. By having the master in the cloud, this problem is eliminated.
> I can't speak for Juliusz, but my first question was "what if i don't want it
> in the cloud"? For one thing, what if it's a cloudless day?
I
Since homenet is supposed to be about an unmanaged network,
and configuration via a management protocol requires somebody who knows what
they’re doing, it doesn’t fall within my interpretation of the charter.
Barbara
From: homenet On Behalf Of Ted Lemon
Sent: Tuesday, July 24, 2018 5:57 PM
> > Since homenet is supposed to be about an unmanaged
> > network, and configuration via a management protocol requires somebody
> > who knows what they’re doing,
>
> Traditionally, yes, but we do actually want to get away from that.
> (It's our explicit goal to do that in ANIMA, for which
> STARK, BARBARA H wrote:
> > Since homenet is supposed to be about an unmanaged
> > network, and configuration via a management protocol requires
> somebody
> > who knows what they’re doing, it doesn’t fall within my interpretation
> > of t
Hi homenet,
Draft minutes have been posted.
Thx to Phill Hallam-Baker for taking them.
https://datatracker.ietf.org/meeting/102/materials/minutes-102-homenet-01.html
Please let us know if you think they need changes.
Barbara and Stephen
___
homenet
Hi homenet,
I just wanted to remind everyone of the call this coming Tuesday. Webex details
below.
Also, if you want to provide Ted with comments on the simple-naming draft,
remember to send him an email to get invited to the Google docs rendition. I
put in a few of my own comments there, and
Thx Juliusz. I’m not expecting discussion on this during the meeting. Hopefully
we can resolve all issues on list.
I’ll be more proactive going forward in pushing this to completion.
Barbara
On Jul 10, 2018, at 9:08 AM, Juliusz Chroboczek wrote:
>> - draft-ietf-homenet-babel-profile-06
I've updated the homenet agenda. Further updates are still possible -- just let
the chairs know. - Barbara
IETF 102 - Homenet Agenda
0. Administrivia (5m)
Blue Sheets
Note taker - TBC
Jabber relay - TBC
1. WG Status Update - Chairs (5 min)
Updated Drafts:
-
I've posted draft minutes for the IETF 101 homenet session. Please let us know
if you have any comments.
https://datatracker.ietf.org/doc/minutes-101-homenet/
It was great fun. We'll have to meet like that again soon.
I hope to see as many of you as possible in Montreal. In the meantime, let's
Hi homenet,
Just a quick reminder ...
Our session is scheduled for Friday morning (see details below). There will be
plenty of room for all who want to attend.
The draft agenda is posted at
https://datatracker.ietf.org/doc/agenda-101-homenet/
And the Internet Draft submission cut-off date is
Hi homenet,
Homenet is currently scheduled to meet in Bangkok November 7 at 13:50-15:20
(Wednesday Afternoon session I).
Important dates between now and then:
Document submission deadline: Monday, October 22
Interim call for simple-naming: Oct 23, 11:00-12:00 EDT (details at
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:
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
Hi homenet,
I've posted a draft agenda at
https://datatracker.ietf.org/doc/agenda-103-homenet/. For convenience, it's
copied below. Please let me and Stephen know what adjustments you'd like.
Barbara
-
IETF 103 - Homenet Agenda
Bangkok,
I've done an individual review of simple-naming-03. I'm splitting the comments
up into several emails, just in case there's anything to discuss related to
each topic. It'll take me some time to get all the emails written (in between
doing other things).
This email has all of my comments
Hi Homenet,
New plan for conference calls scheduled between now and Bangkok:
Canceling both Oct 2 and 16 calls. Scheduling a call for Oct 23 at 11:00-12:00
EDT.
Barbara
___
homenet mailing list
homenet@ietf.org
Hi homenet,
Several very important people have conflicts with the Oct 16 call. Therefore,
I'm cancelling it.
Please let the homenet chairs know if you would like an additional call
(11:00-12:00 ET) on Oct 30. Note that on Oct 30, Europe will have left Daylight
Saving Time (Fall back 1 hour),
Hi homenet,
I've uploaded draft minutes.
https://datatracker.ietf.org/doc/minutes-103-homenet/
Please let us chairs know if changes are needed.
Barbara
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Hi homenet,
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
> > prplMesh solves the wifi broadcast domain issue.
> >
>
> >From their website: « prplMesh is an open-source, carrier-grade and
> certifiable implementation of the WiFi Alliance’s Multi-AP specification. »
>
> That's a purely layer 2 solution that relies on a central controller.
> It
Oh, and thank you to Evan Hunt and Brian Haberman for taking notes in Etherpad,
and to Mikael Abrahamsson for doing jabber. I thought the notes were
outstanding.
Barbara
> From: STARK, BARBARA H
>
> I've uploaded a draft of the IETF 104 meeting minutes. Please let us chairs
> know
1 - 100 of 142 matches
Mail list logo
