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

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

Hi, Andy,

So, to finish this off ...

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

I reread Section 6, and I agree with your assessment that these are
deployment requirements (that point didn't seem quite as clear to me as it
does to you, but could be OK).


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


So, are you saying that this does, or does not, justify adding an Updates
header to this draft, pointing to existing RFCs that define identifier
mapping requirements?

Either answer could be OK, but I wasn't sure what you meant here.

Thanks for helping to finish IESG Evaluation for this draft.

Spencer


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