Skip to main content

Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control
draft-ietf-roll-applicability-home-building-12

Revision differences

Document history

Date Rev. By Action
2015-12-14
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-12-10
12 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-12-02
12 (System) RFC Editor state changed to RFC-EDITOR from AUTH
2015-11-20
12 (System) RFC Editor state changed to AUTH from EDIT
2015-10-27
12 (System) RFC Editor state changed to EDIT from REF
2015-10-14
12 Alvaro Retana Notification list changed to aretana@cisco.com
2015-10-14
12 (System) Notify list changed from roll-chairs@ietf.org, draft-ietf-roll-applicability-home-building.ad@ietf.org, draft-ietf-roll-applicability-home-building@ietf.org, yvonneanne.pignolet@gmail.com, draft-ietf-roll-applicability-home-building.shepherd@ietf.org to (None)
2015-09-09
12 (System) RFC Editor state changed to REF from EDIT
2015-08-05
12 (System) RFC Editor state changed to EDIT
2015-08-05
12 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-08-05
12 (System) Announcement was received by RFC Editor
2015-08-04
12 (System) IANA Action state changed to No IC from In Progress
2015-08-04
12 (System) IANA Action state changed to In Progress
2015-08-04
12 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2015-08-04
12 Cindy Morgan IESG has approved the document
2015-08-04
12 Cindy Morgan Closed "Approve" ballot
2015-08-04
12 Cindy Morgan Ballot approval text was generated
2015-08-04
12 Cindy Morgan Ballot writeup was changed
2015-08-04
12 Alvaro Retana IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2015-07-25
12 Stephen Farrell
[Ballot comment]

Thanks for the discussion about security. I didn't check
if the comments below were handled in -12, happy to
chat about that if …
[Ballot comment]

Thanks for the discussion about security. I didn't check
if the comments below were handled in -12, happy to
chat about that if you want.

First two comments are about text that's new in -11:

- 4.1.8: "MUST be present" is ambiguous - do you mean
it must be used? I think you do.

- 4.1.8: "MUST be distributed or established in a
secure fashion" isn't really a protocol requirement.
Do you really just mean "see 4.1.8.1" ?


OLD COMMENTS FOR -10 below, I didn't check if you'd made
any related changes.

- I don't get how there's an IPR disclosure for this, but
whatever.

- The non-security parts of this were quite a good read.

- 4.1.8: 1st sentence makes no sense. It says RPL does X or
not-X in order to Y. There is no choice but for RPL to do X or
not-X.

- 4.1.8 seems to me to imply that link layer security is
always needed since there can always be some node that will
send an unsecured RPL messsage. If you agree, then I think
that should be made more clear. If you disagree, I'd like to
understand how.

- 4.1.8, I am surprised not to see a recommendation that
separate group keys SHOULD be used for different applications
in the same bulding network. But that may be too fine grained
a recommendation for this document perhaps.

- 5.1.2.1, I think it'd be clearer to say Imin should be
between 10 and 50 ms. The "10 - 50 ms" notation can be
confusing. (Same elsewhere.)

- section 7, 3rd para, "can rely on" is sales language, please
strike that or s/rely on/depend upon/

- section 7, 3rd para, last sentence: this is sales language
and should be deleted. Or perhaps s/is/SHOULD be/ would turn
it back into a piece of specification language.

- 7.1 - this is odd text to see in a proposed standard, but I
think it's accurately describing the level of interop to
expect in RPL security, so is probably the right thing to say.
I'd argue that it'd be even better to bluntly admit/say that
there is currently no interoperable automated key management
for RPL. (Same for 7.3) Or, and better, to fix that lack. (See
my discuss point.)

- 7.2, 1st sentence: this is meaningless as I read it - what
are you trying to say?

- 7.2, when a node is stolen, the chances are that any keys
contained in the node are at significant risk of being leaked.

- 7.3, I do not believe that [I-D.keoh-dice-multicast-security]
is necessarily going to proceed via the DICE WG. Depending
on it would be fairly high-risk in any case.

- 7.4, last sentence: more sales talk

- 7.5, what is this specifying? I don't get it. Does 7416 set
out what to implement to get interop? (I didn't think so, but
nor does this seem to.)
2015-07-25
12 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2015-07-21
12 Peter Van der Stok New version available: draft-ietf-roll-applicability-home-building-12.txt
2015-07-13
11 Stephen Farrell
[Ballot discuss]

Thanks for the discussion so far and for the changes to
the document. I think (modulo comments) we're mostly
done with the blocking …
[Ballot discuss]

Thanks for the discussion so far and for the changes to
the document. I think (modulo comments) we're mostly
done with the blocking discuss stuff but I do two more
question at that level.

1) This could be my ignorance of zigbee, but how can we
use layer 2 security for only some network nodes?  (In
other words, I don't see how 4.1.8.2 works.)

2) Just checking - this depends on the zigbeeip
authentication mechanism, with which I'm also not
familiar, sorry. Does using that mean that this entire
applicability statement only covers use of RPL where
zigbee radios are in use? Or can that authentication
scheme be used independently of the radio technology
used? (I mean used in practice there, not in theory.)
2015-07-13
11 Stephen Farrell
[Ballot comment]

First two comments are about text that's new in -11:

- 4.1.8: "MUST be present" is ambiguous - do you mean
it must …
[Ballot comment]

First two comments are about text that's new in -11:

- 4.1.8: "MUST be present" is ambiguous - do you mean
it must be used? I think you do.

- 4.1.8: "MUST be distributed or established in a
secure fashion" isn't really a protocol requirement.
Do you really just mean "see 4.1.8.1" ?


OLD COMMENTS FOR -10 below, I didn't check if you'd made
any related changes.

- I don't get how there's an IPR disclosure for this, but
whatever.

- The non-security parts of this were quite a good read.

- 4.1.8: 1st sentence makes no sense. It says RPL does X or
not-X in order to Y. There is no choice but for RPL to do X or
not-X.

- 4.1.8 seems to me to imply that link layer security is
always needed since there can always be some node that will
send an unsecured RPL messsage. If you agree, then I think
that should be made more clear. If you disagree, I'd like to
understand how.

- 4.1.8, I am surprised not to see a recommendation that
separate group keys SHOULD be used for different applications
in the same bulding network. But that may be too fine grained
a recommendation for this document perhaps.

- 5.1.2.1, I think it'd be clearer to say Imin should be
between 10 and 50 ms. The "10 - 50 ms" notation can be
confusing. (Same elsewhere.)

- section 7, 3rd para, "can rely on" is sales language, please
strike that or s/rely on/depend upon/

- section 7, 3rd para, last sentence: this is sales language
and should be deleted. Or perhaps s/is/SHOULD be/ would turn
it back into a piece of specification language.

- 7.1 - this is odd text to see in a proposed standard, but I
think it's accurately describing the level of interop to
expect in RPL security, so is probably the right thing to say.
I'd argue that it'd be even better to bluntly admit/say that
there is currently no interoperable automated key management
for RPL. (Same for 7.3) Or, and better, to fix that lack. (See
my discuss point.)

- 7.2, 1st sentence: this is meaningless as I read it - what
are you trying to say?

- 7.2, when a node is stolen, the chances are that any keys
contained in the node are at significant risk of being leaked.

- 7.3, I do not believe that [I-D.keoh-dice-multicast-security]
is necessarily going to proceed via the DICE WG. Depending
on it would be fairly high-risk in any case.

- 7.4, last sentence: more sales talk

- 7.5, what is this specifying? I don't get it. Does 7416 set
out what to implement to get interop? (I didn't think so, but
nor does this seem to.)
2015-07-13
11 Stephen Farrell Ballot comment and discuss text updated for Stephen Farrell
2015-07-02
11 Peter Van der Stok New version available: draft-ietf-roll-applicability-home-building-11.txt
2015-05-17
10 Stephen Farrell
[Ballot discuss]
(Responded to latest version maintaining discuss.)

Please correct me if I'm getting this wrong, I honestly may
have forgotten the plan. My understanding …
[Ballot discuss]
(Responded to latest version maintaining discuss.)

Please correct me if I'm getting this wrong, I honestly may
have forgotten the plan. My understanding was that RPL and RFC
7416
etc. were approved on the basis that you needed to get to
specific applications of RPL before you could sensibly specify
interoperable security with automated key management (AKM) as
is clearly required by BCP107 and as has been discussed
between security ADs and the ROLL WG numerous times. This is
going back to the 2010 discuss from Tim Polk that I inherited
in 2011, hence me being uncertain if I remember the plan for
sure;-) In any case it seems to me that this draft also
doesn't get us to the point where we have a defined way to do
AKM (Again, sigh.) I also have a set of comments on that below
that I won't make into specific discuss points (at least until
we figure out or re-discover the plan).

So, with that context, and with real regrets for sounding like
an old and broken record, the discuss point: why is this not
the ROLL WG draft where we finally get to specify AKM for RPL?
If your answer is that this is just an applicablilty statement
then I'll ask why it's going for proposed standard, and when
to finally expect the AKM spec for RPL (for this application).
2015-05-17
10 Stephen Farrell Ballot discuss text updated for Stephen Farrell
2015-04-26
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-04-26
10 Peter Van der Stok IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2015-04-26
10 Peter Van der Stok New version available: draft-ietf-roll-applicability-home-building-10.txt
2015-04-19
09 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2015-04-16
09 Meral Shirazipour Request for Telechat review by GENART Completed: Ready. Reviewer: Meral Shirazipour.
2015-04-09
09 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2015-04-09
09 Tero Kivinen Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Catherine Meadows.
2015-04-09
09 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2015-04-09
09 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2015-04-08
09 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2015-04-08
09 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2015-04-08
09 Stephen Farrell
[Ballot discuss]

Please correct me if I'm getting this wrong, I honestly may
have forgotten the plan. My understanding was that RPL and RFC
7416 …
[Ballot discuss]

Please correct me if I'm getting this wrong, I honestly may
have forgotten the plan. My understanding was that RPL and RFC
7416
etc. were approved on the basis that you needed to get to
specific applications of RPL before you could sensibly specify
interoperable security with automated key management (AKM) as
is clearly required by BCP107 and as has been discussed
between security ADs and the ROLL WG numerous times. This is
going back to the 2010 discuss from Tim Polk that I inherited
in 2011, hence me being uncertain if I remember the plan for
sure;-) In any case it seems to me that this draft also
doesn't get us to the point where we have a defined way to do
AKM (Again, sigh.) I also have a set of comments on that below
that I won't make into specific discuss points (at least until
we figure out or re-discover the plan).

So, with that context, and with real regrets for sounding like
an old and broken record, the discuss point: why is this not
the ROLL WG draft where we finally get to specify AKM for RPL?
If your answer is that this is just an applicablilty statement
then I'll ask why it's going for proposed standard, and when
to finally expect the AKM spec for RPL (for this application).
2015-04-08
09 Stephen Farrell
[Ballot comment]

- I don't get how there's an IPR disclosure for this, but
whatever.

- The non-security parts of this were quite a good …
[Ballot comment]

- I don't get how there's an IPR disclosure for this, but
whatever.

- The non-security parts of this were quite a good read.

- 4.1.8: 1st sentence makes no sense. It says RPL does X or
not-X in order to Y. There is no choice but for RPL to do X or
not-X.

- 4.1.8 seems to me to imply that link layer security is
always needed since there can always be some node that will
send an unsecured RPL messsage. If you agree, then I think
that should be made more clear. If you disagree, I'd like to
understand how.

- 4.1.8, I am surprised not to see a recommendation that
separate group keys SHOULD be used for different applications
in the same bulding network. But that may be too fine grained
a recommendation for this document perhaps.

- 5.1.2.1, I think it'd be clearer to say Imin should be
between 10 and 50 ms. The "10 - 50 ms" notation can be
confusing. (Same elsewhere.)

- section 7, 3rd para, "can rely on" is sales language, please
strike that or s/rely on/depend upon/

- section 7, 3rd para, last sentence: this is sales language
and should be deleted. Or perhaps s/is/SHOULD be/ would turn
it back into a piece of specification language.

- 7.1 - this is odd text to see in a proposed standard, but I
think it's accurately describing the level of interop to
expect in RPL security, so is probably the right thing to say.
I'd argue that it'd be even better to bluntly admit/say that
there is currently no interoperable automated key management
for RPL. (Same for 7.3) Or, and better, to fix that lack. (See
my discuss point.)

- 7.2, 1st sentence: this is meaningless as I read it - what
are you trying to say?

- 7.2, when a node is stolen, the chances are that any keys
contained in the node are at significant risk of being leaked.

- 7.3, I do not believe that [I-D.keoh-dice-multicast-security]
is necessarily going to proceed via the DICE WG. Depending
on it would be fairly high-risk in any case.

- 7.4, last sentence: more sales talk

- 7.5, what is this specifying? I don't get it. Does 7416 set
out what to implement to get interop? (I didn't think so, but
nor does this seem to.)
2015-04-08
09 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2015-04-08
09 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2015-04-08
09 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2015-04-07
09 Barry Leiba [Ballot comment]
I like this document a lot; thanks for the work on it.
2015-04-07
09 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2015-04-07
09 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2015-04-06
09 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2015-04-06
09 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2015-04-06
09 Kathleen Moriarty
[Ballot comment]
The draft looks good, thank you for your work on it.  I see privacy isn't mentioned, but think that's okay as I can't …
[Ballot comment]
The draft looks good, thank you for your work on it.  I see privacy isn't mentioned, but think that's okay as I can't think of a scenario where privacy isn't covered by the security already provided (through confidentiality protections) since the scope is within a network - home or office.  I'm just mentioning this here in case someone else does think of a scenario that may be necessary to note in the draft.

The SecDir review had some requests for clarification in the text.  In my read, I understood what was intended, but in seeing her questions, I think it would be good to consider rewording the text she points out so it is clear to all readers.  This is non-blocking and just something to consider as I understood the intent of the current text, but that doesn't mean it can't be improved :-)

http://www.ietf.org/mail-archive/web/secdir/current/msg05589.html
2015-04-06
09 Kathleen Moriarty Ballot comment text updated for Kathleen Moriarty
2015-04-06
09 Kathleen Moriarty
[Ballot comment]
The draft looks good, thank you for your work on it.  I see privacy isn't mentioned, but think that's okay as I can't …
[Ballot comment]
The draft looks good, thank you for your work on it.  I see privacy isn't mentioned, but think that's okay as I can't think of a scenario where privacy isn't covered by the security already provided (through confidentiality protections) since the scope is within a network - home or office.  I'm just mentioning this here in case someone else does think of a scenario that may be necessary to note in the draft.
2015-04-06
09 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2015-04-02
09 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2015-04-02
09 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2015-03-30
09 Meral Shirazipour Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour.
2015-03-30
09 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2015-03-30
09 Alvaro Retana Ballot writeup was changed
2015-03-30
09 Alvaro Retana Ballot approval text was changed
2015-03-26
09 Tero Kivinen Request for Telechat review by SECDIR is assigned to Catherine Meadows
2015-03-26
09 Tero Kivinen Request for Telechat review by SECDIR is assigned to Catherine Meadows
2015-03-26
09 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2015-03-25
09 Amy Vezza Shepherding AD changed to Alvaro Retana
2015-03-25
09 Adrian Farrel IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2015-03-25
09 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Record from Yes
2015-03-25
09 Adrian Farrel Ballot has been issued
2015-03-25
09 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2015-03-25
09 Adrian Farrel Created "Approve" ballot
2015-03-25
09 Adrian Farrel Placed on agenda for telechat - 2015-04-09
2015-03-25
09 Adrian Farrel Changed consensus to Yes from Unknown
2015-03-25
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-03-25
09 Peter Van der Stok IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2015-03-25
09 Peter Van der Stok New version available: draft-ietf-roll-applicability-home-building-09.txt
2015-03-23
08 Adrian Farrel Just need to pick up some minor GenArt review points.
2015-03-23
08 Adrian Farrel IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2015-03-23
08 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2015-03-18
08 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2015-03-18
08 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-roll-applicability-home-building-08, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-roll-applicability-home-building-08, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.
2015-03-12
08 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2015-03-12
08 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2015-03-11
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2015-03-11
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2015-03-09
08 Amy Vezza IANA Review state changed to IANA - Review Needed
2015-03-09
08 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Applicability Statement: The use of …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Applicability Statement: The use of the RPL protocol suite in Home Automation and Building Control) to Proposed Standard

The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document:
- 'Applicability Statement: The use of the RPL protocol suite in Home
  Automation and Building Control'
  as Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-03-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  The purpose of this document is to provide guidance in the selection
  and use of protocols from the RPL protocol suite to implement the
  features required for control in building and home environments.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/ballot/


The following IPR Declarations may be related to this I-D:
  http://datatracker.ietf.org/ipr/2413/

This document makes the following downward references (downrefs):
  ** Downref: Normative reference to an Experimental RFC: RFC 4764
  ** Downref: Normative reference to an Informational RFC: RFC 5548
  ** Downref: Normative reference to an Informational RFC: RFC 5673
  ** Downref: Normative reference to an Informational RFC: RFC 5826
  ** Downref: Normative reference to an Informational RFC: RFC 5867
  ** Downref: Normative reference to an Experimental RFC: RFC 6997
  ** Downref: Normative reference to an Experimental RFC: RFC 6998
  ** Downref: Normative reference to an Informational RFC: RFC 7102
  ** Downref: Normative reference to an Informational RFC: RFC 7416
2015-03-09
08 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2015-03-09
08 Adrian Farrel Last call was requested
2015-03-09
08 Adrian Farrel Ballot approval text was generated
2015-03-09
08 Adrian Farrel IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2015-03-09
08 Adrian Farrel Last call announcement was changed
2015-03-09
08 Adrian Farrel Last call announcement was generated
2015-03-09
08 Adrian Farrel Ballot writeup was changed
2015-03-09
08 Adrian Farrel
1. Summary

Yvonne-Anne Pignolet is the document shepherd. Adrian Farrel is the responsible
Area Director.

This document provides guidance in the selection and use of …
1. Summary

Yvonne-Anne Pignolet is the document shepherd. Adrian Farrel is the responsible
Area Director.

This document provides guidance in the selection and use of protocols from the RPL
protocol suite to implement the features required for control in building and home
environments.

The requested publication type is Proposed Standard as it is an "Applicability
Statement" as defined in RFC 2026.
 
2. Review and Consensus

There has not been much discussion on the working group mailing list about this
document. Apart from a review by the shepherd, a review with a focus on security has
been carried out. In both cases the authors amended the document to the reviewers'
satisfaction.

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79. There are no IPR
disclosures on the document. Philips filed IPR statement #2413, related to an unpublished pending patent application. The authors guessed that it might be related
to the "real-time layer" that is mentioned as part of making MPL perform with lower
latency. This issue was not discussed further within the working group.

4. Other Points

There is a long list of downrefs caused by this AS being positioned as PS. These
are shown by idnits and need to be flagged in IETF last call.

  ** Downref: Normative reference to an Experimental RFC: RFC 4764
  ** Downref: Normative reference to an Informational RFC: RFC 5548
  ** Downref: Normative reference to an Informational RFC: RFC 5673
  ** Downref: Normative reference to an Informational RFC: RFC 5826
  ** Downref: Normative reference to an Informational RFC: RFC 5867
  ** Downref: Normative reference to an Experimental RFC: RFC 6997
  ** Downref: Normative reference to an Experimental RFC: RFC 6998
  ** Downref: Normative reference to an Informational RFC: RFC 7102
  ** Downref: Normative reference to an Informational RFC: RFC 7416

There is one outdated reference pointed out by id-nits: draft-ietf-6lo-lowpanz has been published as RFC 7428
2015-03-09
08 Adrian Farrel Last call announcement was generated
2015-03-09
08 Adrian Farrel Ballot writeup was changed
2015-03-09
08 Adrian Farrel Ballot writeup was changed
2015-03-09
08 Adrian Farrel Ballot writeup was changed
2015-03-09
08 Adrian Farrel
1. Summary

Yvonne-Anne Pignolet is the document shepherd. Adrian Farrel is the responsible
Area Director.

This document provides guidance in the selection and use of …
1. Summary

Yvonne-Anne Pignolet is the document shepherd. Adrian Farrel is the responsible
Area Director.

This document provides guidance in the selection and use of protocols from the RPL
protocol suite to implement the features required for control in building and home
environments.

The requested publication type is Proposed Standard as it is an "Applicability
Statement" as defined in RFC 2026.
 
2. Review and Consensus

There has not been much discussion on the working group mailing list about this
document. Apart from a review by the shepherd, a review with a focus on security has
been carried out. In both cases the authors amended the document to the reviewers'
satisfaction.

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79. There are no IPR
disclosures on the document. Philips filed IPR statement #2413, related to an unpublished pending patent application. The authors guessed that it might be related
to the "real-time layer" that is mentioned as part of making MPL perform with lower
latency. This issue was not discussed further within the working group.

4. Other Points

There are two normative downrefs to I-D.ietf-roll-trickle-mcast-11 (work in progress),
November 2014 and I-D.ietf-roll-security-threats-11 (work in progress), October 2014.
There is one outdated reference: draft-ietf-core-groupcomm has been published as
RFC 7390
2015-03-09
08 Adrian Farrel Ballot writeup was changed
2015-03-09
08 Adrian Farrel Ballot writeup was generated
2015-03-09
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-03-09
08 Peter Van der Stok New version available: draft-ietf-roll-applicability-home-building-08.txt
2015-03-05
07 Ines Robles Was decided move this document onto the Standards Track in accordance with the description of an Applicability Statement in Section 3.2 of RFC 2026.
2015-03-05
07 Ines Robles Intended Status changed to Proposed Standard from Informational
2015-03-05
07 Yvonne-Anne Pignolet
1. Summary

Yvonne-Anne Pignolet is the document shepherd. Adrian Farrel is the responsible Area Director.

This document provides guidance in the selection and use of …
1. Summary

Yvonne-Anne Pignolet is the document shepherd. Adrian Farrel is the responsible Area Director.

This document provides guidance in the selection and use of protocols from the RPL protocol suite to implement the features required for control in building and home environments.

The requested publication type is Proposed Standard.
 
2. Review and Consensus

There has not been much discussion on the working group mailing list about this document. Apart from a review by the shepherd, a review with a focus on security has been carried out. In both cases the authors amended the document to the reviewers' satisfaction.

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document. Philips filed IPR statement #2413, related to an unpublished pending patent application. The authors guessed that it might be related to the "real-time layer" that is mentioned as part of making MPL perform with lower latency. This issue was not discussed further within the working group.

4. Other Points

There are two normative downrefs to I-D.ietf-roll-trickle-mcast-11 (work in progress), November 2014 and I-D.ietf-roll-security-threats-11 (work in progress), October 2014. There is one outdated reference: draft-ietf-core-groupcomm has been published as RFC 7390
2015-03-04
07 Adrian Farrel
AD review
=====

Thanks for this really nice document. I found it an easy read.

I have done my usual AD review to catch issues …
AD review
=====

Thanks for this really nice document. I found it an easy read.

I have done my usual AD review to catch issues before IETF last call and
IESG evaluation.

I only have a handful of small issues, but I think it would be worth
resolving them with a new revision before we go to last call. I have
marked the datatracker to show "Revised I-D needed" and I'll wait to
see you post a new version.

Thanks for the work,
Adrian

===

The chairs and I have discussed moving this document onto the Standards
Track in accordance with the description of an Applicability Statement in
Section 32 of RFC 2026. The only thing you need to do is update the
"Intended status" to say "Proposed Standard".

The Shepherd will also need to update the write-up and flip the field in
the datatracker.

---

In 1.1. you have

  The ROLL working group has specified a set of routing protocols for
  Lossy and Low- resource Networks (LLN) [RFC6550]

Yet 6550 defines

  Low-Power and Lossy Networks (LLNs)

---

Section 1.2 seems to only be necessary for a use of "MUST" in section
7. I am comfortable with you having used normal case ("must", "should",
"recommended") in the text. Could Section 7 also drop this to "must"
and then you could remove Section 1.2?

---

2.2.7 mentions AODV without expanding the abbreviation and without a
reference.

---

A few abbreviations need to be expanded on first use:
DIO
DAG
MPL
DAO
RA
ULA
DODAG
ETX

---

4.1.7 has...

  Repetition of the message can be inhibited by a small
  value of k.

I think this is lacking a little context. What is k?

---

Please mark Section 11 "To be deleted by the RFC Editor before
publication."
2015-03-04
07 Adrian Farrel IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2015-02-23
07 Adrian Farrel IESG state changed to AD Evaluation from Publication Requested
2015-02-12
07 Ines Robles
1. Summary

Yvonne-Anne Pignolet is the document shepherd. Adrian Farrel is the responsible Area Director.

This document provides guidance in the selection and use of …
1. Summary

Yvonne-Anne Pignolet is the document shepherd. Adrian Farrel is the responsible Area Director.

This document provides guidance in the selection and use of protocols from the RPL protocol suite to implement the features required for control in building and home environments.

The requested publication type is Informational.
 
2. Review and Consensus

There has not been much discussion on the working group mailing list about this document. Apart from a review by the shepherd there a review with a focus on security has been carried out. In both cases the authors amended the document to the reviewers' satisfaction.

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document. Philips filed IPR statement #2413, related to an unpublished pending patent application. The authors guessed that it might be related to the "real-time layer" that is mentioned as part of making MPL perform with lower latency. This issue was not discussed further within the working group.

4. Other Points

There are two normative downrefs to I-D.ietf-roll-trickle-mcast-11 (work in progress), November 2014 and I-D.ietf-roll-security-threats-11 (work in progress), October 2014. There is one outdated reference: draft-ietf-core-groupcomm has been published as RFC 7390
2015-02-12
07 Ines Robles State Change Notice email list changed to roll-chairs@ietf.org, roll@ietf.org, draft-ietf-roll-applicability-home-building.ad@ietf.org, draft-ietf-roll-applicability-home-building@ietf.org, yvonneanne.pignolet@gmail.com, draft-ietf-roll-applicability-home-building.shepherd@ietf.org
2015-02-12
07 Ines Robles Responsible AD changed to Adrian Farrel
2015-02-12
07 Ines Robles IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2015-02-12
07 Ines Robles IESG state changed to Publication Requested
2015-02-12
07 Ines Robles IESG process started in state Publication Requested
2015-02-12
07 Ines Robles Intended Status changed to Informational from None
2015-01-19
07 Peter Van der Stok New version available: draft-ietf-roll-applicability-home-building-07.txt
2014-12-12
06 Yvonne-Anne Pignolet Changed document writeup
2014-12-01
06 Peter Van der Stok New version available: draft-ietf-roll-applicability-home-building-06.txt
2014-10-14
05 Ines Robles IETF WG state changed to In WG Last Call from WG Document
2014-10-06
05 Peter Van der Stok New version available: draft-ietf-roll-applicability-home-building-05.txt
2014-06-30
04 Peter Van der Stok New version available: draft-ietf-roll-applicability-home-building-04.txt
2014-05-13
(System) Posted related IPR disclosure: Philips' Statement of IPR related to draft-ietf-roll-applicability-home-building-03
2014-05-12
03 Peter Van der Stok New version available: draft-ietf-roll-applicability-home-building-03.txt
2014-02-13
02 Peter Van der Stok New version available: draft-ietf-roll-applicability-home-building-02.txt
2014-01-10
01 Ines Robles Document shepherd changed to yvonne-anne pignolet
2013-12-12
01 Tero Kivinen Request for Early review by SECDIR Completed: Has Issues. Reviewer: Catherine Meadows.
2013-11-28
01 Tero Kivinen Request for Early review by SECDIR is assigned to Catherine Meadows
2013-11-28
01 Tero Kivinen Request for Early review by SECDIR is assigned to Catherine Meadows
2013-08-17
01 Peter Van der Stok New version available: draft-ietf-roll-applicability-home-building-01.txt
2013-05-13
00 Anders Brandt New version available: draft-ietf-roll-applicability-home-building-00.txt