Gen-ART LC Review of draft-ietf-nfsv4-pnfs-block-09

[Ben Campbell <ben at estacado.net>]

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.


Document: draft-ietf-nfsv4-pnfs-block-09
Reviewer: Ben Campbell
Review Date:  2008-11-04
IETF LC End Date: 2008-11-27

Summary:

This draft is almost ready for publication as a proposed standard. I  
have a couple of questions that I think should be considered first,  
and a couple of nits.

Comments:

[Disclaimer]

While it is normal for a Gen-ART reviewer to be inexpert in the  
subject matter being reviewed, I found myself feeling much more  
inexpert than usual while reviewing this draft. This is due to the  
subject matter, not the presentation, which seems to be clear in  
general.


[substantive]

-- Section 2.3.4, second paragraph, last sentence:

> This policy SHOULD be implemented when
>    storage devices do not provide atomicity for concurrent read/write
>    and write/write operations to the same data.

I wonder why that's not a MUST. It seems like the result of neither  
providing atomic operations, or implementing this policy, would result  
in corruption, right? Isn't it safe to say that the client MUST NOT  
create corruption?

-- Section 3, paragraph 2:

> In environments where the
>    security requirements are such that client-side protection from
>    access to storage outside of the layout is not sufficient pNFS
>    block/volume storage layouts for pNFS SHOULD NOT be used, unless  
> the
>    storage device is able to implement the appropriate access checks,
>    via use of virtualized block addresses, or other means.

Maybe this is my ignorance of the subject talking, but I have to  
wonder what sort of environment might exist where it is sufficient to  
allow client-side protection only for this sort of thing. It seems  
like a malicious client could cause all sorts of mayhem.


[Nits and Editorial]

-- IDNITs reports that Page 1 is too long (59 lines)

-- Section 2.2.2, last paragraph:

> In the case of the server
>    returning NFS4ERR_TOOSMALL the client SHOULD allocate a buffer of  
> at
>    least gdir_mincount_bytes to contain the expected result and retry
>    the GETDEVICEINFO request.

Should this be GETDEVICELIST? I don't see a prior reference to an  
initial GETDEVICEINFO request.

Thanks!

Ben.


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf