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

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 2 Sep 2016 12:45:43 -0500

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.

Please let me know what you think.

On Tue, Aug 30, 2016 at 3:14 PM, Ben Campbell <[email-masked]> wrote:

> On 30 Aug 2016, at 13:28, Adamson, Andy wrote:
>
> On Aug 30, 2016, at 2:11 PM, Ben Campbell <[email-masked]> 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/stat
>>> ement/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 <
>> [email-masked]> 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 ...

>
>
>
>> If
>>> the former, should this update any of the nfsv4 RFCs?
>>>
>>
>> The NFSv4 WG has decided to not update the 600+ page NFSv4 RFCs for
>> issues such as this.
>>
>
> Just to be clear, I did not suggest a revision of those RFCs. Just an
> "Updates" header on this one. (But whether it matters depends on the
> previous question.)

... which means I'm also curious about this!

Thanks,

Spencer

>
>
>
>> If deployment, then
>>> I also wonder why this is PS and not BCP.
>>>
>>
>> Because the AD made the judgment call and has decided to make it a PS
>> which is his choice.  I stated my opinion which is PS, and if the AD wants
>> to make this a BCP, OK.
>>
>>
> Sure. These were non-binding comments.
>
> Ben.
>
>

---

From: "Adamson, Andy" <[email-masked]>
Date: Fri, 2 Sep 2016 18:34:13 +0000

> On Sep 2, 2016, at 1:45 PM, Spencer Dawkins at IETF <[email-masked]> 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 refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> 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:
> 
> 2) The first sentence in the abstract (and in the introduction) to be changed from
> 
> On Aug 29, 2016, at 7:23 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 
> I read that, but it didn't answer my question about _what_ the requirements applied to. But you address it below...
> 
> 
> 
> 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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 5 Sep 2016 15:14:44 -0500

Hi, Andy,

So, to finish this off ...

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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 7 Sep 2016 09:46:29 -0500

Dear All,

> 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