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

[David Noveck <[e-mail]>]

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

It was lost in the update process.  Anyway the following is what I intended
to add:

 <t>
      In some cases extensions will contain elements such as new operations
      or previously invalid switch cases.  Although it is possible to
      determine whether these OPTIONAL elements are supported using the
      rules described above, those defining extensions containing such
      elements have the option of defining new attributes that specify
      whether the feature is present and supported.  Since it is easy to
      determine whether a new attribute is supported using the
      supported_attrs attribute, this can make it simple and
      convenient for clients to determine whether support is present,
      particularly when a feature involves support for multiple
      such elements.
    </t>

On Fri, May 26, 2017 at 11:24 AM, Spencer Dawkins at IETF <
[e-mail]> wrote:

> 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)
>>
>
>