Secure Media Frames
charter-ietf-sframe-01
Yes
No Objection
Erik Kline
Roman Danyliw
(Alissa Cooper)
(Deborah Brungard)
(Magnus Westerlund)
(Martin Duke)
(Robert Wilton)
Note: This ballot was opened for revision 00-02 and is now closed.
Ballot question: "Do we approve of this charter?"
Murray Kucherawy
Yes
Comment
(2020-10-26 for -00-02)
Not sent
Magnus and Erik had some concerns with the charter text that they chose not to BLOCK on, but I'm still looking into how to get them resolved just to be as thorough as possible.
Erik Kline
No Objection
Roman Danyliw
No Objection
Alissa Cooper Former IESG member
No Objection
No Objection
(for -00-02)
Not sent
Alvaro Retana Former IESG member
No Objection
No Objection
(2020-11-04 for -00-02)
Sent
It's not clear to me what exactly this last piece of text means: Input to the WG Proposals already existing relating to this charter proposal: https://datatracker.ietf.org/doc/html/draft-omara-sframe-00 It is just a pointer to existing work? Is it a statement that the WG should use (or maybe will use) this document as the base for discussion? Given that the document was the source of the discussion that led to this WG, I assume it's the latter. Please be clear.
Barry Leiba Former IESG member
No Objection
No Objection
(2020-10-28 for -00-02)
Sent
I wonder whether this should be chartered in the Sec Area with an ART AD (Murray) set as responsible AD.
I also think the last bit:
Input to the WG
Proposals already existing relating to this charter proposal:
https://datatracker.ietf.org/doc/html/draft-omara-sframe-00
...shouldn't be in the final charter text (it was fine to have it there during review). The draft is referenced in the milestone, and that should cover it.
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2020-11-05 for -00-03)
Sent for earlier
This working group, however, will not specify the signaling required to configure SFrame encryption. In particular, considerations related to SIP or SDP are out of scope. This is because SFrame is intended to be applied as an additional layer on top of the base levels of protection that these protocols provide. [...] This text reads like it is saying that SIP and SDP provide "base levels of protection", which is not necessarily the case in the context of the protection that SFrame provides.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -00-02)
Not sent
Magnus Westerlund Former IESG member
No Objection
No Objection
(for -00-02)
Not sent
Martin Duke Former IESG member
No Objection
No Objection
(for -00-02)
Not sent
Robert Wilton Former IESG member
No Objection
No Objection
(for -00-02)
Not sent