Dear all,
I agree with Rene and Brian on the need to consider constrained networks.
However, I don't think that "professionally-managed networks"
automatically exclude such environments.
As Barbara S. mentioned in
http://www.ietf.org/mail-archive/web/homenet/current/msg04008.html,
there can be multiple scenarios with different roles, and different
devices being managed.
Exactly.
Regards, Benoit
My opinion is that covering the scenario of professionally-managed
consrained (and less constrained) networks is a challenging one, from
which we could derive "good" common, re-usable protocols/components.
Best regards, Laurent.
On 28/10/2014 23:48, Brian E Carpenter wrote:
On 29/10/2014 10:37, Rene Struik wrote:
Hi Benoit:
-1 on you suggestion #1.
I do not think suggesting "constrained networks and devices" to be
suddenly out of scope helps: it is one of the main areas where
semi-automatic management is imperative.
Rene has a point. My +1 was with the idea of limiting the initially
worked-out use cases, and avoiding any direct interference with
progress in homenet. But understanding the requirements for
constrained networks is desirable. What I don't know is whether
those requirements can in fact be met by the same infrastructure
components that we need for "professionally managed" networks.
There may simply not be enough overlap between "nimble and
heterogeneous" and "managed and homogeneous."
Brian
If one has a bootstrapping
solution and configuration negotiation/synchronization protocol that is
not useful in constrained settings, what is the point? In my mind, it
seems much more prudent to design schemes with constrained networks and
devices and failure recovery models that apply there (configuration
mismatch due to sleepy devices, malfunctioning data store, etc.), where
these would then obviously also fit the less constrained,
"professionally managed" networks. Design for the"nimble", so that both
"nimble" and "fatter" networks can use this.
This also has the advantage that one is forced to think in terms of many
potential actors, rather than a few ones, which helps in viewing
solutions in terms of heterogeneous rather than homogeneous deployment
models.
I have done all my reviews of nmrg drafts
(http://www.ietf.org/mail-archive/web/anima/current/msg00327.html) with
constrained networks and devices in mind. It would be a shame if one
would now narrow down the focus and rule this (future almost ubiquitous)
deployment category out of scope.
Or, is this a political ploy, so as to avoid a turf war with homenet
people?
If that is the case, it would be much more prudent to have another BoF
to iron out some of these issues. {This may be prudent for reasons I
already indicated in the same #00327 message as well - I will not
repeat those arguments here.}
Best regards, Rene
On 10/28/2014 4:13 PM, Benoit Claise wrote:
Dear all,
[sorry for double-posting, but we need the specific feedback from the
HOMENET community]
1. scope
I finished reading the ANIMA mailing list and, based on the feedback,
Joel, Ted, and I would like to clarify the ANIMA scope for "the set of
specific reusable infrastructure components that support autonomic
interactions between devices" (quoting the charter)
The charter currently mentions:
The ANIMA working group will initially focus on enterprise, ISP
networks and IoT.
Multiple tracks were discussed on the mailing list.
* keep enterprise, ISP networks and IoT
* focus on enterprise and ISP networks
* everything, but the initial focus is enterprise and carrier?
* professionally-managed networks
It seems to us that "professionally-managed networks" is what ANIMA is
after. And it's potentially a distraction to try to segment the scope
based on enterprise, ISP, homenet, or IoT. What is IoT after all?
OLD: The ANIMA working group will initially focus on enterprise,
ISP networks and IoT.
NEW: The ANIMA working group focuses on professionally-managed
networks.
Does it sound about right?
2. Overlap with HOMENET
This distinction in point 1 might help regarding the potential overlap
of the solution for distributed IPv6 prefix management.
Btw, the new charter has been adapted:
OLD: A solution for distributed IPv6 prefix management within a network.
NEW: the solution for distributed IPv6 prefix management within a
large-scale network
Also, The HOMENET collaboration has been stressed in the charter.
3. Others
I believe I took care of the others changes proposed on the mailing.
If this is not the case, let me know.
At this point in time, please provide concrete change to the charter
text if some issues persist.
Charter v15 has just been posted, and you can review the detailed
changes at
https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-14.txt&difftype=--html&submit=Go!&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-anima%2Fwithmilestones-00-15.txt
4. Security Advisor.
I have requested one for ANIMA to the security ADs.
Regards, Benoit
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
--
Bien cordialement, Best regards,
*Laurent Ciavaglia*
Advanced Internet Research
Bell Labs | Alcatel Lucent
phone: +33 160 402 636
email: [email protected]
<mailto:[email protected]>
linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>
address: Route de Villejust | 91620 Nozay | France
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
