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

From: Hui Deng <[email-masked]>
Date: Mon, 6 Jan 2014 15:48:34 +0800

Hi Authors,

This document is very useful for service providers and operators that are
managing their constrained devices.

Two cents for authors to consider,

1. in section 3., a section of ‘IPv4/v6 address management’ could be
helpful, including the discussion of different types of ip addresses on
devices, link-local, global, private, etc..

2. in Appendix A, any relevant discussion in ‘oneM2M’?

Regards,

-Hui

2014/1/4 Ersue, Mehmet (NSN - DE/Munich) <[email-masked]>

> Hi Dan,
>
> thank you for your review and comments. See below.
>
> Cheers,
> Mehmet
>
> > -----Original Message-----
> > From: OPSAWG [mailto:[email-masked]] On Behalf Of ext
> Romascanu, Dan
> > (Dan)
> > Sent: Thursday, December 12, 2013 2:23 PM
> > To: Warren Kumari; [email-masked]
> > Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-*
> >
> > Hi,
> >
> > I do not know if I really should be included in the reviewers count, as
> I am a participant
> > in the coman work since it started, and my name shows up on the list of
> authors,
> > although in all sincerity most of the credits go to Mehmet, who hold the
> pen for most
> > of the time, including this latest wound which split the original
> document into two
> > separate documents - one for use cases, the other for problem statement
> and
> > requirements. Anyway, FWIW I obviously believe this work is useful and I
> support
> > doing it in the OPSAWG. I have a few comments recorded below:
> >
> >  draft-ersue-opsawg-coman-use-cases
> >
> > 1. I do not believe that we can get away with a zero-content security
> considerations
> > section. The described use cases mention the need to secure information
> collected by
> > constrained devices, some other (like security cameras) carry
> information related to
> > personal or public security that needs to be protected by robust
> mechanisms. These
> > kind of threats need to be mentioned IMO.
>
> You are right a dummy security considerations section is not sufficient.
> Coman was not planning to address security exhaustively. Solace, now ACE,
> has
> been started where security for constrained devices will be discussed.
> We discussed the security requirements in section 3.6 of the problem
> statement draft.
>
> I agree, a discussion of the security threads should be provided in a
> security considerations section.
>
> > draft-ersue-opsawg-coman-probstate-reqs
> >
> > 1. The draft uses the 'adjective' small device in association with
> constrained device in a
> > few place. I suggest to remove this. There is no automatic association
> of a device
> > being small implying that it is also constrained. Nor are all
> constrained devices small in
> > size.
>
> Agree. We should be more precise with the terminology.
>
> > 2. We have made an effort in the last few versions and especially in
> this one to
> > distinguish between the constrained devices and constrained networks,
> but the clean-up
> > on this issue is not complete. For example section 1.6 still has text
> about constrained
> > networks - this section and other in which constrained networks are
> mentioned should
> > be carefully examined to make sure that the focus of the document stays
> with
> > constrained devices, and that if constrained networks are mentioned at
> all this is in the
> > context of their relationship with the constrained devices.
>
> Why strictly devices? We also have requirements discussing the
> organization of constrained networks from management pov. in section 3.1.
>
> > 3. I do not believe that we can get away with a zero-content security
> considerations
> > section here either. The document even says:
> >
> >    If specific requirements for
> >    security will be identified, they will be described in future
> >    versions of this document.
> >
> > This is not accurate - section 3.6 already speaks about requirments for
> security and
> > access control, and section 1.6 mentions limitations that would prevent
> the
> > implementation of strong scryptographic algorythms. The text needs to be
> reviewed
> > and revised from this perspective.
>
> I think the "future" is now and the current text in the security
> considerations section needs to be replaced. I would suggest to provide a
> security considerations section by listing and discussing threads in the
> problem statement draft and refer to it from the use cases draft.
> Comments?
>
> >
> > Regards,
> >
> > Dan
> >
> > > -----Original Message-----
> > > From: OPSAWG [mailto:[email-masked]] On Behalf Of Warren
> Kumari
> > > Sent: Wednesday, December 04, 2013 6:49 PM
> > > To: [email-masked]
> > > Subject: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-*
> > >
> > > Hi all,
> > >
> > > Hopefully you all had a good Thanksgiving -- if you are in the US,
> > > hopefully you had good turkey, stuffing / whatever.
> > > If you are not US based, hopefully you enjoyed the decrease in email
> > > volume while everyone recovered form eating too much. :-)
> > >
> > > One of the action items from Vancouver was for us to call for reviewers
> > > for:
> > >
> http://datatracker.ietf.org/doc/draft-ersue-opsawg-coman-probstate-reqs/
> > > and
> > > http://datatracker.ietf.org/doc/draft-ersue-opsawg-coman-use-cases/
> > >
> > > So, can we get some volunteers please? According to our new guidelines
> > > we require sufficient reviewers before adopting new work.
> > >
> > > The documents are (IMO) interesting and easy to read. Constrained
> > > devices have some interesting requirements and limitations.
> > > If you would like a quick reminder / refresher from the meeting, slides
> > > are here:
> http://tools.ietf.org/agenda/88/slides/slides-88-opsawg-11.pdf
> > >
> > > Juergen Schoenwaelder <[email-masked]> indicated
> > > that one of his Ph.D. students had read the draft a couple of weeks
> ago.
> > > So they just have to review the changes to the latest version.
> > >
> > >
> > > W
> > > --
> > > "I think it would be a good idea."
> > > - Mahatma Ghandi, when asked what he thought of Western civilization
> > >
> > >
> > >
> > > _______________________________________________
> > > OPSAWG mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/opsawg
> > _______________________________________________
> > OPSAWG mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/opsawg
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 6 Jan 2014 18:56:28 +0000

Hi Hui,

thank you for your kind review.

> 1. in section 3., a section of 'IPv4/v6 address management' could be helpful, including the discussion of different types of ip addresses on devices, link-local, global, private, etc..
Concerning IPv4/v6 addresses which requirements do you have in mind from management pov.?

> 2. in Appendix A, any relevant discussion in 'oneM2M'?
I would need your help for this as I'm not involved in oneM2M. Thanks.

Cheers,
Mehmet

From: OPSAWG [mailto:[email-masked]] On Behalf Of ext Hui Deng
Sent: Monday, January 06, 2014 8:49 AM
To: [email-masked]
Subject: [OPSAWG] Comments on draft-opsawg-ersue-coman-probstate-reqs

Hi Authors,

This document is very useful for service providers and operators that are managing their constrained devices.

Two cents for authors to consider,
1. in section 3., a section of 'IPv4/v6 address management' could be helpful, including the discussion of different types of ip addresses on devices, link-local, global, private, etc..
2. in Appendix A, any relevant discussion in 'oneM2M'?

Regards,

-Hui

2014/1/4 Ersue, Mehmet (NSN - DE/Munich) <[email-masked]<mailto:[email-masked]>>
Hi Dan,

Cheers,
Mehmet

> From: OPSAWG [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Romascanu, Dan
> (Dan)
> To: Warren Kumari; [email-masked]<mailto:[email-masked]>
> I do not know if I really should be included in the reviewers count, as I am a participant
> in the coman work since it started, and my name shows up on the list of authors,
> although in all sincerity most of the credits go to Mehmet, who hold the pen for most
> of the time, including this latest wound which split the original document into two
> separate documents - one for use cases, the other for problem statement and
> requirements. Anyway, FWIW I obviously believe this work is useful and I support
> 1. I do not believe that we can get away with a zero-content security considerations
> section. The described use cases mention the need to secure information collected by
> constrained devices, some other (like security cameras) carry information related to
> personal or public security that needs to be protected by robust mechanisms. These

You are right a dummy security considerations section is not sufficient.
Coman was not planning to address security exhaustively. Solace, now ACE, has
been started where security for constrained devices will be discussed.
We discussed the security requirements in section 3.6 of the problem statement draft.

I agree, a discussion of the security threads should be provided in a security considerations section.

> 1. The draft uses the 'adjective' small device in association with constrained device in a
> few place. I suggest to remove this. There is no automatic association of a device
> being small implying that it is also constrained. Nor are all constrained devices small in
> size.

> 2. We have made an effort in the last few versions and especially in this one to
> distinguish between the constrained devices and constrained networks, but the clean-up
> on this issue is not complete. For example section 1.6 still has text about constrained
> networks - this section and other in which constrained networks are mentioned should
> be carefully examined to make sure that the focus of the document stays with
> constrained devices, and that if constrained networks are mentioned at all this is in the

Why strictly devices? We also have requirements discussing the organization of constrained networks from management pov. in section 3.1.

> 3. I do not believe that we can get away with a zero-content security considerations
> This is not accurate - section 3.6 already speaks about requirments for security and
> access control, and section 1.6 mentions limitations that would prevent the
> implementation of strong scryptographic algorythms. The text needs to be reviewed

I think the "future" is now and the current text in the security considerations section needs to be replaced. I would suggest to provide a security considerations section by listing and discussing threads in the problem statement draft and refer to it from the use cases draft.
Comments?

> > From: OPSAWG [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Warren Kumari
> > To: [email-masked]<mailto:[email-masked]>
> > are here: http://tools.ietf.org/agenda/88/slides/slides-88-opsawg-11.pdf
> >
> > Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> indicated
> > that one of his Ph.D. students had read the draft a couple of weeks ago.
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg

---

From: James Nguyen <[email-masked]>
Date: Wed, 15 Jan 2014 16:47:17 -0500

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.

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

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

Hope this helps.

James

On Mon, Jan 6, 2014 at 1:56 PM, Ersue, Mehmet (NSN - DE/Munich) <
[email-masked]> wrote:

> I would need your help for this as I’m not involved in oneM2M. Thanks.
>
>
>
> Cheers,
> Mehmet
>
>
>
> *From:* OPSAWG [mailto:[email-masked]] *On Behalf Of *ext Hui
> Deng
> *Sent:* Monday, January 06, 2014 8:49 AM
> *To:* [email-masked]
> *Subject:* [OPSAWG] Comments on draft-opsawg-ersue-coman-probstate-reqs
>
>
>
> Hi Authors,
>
>
>

-- 
James Nguyen
Email: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Jan 2014 08:37:34 +0100

>      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?
 
>      Stateless configuration update solution would also work well for

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?

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

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

---

From: James Nguyen <[email-masked]>
Date: Thu, 16 Jan 2014 09:38:30 -0500

Sent from my iPad

>> On Jan 16, 2014, at 2:37 AM, Juergen Schoenwaelder <[email-masked]> wrote:
>>

It's clear to me now.  Thx.

> do successfully use reliable multicast to configure constrained

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"

I meant stateless configuration management.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Jan 2014 16:29:13 +0100

> configurations) to prevent these radios/comms devices to fall in

Luckily, I am not familiar with any of this. But my concern remains
and in such scenarios, I would have serious trouble to define what
'reliable' means given that the group membership is open ended.

> I meant stateless configuration management.

And that means what to you? What is 'stateless'?

/js

---

From: James Nguyen <[email-masked]>
Date: Thu, 16 Jan 2014 10:50:34 -0500

> 'reliable' means given that the group membership is open ended.

I see that Req-ID 4.10.003 is about best-effort multicast.  Would
"best-effort" be good enough instead of reliable?  We can assume that
developers have an option of how to implement.

> And that means what to you? What is 'stateless'?
Let's take NETCONF as an example of stateful management protocol that
requires many message exchanges.  This might be inefficient in constrained
networks.  A less chatty management protocol fits better in this case.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Jan 2014 08:39:11 -0800

Hi,

> And that means what to you? What is 'stateless'?

Perhaps state-less means 1 session-less request/response
pair instead of establishing a session, performing a sequence of
request/response pairs, and then closing the session.

> /js
Andy

---

From: James Nguyen <[email-masked]>
Date: Thu, 16 Jan 2014 12:29:19 -0500

> request/response pairs, and then closing the session.

+1