Re: [homenet] Thoughts about routing

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 supp

Re: [homenet] Creating a security association via physical link +button

+1 And if the goal is just to identify the boundaries, I don't think that passphrases and encryption are the right way to go about that. But to be honest, I'm sort of fuzzy as to what the goals really are. Barbara An IGP in a homenet setting needs crypto security no more than DHCP, ND or m

Re: [homenet] #6: Support for arbitrary topologies

> > #6: Support for arbitrary topologies > > > > We currently state that homenets should support arbitrary topologies > > (SD1). There have been some comments that this might not be > realistic. > > Should we continue to shoot for that? > > The users will create arbitrary topologies. How can w

Re: [homenet] a modest proposal

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 quan

Re: [homenet] prefix assignment on home networks

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

Re: [homenet] prefix assignment on home networks

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

Re: [homenet] prefix assignment on home networks

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

Re: [homenet] prefix assignment on home networks

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

[homenet] ISP-delegated IPv6 prefixes (3.4.1) in draft-ietf-homenet-arch-07

This section of the homenet architecture draft has the following paragraph: The home network needs to be adaptable to ISP prefix allocation policies, and thus make no assumptions about the stability of the prefix received from an ISP, or the length of the prefix that may be offered. Ho

Re: [homenet] ISP-delegated IPv6 prefixes (3.4.1) in draft-ietf-homenet-arch-07

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

Re: [homenet] ISP-delegated IPv6 prefixes (3.4.1) in draft-ietf-homenet-arch-07

I've stopped keeping track now as it has become rather widely understood 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 mailto:bs7...@att.com>> wrote: As a home user who currently gets a /64 (via 6rd) from my

Re: [homenet] HNCP security?

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 sel

Re: [homenet] HNCP security?

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

Re: [homenet] HNCP security?

> 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

Re: [homenet] HNCP security?

tf.org Cc: Subject: Re: [homenet] HNCP security? On 9/18/14, 2:10 PM, STARK, BARBARA H wrote: >> 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 baggag

Re: [homenet] HNCP security?

> >> I further suggest that if two routers have wireless that they might > well > >> have a WPA2/PSK available to them, and that they can and SHOULD use > something > >> derived from that key to authenticate each other. Could be over IKEv2, > yes. > > > I _think_ we have to assu

Re: [homenet] Home-network support (was Re: [Anima] Homenet feedback on the ANIMA charter

> It seems that the definition of the coined term "professionally managed" > is somewhat ambiguous. +1 Here is the way I see things going. Note that I'm not proposing this as a direction where IETF needs to drive things. I'm describing my pragmatic view of "what is" based on my experiences and

Re: [homenet] Let's make in-home ULA presence a MUST !?

>> 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 http://tools.ietf.org/html

Re: [homenet] Let's make in-home ULA presence a MUST !?

> On Oct 16, 2014, at 9:18 AM, Lorenzo Colitti 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 this as expensi

[homenet] =?Windows-1252?Q?RE:__Fwd:_New_Liaison_Statement, _"Broadband_For?= um Work on “Hybrid Access for Broadband Networks” (WT-348)"

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

Re: [homenet] Comments requested for draft CER-ID

My comments continue to be: I think an indication of "this interface is external" (i.e., don't trust me, this is a "public" network) can be valuable in applying "external" classification to an interface. I'm happy not to trust those who claim to be untrustworthy. But that doesn't seem to be the

Re: [homenet] Comments requested for draft CER-ID: firewall behavior

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

Re: [homenet] draft-cheshire-homenet-dot-home-01

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

Re: [homenet] draft-cheshire-homenet-dot-home-01

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

Re: [homenet] Homenet local service device reachability problem

> On Nov 13, 2014, at 1:50 PM, STARK, BARBARA H 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 i

Re: [homenet] Routing protocol comparison document

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

Re: [homenet] More about marginal links [was: Routing protocol comparison document]

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

Re: [homenet] Routing protocol comparison document

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

Re: [homenet] More about marginal links [was: Routing protocol comparison document]

> > 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 plug&play > requirements. Also, there is a lot more wireless in homes. That

Re: [homenet] Routing protocol comparison document

> 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

Re: [homenet] 6renum redux [Routing protocol comparison document]

> 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

Re: [homenet] a modest plugfest proposal

> 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

Re: [homenet] Orchestration of renumbering

> >> Wasn't aware of that need. One way to make this happen would be for > the CPE to reset its DUID. But it's no longer smooth renumbering, the prefix > will simply change. In this case however, this is a user-triggered action, so > immediate renumbering might be acceptable. Support for RFC7084 L-

Re: [homenet] Orchestration of renumbering

> 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

[homenet] IEEE 1905.1 and 1905.1a

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,

Re: [homenet] IEEE 1905.1 and 1905.1a

It does sound like there may be multiple IEEE solutions that might be considered as potentially helpful to homenet scenarios. Just as information to those unfamiliar with IEEE: 1905 is an "entity" based IEEE group (i.e., companies are members, not individuals) that is very distinct from 802 (whi

Re: [homenet] Routing Protocol in HNCP

Given discussion during the meeting, I agree with the design team recommendation that HNCP should implement the router protocol selection mechanism (that hopefully would select the most ubiquitously supported router protocol). This would allow HNCP to proceed without a mandatory-to-implement ro

Re: [homenet] Most simple example "lossy routing" setup / value prop ?

> 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

[homenet] some IS-IS questions

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

Re: [homenet] some IS-IS questions

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 > _chapter_01011.html#c

Re: [homenet] Moving forward.

> 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

Re: [homenet] Moving forward.

> >There are mesh extensions for ISIS? Interesting, could I please have a > pointer to that work? > > TRILL RBridges using ISIS in a RBridged mesh topology. I continue to be confused about the vast array of what is possible in a top-of-the-line IS-IS deployment, and what is being proposed for a

Re: [homenet] some IS-IS questions

> >So the answer is no. Bridges are not going to be discovered in a homenet IS- > IS topology. > > A bridge does issue ARP to a switch/router The switch/router learns the > mac-address of the bridge and the bridged domain. The switch/router > propagates the learnt information in a sub-TLV of ISI

Re: [homenet] some IS-IS questions

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

Re: [homenet] HNCP, RA and DHCPv4

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

Re: [homenet] HNCP, RA and DHCPv4

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

Re: [homenet] HNCP, RA and DHCPv4

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

Re: [homenet] Moving forward.

> > >> Whilst not wanting to de-rail any effort to standardise Babel > > >> (since I firmly believe it should be standardised), I'd like to > > >> hear the WG's view on having part of our Homenet stack be on > > >> Experimental Track instead of PS. E.g., would it affect vendors' > > >> willingnes

Re: [homenet] NTP in Homenet?

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

Re: [homenet] NTP in Homenet?

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

Re: [homenet] Host naming in Homenet

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

Re: [homenet] Host naming in Homenet

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

Re: [homenet] The minimal Babel profile for Homenet

> (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 default,

Re: [homenet] The minimal Babel profile for Homenet

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

Re: [homenet] The minimal Babel profile for Homenet

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

Re: [homenet] [Babel-users] Detecting bridges

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

Re: [homenet] write up of time without clocks

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

Re: [homenet] write up of time without clocks

> > Yes, I agree it's possible to do better, but what's the incentive for > > a bottom-feeding vendor of cheap devices to bother? > > I hate to say this, but how about legal solutions? My reading of the tea leaves: either the industry creates its own certification plan, or the regulators will d

Re: [homenet] Clarification on homenet-dot slides

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

Re: [homenet] The HOMENET WG has placed draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued"

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 11

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

> 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

Re: [homenet] The HOMENET WG has placed draft-tldm-simple-homenet-naming in state "Call For Adoption By WG Issued"

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 state

[homenet] Status of draft-tldm-simple-homenet-naming CFA

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 r

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

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

[homenet] homenet has adopted draft-tldm-simple-homenet-naming

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

Re: [homenet] tuscles and conflicting goals / trust with draft-tldm-simple-homenet-naming CFA

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

[homenet] homenet "no host changes" assumption and DNS

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 th

Re: [homenet] homenet "no host changes" assumption and DNS

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

Re: [homenet] support for HNCP in IPv6 CE routers

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 ed

Re: [homenet] IETF WG state changed for draft-ietf-homenet-babel-profile

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 witho

[homenet] homenet agenda posted

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

[homenet] IETF100 minutes

Draft minutes have been uploaded. https://datatracker.ietf.org/doc/minutes-100-homenet/ Thanks to Tim Wicinski for supplying them (and Mikael for jabbering). Comments welcome. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailma

[homenet] homenet-babel-profile: references

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 disconce

[homenet] homenet-babel-profile: status experimental?

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 6

[homenet] homenet-babel-profile: determining link type

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

Re: [homenet] homenet-babel-profile: references

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

Re: [homenet] homenet-babel-profile: references

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

Re: [homenet] Link between IEEE 1905.1 and homenet work?

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

Re: [homenet] homenet-babel-profile: status experimental?

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, draft-ietf-bab

[homenet] homenet at IETF 101

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

Re: [homenet] Genart last call review of draft-ietf-homenet-babel-profile-05

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

Re: [homenet] homenet - Requested session has been scheduled for IETF 101

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 Mond

[homenet] minutes from IETF 101

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 k

Re: [homenet] Alvaro Retana's Discuss on draft-ietf-homenet-babel-profile-06: (with DISCUSS and COMMENT)

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

[homenet] FW: RFC 8375 on Special-Use Domain 'home.arpa.'

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 librari

Re: [homenet] Introduction to draft-ietf-homenet-simple-naming

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

[homenet] agenda planning

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 t

Re: [homenet] [babel] about Babel security (questions for Juliusz Chroboczek)

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

[homenet] homenet agenda update

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: - draft-ietf-homenet-front-end-namin

Re: [homenet] homenet agenda update

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 waiti

[homenet] agenda changes

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

Re: [homenet] (no subject)

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

[homenet] homenet 102 minutes

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 mail

Re: [homenet] standard way of configuring homenets

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

Re: [homenet] standard way of configuring homenets

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

Re: [homenet] standard way of configuring homenets

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

Re: [homenet] standard way of configuring homenets

rely on this enrollment to guarantee that components 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> wrot

Re: [homenet] drafts on github

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 front-end-naming

Re: [homenet] drafts on github

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 https://github.com/ietf-homenet-wg

Re: [homenet] [babel] about Babel security (questions for Juliusz Chroboczek)

> 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

  1   2   >