Re: [nfsv4] Spencer Dawkins' Yes on draft-ietf-nfsv4-versioning-09: (with COMMENT)

[Spencer Dawkins at IETF <[e-mail]>]

Dear NFSv4,

On Thu, May 25, 2017 at 12:13 PM, Spencer Dawkins at IETF <
[e-mail]> wrote:

> Dear -versioning- folk,
>
> On Fri, May 12, 2017 at 11:17 AM, Trond Myklebust <[e-mail]>
> wrote:
>
>> On Fri, 2017-05-12 at 07:36 -0700, Spencer Dawkins wrote:
>> >
>> > I did have one question that came up during AD Evaluation that I
>> > wanted
>> > to mention.
>> >
>> > The first two drafts that used this mechanism (umask and xattrs) used
>> > two
>> > different idioms for discovering support. The xaddrs draft defines an
>> > xaddr_support attribute, while umask does not.
>> >
>> > In conversations with the working group, the reasoning was that
>> > xattrs
>> > defines a number of operations, so discovering that the complete
>> > mechanism is supported before you start trying to use the attributes
>> > makes sense, while umask defines only one attribute, and for any
>> > attribute, you can find out if it is supported within a given file
>> > system
>> > by interrogating the appropriate bit position in the REQUIRED
>> > attribute
>> > supported_attrs, so there is no advantage to adding a umask_support
>> > attribute.
>> >
>> > That all made perfect sense to me, but the explanation was helpful
>> > enough
>> > to me that I wonder if it's worth a sentence or two, pointing out
>> > that
>> > some protocol designers may choose one idiom, while other protocol
>> > designers choose the other, and saying that's not a problem.
>> >
>>
>> It's an extra mechanism that could be a convenience, but is not
>> something that a client can or should rely on. The only reliable
>> mechanism for verifying that the feature is available is to try it, and
>> handle the resulting NFS4ERR_NOTSUPP and/or NFS4ERR_OP_ILLEGAL error.
>>
>> This is how the Linux client handles all the other NFSv4.x optional
>> features as well.
>
>
> This draft was approved on today's telechat, but the secretariat is
> holding off sending the approval announcement until I let them know that
> all the comments have been addressed.
>
> It looked like David had a plan for this specific comment on idioms for
> detecting support, and Trond had a response, so if others have thoughts
> that would affect the text that appears in the RFC, it would be great to
> hear that, Real Soon Now.
>

David has submitted a -10 version of this draft, that does not discuss
idioms about detecting support (that I can find).

I don't think that's a problem for this document, so I won't hold this
document up. I would, of course, appreciate the working group thinking
about comments in this thread, and discussing whether it would be helpful
to say something in a future draft (or, potentially, a revision to the RFC
this draft will become).

And thanks for the explanations.

Spencer

>
> Thanks!
>
> Spencer (D)
>