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

[Spencer Dawkins at IETF <[e-mail]>]

Dear All,

On Fri, Sep 2, 2016 at 1:34 PM, Adamson, Andy <[e-mail]>
wrote:

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


Just to follow up, I wasn't sure what Andy was saying here, so I had a
private conversation with Andy, where he said

The coding requirements to map domain portion of the name@domain and/or the
REALM portion of the Kerberos principal@REALM exist in RFC7530 and RFC5661,
so there are no new coding requirements and so no Updates header.


So, no Updates header is needed.

Thanks,

Spencer


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