Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-*

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 02 Jan 2014 09:55:04 +0100

My review of the coman documents.

I am not well versed in these spaces, so take that into account.

Reading the use cases I got a bit annoyed by the military discussion.
I am a pacifist, so don't really want to review/discuss military needs
or requirements. Oh well....

I am also not very familiar with the uses cases of intelligent meters,
factory automation/monitoring, health care devices monitoring and being
remotely managed.
It is interesting reading, and I learned a lot, but I cannot evaluate
if they represent real scenarios or are detailed anough. Also can I not
evaluate if they are exhaustive.

So I focused on the requirements.
Good list of requirements to start with I think. I have some questions:

- for requirement 4.2.0001
   I wonder why a C0 device would have to implement in a modular fashion.
   I could see that a C0 device (Maybe even C1) does the minimal
   modular-function-set implementation, but that the impleementation is in
   fact monolythic. It often save memory and possibly cpu cycles.

- for requirement 4.9.001
   It might be good to add a refereence to RFC2914 ??
   Just thinking aloud.

- for requirement 4.9.003
   is that more or less an "implementation" suggestion for requirement 4.9.001 ??

See you all in the neaw year, which I hope is prosperous for you all.

Bert

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 3 Jan 2014 16:41:00 +0000

Hi Bert,

thank you for your kind review. See below.

Cheers, 
Mehmet 

> -----Original Message-----
> From: OPSAWG [mailto:[email-masked]] On Behalf Of ext Bert Wijnen
> (IETF)
> Sent: Thursday, January 02, 2014 9:55 AM
> To: opsawg >> "[email-masked]"
> Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-*
> 

I wonder how you define the "minimal modular-function-set". Isn't this already a decision?
The draft avoids defining function sets to be used. I assume different vendors will provide 
different monolithic devices. 

>    It might be good to add a refereence to RFC2914 ??
Yes, RFC2914 is indeed interesting reference to add.

>    is that more or less an "implementation" suggestion for requirement 4.9.001 ??

You are right. It could be seen as such.
However, there might be different reasons why people would want to reduce the amount of traffic in the network.
Congestion is one of them. One can also begin acting before congestion happens. WDYT?

> See you all in the neaw year, which I hope is prosperous for you all.

See you!!! Happy New Year!!

Cheers,
Mehmet

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

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Fri, 03 Jan 2014 18:55:26 +0100

inline

> different monolithic devices.

There is two things that (in my view are/can be modular:
- the implementation
- the specification

EVen if the specification is "modular", even then someone can chose to
implement it as a monolythic program/process I would think. And often that can
save memory usage.

> Congestion is one of them. One can also begin acting before congestion happens. WDYT?
OK, maybe add a line of text about that then. IN my view it looked like basically twice the
same requirement. But if you define it this way, then it can be seen as a different requirement
may be.

Bert

---

From: Andy Bierman <[email-masked]>
Date: Fri, 3 Jan 2014 10:23:09 -0800

Hi,

On Fri, Jan 3, 2014 at 9:55 AM, Bert Wijnen (IETF) <[email-masked]>wrote:

> ....

I think this refers to the issues left unresolved by the "NETCONF Lite"
discussions.
The current NETCONF approach consists of a base protocol + several purely
optional
capabilities.  This is a modular approach.  The problem is that the base
protocol
is way too heavyweight for constrained devices.

Another way to create modular functionality would look more like a
hierarchy,
not 1 mandatory blob + N optional blobs.  NMS applications should be written
so they can fall-back to lower functionality levels, in order to work with
constrained devices.

E.g. (not a complete list)

  Level 0: pre-configured; able to push pre-defined monitoring data
  Level 1: pre-configured; able to pull pre-defined monitoring data
  Level 2: pre-configured; able to pull user-defined filtered subsets of
monitoring data
  Level 3: has config objects; requires a restart for new values to take
affect
  Level 4: entire config (or pre-determined subset) can be replaced in bulk
  Level 5: ability to patch objects without replacing entire config
  Level 6: ability to lock datastores for write access
  Level 7: has transaction (all-or-none) capability
  Level 8: has recoverable transaction (confirmed-commit) capability

Andy

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sat, 4 Jan 2014 12:06:27 +0000

... 
> implement it as a monolythic program/process I would think. And often that can

Agree.
 
... 
> same requirement. But if you define it this way, then it can be seen as a different

I think the requirements can be justified. Will add text. 

Cheers,
Mehmet