Skip to main content

IEEE 802.15.4 Information Element for the IETF
RFC 8137

Yes

(Suresh Krishnan)

No Objection

(Alexey Melnikov)
(Alia Atlas)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Spencer Dawkins)
(Terry Manderson)

Note: This ballot was opened for revision 05 and is now closed.

(Suresh Krishnan; former steering group member) Yes

Yes (for -05)

                            

(Alexey Melnikov; former steering group member) No Objection

No Objection (for -05)

                            

(Alia Atlas; former steering group member) No Objection

No Objection ()

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (2017-02-28 for -05)
= Section 1 =

"IEEE Std 802.15.4 [IEEE-802-15-4] is a standard, referred to by RFC
   4944 ([RFC4944]), et al, that enables very low-cost, low-power
   communications."

Does "et al refer" to all the documents that update RFC 4944? Would probably be better to list them explicitly, the current text is ambiguous.

(Ben Campbell; former steering group member) No Objection

No Objection (2017-03-01)
I agree with Stephan's comment.

(Deborah Brungard; former steering group member) No Objection

No Objection (for -05)

                            

(Jari Arkko; former steering group member) No Objection

No Objection ()

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection ()

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2017-03-01)
I agree with Stephen's comment.

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2017-02-27 for -05)
I guess the name of the new registry could be chosen more meaningful, maybe IEEE Std 802.15.4 IETF IE subtype IDs...?

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -05)

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2017-02-27 for -05)
Section 6 correctly says that  all IETF IE
subtypes need to be handled identically wrt 
confidentiality. Doesn't that imply that we ought be
conservative and encourage encryption of this IE
whenever it is used? While I don't think that'd
approach a MUST level requirement (and if we tried
we'd likely be ignored;-) I wonder if there are any
known or planned IETF IE subtypes for which we would
argue for a "SHOULD encrypt" statement?  If there
are, then I think that'd argue that we ought also
include that SHOULD here as well. If there are not,
then fair enough that 2119 language is probably not
appropriate (though generic encouragement to encrypt
would I think still be right)

(Terry Manderson; former steering group member) No Objection

No Objection ()