On Nov 18, 2008, at 4:52 PM, [EMAIL PROTECTED] wrote:
Ben,
Thanks for doing this review.
-- 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?
That's actually from 2.3.5, and yes, we'll do something like that -
a MUST or MUST NOT is clearly called for here.
Good, thanks!
-- 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.
The motivation is a physically isolated SAN where all the servers are
trusted. FWIW, early versions of this technology worked over parallel
SCSI cables, and the block layout is designed to be used this way if
desired.
Ok, understood.
[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.
I believe you've found a think-o. We'll double-check this and correct
it.
Great, thanks!
Thanks,
Ben.
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[EMAIL PROTECTED] Mobile: +1 (978) 394-7754
----------------------------------------------------
-----Original Message-----
From: Ben Campbell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 04, 2008 5:51 PM
To: General Area Review Team; Black, David; fridella,
stephen; [EMAIL PROTECTED]
Cc: Lars Eggert; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Gen-ART LC Review of draft-ietf-nfsv4-pnfs-block-09
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.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
