Requirements for NFSv4 Multi-Domain Namespace Deployment
RFC 8000

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

(Spencer Dawkins) Yes

(Jari Arkko) No Objection

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

Deborah Brungard No Objection

(Ben Campbell) No Objection

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

Alissa Cooper No Objection

(Stephen Farrell) No Objection

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

(Joel Jaeggli) No Objection

Suresh Krishnan No Objection

Mirja Kühlewind No Objection

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

(Terry Manderson) No Objection

Comment (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". ;)

Alexey Melnikov No Objection

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

(Kathleen Moriarty) No Objection

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

Alvaro Retana No Objection