Re: [OPSAWG] Comments on draft-opsawg-ersue-coman-probstate-reqs

[James Nguyen <[e-mail]>]

Sent from my iPad

>> On Jan 16, 2014, at 2:37 AM, Juergen Schoenwaelder <[e-mail]> wrote:
>>
>> On Wed, Jan 15, 2014 at 04:47:17PM -0500, James Nguyen wrote:
>> Hi,
>>
>> I really enjoy reading this draft.  In general, in my opinion is very
>> useful for managing constrained devices.
>>
>> I have a couple of questions/suggestions:
>>
>> (1) Req-ID 4.3.002 Title: Capacity Discovery
>>
>>     I don't quite understand this req.  Please be more specific.
>
> Here is the text (it is _capability_ not _capacity_ discovery):
>
>   Req-ID:  4.3.002
>
>   Title:  Capability Discovery
>
>   Description:  Enable the discovery of supported optional management
>      capabilities of a device and their exposure via at least one
>      protocol and/or data model.
>
> Devices may have different levels of management support. This
> requirement says that it should be possible to discover any optional
> management capabilities. What is unclear here? How can we improve it?

It's clear to me now.  Thx.

>
>> (2) Section 3.3 Configuration Management
>>
>>     Session-oriented configuration protocol may be expensive for managing
>> a large number of similar devices.  In a case when common redundant
>> configurations is issued, reliable multicast with negative acknowledgement
>> (e.g. Negative ACKnowledgement (NACK)-Oriented Reliable Multicast (NORM))
>> would work best.  I suggest to add a reliable transport requirement in this
>> section.  Moreover, a common data model would be needed.
>>
>>     Stateless configuration update solution would also work well for
>> constrained networks.
>
> My assumption is that reliable multicast protocols are not simple and
> bring their own can of worms. Can you point to prototype systems that
> do successfully use reliable multicast to configure constrained
> devices?

I certainly can list a couple of scenarios:

I assume that military radios could be categorized as constrained
devices as they're often on the move and operated in unreliable
networks with lossy links and/or highly disrupted environment.
Military radios or military devices seem to fit the definitions that
are listed in Section 1.6.

(1) In military theater or emergency disaster incident, a group of
soldiers or a group of search-and-rescuers need to switch frequency of
their radios to join other group's communication network.

(2) In battlefield, soldiers' need to be zero-outed (of
configurations) to prevent these radios/comms devices to fall in
enemies' hands.

>
> Can you also elaborate what "stateless configuration update solution"
> means to you?

I meant stateless configuration management.

>
>> (3) Section 3.8 Group-based provisioning
>>
>>     As I mentioned in (2), a common data model would be required for
>> common redundant configurations.  I suggest to add this requirement here.
>
> Yes, perhaps we have to say something explicit about this.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>