From: Spencer Shepler (shepler@eng.sun.com)
Date: 08/12/99-02:44:18 PM Z
Message-ID: <37B32412.A6B3418@eng.sun.com>
Date: Thu, 12 Aug 1999 14:44:18 -0500
From: Spencer Shepler <shepler@eng.sun.com>
Subject: Re: minor comments on draft-ietf-nfsv4-00.txt
Mike Eisler wrote:
>
> minor comments on the June 1999 edition of the draft:
>
...
> > This section will be expanded to include the pertinent
> > details from draft-ietf-nfsv4-nfssec-00.txt.
>
> Rather than expand it, perhaps the section should simply refer to
> RFC 2623.
Will update the draft.
> > 10.2. Procedure 1: COMPOUND - Compound Operations
> ...
> >
> > RESULT
> >
> > struct COMPOUND4resok {
> > utf8string tag;
> > resultdata data<>;
> > };
> >
> > union COMPOUND4res switch (nfsstat4 status){
> > case NFS4_OK:
> > COMPOUND4resok resok4;
> > default:
> > void;
> > };
>
> The above doesn't quite do what I was looking for.
> The above returns a void result if the global status is non-zero.
>
> What I was seeking was:
>
> struct COMPOUND4resok {
> utf8string tag;
> resultdata data<>;
> };
>
> struct COMPOUND4res {
> nfsstat4 status; /* status of last operation */
> utf8string tag;
> resultdata data<>
>
> };
>
> This way, the NFS client can quickly determine the status code for the
> purpose of deciding if there is say a JUKEBOX error that requires
> retrying the operations that didn't complete.
Sounds reasonable and it appears that COMPOUND4resok is not needed since
the data is contained in COMPOUND4res.
> There seems to be lots of cases where white space between a data type and
> field is missing:
>
> struct CLOSE4args {
> stateid4stateid;
> };
I will check the document formatting.
> > enum rpc_flavor4 {
> > AUTH4_NONE = 0,
> > AUTH4_SYS = 1,
> > AUTH4_DH = 2,
> > AUTH4_KRB4 = 3,
> > AUTH4_RPCSEC_GSS = 4
> ^
>
> BTW, RPCSEC_GSS is 6, not 4.
Will change.
> > 10.29. Procedure 28: SECINFO - Obtain Available Security
> ...
> > RESULT
> >
> > struct rpc_flavor_info {
> > sec_oid4oid;
> > qop4qop;
> > rpc_gss_svc_t service;
> > };
> >
> > struct secinfo4 {
> > rpc_flavor4flavor;
> > rpc_flavor_info *flavor_info;
> > secinfo4*nextentry;
> > };
> >
> > struct SECINFO4resok {
> > secinfo4reply;
> > };
> >
> >
> > union SECINFO4res switch (nfsstat4 status) {
> > case NFS4_OK:
> > SECINFO4resokresok4;
> > default:
> > void;
> > };
>
> Instead of linked list, the secinfo4 entries ought to be in an
> array. I don't expect the list to be lengthy, so an array is more
> appropriate.
Okay.
> While the WG has reached consensus on the use of RPCSEC_GSS, NFS V4
> should be flexible enough to work over other kinds of security flavors,
> jsut as NFS V3's mount protocol should have been flexible enough to work
> over flavors other than AUTH_NONE, AUTH_SYS, AUTH_KERB, AUTH_DES, and
> wasn't.
>
> So I propose:
>
> /* delete rpc_flavor4 enum */
>
> struct rpcsec_gss_info {
> sec_oid4 oid;
> qop4 qop;
> rpc_gss_svc_t service;
> };
>
> struct secinfo4 {
> unsigned int flavor;
> opaque flavor info /* null for AUTH_SYS, AUTH_NONE, contains
> rpcsec_gss_info for RPCSEC_GSS.
> };
>
> struct SECINFO4resok {
> secinfo4 reply<>;
> };
>
>
> union SECINFO4res switch (nfsstat4 status) {
> case NFS4_OK:
> SECINFO4resok resok4;
> default:
> void;
> };
>
> The abve has the side benefits of using less bandwidth for flavors other
> than RPCSEC_GSS, and less bandwidth if there are two more more
> RPCSEC_GSS flavors in the results.
Good idea. If no objections, I will go ahead and update.
> > [SPNEGO]
> > Baize, E., Pinkas, D., "The Simple and Protected GSS-API Negotiation
> > Mechanism", draft-ietf-cat-snego-09.txt, Bull, April 1998.
> >
> > ftp://ftp.isi.edu/internet-drafts/draft-ietf-cat-snego-09.txt
>
> There doesn't appear to be a reference to this document in specification.
> This i-d has become RFC 2478.
Will change.
Spencer
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:30 AM Z CST