Re: [nfsv4] Stephen Farrell's No Objection on draft-ietf-nfsv4-multi-domain-fs-reqs-10: (with COMMENT)

[Stephen Farrell <[e-mail]>]

Hiya,

On 31/08/16 13:12, Adamson, Andy wrote:
> 
>> On Aug 30, 2016, at 4:47 PM, Stephen Farrell <[e-mail]> wrote:
>>
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-nfsv4-multi-domain-fs-reqs-10: No Objection
>>
>> 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-multi-domain-fs-reqs/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>>
>> - general: I agree with Kathleen who agrees with Russ'
>> secdir review. [1]
> 
> Hello Stephen
> 
> The referenced review [1] was for draft-08. Did you review draft-08 or draft-10?

I reviewed draft-10.

> if this is a review of draft-10 why bring up a review of draft-08?

Because, as I said, I think this draft is still overall not very
clear to me. (But not to the point where it needs to be held up.)

I know from my own writing that it's quite easy to consider text
that one has looked at a lot to be very clear, when other readers
don't find the text clear. I suspect that may be the case here.

> 
> I responded to review [1] in draft-09 and tweeked it again in draft-10.
> 
> Here is Russ’ secdir reveiw of draft-09 where AFAICS he feels the issues in [1] (draft-08) were addressed.
> 
> https://www.ietf.org/mail-archive/web/secdir/current/msg06746.html

Fair enough. But see above.

> 
> 
>> I was left puzzled as to how this
>> would be useful to readers. But I've no objection if
>> that's felt to be the case. However, I'd really
>> encourage the editors/WG/AD to consider that a 
>> number of folks (who are familiar with GSS etc.) have
>> found this draft pretty unclear.
>>
>>   [1]
>> https://www.ietf.org/mail-archive/web/secdir/current/msg06642.html
>>
>> - abstract: 1st sentence seems unwieldy - it puzzled me
>> anyway;-)
> 
> Here it is:
> 
>   This document presents requirements on the deployment of the NFSv4
>    protocols for the construction of an NFSv4 file name space in
>    environments with multiple NFSv4 Domains.
> 
> I don’t get what is puzzling about it. 

"...requirements on the deployment ... for the construction of...
in environments with... " is too many clauses for clarity IMO.
Short sentences are cheap:-) And valuable in abstracts.

> 
>>
>> - (various places): Would "identifier syntax" not be
>> better than "identity syntax"? There's no need to
>> bikeshed on it, but I do prefer the latter a good bit in
>> case that helps:-)
> 
> I don’t see an improvement in identity syntax / identifier syntax. I can see dropping ‘identity’
> 
> name@domain identity syntax / name@domain syntax

That's better yes. The term "identity" often brings confusion
as it can imply much more than an identifier.

> 
>>
>> - 5.3: Would that "must never" in the 2nd last para be
>> clearer as an RFC2119 "MUST NOT"? (Just checking.)
> 
> It’s actually ‘must not blindly’. The original intent of that paragraph was to point out that many stand-alone NFSv4 deployments make the NFSv4 domain name the to_lower(REALM) name, insist that the POSIX user name matches the Kerberos principal name, and then map principal@REALM to a POSIX uid by dropping the @REALM and presenting the principal to the ns_switch mapper.
> 
> This practice will not work in an NFSv4 multi-domain environment, and should not be encouraged.
> 
> The paragraph has morphed into a form that is of no use. I’ll remove it.
> 
>>
>> - 6.1: Are there any cases of domain names that allow
>> for escaping or have other syntatic features that
>> involve more than just octet string comparisons to check
>> domain name equality? I don't think there are, so just
>> checking. If there were, then you might need to say
>> something about that somewhere.
> 
> name@domain parsing issues are dealt with in RFC7530 and RFC5661, and are not unique to an NFSv4 multi-domain deployment.
> 

If there're pointers to those, then that's fine. (I didn't
re-check if there are.)

S.


> —>Andy
> 
>>
>>
>