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