Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf-nfsv4-flex-files-15: (with DISCUSS and COMMENT)

Hi Eric,

Kathleen has removed her “discuss” from this document (the new version was pushed,
which satisfied her need for the SecDir review.

Could you please revisit your position on this draft?

Thanks,
Tom

> On Jan 24, 2018, at 2:34 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 
> 
> On Wed, Jan 24, 2018 at 2:32 PM, Tom Haynes <loghyr@gmail.com <mailto:loghyr@gmail.com>> wrote:
> 
> 
> > On Jan 24, 2018, at 1:48 PM, Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>> wrote:
> >
> > Eric Rescorla has entered the following ballot position for
> > draft-ietf-nfsv4-flex-files-15: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-nfsv4-flex-files/ <https://datatracker.ietf.org/doc/draft-ietf-nfsv4-flex-files/>
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > I concur with Kathleen's discuss. To put a finer point on it, I think the
> > security considerations section here needs to really clearly state what the
> > security properties of this design are and how they differ from existing NFS.
> > That's not true yes.
> 
> 
> Could you please clarify the last sentence?
> 
> That’s not true yet.
> 
> Or:
> 
> That’s not true, yes?
> 
> If yet, then hopefully pushing the next version will suffice.
> 
> Sorry. "yet"
>  
> 
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > - I'm a bit confused on whether the client can tell which model the server is using. I see:
> >
> >   An implementation can always be deployed as a loosely coupled model.
> >   There is however no way for a storage device to indicate over a NFS
> >   protocol that it can definitively participate in a tightly coupled
> >   model:
> >
> > But then there is a flag that you use to indicate you are tightly coupled. So I'm confused.
> >
> 
> Ah, the flag ffdv_tightly_coupled is used between the metadata server
> and the client. Not between the storage device and the metadata server.
> 
> OK. Thanks.
>  
> 
> 
> > - I note that some of your PDUs have /// in front and some do not. E.g., Section 5. Is that a bug.
> >
> 
> No, the ones with a /// are to be extracted and the other ones refer to existing fragments
> from other IDs. So for example, the one in Section 5 is referring to RFC5662.
> 
> Makes sense.
> 
> -Ekr
> 
> 
> 
> 
> > - S 2.2.
> > " Note: it is recommended to implement common access control methods at"
> >
> > Do you want RECOMMENDED.
> 
> Yes, this was pointed out by Brian Weis in the SecDir review.
> 
> 
> >
> >
> > _______________________________________________
> > nfsv4 mailing list
> > nfsv4@ietf.org <mailto:nfsv4@ietf.org>
> > https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>