Re: [nfsv4] Ben Campbell's Discuss on draft-ietf-nfsv4-minorversion2-39: (with DISCUSS and COMMENT)

["Ben Campbell" <[e-mail]>]

Thanks for the response. Comments inline (I deleted sections that do not 
seem to need further discussion.)

On 5 Jan 2016, at 18:37, Tom Haynes wrote:

>> On Jan 4, 2016, at 8:10 PM, Ben Campbell <[e-mail]> wrote:
>>
>> Ben Campbell has entered the following ballot position for
>> draft-ietf-nfsv4-minorversion2-39: 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
>> 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-minorversion2/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> I have a couple of items I would like to see discussed prior to 
>> approval.
>> Hopefully they can be resolved easily:
>>
>
> Hi Ben,
>
> Proposals inline.
>
>
>> - 12.1 says:
>>
>> "Id:  The number assigned to the attribute.  In the event of 
>> conflicts
>> between the assigned number and [NFSv42xdr], the latter is likely
>> authoritative, but should be resolved with Errata to this document
>> and/or [NFSv42xdr].  See [IESG08] for the Errata process."
>>
>> This leaves a window open for considerable confusion down the road. 
>> Is
>> there a reason not to just fix it now?
>
> Note that this was taken verbatim from RFC5661 and RFC5662.

It seems odd there, too :-)

>
>
>> This draft normatively depends on
>> [NFSv42xdr] anyway, so why not completely delegate the assigned Id
>> numbers to it?
>
>
> How about:
>
> Id:  The number assigned to the attribute.  In the event of conflicts
>    between the assigned number and [NFSv42xdr], the latter is
>    authoritative, and should be resolved with Errata to this document.
>    See [IESG08] for the Errata process.

That's better, and enough for me to clear the discuss. I'd still prefer 
to remove the reference to the errata process; the draft does not need 
to invoke that now to use it later. As it is, it gives the impression 
that it's not necessary to get this draft right, because we can fix it 
later. (Which I doubt very much is the intent.) In any case, I will not 
block further on it.

>
>
>
>>
>> - 4.4.2, "The client SHOULD write back the data..."
>> SHOULD seems weak for something where failure  could result in data
>> corruption. Are there ever situations where it might make sense not 
>> to do
>> this?
>
>
> I’m okay with making that a

The sentence was cut off. I assume you were going to say "MUST"? (It's 
still a SHOULD in version 40.)

>
>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> === Substantive Comments ===
>>

[...]


>
>
>
>> -4.10.1.1, last paragraph: "Servers SHOULD reject..."
>> Why not MUST? Do you envision circumstances where it might be okay to
>> accept COPY_NOTIFY requests over insecure channels? Channels with 
>> other
>> forms of privacy protection?
>
> Yes - for example such security may be provided with a network which 
> has restricted physical access.
>
> For NFSv4.x, we have a strong requirement that kerberos MUST be 
> supported, but we
> have a weak requirement that it be deployed.
>
> See Section 2.2.1.1.1.2 of RFC5661.

(I meant 40.10.2.1, but you seem to have found it anyway)

I think it would help to have an explanation to that effect in the text.

[...]

>
>>
>> - 9.6.1.2, last paragraph:
>>
>> Why just MAY? does it ever make sense for a "Full Mode" 
>> implementation to
>> not validate the security attributes?
>
> It is MAY because we don’t control the policies on the server - that 
> is a decision that may be controlled by the software or even by a 
> conjuration made by the administrator.
>
> “Full Mode” simply means that both the client and server may make 
> decisions.

On re-reading this section, I think I understand this to mean that the 
implementation MAY (or MAY not) limit the security attributes acceptable 
from a certain _peer_, (as opposed to a certain user and/or resource). 
Given that, I think the MAY makes sense.


[...]