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

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

> On Sep 2, 2016, at 1:45 PM, Spencer Dawkins at IETF <[e-mail]> wrote:
> 
> Hi, Andy,
> 
> This draft was approved on the telechat yesterday, but I still had two questions from Ben's comments after looking at the diffs for 09-11 (below). The other responses seem to be handled.

Hi Spencer 

OK - good to hear. See below.


> 
> Please let me know what you think.
> 
> On Tue, Aug 30, 2016 at 3:14 PM, Ben Campbell <[e-mail]> wrote:
> On 30 Aug 2016, at 13:28, Adamson, Andy wrote:
> 
> On Aug 30, 2016, at 2:11 PM, Ben Campbell <[e-mail]> wrote:
> 
> Ben Campbell 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:
> ----------------------------------------------------------------------
> 
> I am a little bit confused about the purpose of this draft.
> My confusion
> is probably related to Brian's Gen-ART comments.
> 
> OK - did you read the response? I case you have not, here is portion of the response that addresses the SP vrs BCP concern.
> 
> —————
> This latest round of comments - including the SecDir review from Russ Housley shows that there is still an impedence mis-match between the title/abstract and the intended status of Standards Track versus an Informational draft or best practices.
> 
> I feel that the use of "Guidelines" in the title, and "guidance" in the abstract point to an Informational draft rather than a Standards track.
> 
> This draft is a Proposed Standard (not an Informational or BCP) because the MUST and REQUIRED noted in section 6 of the doc are absolute requirements for an NFSv4 multi-domain file name space to work. These can not be BCP as an NFSv4 multi-domain file name space will _not_ work without these requirements.
> 
> I have completed a draft-ietf-nfsv4-multi-domain-fs-reqs-10 with the following changes:
> 
> 1) The title to be changed from
> 
> "Multiple NFSv4 Domain Namespace Deployment Guidelines"
> 
> to
> 
> "Multiple NFSv4 Domain Namespace Deployment Requirements"
> 
> 
> 2) The first sentence in the abstract (and in the introduction) to be changed from
> 
>   This document provides guidance on the deployment of the NFSv4
>   protocols for the construction of an NFSv4 file name space in
>   environments with multiple NFSv4 Domains.
> 
> to
>   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.
> 
> —————
> 
> to which Brian responded:
> 
> 
> On Aug 29, 2016, at 7:23 PM, Brian E Carpenter <[e-mail]> wrote:
> 
> Hi,
> 
> Thanks for version -10. I appreciate the clarification to the title etc.
> 
> (All the same, a BCP is just as mandatory as a Draft Standard. But it's
> a judgment call, of course.)
> 
> Regards
>   Brian Carpenter
> 
> I read that, but it didn't answer my question about _what_ the requirements applied to. But you address it below...
> 
> 
> 
> Specifically, who/what do the normative requirements in section 6 apply
> to. Are these implementation requirements or deployment requirements?
> 
> They are deployment requirements - which I feel is very clear.
> 
> To put a finer point on it, do you think an implementer can write the code for a multi-domain nfsv4 service without reading this document? For example, are the identifier mapping requirements strictly deployment issues without impact on the code?
> 
> I am also curious about this …

The identifier mapping requirements of preserving the domain portion of the name@domain and/or the REALM portion of the Kerberos principal@REALM could impose some extra coding requirements on what is stored in a name service and the query calls to the nameservice. 

For example, the Linux ns_switch getpwnam, getpwuid which are commonly used for name<=>ID mapping do not utilize an @domain or an @REALM portion of a name (either as input nor as output). 

Back in 2007 I wrote the Linux idmapd daemon translation service which included the nsswitch translation method, and the umich_ldap translation method (I worked for CITI at the University of Michigan at the time). The umich_ldap translation method was written to handle the @domain and @REALM portion of names for name to ID mapping. It included adding schema to LDAP (NFS4Name, GSSAuthName) and coding the associated LDAP queries for mapping between NFSv4Name or  GSSAuthName and the UID.

http://www.citi.umich.edu/projects/nfsv4/crossrealm/libnfsidmap_config.html

It still exists - if you are curious, see the attached /etc/idmapd.conf