Skip to main content

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 steering group member) (was Discuss) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(David Ward; former steering group member) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection (2008-12-11)
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 steering group member) No Objection

No Objection ()

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection ()

                            

(Pasi Eronen; former steering group member) (was Discuss) No Objection

No Objection (2009-02-02)
Editorial nit: Section 8.3, the chart isn't actually "in groups of 
hexadecimal 20000000" any more (it was in 1831).

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Tim Polk; former steering group member) (was No Record, Discuss) No Objection

No Objection ()

                            

(Lisa Dusseault; former steering group member) Abstain

Abstain (2008-12-10)
I support the various DISCUSS positions

(Cullen Jennings; former steering group member) (was Discuss, No Objection) No Record

No Record ()