Subject: [coman] FW: New Version Notification for draft-ersue-constrained-mgmt-02.txt

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 17 Oct 2012 10:17:48 +0200

Hi All,

we submitted an update for the constrained-mgmt draft on the "Management
of Networks with Constrained Devices: Use Cases and Requirements". The
draft hopefully addresses most of the issues we discussed in the last
meeting. 

I think it is already time to split the draft into three; e.g. problem
statement, use cases and requirements. But this can be done after
getting your feedback before and during IETF 85.

I would highly appreciate your comments and any kind of discussion on
the draft content especially on the requirements section. Thank you.

Cheers, 
Mehmet 

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 15, 2012 9:59 PM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: [email-masked]; [email-masked]
Subject: New Version Notification for
draft-ersue-constrained-mgmt-02.txt

A new version of I-D, draft-ersue-constrained-mgmt-02.txt
has been successfully submitted by Mehmet Ersue and posted to the
IETF repository.

Filename:	 draft-ersue-constrained-mgmt
Revision:	 02
Title:		 Management of Networks with Constrained Devices: Use
Cases and Requirements
Creation date:	 2012-10-15
WG ID:		 Individual Submission
Number of pages: 78
URL:
http://www.ietf.org/internet-drafts/draft-ersue-constrained-mgmt-02.txt
Status:
http://datatracker.ietf.org/doc/draft-ersue-constrained-mgmt
Htmlized:
http://tools.ietf.org/html/draft-ersue-constrained-mgmt-02
Diff:
http://www.ietf.org/rfcdiff?url2=draft-ersue-constrained-mgmt-02

Abstract:
   This document raises the questions on and discusses the use cases and
   requirements for the management of networks with constrained devices.

The IETF Secretariat

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 19 Oct 2012 16:45:39 -0700

Hi Mehmet,

thank you for updating the draft. There is a huge amount of great work in
it, and I think this will provide a great basis for further discussions.
Indeed, splitting up the document would be required at some point.

Some high-level comments:
  - Section 1.2 (Terminology): The definition of MANET and Intermediate
entity (in COAP) come a bit surprising, since there has been no discussion
before. Also, it seems inconsistent to define MANET, but not all the other
use cases, such as AMI.

  - Section 1.3 (Constrained Device Classes): I know that this definition
is taken from Lwig, but I doubt that it is of much use. The absolute values
will change. While now there are still many C0 devices out, in five years,
they will not exist (or rather, the number 10KB would need to be replaced
by a larger number). I think I would prefer a classification based on the
capabilities (e.g. can support full IP stack, or not)

  - Section 1.4 (constrained networks): I don't think this is a very
consistent classification of networks. First, CN0 seems to be the least
constrained network, whereas C0 devices are the most constrained. I would
suggest the remain the same ordering (0 the most constrained up to a
positive number).
More importantly, there is a mixture with constrained devices in this
definition. Since we talk about the network only, we should only talk about
topology, lossy links, multi-hop, mobility etc. but not constrained
devices.
I don't understand why MANETs are not supported. Several of the use cases,
such as the military use case, community networks and AMI are multi-hop
networks with dynamic topology and lossy links. That is what I call a
MANET. Even the definition of CN1 is, IMO, entirely a MANET; you even
mention Mesh networks, which are nothing else than MANETs (only difference
is that routers are usually non-mobile; nevertheless, the topology is still
dynamic because of fluctuating links.). Is the intention to focus on
non-mobile devices?
Constrained networks are more difficult to define, as there are several
aspects: bandwidth, loss rates of the channel, MTU, topology, etc. I think
that we need more discussion (but maybe after a BOF has been initiated?)

- Section 1.5: (Network Topology Options): I think there is a mix between
the topology (i.e., the graph that represents routers and communication
links), traffic flows (which devices communicate with which other devices),
and application layer (proxies and NMS).

- Section 1.6: I like that.

- Section 1.7: There is mixture of constrained networks (first bullet); I
thought that constrained devices only means that they have little CPU power
and memory. Can't that device still use cable connectivity (i.e.
unconstrained network)? Or is it necessarily linked?
I am unclear about the purpose of this whole section. What does it serve
for?

- Section 2: I think that the problem statement is not quite clear yet. It
is hard to identify what the problems are; there are so many useful
requirements in section 4, so maybe it could be better matched to these
requirements. It would be nice to read section 4, and then say "ah,
requirement x indeed logically follows from the problem y that has been
described in section 2".

- Section 3: I like the diverse use cases. That can be very useful to
identify different requirements and problems.

- Section 4: I very much appreciate the enormous effort for gathering the
requirements. There will be detailed discussions about them (hopefully),
but this is a very good list to start from.
We have to define if the security related requirements also fit in this
discussion, or better some place else (SOLACE?).

Again, I appreciate the effort of the authors, and hope that we can
continue the discussions in Atlanta. I apologize that I only provided this
high-level review, but the last weeks were very busy for me. If you need
help authoring the documents once they are split up, I could help out.

Is there a meeting already planned?

Best regards
Ulrich

On Wed, Oct 17, 2012 at 1:17 AM, Ersue, Mehmet (NSN - DE/Munich) <
[email-masked]> wrote:

> _______________________________________________
> coman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/coman
>

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 20 Oct 2012 06:33:20 +0200

On Oct 20 2012, at 01:45, Ulrich Herberg wrote:

>   - Section 1.3 (Constrained Device Classes): I know that this  
> definition is taken from Lwig, but I doubt that it is of much use.

Well, I can only say that it has been extremely useful in the  
discussions abou protocol capabilities so far.
It may have been the single most useful piece of output of the Prague  
workshop.

This is a discussion we should have in LWIG, but I'm curious:

> The absolute values will change.

Why?
Because we make the protocols more complex all the time so a device  
that is class 1 today will be class 0 in five years?
This madness has to stop.

> While now there are still many C0 devices out, in five years, they  
> will not exist (or rather, the number 10KB would need to be replaced  
> by a larger number).

That is not the feedback I'm getting from industry types.

Yes, one would hope that class 0 devices are eventually going away, so  
we can have full Internet capabilities on all smart object style  
devices.
But that doesn't mean hat the class as an abstract concept is no  
longer useful (if only to say, "fortunately, there are no class 0  
devices any more").
(And they are not going away that fast, at all.)

> I think I would prefer a classification based on the capabilities  
> (e.g. can support full IP stack, or not)

The classes have been defined the way they are because they mirror a  
step function in capabilities.
(They also haven been defined on approximate orders of magnitude  
because you can't nail these steps down to a kilobyte.)

What do you think is missing?

Gruesse, Carsten

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 19 Oct 2012 22:04:31 -0700

Hi Carsten,

On Oct 19, 2012, at 21:33, Carsten Bormann <[email-masked]> wrote:

>>  - Section 1.3 (Constrained Device Classes): I know that this definition is taken from Lwig, but I doubt that it is of much use.
> 
> Well, I can only say that it has been extremely useful in the discussions abou protocol capabilities so far.

Let me reformulate what I meant: I don't mean it's not useful. I am just wondering if using absolute values for memory is the right way to distinguish the different classes.

> It may have been the single most useful piece of output of the Prague workshop.
> 

Right, it was not the main point of my review, and it's fine for me to have the argument in lwig, not here.

>> The absolute values will change.

Because memory will get much cheaper (Moore's law).

> Because we make the protocols more complex all the time so a device that is class 1 today will be class 0 in five years?

Which madness?

> 
>> While now there are still many C0 devices out, in five years, they will not exist (or rather, the number 10KB would need to be replaced by a larger number).
> 

Which feedback do you get then?

> 
> Yes, one would hope that class 0 devices are eventually going away, so we can have full Internet capabilities on all smart object style devices.

Right.

> But that doesn't mean hat the class as an abstract concept is no longer useful (if only to say, "fortunately, there are no class 0 devices any more").

I don't object. Let me clarify what I meant: a device classification is very useful, but I was only wondering if absolute values for memory is the right approach. An RFC defining these classes will be around for a long time, but memory will get so much cheaper in the meantime. What was a lot of memory 10 years ago, is not much today.

> (And they are not going away that fast, at all.)

I am unsure about that. 

> 
>> I think I would prefer a classification based on the capabilities (e.g. can support full IP stack, or not)
> 
> The classes have been defined the way they are because they mirror a step function in capabilities.
> (They also haven been defined on approximate orders of magnitude because you can't nail these steps down to a kilobyte.)
> 

Don't get me wrong.. If the Lwig wg group believes that this is the right way to classify devices, I won't object this.

Best
Ulrich

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 20 Oct 2012 08:45:59 +0200

> What do you think is missing?

Hijacking the thread, I do actually think we should have some more
classes. For coman, in the use cases also devices included that have
the memory to run embedded linux. I think we would do well to cover
devices such xports or even raspberrys. Yes, those boxes probably are
not the target of lwig but they will exist in the internet of things
and some of them will exhibit properties (like mostly sleeping) that
coman I think needs to address.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 22 Oct 2012 12:55:23 +0200

Hi Ulrich,

see my comments below.

Cheers, 
Mehmet 

From: ext Ulrich Herberg [mailto:[email-masked]] 
Sent: Saturday, October 20, 2012 1:46 AM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: [email-masked]; [email-masked]
Subject: Re: [coman] FW: New Version Notification for
draft-ersue-constrained-mgmt-02.txt

Hi Mehmet,

thank you for updating the draft. There is a huge amount of great work
in it, and I think this will provide a great basis for further
discussions. Indeed, splitting up the document would be required at some
point.

  - Section 1.2 (Terminology): The definition of MANET and Intermediate
entity (in COAP) come a bit surprising, since there has been no
discussion before. Also, it seems inconsistent to define MANET, but not
all the other use cases, such as AMI.

[ME]: The terminology section is incomplete and should be extended e.g.
with AMI.

  - Section 1.3 (Constrained Device Classes): I know that this
definition is taken from Lwig, but I doubt that it is of much use. The
absolute values will change. While now there are still many C0 devices
out, in five years, they will not exist (or rather, the number 10KB
would need to be replaced by a larger number). I think I would prefer a
classification based on the capabilities (e.g. can support full IP
stack, or not)

[ME]: The definition was actually first introduced by Carsten in the
Smart Object workshop before IETF 80 in Prague. This is an important
point. See my other mail.

  - Section 1.4 (constrained networks): I don't think this is a very
consistent classification of networks. First, CN0 seems to be the least
constrained network, whereas C0 devices are the most constrained. I
would suggest the remain the same ordering (0 the most constrained up to
a positive number).

[ME]: The "0" in CN0 and C0 don't relate to each other. The
constrainedness of a network is mostly dependent on the wireless
technology used. I found it more useful to differentiate the type of the
network, where the wireless technology can be manifold.

More importantly, there is a mixture with constrained devices in this
definition. Since we talk about the network only, we should only talk
about topology, lossy links, multi-hop, mobility etc. but not
constrained devices. 

[ME]: I agree, we should talk here on devices only.

I don't understand why MANETs are not supported. Several of the use
cases, such as the military use case, community networks and AMI are
multi-hop networks with dynamic topology and lossy links. That is what I
call a MANET. 

[ME]: The agreement in our last f2f meeting was that we want to include
the MANET use case to highlight what it is but exclude from the
requirements discussion. The reason is that MANETs can be based on very
distinct scenarios and have specifics which are unique compared to other
networks. The essential point is that MANETs are infrastructureless
(i.e. without any hierarchy), which seems to be not the case in other
network types the draft describes and makes network management
essentially different.

Even the definition of CN1 is, IMO, entirely a MANET; you even mention
Mesh networks, which are nothing else than MANETs (only difference is
that routers are usually non-mobile; nevertheless, the topology is still
dynamic because of fluctuating links.). 

[ME]: There might be similarities between a MANET and a Mesh network,
however they are not the same thing. I have to admit we don't conceive
sufficiently the special MANET use cases for frequent movement of
routing devices without infrastructure. If we agree that a Mesh network
covers the essential part of a MANET then I would suggest to focus on a
Mesh network instead of trying to cover everything.

Is the intention to focus on non-mobile devices?

[ME]: There is no intention to exclude non-mobile devices. The draft
currently assumes that, from the "network management" pov., both mobile
and non-mobile devices have similar characteristics (I think we should
describe this somewhere). The draft further assumes that the managing
entity is not moving.

I might be wrong in this. Please describe which mobility aspects you
think should be covered from "network management" pov. Managing the IP
mobility itself, e.g. the IP address etc., is not network management per
se.

Constrained networks are more difficult to define, as there are several
aspects: bandwidth, loss rates of the channel, MTU, topology, etc. I
think that we need more discussion (but maybe after a BOF has been
initiated?)

[ME]: We can start such a discussion already today. However, I assume it
is mostly following the capabilities and limitations of the wireless
technology. What would be your proposal for a classification of
constrained networks?

- Section 1.5: (Network Topology Options): I think there is a mix
between the topology (i.e., the graph that represents routers and
communication links), traffic flows (which devices communicate with
which other devices), and application layer (proxies and NMS).

- Section 1.7: There is mixture of constrained networks (first bullet);
I thought that constrained devices only means that they have little CPU
power and memory. Can't that device still use cable connectivity (i.e.
unconstrained network)? Or is it necessarily linked?

[ME]: Section 1.7 in general tries to list and discuss the issues a
constrained device might have and how these issues influence the
management of such a device. As described in section 1.4 and 2. we
include non-constrained networks with constrained devices.

- Section 2: I think that the problem statement is not quite clear yet.
It is hard to identify what the problems are; there are so many useful
requirements in section 4, so maybe it could be better matched to these
requirements. It would be nice to read section 4, and then say "ah,
requirement x indeed logically follows from the problem y that has been
described in section 2".

[ME]: I agree the problem statement in section 2 (which I didn't have
time to update yet) could benefit from a revision aligning it with the
new sections 1.7 and section 4.

- Section 4: I very much appreciate the enormous effort for gathering
the requirements. There will be detailed discussions about them
(hopefully), but this is a very good list to start from. 

[ME]: We see authentication and access control (to the extend it
matters) as part of network management. This is probably the part where
Coman and Solace can profit from and complement each other.

Again, I appreciate the effort of the authors, and hope that we can
continue the discussions in Atlanta. I apologize that I only provided
this high-level review, but the last weeks were very busy for me. If you
need help authoring the documents once they are split up, I could help
out.

[ME]: Yes, there will be a meeting on Thursday. I wanted to announce it
once the room is known. Stay tuned.

Best regards

Ulrich 

On Wed, Oct 17, 2012 at 1:17 AM, Ersue, Mehmet (NSN - DE/Munich)
<[email-masked]> wrote:

Hi All,

Cheers,
Mehmet

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Monday, October 15, 2012 9:59 PM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: [email-masked]; [email-masked]
Subject: New Version Notification for

Abstract:

The IETF Secretariat

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 22 Oct 2012 12:57:32 +0200

Dear Ulrich,

I have no idea when the absolute values will change. A more detailed
classification might be interesting in the long run. 
However, Carsten's classification is a good working assumption for now.

One point we need to consider is that different people are looking at
the capabilites of constrained devices from different angles. If we have
x features which are possible to execute on a constrained device this
does not mean a constrained device can execute them all at once. We
should look on those features as stand-alone features to be executed.
E.g. if a C1 device can in general execute the features f1, f2, .., fx.
The device vendor or the user might be forced to choose e.g. 3 of them
as the device cannot all x features. 

This actually makes it impossible to judge which features a constrained
device can support as a sum.

PS: I assume it would be better to reduce the bandwidth on opsawg
maillist. So I send this to Coman only.

Cheers, 
Mehmet 

> Sent: Saturday, October 20, 2012 7:05 AM
> To: Carsten Bormann
> Cc: Ersue, Mehmet (NSN - DE/Munich); [email-masked]; [email-masked]
draft-ersue-constrained-mgmt-
> 02.txt
definition is taken
> from Lwig, but I doubt that it is of much use.
> >
discussions abou
> protocol capabilities so far.
> 
> Let me reformulate what I meant: I don't mean it's not useful. I am
just wondering if
> using absolute values for memory is the right way to distinguish the
different classes.
> Right, it was not the main point of my review, and it's fine for me to
have the
> argument in lwig, not here.
> 
> >
that is class 1
> today will be class 0 in five years?
will not exist (or
> rather, the number 10KB would need to be replaced by a larger number).
> >
> > Yes, one would hope that class 0 devices are eventually going away,
so we can have
> full Internet capabilities on all smart object style devices.
> 
> Right.
> 
> 
longer useful (if
> only to say, "fortunately, there are no class 0 devices any more").
> 
> I don't object. Let me clarify what I meant: a device classification
is very useful, but I
> was only wondering if absolute values for memory is the right
approach. An RFC
> defining these classes will be around for a long time, but memory will
get so much
> cheaper in the meantime. What was a lot of memory 10 years ago, is not
much today.
> >> I think I would prefer a classification based on the capabilities
(e.g. can support full
> IP stack, or not)
step function
> in capabilities.
because you
> can't nail these steps down to a kilobyte.)
> >
> Don't get me wrong.. If the Lwig wg group believes that this is the
right way to classify
> devices, I won't object this.
> 
> Best
> Ulrich
> 
> 
> >
> > Gruesse, Carsten
> >

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 22 Oct 2012 16:19:13 +0200

> [ME]: There is no intention to exclude non-mobile devices.

s/non-mobile/mobile/

Cheers, 
Mehmet 

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ersue, Mehmet (NSN - DE/Munich)
Sent: Monday, October 22, 2012 12:55 PM
To: ext Ulrich Herberg; Carsten Bormann
Cc: [email-masked]; [email-masked]
Subject: Re: [OPSAWG] [coman] FW: New Version Notification
fordraft-ersue-constrained-mgmt-02.txt

Hi Ulrich,

see my comments below.

Cheers, 
Mehmet 

Hi Mehmet,

Best regards

Ulrich 

Hi All,

Cheers,
Mehmet

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Monday, October 15, 2012 9:59 PM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: [email-masked]; [email-masked]
Subject: New Version Notification for

Abstract:

The IETF Secretariat

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 22 Oct 2012 20:46:08 -0700

Hi Mehmet,

thanks for your reply. See below:

On Oct 22, 2012, at 7:19, "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]> wrote:

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ersue, Mehmet (NSN - DE/Munich)
> Subject: Re: [OPSAWG] [coman] FW: New Version Notification fordraft-ersue-constrained-mgmt-02.txt
>  
> Hi Ulrich,
>  
> see my comments below.
>  
> Cheers, 
> Mehmet
>  
> Subject: Re: [coman] FW: New Version Notification for draft-ersue-constrained-mgmt-02.txt
>  
> Hi Mehmet,
>  
> thank you for updating the draft. There is a huge amount of great work in it, and I think this will provide a great basis for further discussions. Indeed, splitting up the document would be required at some point.
>  
>   - Section 1.2 (Terminology): The definition of MANET and Intermediate entity (in COAP) come a bit surprising, since there has been no discussion before. Also, it seems inconsistent to define MANET, but not all the other use cases, such as AMI.
>  
> [ME]: The terminology section is incomplete and should be extended e.g. with AMI.

okay

>  
>   - Section 1.3 (Constrained Device Classes): I know that this definition is taken from Lwig, but I doubt that it is of much use. The absolute values will change. While now there are still many C0 devices out, in five years, they will not exist (or rather, the number 10KB would need to be replaced by a larger number). I think I would prefer a classification based on the capabilities (e.g. can support full IP stack, or not)
>  
> [ME]: The definition was actually first introduced by Carsten in the Smart Object workshop before IETF 80 in Prague. This is an important point. See my other mail.

Right, I understood that.

>  
>   - Section 1.4 (constrained networks): I don't think this is a very consistent classification of networks. First, CN0 seems to be the least constrained network, whereas C0 devices are the most constrained. I would suggest the remain the same ordering (0 the most constrained up to a positive number).
>  
> [ME]: The “0” in CN0 and C0 don’t relate to each other. The constrainedness of a network is mostly dependent on the wireless technology used. I found it more useful to differentiate the type of the network, where the wireless technology can be manifold.
>  
> More importantly, there is a mixture with constrained devices in this definition. Since we talk about the network only, we should only talk about topology, lossy links, multi-hop, mobility etc. but not constrained devices. 
>  
> I don't understand why MANETs are not supported. Several of the use cases, such as the military use case, community networks and AMI are multi-hop networks with dynamic topology and lossy links. That is what I call a MANET.
>  
> [ME]: The agreement in our last f2f meeting was that we want to include the MANET use case to highlight what it is but exclude from the requirements discussion. The reason is that MANETs can be based on very distinct scenarios and have specifics which are unique compared to other networks. The essential point is that MANETs are infrastructureless (i.e. without any hierarchy), which seems to be not the case in other network types the draft describes and makes network management essentially different.

If we exclude MANETs, I'd like to understand why we don't exclude mesh networks or AMIs. I don't see a major difference in these networks (and I have studied them for a while). MANETs may be infrastructureless, yes, but so may be mesh networks. In both cases, there may be a gateway to other networks (Internet). Same for AMIs. Also, distributed management is mentioned in the draft, so I am still unclear what particularities of MANETs make them so different.

>  
> Even the definition of CN1 is, IMO, entirely a MANET; you even mention Mesh networks, which are nothing else than MANETs (only difference is that routers are usually non-mobile; nevertheless, the topology is still dynamic because of fluctuating links.).
>  
> [ME]: There might be similarities between a MANET and a Mesh network, however they are not the same thing.

Then tell me the difference.

> I have to admit we don’t conceive sufficiently the special MANET use cases for frequent movement of routing devices without infrastructure.
> If we agree that a Mesh network covers the essential part of a MANET then I would suggest to focus on a Mesh network instead of trying to cover everything.

But why? I don't see any major difference (other than mobility)

> [ME]: There is no intention to exclude non-mobile devices. The draft currently assumes that, from the “network management” pov., both mobile and non-mobile devices have similar characteristics (I think we should describe this somewhere). The draft further assumes that the managing entity is not moving.

Why does it matter if the managing entity moves? It's all about the dynamic topology, so at any time the path between any node and the NMS can break.. And if the nodes can move, they can move away from the NMS anyway (so the connection is interrupted)

>  
> I might be wrong in this. Please describe which mobility aspects you think should be covered from “network management”

I think we should cover dynamic topologies where links can frequently go up or down, are asymmetric and of low capacity. That can be due to mobility, or due to other factors such as very flaky links.

> pov. Managing the IP mobility itself, e.g. the IP address etc., is not network management per se.

I agree. I'd call that autoconfiguration.

>  
> Constrained networks are more difficult to define, as there are several aspects: bandwidth, loss rates of the channel, MTU, topology, etc. I think that we need more discussion (but maybe after a BOF has been initiated?)
>  
> [ME]: We can start such a discussion already today. However, I assume it is mostly following the capabilities and limitations of the wireless technology. What would be your proposal for a classification of constrained networks?

That is a good question... I'll think about it, and we can discuss that in Atlanta. (I know, it's easy to criticize, but hard to be constructive ;-)

>  
> - Section 1.5: (Network Topology Options): I think there is a mix between the topology (i.e., the graph that represents routers and communication links), traffic flows (which devices communicate with which other devices), and application layer (proxies and NMS).
> - Section 1.7: There is mixture of constrained networks (first bullet); I thought that constrained devices only means that they have little CPU power and memory. Can't that device still use cable connectivity (i.e. unconstrained network)? Or is it necessarily linked?
> I am unclear about the purpose of this whole section. What does it serve for?
>  
> [ME]: Section 1.7 in general tries to list and discuss the issues a constrained device might have and how these issues influence the management of such a device. As described in section 1.4 and 2. we include non-constrained networks with constrained devices.
>  
> - Section 2: I think that the problem statement is not quite clear yet. It is hard to identify what the problems are; there are so many useful requirements in section 4, so maybe it could be better matched to these requirements. It would be nice to read section 4, and then say "ah, requirement x indeed logically follows from the problem y that has been described in section 2".
>  
> [ME]: I agree the problem statement in section 2 (which I didn’t have time to update yet) could benefit from a revision aligning it with the new sections 1.7 and section 4.
>  
> - Section 3: I like the diverse use cases. That can be very useful to identify different requirements and problems.
>  
> - Section 4: I very much appreciate the enormous effort for gathering the requirements. There will be detailed discussions about them (hopefully), but this is a very good list to start from. 
> We have to define if the security related requirements also fit in this discussion, or better some place else (SOLACE?). 
>  
> [ME]: We see authentication and access control (to the extend it matters) as part of network management. This is probably the part where Coman and Solace can profit from and complement each other.

It also depends where SOLACE is going. 

>  
> Again, I appreciate the effort of the authors, and hope that we can continue the discussions in Atlanta. I apologize that I only provided this high-level review, but the last weeks were very busy for me. If you need help authoring the documents once they are split up, I could help out.
>  
> [ME]: Yes, there will be a meeting on Thursday. I wanted to announce it once the room is known. Stay tuned.

Thanks. Looking forward to more discussions.

Best
Ulrich

>  
> Best regards
> Ulrich 
>  
> 
> On Wed, Oct 17, 2012 at 1:17 AM, Ersue, Mehmet (NSN - DE/Munich) <[email-masked]> wrote:
> Hi All,
>

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 24 Oct 2012 18:34:46 +0200

Hi Ulrich,

O&M area guys usually don’t have sufficient expertise on managing highly dynamic networks without any hierarchy (possibly without any managing entity). I would like to suggest to focus for the time being on mesh networks where we assume a known hierarchy and infrastructure.

Though, as we were discussing earlier, I would find it very useful to have a draft addressing especially the management of MANET-type of networks. If we once have to prepare a charter proposal such a draft would be very helpful to round it off and would quite likely lead to a work item. 

Let’s discuss this topic also at IETF (I am going to arrive on Friday).

Cheers, 
Mehmet

From: ext Ulrich Herberg [mailto:[email-masked]] 
Sent: Tuesday, October 23, 2012 5:46 AM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: <[email-masked]>
Subject: Re: [OPSAWG] [coman] FW: New Version Notification fordraft-ersue-constrained-mgmt-02.txt

Hi Mehmet,

	s/non-mobile/mobile/

	Cheers, 
	Mehmet 

	Hi Ulrich,

	see my comments below.

	Cheers, 
	Mehmet 

	Hi Mehmet,

okay

 

 

 

 

 

 

 

Best

Ulrich

Best regards

Ulrich 

Hi All,

Cheers,
Mehmet

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Monday, October 15, 2012 9:59 PM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: [email-masked]; [email-masked]
Subject: New Version Notification for

Abstract:

The IETF Secretariat

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 24 Oct 2012 09:42:21 -0700

Hi Mehmet

On Wed, Oct 24, 2012 at 9:34 AM, Ersue, Mehmet (NSN - DE/Munich) <
[email-masked]> wrote:

> Hi Ulrich,****
>
> ** **
>
> O&M area guys usually don’t have sufficient expertise on managing highly
> dynamic networks without any hierarchy (possibly without any managing
> entity). I would like to suggest to focus for the time being on mesh
> networks where we assume a known hierarchy and infrastructure.
>

In that case, I suggest to clarify the text on the constrained networks.
Since I was confused by the difference of what you meant by MANET vs
mesh-network in the draft, other people may also be confused. What you
wrote in this email makes that clearer. I will try to come up with a text
in the section of constrained networks; but I won't come up with something
before this IETF.

> ****
>
> ** **
>
> Though, as we were discussing earlier, I would find it very useful to have
> a draft addressing especially the management of MANET-type of networks. If
> we once have to prepare a charter proposal such a draft would be very
> helpful to round it off and would quite likely lead to a work item.
>

Agreed.

> ****
> ** **

Great, I'll arrive on Saturday evening.

See you there!
Ulrich

> ****
>
> ** **
>
> Cheers,
> Mehmet****
>
> ** **
>
> ** **
>
> *From:* ext Ulrich Herberg [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Tuesday, October 23, 2012 5:46 AM
>
> *To:* Ersue, Mehmet (NSN - DE/Munich)
> *Cc:* <[email-masked]>
> *Subject:* Re: [OPSAWG] [coman] FW: New Version Notification
> fordraft-ersue-constrained-mgmt-02.txt****
>
> ** **
>
> Hi Mehmet,****
>
> ** **
>
> On Oct 22, 2012, at 7:19, "Ersue, Mehmet (NSN - DE/Munich)" <
> [email-masked]> wrote:****
>
> > [ME]: There is no intention to exclude non-mobile devices.****
>
>  ****
>
> s/non-mobile/mobile/****
>
>  ****
>
> Cheers,
> Mehmet ****
>
>  ****
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Ersue, Mehmet (NSN - DE/Munich)
> *Sent:* Monday, October 22, 2012 12:55 PM
> *To:* ext Ulrich Herberg; Carsten Bormann
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [OPSAWG] [coman] FW: New Version Notification
> fordraft-ersue-constrained-mgmt-02.txt****
>
>  ****
>
> Hi Ulrich,****
>
>  ****
>
> see my comments below.****
>
>  ****
>
> Cheers,
> Mehmet ****
>
>  ****
>
> *From:* ext Ulrich Herberg [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Saturday, October 20, 2012 1:46 AM
> *To:* Ersue, Mehmet (NSN - DE/Munich)
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [coman] FW: New Version Notification for
> draft-ersue-constrained-mgmt-02.txt****
>
>  ****
>
> Hi Mehmet,****
>
>  ****
>
> Indeed, splitting up the document would be required at some point.****
>
>  ****
>
> Some high-level comments:****
>
> use cases, such as AMI.****
>
>  ****
>
> with AMI.****
> ** **
> okay****
> ****
>  ****
> capabilities (e.g. can support full IP stack, or not)****
>
>  ****
>
> [ME]: The definition was actually first introduced by Carsten in the Smart
> Object workshop before IETF 80 in Prague. This is an important point. See
> my other mail.****
>
> ** **
>
> Right, I understood that.****
>
> ** **
>
>
>
> ****
>
>  ****
>
> positive number).****
>  ****
> [ME]: The “0” in CN0 and C0 don’t relate to each other. The
> constrainedness of a network is mostly dependent on the wireless technology
> used. I found it more useful to differentiate the type of the network,
> where the wireless technology can be manifold.****
>
>  ****
>
> devices. ****
>  ****
> [ME]: I agree, we should talk here on devices only.****
>
>  ****
>
> MANET. ****
>  ****
> networks. The essential point is that MANETs are infrastructureless (i.e.
> without any hierarchy), which seems to be not the case in other network
> types the draft describes and makes network management essentially
> different.****
>
> ** **
>
> If we exclude MANETs, I'd like to understand why we don't exclude mesh
> networks or AMIs. I don't see a major difference in these networks (and I
> have studied them for a while). MANETs may be infrastructureless, yes, but
> so may be mesh networks. In both cases, there may be a gateway to other
> networks (Internet). Same for AMIs. Also, distributed management is
> mentioned in the draft, so I am still unclear what particularities of
> MANETs make them so different.****
>
> ** **
>
>
>
> ****
>
>  ****
>
> Mesh networks, which are nothing else than MANETs (only difference is that
> routers are usually non-mobile; nevertheless, the topology is still dynamic
> because of fluctuating links.). ****
>
>  ****
>
> however they are not the same thing.****
>
> ** **
>
> Then tell me the difference.****
>
>
>
> ****
>
> I have to admit we don’t conceive sufficiently the special MANET use cases
> for frequent movement of routing devices without infrastructure.****
>
> If we agree that a Mesh network covers the essential part of a MANET then
> I would suggest to focus on a Mesh network instead of trying to cover
> everything.****
>
> ** **
>
> But why? I don't see any major difference (other than mobility)****
>
>
>
> ****
>
>  ****
>
> Is the intention to focus on non-mobile devices?****
>
>  ****
>
> currently assumes that, from the “network management” pov., both mobile and
> non-mobile devices have similar characteristics (I think we should describe
> this somewhere). The draft further assumes that the managing entity is not
> moving.****
>
> ** **
>
> Why does it matter if the managing entity moves? It's all about the
> dynamic topology, so at any time the path between any node and the NMS can
> break.. And if the nodes can move, they can move away from the NMS anyway
> (so the connection is interrupted)****
>
>
>
> ****
>
>  ****
>
> I might be wrong in this. Please describe which mobility aspects you think
> should be covered from “network management” ****
>
> ** **
>
> I think we should cover dynamic topologies where links can frequently go
> up or down, are asymmetric and of low capacity. That can be due to
> mobility, or due to other factors such as very flaky links.****
>
> ** **
>
>
>
> ****
>
> pov. Managing the IP mobility itself, e.g. the IP address etc., is not
> network management per se.****
>
> ** **
>
> I agree. I'd call that autoconfiguration.****
>
>
>
> ****
>
>  ****
>
> that we need more discussion (but maybe after a BOF has been initiated?)**
> **
>
>  ****
>
> technology. What would be your proposal for a classification of constrained
> networks?****
>
> ** **
>
> That is a good question... I'll think about it, and we can discuss that in
> Atlanta. (I know, it's easy to criticize, but hard to be constructive ;-)*
> ***
>
> ** **
>
>
>
> ****
>
>  ****
>
> and application layer (proxies and NMS).****
>
> - Section 1.6: I like that.****
>
>  ****
>
> unconstrained network)? Or is it necessarily linked?****
>
> for?****
>  ****
> constrained device might have and how these issues influence the management
> of such a device. As described in section 1.4 and 2. we include
> non-constrained networks with constrained devices.****
>
>  ****
>
> described in section 2".****
>
>  ****
>
> [ME]: I agree the problem statement in section 2 (which I didn’t have time
> to update yet) could benefit from a revision aligning it with the new
> sections 1.7 and section 4.****
>
>  ****
>
> identify different requirements and problems.****
>
>  ****
>
> but this is a very good list to start from. ****
>
> discussion, or better some place else (SOLACE?). ****
>
>  ****
>
> [ME]: We see authentication and access control (to the extend it matters)
> as part of network management. This is probably the part where Coman and
> Solace can profit from and complement each other.****
>
> ** **
>
> It also depends where SOLACE is going. ****
>
>
>
> ****
>
>  ****
>
> help authoring the documents once they are split up, I could help out.****
>
>  ****
>
> Is there a meeting already planned? ****
>
>  ****
>
> once the room is known. Stay tuned.****
>
> ** **
>
> Thanks. Looking forward to more discussions.****
>
> ** **
>
> Best****
>
> Ulrich****
>
> ** **
>
>
>
> ****
>
>  ****
>
> Best regards****
>
> Ulrich ****
>
>  ****
>
> [email-masked]> wrote:****
>
> Hi All,
>
> https://www.ietf.org/mailman/listinfo/coman****
>
>  ****
>