Hi,

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

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

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



>
>
>>> - for requirement 4.9.001
>>>     It might be good to add a refereence to RFC2914 ??
>>>     Just thinking aloud.
>>>
>> Yes, RFC2914 is indeed interesting reference to add.
>>
>>
>>> - for requirement 4.9.003
>>>     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?
>>
>>  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
>
>>
>>> 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 protected]
>>> https://www.ietf.org/mailman/listinfo/opsawg
>>>
>>
>>  _______________________________________________
> OPSAWG mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/opsawg
>
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to