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

["Adamson, Andy" <[e-mail]>]

> 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?
if this is a review of draft-10 why bring up a review of draft-08?

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


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

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

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

—>Andy

> 
>