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

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 30 Aug 2016 13:47:25 -0700

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

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

- 5.3: Would that "must never" in the 2nd last para be
clearer as an RFC2119 "MUST NOT"? (Just checking.)

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

---

From: "Adamson, Andy" <[email-masked]>
Date: Wed, 31 Aug 2016 12:12:32 +0000

> On Aug 30, 2016, at 4:47 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 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

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. 

> bikeshed on it, but I do prefer the latter a good bit in

I don’t see an improvement in identity syntax / identifier syntax. I can see dropping ‘identity’

name@domain identity syntax / name@domain syntax

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

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 31 Aug 2016 13:30:21 +0100

Hiya,

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

> https://www.ietf.org/mail-archive/web/secdir/current/msg06746.html

Fair enough. But see above.

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

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

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