From: Robert Thurlow (Robert.Thurlow@eng.sun.com)
Date: 12/20/02-03:43:43 PM Z
Date: Fri, 20 Dec 2002 14:43:43 -0700 (MST) From: Robert Thurlow <Robert.Thurlow@eng.sun.com> Subject: Re: Comments on draft-ietf-nfsv4-repl-mig-proto-00.txt Message-ID: <Roam.SIMC.2.0.6.1040420623.20804.thurlow@jurassic.eng> [RPC] > Cool. Let's cover the security thing and make > krb5, krb5i, krb5p MANDATORY too. Certainly, if we go with RPC this is essential. > Speaking of Connectathon, in addition to testing > the strawman, it would be nice to do some NFSv4 client > testing to see if NFSv4 referrals (fs_locationed, > NFS4ERR_MOVED, etc.) actually work. This doesn't > necessarily require a complete or partial implementations > of the strawman repl-mig protocol. Agreed. > There are dozens of attribues other than nfsace4, and they aren't > in the strawman, It should be sufficient to refer to the types > coming from nfsv4, rather that having duplicates in the > repl-mig protocol's .x file. Okay; I don't want duplicate (and especially inconsistent) definitions here. I just don't know of a prior example of pointing correctly to something whose encoding is defined in another RFC. Can anyone think of an analogue? > The target might be storing just US-ASCII, or US-ASCII > plus the 8 bit Euro character set, or the entire > 16-bit only Unicode. And there are probably intermediate degrees > of capability. So in general I don't know how this information gets > conveyed. > I think it is best to use the existing NFSv4 practice for letting the target > reject names it can't convey, and thus give the source the ooption of > mapping the names to simpler characters. But by then you may have been terabytes into the transfer and will have just messed up the client by that change. I think we need to try to codify the capabilities somehow to be able to provide a warning before the transfer starts. > >>Does RM_FHPRESERVE also imply preservation of fileid? > > > >For domains where it is useful, it probably will, but I > >don't know if it should be specified so. > > If there is no implication, we may need RM_FILEID > since there's prose in the v4 spec that talks about leveraging > fileid to tell if file handles are unique. Agreed - thanks for the reminder. > >>In Section 5.1, Data transfer phase messages, shouldn't > >>there be a SEND_DELEGATION_STATE message as well? > >> > > > >Possibly helpful; I'd expected we'd recall delegations > >just before pushing the final set of changes, and not > >issue new delegations until completion. > > > That could be bad, just as we agree that it would > be bad if overall system forced clients to re-establish lock state > on the target. Recall of the delegation can result in a flurry of > byte range lock requests (per delegation) getting synced > to the source, and then the target (via the transfer protocol). > That's just one example. I think SEND_DELEGATION_STATE should > be in; sources don't have to use it, and we could even make > it a negotiable capability. Okay, I'm sold - it's in. > We can encode any attrbute in NFSv4, just add a minor version. > Vendors that with multi-protocol servers are accomodated whether they > support NFSv4 or not, CIFS or not. > > Otherwise, here's what we have: > > - underspecified and/or opaque attributes that aren't in > control of IETF, or > > - well specified attributes that are in the transfer > protocol, but not in the NFSv4 protocol, thereby denying > NFS users the capability to read these attributes. In the past, at least some people (Brent, your cue) have talked about this being able to grow up into a generalized replication protocol that might be used with other types of data, e.g. WebDAV. The "attribute profiles" were a way to define NFSv4 first, but permit other things to plug in later should someone want to do that. If this seems architectually wrong (i.e., more is wrong than just the way I dealt with it in the draft), then we should kill it now. I'm running out of energy to defend this, myself, and want to get on with stuff that matter more. > >I guess I expect the abort stuff to be in a crisis handler, > >where a lot of computation is not welcome. The implementation > >could advertise if it can do restart or not at connection > >time, which might accomplish enough here - would that work? > > > There are cases where the target and server will be able to restart or not, > and it may not know when the session is created (e.g. the source or target's > disk has crashed, or ENOSPC has occurred on the target). Does this need to be a new RPC or a new argument to ABORT_SESSION? > Also, there are likely intellectual property issues around some of those > compression types. We want to tread carefully here; optional, > negotiable compression is goodness since it is possible > (probable?) ipr issues won't let us make > any mandatory. Agreed! > Thisi is the only mention of TCP I found, > but I think adopting the Area Director > approved language from the nfsv4 spec is a > good thing to do now: Agreed. Rob T
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:44 AM Z CST