Subject: [nfsv4] pnfs: issue 57: private layout ranges and IANA

From: Garth Goodson <[email-masked]>
Date: Wed, 21 Jun 2006 15:57:29 -0700

Here is an outline of the current proposal a few of us discussed 
off-list.  We want:

1) IANA defined layout types, however review/approval of the 
IETF/NFSv4-working-group is necessary before being accepted by IANA

2) IANA defined experimental range

I'll try to put together some text of an initial draft of the IANA 
section and will send to the WG for review.

-Garth

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Lars Eggert <[email-masked]>
Date: Tue, 27 Jun 2006 09:55:08 +0200

On Jun 22, 2006, at 0:57, Garth Goodson wrote:
> 1) IANA defined layout types, however review/approval of the IETF/ 
> NFSv4-working-group is necessary before being accepted by IANA

The registration policy "review/approval of the IETF/NFSv4-working- 
group is necessary" is problematic, because a WG is ephemeral.

Please check Section 2 in RFC2434 for usual registration policies.  
(I'd guess you probably want "Expert Review" or "Specification  
Required"?)

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

---

From: Mike Eisler <[email-masked]>
Date: Tue, 27 Jun 2006 07:35:08 -0700 (PDT)

> IETF/NFSv4-working-group is necessary before being accepted by IANA

If IETF approved layout types are needed, why does IANA need to be
involved? 

> 2) IANA defined experimental range

What is the motivation for this? I thought the point of pNFS
was to bring the NFS-like parallel file systems in from the
cold, not continue balkanization. My fear is that vendors
will extend NFSv4.x in incompatible ways that prevent
others from playing and still call it NFSv4.x.

In the past, we've successfully resisted inventing 
ways to allow private extensions, including dealing with
the FUD that minor versions would be used to for vendor
specific extensions.

Anyway, I suggest not going the IANA route (you are already
getting resistance from IESG I see :-), and look to
leverages that already registries. E.g. 

- DNS doman names (which NFSv4 uses for uids and gids)
- Object Identifiers (OIDS) which the GSS standard and other
  standards use for tagging algorithms and other concepts.
- uuids

The idea is that a private layout type could be presented in the
form of an OID or domain name, and if shorthand is necessary
due to the layout type appearing frequently, then the server could
assign a temporarty layout type as a 32 bit integer.

---

From: Garth Goodson <[email-masked]>
Date: Tue, 27 Jun 2006 08:43:17 -0700

> If IETF approved layout types are needed, why does IANA need to be
This can be put up for discussion.  I do not the pros/cons of IANA.  But 
I thought it was generally agreed that IANA registration of types was a 
'good thing'.

> the FUD that minor versions would be used to for vendor
This range would be private.  It would not be for vendor extensions. 
Groups such as the National Labs would like a range that could be used 
internally only and would like a range which they could use which would 
not conflict with any other defined range.

> assign a temporarty layout type as a 32 bit integer.
I'm not sure what you are refering to regarding an OID or domain name 
for layout types.  A layout type is simply an integer ID.

-Garth