Skip to main content

IEEE 802.15.4 Information Element for the IETF
draft-kivinen-802-15-ie-06

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 IESG member
Yes
Yes (for -05) Unknown

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection () Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2017-02-28 for -05) Unknown
= 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 IESG member
No Objection
No Objection (2017-03-01) Unknown
I agree with Stephan's comment.
Deborah Brungard Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection () Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2017-03-01) Unknown
I agree with Stephen's comment.
Mirja K├╝hlewind Former IESG member
No Objection
No Objection (2017-02-27 for -05) Unknown
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 IESG member
No Objection
No Objection (for -05) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2017-02-27 for -05) Unknown
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 IESG member
No Objection
No Objection () Unknown