Source Packet Routing in Networking
charter-ietf-spring-02
Yes
(Adrian Farrel)
(Jari Arkko)
(Stewart Bryant)
No Objection
(Gonzalo Camarillo)
(Pete Resnick)
Abstain
(Brian Haberman)
No Record
Note: This ballot was opened for revision 00-16 and is now closed.
Ballot question: "Do we approve of this charter?"
Adrian Farrel Former IESG member
Yes
Yes
(for -00-17)
Unknown
Jari Arkko Former IESG member
Yes
Yes
(for -00-17)
Unknown
Stewart Bryant Former IESG member
Yes
Yes
(for -00-16)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2013-10-23 for -00-17)
Unknown
No objection to the charter text. It's not clear, though, what the milestones are specifying. For the documents, I presume it's the end of the process (publication requested). For some of the milestones, though, is it possible to meet them with a working group consensus that does not turn into a document?
Benoît Claise Former IESG member
No Objection
No Objection
(2013-10-24 for -00-17)
Unknown
OLD: In the context of this charter, 'source' means 'the point at which the explicit route is imposed. NEW: In the context of this charter, 'source' means 'the point at which the explicit route is imposed'. OLD: filtering, cryptographic NEW filtering, cryptographic OLD: The SPRING WG should provide OAM and the management needed to manage SPRING enabled networks. NEW: The SPRING WG should provide OAM and the management needed to manage SPRING enabled networks. - Some alignment issues with the Milestones We might consider the comments above as trivial, but when I see alignment issues in the charter pages, and the charters are in THE contracts between the IESG and the WGs, I have the feeling that this doesn't look too professional. Mea culpea: it even happens in one of my OPS charters, even if I tried hard to fix all issues.
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -00-17)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -00-17)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(2013-10-23 for -00-17)
Unknown
I agree with Sean's security concerns, especially given that security problems in the routing domain have often proven tricky to solve -- and even harder to solve post-hoc.
Sean Turner Former IESG member
No Objection
No Objection
(2013-10-23 for -00-17)
Unknown
Not blocking but I'm curious whether the security analysis has to be done before they get to bring the protocol to the IESG? I'd hate to follow the normal path which is yeah yeah we'll do security, but we'll probably get distracted by this cool protocol work, and then loose energy and just pass the protocol to the IESG.
Stephen Farrell Former IESG member
No Objection
No Objection
(2013-10-24 for -00-17)
Unknown
- I agree with Sean's comment (of course:-) - "These applications" in the para after the 1st bullet list could maybe be clearer. I guess you mean the "network functions" mentioned before.
Brian Haberman Former IESG member
(was Block)
Abstain
Abstain
(for -00-17)
Unknown
Ted Lemon Former IESG member
Abstain
Abstain
(2013-10-23 for -00-17)
Unknown
I have yet to see a reason given why this is a good idea, but the routing guys seem to want it, and I think the security requirements in the charter are probably adequate, so I'm not going to block it. I share Sean's concerns about security handwaving.
Martin Stiemerling Former IESG member
No Record
No Record
(2013-10-24 for -00-17)
Unknown
I'm also concerned about Sean's issues and wonder if the quoted text implies a show stopper if no secure solution can be found at all: " As a part of its work, the working group will define the new IPv6-based routing header in way that blind attacks are never possible, i.e., attackers will be unable to "