Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
On 1.10.2014, at 22.44, Brian E Carpenter brian.e.carpen...@gmail.com wrote:
Personal comments on this:
1) One reason for not stating homenet as part of the scope is
that we do not want to interfere with the current progress in
homenet. Personally I think there is a lot to learn from
homenet, but as I just said to Pierre, we are too late to affect
homenet's choices. I will be delighted if the results can be
applied to homenets in future, of course.
Well, it sounds as if you plan to WGLC your negotiation protocol probably
around the time we WGLC HNCP (or sooner? who knows).
2) I am also a little nervous about the IoT reference in the
charter. We haven't yet seen a use case description that would
apply to IoT (which has IMHO a much broader scope than home
networks, e.g. building services.)
I think the initial focus is indeed on enterprise and carrier
networks where the OPEX pain is greatest, but we should not
artificially limit the applicability either.
I would just say that you aim at enterprise networks and leave it at that,
then. Considering home networks, and even more so constrained devices in the
IoT land have different management model and resources than your typical
enterprise devices.
There are the existing NMRG documents and there will be an
overview document, but we are following quite specific direction
from the ADs about this.
Well, at least providing links to them in the charter would be probably good
idea then. As it is, it looks like ‘we have solution, here is the WG’ to me.
It is not also clear to me how well the suitability of the
solution has been evaluated. For implementation of some
autonomic, distributed algorithms, point-to-point negotiation
protocol such as the suggested solution is far from optimal.
In case of homenet, we moved from hierarchical DHCPv6 PD
(point-to-point hierarchy) to a distributed algorithm
(draft-ietf-homenet-prefix-assignment*) which was result of
over two years of draft updates, academic proving of
correctness etc.
There is a subtle point here. The idea is to produce generic
components that do *not* imply specific autonomic algorithms. If
we do it correctly, those components will support either a top
down or a distributed mechanism or even a blend of the two
approaches. So actually the solution choices come later: we
don’t have to decide in advance between top-down and peer-to-peer.
A protocol (draft-jiang-config-negotiation-protocol) that is essentially
point-to-point state push/pull mechanism does not seem like natural fit for
that (+- some discovery).
The scalable solutions with such protocol require hierarchies of delegation.
For example, given prefix delegation problem, the reasonable (=low number of
total message exchanges) solutions wind up subdividing the prefix
hierarchically, or alternatively with some ‘god node’(s) that perform the
allocations. It becomes harder if you have multiple sources of same resource
(=prefix) or want to be robust in case of failure.
although it is covered
only by one mention in the whole charter (and the rest does
not seem very IoT oriented).
So should we say in the charter that the scope is everything but
the initial focus is enterprise and carrier?
Or that you are developing enterprise solution and it can work for anything
with luck.
Looking at the solutions, from homenet developer / draft
writer point of view, I would welcome a general trust
bootstrapping framework. I am not convinced by the current
solution draft for that (it assumes too many components for a
home network case at least). A lot of the other things seem
somewhat enterprise-y (control plane with IPsec, own routing
protocol and ULAs? Not in IoT device at least, nor probably
in constrained homenet router), or just unsuitable, such as
the negotiation protocol that does not seem like a good fit
for distributed decision making which is usually the key
thing in autonomic networking.
That means we have explained the negotiation idea badly. It is
not top-down negotiation like
draft-boucadair-network-automation-requirements. It is peer to
peer with top-down as a special case.
Sure, it is simple ‘who is there’, ’{can I haz X, (yes|no|no but you can have
Y)}+’ protocol as far as I can read the draft anyway
(draft-jiang-config-negotiation-protocol-02)
It is not obvious to me how it would be even used to tell other all other nodes
about e.g. change in some network parameter (say, NTP server). Is it a
‘request’? Who is it sent to? How to prevent duplication of sending it to nodes
that already did receive it?
From my point of view, a general network infra protocol needs
- discovery
- state push/pull _network wide_
HNCP does this; I am not sure how CDNP can be used for this, but I welcome
examples.
Cheers,
-Markus
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet feedback on the ANIMA charter
On 01/10/2014 18:27, Markus Stenberg wrote: On 1.10.2014, at 16.20, Benoit Claise bcla...@cisco.com wrote: Based on the previous UCAN BoF, we are considering having an ANIMA WG: Autonomic Networking Integrated Model and Approach This is now a proposed charter, under consideration by the IESG. This is your chance to provide feedback on http://datatracker.ietf.org/wg/anima/charter/ Note also that a BoF has been requested, just in case. Since HOMENET was mentioned during the UCAN BoF, I thought of double-checking with you guys. TL;DR: Please either add homenet (and solutions already in the WG) to the WG goals, or drop IoT too and just focus on enterprise. Looking at the milestones, I am very curious about lack of requirements or architecture work before promoting solutions and even WGLCing them. As mentioned in http://www.ietf.org/mail-archive/web/anima/current/msg00246.html A few observations, to start with: 1. Autonomic Networking could be a huge explanatory field. 2. From the BoF, we heard (among other points): There is interest but focus ... focus ... focus on things that could be done quickly 3. The IESG has also been realizing that the process of problem statement/use cases/requirements/architecture/protocol takes way too long for the industry. 4. If a great architecture document to rule all autonomic functions would have been easy, it would been done already. In NMRG for example, which had plenty of time to think about it! So an architecture as a starting point is not the right approach. 5. A WG can always be re-chartered in future phases These are the reasons why Joel and I asked the BoF chairs to lead a charter discussion, focusing on only 2 use cases Notably, adoption of a solution (discovery+negotiation protocol) before adoption of use cases seems like putting cart before the horse. Valid point. Regards, Benoit It is not also clear to me how well the suitability of the solution has been evaluated. For implementation of some autonomic, distributed algorithms, point-to-point negotiation protocol such as the suggested solution is far from optimal. In case of homenet, we moved from hierarchical DHCPv6 PD (point-to-point hierarchy) to a distributed algorithm (draft-ietf-homenet-prefix-assignment*) which was result of over two years of draft updates, academic proving of correctness etc. Also, while dropping homenet from list of target things is _a_ way to solve the conflict that we already have autonomic solution for that particular problem which works (it was mentioned there before in e.g. IETF 90 not-quite-WG-forming BoF), even better would be to have a general solution that _also_ works in a homenet. Especially as IoT is just specialized type of homenet, I assume, although it is covered only by one mention in the whole charter (and the rest does not seem very IoT oriented). Looking at the solutions, from homenet developer / draft writer point of view, I would welcome a general trust bootstrapping framework. I am not convinced by the current solution draft for that (it assumes too many components for a home network case at least). A lot of the other things seem somewhat enterprise-y (control plane with IPsec, own routing protocol and ULAs? Not in IoT device at least, nor probably in constrained homenet router), or just unsuitable, such as the negotiation protocol that does not seem like a good fit for distributed decision making which is usually the key thing in autonomic networking. Cheers, -Markus . ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
Dear Benoit, Markus, all, On 02/10/2014 14:16, Benoit Claise wrote: On 01/10/2014 18:27, Markus Stenberg wrote: Notably, adoption of a solution (discovery+negotiation protocol) before adoption of use cases seems like putting cart before the horse. Valid point. Regards, Benoit Indeed a valid point, however before concluding here, some insights might help: -OPS ADs gave guidance to focus on (applicability on) 2 use cases only. -The solution adoption milestone shall read as _applicability_ of the protocols onto the two proposed/elected use cases (the milestone should be rewritten in that sense for more clarity). -The WG aims at developing protocols reusable _among __multiple_ use cases. -An initial step of the WG should be to extract, from these multiple use cases, the boundaries / problems these protocols have to solve. HTH, best regards, Laurent. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK)
On 02/10/14 13:49, Michael Behringer (mbehring) wrote: My personal goal is that what we do in ANIMA is fully compatible with and ideally used in homenet. It would feel wrong to me to have an infrastructure that doesn't work in a homenet. The security bootstrap is a good example of what we can achieve, with reasonable effort. FWIW, it is not clear to me that the reasonable requirements for provisioning device security information (or bootstrapping if we wanted to call it that) are the same. In enterprise environments we see fewer larger vendors of devices. In the home where we additionally have a large range of vendors many of whom are tiny and leverage a lot of OSS and who could perhaps not take part in the kind of provisioning infrastructure that is quite reasonable for enterprises and their vendors. I do think both want to end up in the same state, where devices are authorised for connection to the network and where there is some keying material usable for security, but I'd be surprised if one approach to getting there worked the same way for both homes and enterprises. S. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK)
My worry on this topic is that we are referring to ³the Home² and ³the Enterprise². It isn¹t that clear of a distinction. This isn¹t just a simple L2 flat home vs. a Fortune 1000 enterprise. The home is getting more complex and includes work from home; IOT, home security, hot spots, cloud services, policies, discovery etc. Large numbers of SMB¹s look like more high end residential than they do large enterprises. It would be ideal to have a solution that spans the range of size and complexity for both residential and enterprise. Perhaps enabling features/capabilities where required. Also, as far as IPV6 connectivity residential is probably ahead of enterprises in adopting V6 centric architectures and services. Residential doesn¹t have much of a choice, it just happens. 2cents, John On 10/2/14, 9:15 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 02/10/14 13:49, Michael Behringer (mbehring) wrote: My personal goal is that what we do in ANIMA is fully compatible with and ideally used in homenet. It would feel wrong to me to have an infrastructure that doesn't work in a homenet. The security bootstrap is a good example of what we can achieve, with reasonable effort. FWIW, it is not clear to me that the reasonable requirements for provisioning device security information (or bootstrapping if we wanted to call it that) are the same. In enterprise environments we see fewer larger vendors of devices. In the home where we additionally have a large range of vendors many of whom are tiny and leverage a lot of OSS and who could perhaps not take part in the kind of provisioning infrastructure that is quite reasonable for enterprises and their vendors. I do think both want to end up in the same state, where devices are authorised for connection to the network and where there is some keying material usable for security, but I'd be surprised if one approach to getting there worked the same way for both homes and enterprises. S. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
On 02/10/2014 19:26, Lorenzo Colitti wrote: On Thu, Oct 2, 2014 at 12:16 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: This use case is precisely what draft-ietf-homenet-prefix-assignment does (which has roots all the way back to draft-arkko-homenet-prefix-assignment-00 in October 2011). So to homenet, this is a solved problem - with an algorithm that has been applied not just to HNCP, but to OSPF and ISIS. Well, we have a bug in our short description, because the intention is to support prefix assignment in a carrier scenario, which is different in many ways. Really? Which ways? That was the point of draft-jiang-auto-addr-management which was briefly presented at the UCAN BOF. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet feedback on the ANIMA charter
Markus Stenberg markus.stenb...@iki.fi wrote: Note also that a BoF has been requested, just in case. Since HOMENET was mentioned during the UCAN BoF, I thought of double-checking with you guys. TL;DR: Please either add homenet (and solutions already in the WG) to the WG goals, or drop IoT too and just focus on enterprise. I see your point; if you think that much IoT will be in the home. However, there are significant areas of IoT deployment into industrial settings which have very different availability of human resources. While in the home, there is perhaps an IoT : HUMAN ration of 1000:1, which is to say that in an average home of 100 devices, there is barely 10% of a human available set them up, in industrial settings the ratio could be even worse (1:1?), but still that might leave a team of ten trained humans available to create Intents. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- pgp1lSXvkXMx6.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
On 02/10/2014 21:20, Markus Stenberg wrote: On 1.10.2014, at 22.44, Brian E Carpenter brian.e.carpen...@gmail.com wrote: Personal comments on this: 1) One reason for not stating homenet as part of the scope is that we do not want to interfere with the current progress in homenet. Personally I think there is a lot to learn from homenet, but as I just said to Pierre, we are too late to affect homenet's choices. I will be delighted if the results can be applied to homenets in future, of course. Well, it sounds as if you plan to WGLC your negotiation protocol probably around the time we WGLC HNCP (or sooner? who knows). I have no idea. The homenet milestones haven't been updated for 2 years, but I would expect HNCP to be much sooner than Anima. 2) I am also a little nervous about the IoT reference in the charter. We haven't yet seen a use case description that would apply to IoT (which has IMHO a much broader scope than home networks, e.g. building services.) I think the initial focus is indeed on enterprise and carrier networks where the OPEX pain is greatest, but we should not artificially limit the applicability either. I would just say that you aim at enterprise networks and leave it at that, then. Considering home networks, and even more so constrained devices in the IoT land have different management model and resources than your typical enterprise devices. Yes, but we are (to be frank) trying to disrupt the current enterprise model and I don't want to constrain the thinking by constraining the scope. There are the existing NMRG documents and there will be an overview document, but we are following quite specific direction from the ADs about this. Well, at least providing links to them in the charter would be probably good idea then. As it is, it looks like ‘we have solution, here is the WG’ to me. The NMRG drafts are cited in the charter. We are trying to avoid claiming that existing solution proposals *are* the draft solutions, because that's the WG's choice to make. It is not also clear to me how well the suitability of the solution has been evaluated. For implementation of some autonomic, distributed algorithms, point-to-point negotiation protocol such as the suggested solution is far from optimal. In case of homenet, we moved from hierarchical DHCPv6 PD (point-to-point hierarchy) to a distributed algorithm (draft-ietf-homenet-prefix-assignment*) which was result of over two years of draft updates, academic proving of correctness etc. There is a subtle point here. The idea is to produce generic components that do *not* imply specific autonomic algorithms. If we do it correctly, those components will support either a top down or a distributed mechanism or even a blend of the two approaches. So actually the solution choices come later: we don’t have to decide in advance between top-down and peer-to-peer. A protocol (draft-jiang-config-negotiation-protocol) that is essentially point-to-point state push/pull mechanism does not seem like natural fit for that (+- some discovery). Well, I disagree, but that again is a job for the WG. The scalable solutions with such protocol require hierarchies of delegation. For example, given prefix delegation problem, the reasonable (=low number of total message exchanges) solutions wind up subdividing the prefix hierarchically, or alternatively with some ‘god node’(s) that perform the allocations. It becomes harder if you have multiple sources of same resource (=prefix) or want to be robust in case of failure. If a resource needs a hierarchy you would contstruct that on top of the negotiation protocol, not as an intrinsic feature of the protocol. although it is covered only by one mention in the whole charter (and the rest does not seem very IoT oriented). So should we say in the charter that the scope is everything but the initial focus is enterprise and carrier? Or that you are developing enterprise solution and it can work for anything with luck. No, not with luck, if we do it right. That would be like saying that DHCP(v4) was designed for campus networks but would work for home networks with luck. Looking at the solutions, from homenet developer / draft writer point of view, I would welcome a general trust bootstrapping framework. I am not convinced by the current solution draft for that (it assumes too many components for a home network case at least). A lot of the other things seem somewhat enterprise-y (control plane with IPsec, own routing protocol and ULAs? Not in IoT device at least, nor probably in constrained homenet router), or just unsuitable, such as the negotiation protocol that does not seem like a good fit for distributed decision making which is usually the key thing in autonomic networking. That means we have explained the negotiation idea badly. It is not top-down negotiation like draft-boucadair-network-automation-requirements. It is
Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK)
On Thu, Oct 2, 2014 at 6:50 AM, Leddy, John john_le...@cable.comcast.com wrote: My worry on this topic is that we are referring to ³the Home² and ³the Enterprise². I have always approached homenet as a place to get standards that also work for small business. Small business is the place (IMHO) where much of an ipv6 revolution could start to happen. It isn¹t that clear of a distinction. This isn¹t just a simple L2 flat home vs. a Fortune 1000 enterprise. +1 The home is getting more complex and includes work from home; IOT, home security, hot spots, cloud services, policies, discovery etc. Large numbers of SMB¹s look like more high end residential than they do large enterprises. +1 It would be ideal to have a solution that spans the range of size and complexity for both residential and enterprise. Perhaps enabling features/capabilities where required. Also, as far as IPV6 connectivity residential is probably ahead of enterprises in adopting V6 centric architectures and services. Residential doesn¹t have much of a choice, it just happens. Comcast's rollout has been quite impressive. Gfiber's also. Others, not so much. 2cents, John On 10/2/14, 9:15 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 02/10/14 13:49, Michael Behringer (mbehring) wrote: My personal goal is that what we do in ANIMA is fully compatible with and ideally used in homenet. It would feel wrong to me to have an infrastructure that doesn't work in a homenet. The security bootstrap is a good example of what we can achieve, with reasonable effort. FWIW, it is not clear to me that the reasonable requirements for provisioning device security information (or bootstrapping if we wanted to call it that) are the same. In enterprise environments we see fewer larger vendors of devices. In the home where we additionally have a large range of vendors many of whom are tiny and leverage a lot of OSS and who could perhaps not take part in the kind of provisioning infrastructure that is quite reasonable for enterprises and their vendors. I do think both want to end up in the same state, where devices are authorised for connection to the network and where there is some keying material usable for security, but I'd be surprised if one approach to getting there worked the same way for both homes and enterprises. S. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht https://www.bufferbloat.net/projects/make-wifi-fast ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK)
I am fully agree with Brian and Kathleen. It is well understood that the new WG would study on existing solutions and ongoing proposals to make sure it is necessary to create new mechanisms. Coordination and awareness is essential for the ANIMA group. Best regards, Sheng From: homenet [homenet-boun...@ietf.org] on behalf of Brian E Carpenter [brian.e.carpen...@gmail.com] Sent: 03 October 2014 5:47 To: Kathleen Moriarty Cc: Michael Behringer (mbehring); The IESG; homenet@ietf.org; Stephen Farrell; an...@ietf.org; Ted Lemon Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) On 03/10/2014 04:12, Kathleen Moriarty wrote: On Thu, Oct 2, 2014 at 9:15 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 02/10/14 13:49, Michael Behringer (mbehring) wrote: My personal goal is that what we do in ANIMA is fully compatible with and ideally used in homenet. It would feel wrong to me to have an infrastructure that doesn't work in a homenet. The security bootstrap is a good example of what we can achieve, with reasonable effort. FWIW, it is not clear to me that the reasonable requirements for provisioning device security information (or bootstrapping if we wanted to call it that) are the same. This is where we would have overlap with SACM and I2NSF. I've spoken in Ops and Dan R has helped to try to recruit some folks to help in SACM. It would be good to not solve this in multiple places. SACM and I2NSF are de-conflicting what they cover. Provisioning and assessing security information is part of those efforts already, hence my questions on the charter as well. In enterprise environments we see fewer larger vendors of devices. In the home where we additionally have a large range of vendors many of whom are tiny and leverage a lot of OSS and who could perhaps not take part in the kind of provisioning infrastructure that is quite reasonable for enterprises and their vendors. There is a push in the vendor space for this type of automation and I'm all for it, let's just coordinate on it so we don't wind up with too many ways to do it. Absolutely. It isn't surprising that Anima proponents are proposing specific approaches to security (or anything else), but there is an overriding sentence in the charter: Where suitable protocols, models or methods exist, they will be preferred over creating new ones. Clerarly that calls for coordination and awareness. Brian I do think both want to end up in the same state, where devices are authorised for connection to the network and where there is some keying material usable for security, but I'd be surprised if one approach to getting there worked the same way for both homes and enterprises. I'd like to see this discusses more, but maybe it's not in this group? Thanks, Kathleen S. ___ Anima mailing list an...@ietf.org https://www.ietf.org/mailman/listinfo/anima ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK)
I also think ISP networks and enterprise networks are different from home networks. Although many requirements may looks similar, particularly considering the auto operation target, there are many preconditions are different. It could result on different solution though some components may be reusable among these networks. For ANIMA, we should surely study what homenet is working on and identify the differentia. Only after then, we can produce necessary solution with confusing the world. Best regards, Sheng From: homenet [homenet-boun...@ietf.org] on behalf of Toerless Eckert [eck...@cisco.com] Sent: 02 October 2014 22:41 To: Leddy, John Cc: Michael Behringer (mbehring); The IESG; homenet@ietf.org; Stephen Farrell; an...@ietf.org; Ted Lemon Subject: Re: [homenet] [Anima] Ted Lemon's Block on charter-ietf-anima-00-09: (with BLOCK) Fully agreed. But does this imply that we will make most progress by blocking out a working group that is actively chartered to look at the problems in the market segments Homenet is not addressing ? If the BLOCK is meant to suggest a charter improvements for anima to better define our mutual desire to share whatever is applicable and not reinvent unnecessarily, then where is the proposed charter text change ? Cheers Toerless P.S.: Also, if i may throw in some random tidbit of technology thoughts: I love home networks (and the WG for it), because it is the best place for IPv6 to eliminate IPv4 and start creating fresh, better IP network. I have a lot of doubt that we are anywhere close to going that route especially in larger enterprises, so the address management for IPv4 in those networks is going to be a crucial requirement where i don't think homenet could (or should) be any big help. And i am not sure if i would want to hold my breath for a lot of IPv4 adress complexity reduction in IoT either. But certainly autonomic processes cold rather help than hurt in that matter. On Thu, Oct 02, 2014 at 01:50:13PM +, Leddy, John wrote: My worry on this topic is that we are referring to ³the Home² and ³the Enterprise². It isn¹t that clear of a distinction. This isn¹t just a simple L2 flat home vs. a Fortune 1000 enterprise. The home is getting more complex and includes work from home; IOT, home security, hot spots, cloud services, policies, discovery etc. Large numbers of SMB¹s look like more high end residential than they do large enterprises. It would be ideal to have a solution that spans the range of size and complexity for both residential and enterprise. Perhaps enabling features/capabilities where required. Also, as far as IPV6 connectivity residential is probably ahead of enterprises in adopting V6 centric architectures and services. Residential doesn¹t have much of a choice, it just happens. 2cents, John On 10/2/14, 9:15 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 02/10/14 13:49, Michael Behringer (mbehring) wrote: My personal goal is that what we do in ANIMA is fully compatible with and ideally used in homenet. It would feel wrong to me to have an infrastructure that doesn't work in a homenet. The security bootstrap is a good example of what we can achieve, with reasonable effort. FWIW, it is not clear to me that the reasonable requirements for provisioning device security information (or bootstrapping if we wanted to call it that) are the same. In enterprise environments we see fewer larger vendors of devices. In the home where we additionally have a large range of vendors many of whom are tiny and leverage a lot of OSS and who could perhaps not take part in the kind of provisioning infrastructure that is quite reasonable for enterprises and their vendors. I do think both want to end up in the same state, where devices are authorised for connection to the network and where there is some keying material usable for security, but I'd be surprised if one approach to getting there worked the same way for both homes and enterprises. S. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
