RPC: Remote Procedure Call Protocol Specification Version 2
RFC 5531
Yes
Lars Eggert
No Objection
(Chris Newman)
(Dan Romascanu)
(David Ward)
(Jon Peterson)
(Magnus Westerlund)
(Ron Bonica)
(Russ Housley)
(Tim Polk)
Abstain
No Record
(Cullen Jennings)
Note: This ballot was opened for revision 13 and is now closed.
Lars Eggert
(was Discuss, Yes)
Yes
Chris Newman Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2008-12-11)
Unknown
Christian Vogt's review: Document..........: draft-ietf-nfsv4-rfc1831bis-10 Reviewer..........: Christian Vogt Review date.......: December 11, 2008 IESG Telechat date: December 11, 2008 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Document draft-ietf-nfsv4-rfc1831bis-10 is an update of the "Remote Procedure Call Protocol Specification Version 2", RFC 1831. It seeks to promote the RPC protocol to draft standard. The document is overall in good quality. However, one aspect where I found the document to be insufficient is in the specification of security methods. The documents does list possible security methods, but it neither specifies them, nor does it state a mandatory-to-support method other than null-authentication. I am aware that the predecessor document, RFC 1831 also did not attend to security methods any more carefully. But the security-related requirements for IETF documents have become stricter since the publication of the predecessor document in 1995, which implies that this document would need to pay more attention to security-related aspects. Suggestion: Could the list of possible security methods (alias "security flavors") be limited to those for which there are clear protocol specifications? E.g., one of the possible methods, AUTH_DH, currently refers to an academic publication rather than a protocol specification. That's insufficient. And could one of the non-null security methods be made mandatory?
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
(was Discuss)
No Objection
No Objection
(2009-02-02)
Unknown
Editorial nit: Section 8.3, the chart isn't actually "in groups of hexadecimal 20000000" any more (it was in 1831).
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
(was No Record, Discuss)
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
Abstain
Abstain
(2008-12-10)
Unknown
I support the various DISCUSS positions
Cullen Jennings Former IESG member
(was Discuss, No Objection)
No Record
No Record
()
Unknown