Sent from my iPad >> On Jan 16, 2014, at 2:37 AM, Juergen Schoenwaelder >> <[email protected]> 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: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
