Requirements for NFSv4 Multi-Domain Namespace Deployment
draft-ietf-nfsv4-multi-domain-fs-reqs-11

Note: This ballot was opened for revision 09 and is now closed.

Alvaro Retana No Objection

(Spencer Dawkins; former steering group member) Yes

Yes ( for -09)
No email
send info

(Alexey Melnikov; former steering group member) No Objection

No Objection (2016-08-29 for -09)
No email
send info
I think using more examples in the document would improve readability.

A couple of very small nits with this document:

"mulit-domain" typo at least 4 times.

LDAP reference should probably be listed on first mention. Similar for Kerberos.

(Alissa Cooper; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Ben Campbell; former steering group member) No Objection

No Objection (2016-08-30 for -10)
No email
send info
I am a little bit confused about the purpose of this draft. My confusion is probably related to Brian's Gen-ART comments.

Specifically, who/what do the normative requirements in section 6 apply to. Are these implementation requirements or deployment requirements? If the former, should this update any of the nfsv4 RFCs? If deployment, then I also wonder why this is PS and not BCP.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection (2016-08-30 for -10)
No email
send info
I do note the BCP/PS question from Brian in his Gen-ART review. My own opinion is that BCP would have equal strength, and if it were up to me, I’d pick that category. However, I’m not religious about this — clearly you could go two ways on this.

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2016-08-29 for -09)
No email
send info
Thanks for following the advice in the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg06652.html

I think the draft could be a bit more clear, following Russ' comments a bit further.  I had similar questions in this version, but then read his review and the responses.  I'll leave this as a comment for the AD since my comments would be similar to those already made.  If the draft could read a bit better, that would be helpful.

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2016-08-31 for -10)
No email
send info
Agree to other comments about clarity. As also mentioned by Ben, I believe this should probably update rfc7530 (and maybe even rfc5661) and the updates made should then be indicated clearly.

(Stephen Farrell; former steering group member) No Objection

No Objection (2016-08-30 for -10)
No email
send info
- 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.

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -10)
No email
send info

(Terry Manderson; former steering group member) No Objection

No Objection (2016-08-30 for -10)
No email
send info
Everything that came to mind when reading this draft has already been raised in Kathleen's (Russ's), Stephen's, and Jari's comments. That doesn't really need a +1, but "+1". ;)