> -----Original Message----- > From: nfsv4-bounces@xxxxxxxx [mailto:nfsv4-bounces@xxxxxxxx] On Behalf > Of J. Bruce Fields > Sent: Friday, April 12, 2013 5:01 PM > To: nfsv4@xxxxxxxx > Cc: linux-nfs@xxxxxxxxxxxxxxx > Subject: [nfsv4] unsupported mandatory server features > > I'm expecting to turn on basic 4.1 support by default on the Linux server > before supporting two mandatory 4.1 features, and looking for advice on > handling that without too much pain to future clients. I suspect I'm not the > only server in this situation; anyone know what others are doing? > > The features are: > > - State protection (SSV and MACH_CRED): I'm currently returning > SERVERFAULT on EXCHANGE_ID's that request this, but this isn't > really what SERVERFAULT is for. > > I'm inclined to switch to ENC_ALG_UNSUPP; that leaves future > clients unable to distinguish between servers lacking SSV > entirely from those lacking support for a particular > algorithm, but in practice I think they'd handle both in the > same way anyway. Why not just reply with NFS4ERR_ENC_ALG_UNSUPP for SP4_SSV (as you suggest) and return an empty spo_must_allow, and minimal spo_must_enforce sets for SP4_MACH_CRED? By minimal spo_must_enforce, I mean EXCHANGE_ID, CREATE_SESSION, DESTROY_SESSION, BIND_CONN_TO_SESSION, and DESTROY_CLIENTID. I'm assuming that you default to checking the principal name for those anyway since NFSv4 requires it for the corresponding SETCLIENTID/CONFIRM? > - GSS on the backchannel: currently CREATE_SESSION or > BACKCHANNEL_CTL will succeed but SEQUENCE will start returning > with the CB_DOWN flag set. I would rather return an error > immediately than make the client guess what's going on in > recovery. > > Could I get away with returning ENC_ALG_UNSUPP here too? It's > not entirely logical, but it's also currently illegal for > these two operations so its use wouldn't be confused with some > other. Why not return NFS4ERR_NOENT to tell the client that the handle does not exist? > Of course my preference would be just to support these features, but given > resource limitations, the lack of interest, and the lack of any implementation > to test against, that doesn't look likely to happen in the near future. > > --b. > _______________________________________________ > nfsv4 mailing list > nfsv4@xxxxxxxx > https://www.ietf.org/mailman/listinfo/nfsv4 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
