From: Nicolas Williams (Nicolas.Williams@sun.com)
Date: 12/20/02-04:27:33 PM Z
Date: Fri, 20 Dec 2002 14:27:33 -0800 From: Nicolas Williams <Nicolas.Williams@sun.com> Subject: Re: Comments on draft-ietf-nfsv4-repl-mig-proto-00.txt Message-ID: <20021220142733.J1041@binky.central.sun.com> On Fri, Dec 20, 2002 at 02:24:11PM -0800, Mike Eisler wrote: > > Nicolas Williams wrote: > > >If the issue is encoding efficiency and there aren't going to be lots of > >octet streams per packet then PER is probably the best encoding. But a > >migration protocol will likely involve sending large numbers of large > >data chunks with fairly little header overhead, so that the inefficiency > >of XDR as an encoding will hardly matter. As Mike Eisler points out, > >the crypto overhead will be pretty hefty already, so will the encoding > >overhead be significant? (As long as XML is not used I'd say "no" :) > > > >If the efficiency of XDR does turn out to be an issue, couldn't the > >encoding be changed later? Switching to PER would involve using ASN.1 > >instead of ONC RPC, of course, but the structure of the types might not > >change much... I rather suspect that noone in this WG will want to use > >ASN.1/PER though :) , so that leaves ONC RPC/XDR and what else? SSHv2 or TLS > > > > The use of ASN.1 introduces huge barriers to entry. > XDR has an open source, free and *complete* > compiler. Can't say the same thing about ASN.1. > I'm suprised/skeptical to learn that PER/ASN.1 is > faster than XDR, but I don't claim to know > much about either. I'm not proposing that ASN.1 actually be used for this protocol, but merely pointing out that there aren't a lot of alternatives. I don't think a pure "bytes-on-the-wire" specification is good enough, though a TLS or SSH-like approach is quite reasonable. And ONC RPC / XDR is not unreasonable, IMO. > > > >encodings? > > > > SSH and TLS define an encoding language for themselves, > but not for their payloads. If there are SSH and TLS hardware > accelerators, then that's a point in their favor. If > not, what's the point? *nod* > >As for RPCSEC_GSS performance, it may be possible to use a single > >context to provide integrity/privacy for an entire stream, at the stream > >level, with each operation referencing a GSS context handle for > >authorization on the server side. No? > > > > That's what I have in mind. I'll follow up today. Good, very good. > -mre Nico --
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:45 AM Z CST