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

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

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

---

From: "Cao,Zhen" <[email-masked]>
Date: Mon, 6 Jan 2014 15:39:20 +0800

Dear authors and all,

I read through the two drafts, and believe the two documents are
useful for operators and SPs that manage a constrained device network.
Thank you for the work.

a) http://tools.ietf.org/html/draft-ersue-opsawg-coman-use-cases-00

This draft is pretty sufficient at the time of writing. But i do not
know how to act for new use cases coming up. For example, vehicle
communication networks. There are many use case documents in IETF, but
how sufficient they should be. I believe the issue will be raised up
during IESG review.

b) http://datatracker.ietf.org/doc/draft-ersue-opsawg-coman-probstate-reqs/

This document is also pretty sufficient. The requirement template is
very good practice.

One cent to the document is, shall we consider the management of
sleepy nodes in section 3? There are many discussions in coap/lwig for
these sleepy nodes. The management of these devices is rather
challenging. Although there are some discussion in 'Energy
management', the scope of sleepy nodes management should be broader
than that.

Best regards,
caozhen@chinamobile

On Thu, Dec 5, 2013 at 12:49 AM, Warren Kumari <[email-masked]> wrote:
> 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:
> 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
> --

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 6 Jan 2014 11:04:20 +0000

Hi Mehmet,

One short reply on one of your answers: 

> From: Ersue, Mehmet (NSN - DE/Munich) [mailto:[email-masked]]
> 
> > 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.

[[DR]] hmmm ... the titles of both documents in review start by 'Management of Networks with Constrained Devices'. Is it rather 'Management of Constrained Networks and Networks with Constrained Devices'? 

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Jan 2014 12:19:46 +0100

> [[DR]] hmmm ... the titles of both documents in review start by 'Management of Networks with Constrained Devices'. Is it rather 'Management of Constrained Networks and Networks with Constrained Dev…

Including management of constrained networks expands the scope
considerably. In the past, we preferred to keep the scope narrow,
hence the current title.

/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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 6 Jan 2014 11:21:51 +0000

Hi,

That was my recollection as well. However - see the part of the discussion that you left out - there are still sections that deal with constrained networks in text

Regards,

Dan

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Monday, January 06, 2014 1:20 PM
> To: Romascanu, Dan (Dan)
> Cc: Ersue, Mehmet (NSN - DE/Munich); Warren Kumari; [email-masked]
> > [[DR]] hmmm ... the titles of both documents in review start by
> 'Management of Networks with Constrained Devices'. Is it rather
> 'Management of Constrained Networks and Networks with Constrained
> Devices'?
> >
> 
> considerably. In the past, we preferred to keep the scope narrow, hence
> the current title.
> 
> /js
> 
> --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Jan 2014 12:34:52 +0100

> That was my recollection as well. However - see the part of the discussion that you left out - there are still sections that deal with constrained networks in text

Then either the text needs to go or some of it needs to stay because
sometimes (in some application scenarios) constrained nodes to exist
on constrained networks. In other words, it needs to be looked at on
a case-by-case basis.

/js

---

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

Dear Zhen,

thank you for your kind review. 

We mentioned in-car networks as part of Mobile Applications in section 2.10.
Do you think a separate use case should be added or it can be seen as covered under M2M services?

I agree management of 'sleepy nodes' might become challenging. I will look into that in more detail.
Would you like to contribute some text?

Cheers, 
Mehmet 

> From: OPSAWG [mailto:[email-masked]] On Behalf Of ext Cao,Zhen
> Sent: Monday, January 06, 2014 8:39 AM
> To: Warren Kumari
> Cc: [email-masked]
> > If you are not US based, hopefully you enjoyed the decrease in email volume while
> everyone recovered form eating too much. :-)
> >
> > 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
> > --

---

From: "Sehgal, Anuj" <[email-masked]>
Date: Mon, 6 Jan 2014 18:56:45 +0000

On 06 Jan 2014, at 7:44 pm, Ersue, Mehmet (NSN - DE/Munich) <[email-masked]<mailto:[email-masked]>> wrote:

I believe it would be better to expand the whole in-car networks part into a new section on vehicular networking technologies, since this is a part of emerging networks that will undoubtedly use constrained devices and possibly even constrained networks. Logically, in-car networks should be a sub-class of vehicular networks.

Furthermore, it seems that the whole section on mobile applications is mostly focusing purely on special cases of previous sections, or based on special access technologies. Just this difference does not warrant a whole section, in my opinion. It would seem much better to take the special cases (like in-car networks) and merge them into appropriate sections (maybe new ones, like on vehicular networks) and discuss limitations posed by access technologies separately, especially since access technology based limitations would impact not only constrained but, to a slightly lesser degree, regular networking devices within those networks as well.

Regards,
Anuj Sehgal

---

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

Hi Dan, Juergen,

I agree that we need to keep the document focused on the 'Management of Networks with Constrained Devices'.
The discussion on the networks is because of the management considerations where constrained devices are connected and need to be managed. 
This network can be indeed constrained or non-constrained.

Cheers, 
Mehmet 

> From: ext Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: Monday, January 06, 2014 12:35 PM
> To: Romascanu, Dan (Dan)
> > That was my recollection as well. However - see the part of the discussion that you
> left out - there are still sections that deal with constrained networks in text
> >
>

---

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

I actually don't see a big coverage of Mobile Applications in other use cases. Only the use case Transport Applications is covering the mobility aspect (actually it includes also vehicle networks).

For example use cases like Environmental Monitoring, Industrial Applications, Building Automation etc. use a fixed or wireless network but the devices are mainly non-mobile.

May be the sections on Transport Applications and Mobile Applications could be merged. Though Mobile Applications can have different facets which go beyond transport networks. I think Mobile Applications should be kept separate as they differ from fixed/wireless non-mobile applications.

Cheers,
Mehmet

From: ext Sehgal, Anuj [mailto:[email-masked]]
Sent: Monday, January 06, 2014 7:57 PM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: ext Cao,Zhen; [email-masked]
Subject: Re: [OPSAWG] Call for reviewers of draft-ersue-opsawg-coman-*

Regards,
Anuj Sehgal