Re: [nfsv4] draft-ietf-nfsv4-umask

[spencer shepler <[e-mail]>]

On Wed, Aug 23, 2017 at 6:53 PM, David Noveck <[e-mail]> wrote:

> > We need to close on this (if there is going to be a change or not)..
>
> We certainly do.
>
> I'm kind of unsure about how a decision will be made.
>
> I suppose some people will comment and then Spencer will wrestle with the
> subtleties of the concept of consensus.
>

Consensus has been met IMO.  Tom raised the issue, Bruce responded, I asked
if Tom would be okay without making the change, he said he was "fine
without making the change".


>
> I hope it will be a help to the proocess but my opinion is that Tom' s
> requests are reasonable and the requested changes should be made.  I think
> I raised these issues during WGLC but didn't bother to press the matter at
> that time.  Unlike Tom, I would not be OK if this change is not made, but I
> don't want to make a big deal about it.   I guess we need to  hear from
> Bruce with a clear statement about his willingness to make the requested
> changes.  Bruce appears reluctant (so far) to make these changes but he has
> not actually refused.
>

If you like to suggest a change, Dave, then please do so directly.  It is
unclear with the above text your position since you state "I don't want to
make a big deal about it" and "but he has not actually refused".

As mentioned, I consider the issue closed and we can move forward.  Please
clarify.


>
> > This document is technically in AUTH48 period
>
> Actually, it has not yet started RFC editing.  For some reason it is stuck
> in MISSREF.  It shouldn't be because it is waiting for RFC 8178 which was
> published in July.
>

Looks like the editor needs a nudge as to the MISSREF - I will check into
that.


>
> >we can make the changes but need to know what they are and hear any
> objections
>
> I think Tom's request was pretty clear.
>
> I haven't heard any objections, unless you count Bruce's remarks, which
> are ambiguous.  It is a question of how long we are willing to wait, but
> even if there are no objections, the real question is whether Bruce is
> willing to make the requested changes.  I think these changes will only be
> made if Bruce is willing to make them.
>

As mentioned, I am clear so if there is is concern with my position -
suggest modified text or assert support for Tom's modifications clearly and
we will go from there and reopen the issue.


>
>
>  > (as has been queried for Manoj's changes).
>
> There the changes have alreay been made and the question is how long we
> are willing to wait for objections which are unlikely to arive.
>
> How about 48 hours?  i.e. if there are no objections by 3:00 UTC on 8/26,
> the changes are to be considered to be approved.  OK?
>

No.  Thanks for pointing out that I did not provide a deadline for
feedback.  Given summer vacations, etc. I will ask for feedback by next
Wednesday and will post this to the original thread.

Spencer


>
> On Wed, Aug 23, 2017 at 7:46 PM, Thomas Haynes <[e-mail]>
> wrote:
>
>>
>> On Aug 23, 2017, at 4:24 PM, spencer shepler <[e-mail]>
>> wrote:
>>
>>
>> We need to close on this (if there is going to be a change or not).. This
>> document is technically in AUTH48 period - we can make the changes but need
>> to know what they are and hear any objections (as has been queried for
>> Manoj's changes).
>>
>> Tom?
>>
>>
>> While I would like it cleaner, I am fine without making a change.
>>
>>
>>
>> Spencer
>>
>> On Wed, Aug 23, 2017 at 8:55 AM, J. Bruce Fields <[e-mail]>
>> wrote:
>>
>>> On Tue, Aug 22, 2017 at 08:36:38PM +0000, Thomas Haynes wrote:
>>> > Hi Bruce,
>>> >
>>> > Can you modify your draft such that it generates xdr?
>>>
>>> I considered that but it seemed like a lot of boilerplate for little
>>> return.  The code to extract the xdr might almost be longer than the xdr
>>> you're extracting.  I dunno.
>>>
>>> >
>>> > I.e., I went to add a new const for your new attribute, and unlike the
>>> xattr document, I had to guess:
>>>
>>> You didn't have to guess the number, just the constant name, right?  I'm
>>> not sure how much that matters.
>>>
>>> --b.
>>>
>>> > %/*
>>> > % * New For UMASK
>>> > % */
>>> > const FATTR4_MODE_UMASK         = 81;
>>> >
>>> > I’d recommend that you add the ‘///‘.
>>> >
>>> > Also, you should use the <CODE BEGINS> and <CODE ENDS> at the very
>>> least here:
>>> >
>>> > 4.  mode_umask Attribute
>>> >
>>> >
>>> >          struct mode_umask4 {
>>> >            mode4  mu_mode;
>>> >            mode4  mu_umask;
>>> >          };
>>>
>>> _______________________________________________
>>> nfsv4 mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>>
>>
>>
>>
>> _______________________________________________
>> nfsv4 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nfsv4
>>
>>
>