Subject: [nfsv4] Ben Campbell's No Objection on draft-ietf-nfsv4-rpcsec-gssv3-14: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Tue, 05 Jan 2016 19:19:39 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-nfsv4-rpcsec-gssv3-14: 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-rpcsec-gssv3/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi just a couple of comments:

- 2.7.1.4:
rp_name is labeled "human readable". Are there internationalization
considerations?

-5:
It would be nice to see the IANA request details in this draft

---

From: "Adamson, Andy" <[email-masked]>
Date: Wed, 6 Jan 2016 15:56:10 +0000

> On Jan 5, 2016, at 10:19 PM, Ben Campbell <[email-masked]> wrote:
> 

the rp_name string is 100% RPC application defined, including any internationalization considerations.

> It would be nice to see the IANA request details in this draft

Fixed in draft-15

Thanks

—>Andy

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 06 Jan 2016 10:19:04 -0600

Did I miss language in the draft that said that? (It's quite possible).

But along those lines, let's say an application needed to include a 
language tag. How might it do that?

Ben.

---

From: "Adamson, Andy" <[email-masked]>
Date: Wed, 6 Jan 2016 17:00:21 +0000

> On Jan 6, 2016, at 11:19 AM, Ben Campbell <[email-masked]> wrote:
> 

No - you did not miss specific language to that effect, just that all of a structured privilege is RPC application defined. 
> 
> But along those lines, let's say an application needed to include a language tag. How might it do that?

Sigh. Yes, there is no place for a tag. I do note that rfc2203 uses ‘a simple ASCII string” name for flavors.

Perhaps I can use something like RFC5661 utf8str_cs:

   | utf8string    | typedef opaque utf8string<>;                      |
   |               | UTF-8 encoding for strings.                       |
   | utf8str_cis   | typedef utf8string utf8str_cis;                   |
   |               | Case-insensitive UTF-8 string.                    |
   | utf8str_cs    | typedef utf8string utf8str_cs;                    |
   |               | Case-sensitive UTF-8 string.                      |
   | utf8str_mixed | typedef utf8string utf8str_mixed;                 |
   |               | UTF-8 strings with a case-sensitive prefix and a  |
   |               | case-insensitive suffix.                          |

—>Andy

> 
> Ben.r
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 06 Jan 2016 21:58:29 -0600

On 6 Jan 2016, at 11:00, Adamson, Andy wrote:

> No - you did not miss specific language to that effect, just that all 
> of a structured privilege is RPC application defined.

Is the fact of the string being human readable also application 
specific? Would it make sense to make it opaque, and depend on the 
application for the interpretation?

> Sigh. Yes, there is no place for a tag. I do note that rfc2203 uses 
> ‘a simple ASCII string” name for flavors.
>

I think something like that could help. I gather 5661 depends on 
stringprep for the utf8 string types, which seems a bit out of fashion 
these days. But it might be sensible to keep things consistent.

I noticed Barry also wanted to have a discussion on this. He is more 
expert on internationalization that I, so hopefully he will comment:-)

Ben.

---

From: David Noveck <[email-masked]>
Date: Thu, 7 Jan 2016 08:27:46 -0500

I think something like that could help. I gather 5661 depends on stringprep
for the utf8 string types, which seems a bit out of fashion these days. But
it might be sensible to keep things consistent.

The good news is that RFCs 7530/7531 define exactly the same types and they
do not depend on stringprep.  So using these types would mean that you
would be consistent with v4.0 and v4.1 and if
v4.1 is ever fixed to get rid of the stringprep stuff, I presume these
types would remain, and be defined without depending on stringprep.

On Wed, Jan 6, 2016 at 10:58 PM, Ben Campbell <[email-masked]> wrote:

>> No - you did not miss specific language to that effect, just that all of
>> a structured privilege is RPC application defined.
>>
>
> Is the fact of the string being human readable also application specific?
> Would it make sense to make it opaque, and depend on the application for
> the interpretation?
>
>