Subject: [precis] Anybody do any review of NFS documents?

From: Pete Resnick <[email-masked]>
Date: Tue, 28 May 2013 23:04:53 -0500

Folks,

The new rev of NFS (3530bis) is on the IESG agenda for this week. I saw 
that David Black had some hand in the discussion on the NFS WG list 
regarding i18n. Did anyone else here participate in the discussion with 
this WG on their new i18n section? I've got some concerns, but I'd like 
to understand who was involved in that discussion and how much review it 
got.

Thanks,

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 May 2013 10:15:21 -0600

> to understand who was involved in that discussion and how much review it

I have't looked at those specs. The size of 3530bis scared me off. Are
there particular sections that it would be best for us to review?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Pete Resnick <[email-masked]>
Date: Wed, 29 May 2013 13:13:56 -0500

> there particular sections that it would be best for us to review?

Section 12.

http://tools.ietf.org/html/draft-ietf-nfsv4-rfc3530bis-26#section-12

It is entirely new to this document and (from what I can tell from the 
NFSv4 WG list) entirely unimplemented to date.

pr

---

From: "Black, David" <[email-masked]>
Date: Wed, 29 May 2013 14:56:12 -0400

Pete,

Well, the 3530bis draft is actually an update to an older NFS version,
NFSv4.0.  The latest version of NFS is v4.1 and work is in progress
on v4.2.  I had some involvement in some of the Unicode provisions of
3530bis a while back, but I have not reviewed the Unicode portion
of the current 3530bis draft in detail.  The history here is unfortunate:

- RFC 3530 specified use of stringprep - see section 11:
	http://tools.ietf.org/html/rfc3530#section-11

- That didn't work, as the "running code" does "other things,"
	some of which are "interesting" ;-).

Among the more "interesting" of those "other things" is that there are
apparently both NFC-based and NFD-based implementations of filename
normalization in use (see 12.7.1.5.1 in 3530bis for a glimpse), and
hence specifying a single normalization approach "on the wire" won't
work.

My general understanding of the 3530bis draft's Unicode provisions is
that they're strongly influenced by compatibility with "running code"
even if what they specify is new and not yet (fully) implemented.

Thanks,
--David

p.s.  Now you have some insight into why I've chosen to initially focus
on iSCSI in precis ... but I guess I should start paying attention to this
NFSv4 situation, as the work that Peter Saint-Andre and I have been
putting into the Unicode provisions in a DIAMETER draft seems to be
close to done.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Pete Resnick
> Sent: Wednesday, May 29, 2013 2:14 PM
> To: [email-masked]
> Subject: Re: [precis] Anybody do any review of NFS documents?
> 
> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis