Re: [nfsv4] Review of draft-ietf-nfsv4-scsi-layout-nvme-01

Thomas Haynes <loghyr@gmail.com> Mon, 13 March 2023 18:53 UTC

Return-Path: <loghyr@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8576EC14EB1E for <nfsv4@ietfa.amsl.com>; Mon, 13 Mar 2023 11:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoWkTIL4yKbD for <nfsv4@ietfa.amsl.com>; Mon, 13 Mar 2023 11:53:26 -0700 (PDT)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92076C14F738 for <nfsv4@ietf.org>; Mon, 13 Mar 2023 11:53:06 -0700 (PDT)
Received: by mail-pj1-x102d.google.com with SMTP id 6-20020a17090a190600b00237c5b6ecd7so17877963pjg.4 for <nfsv4@ietf.org>; Mon, 13 Mar 2023 11:53:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678733586; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=BnojVyyt2FXB20TtzuAtdUgKYpCl7d/BVPd/nZGWGd4=; b=kwL7/Sejn6vYZhR5jgure6N9VYS10ydKs0O2gO7HL391NjC8e+7l+ntNF5z0QCB8jf QwqzldZ1IgUl+mAqczPkFegXeDInn3yKEkOhWK9o5YgISAzBi3RO7vZohcsK1C49mNzU /JJFdLn6p3teJs4PPP63SLR4j35bnAufYTWQ15hQ8YJVZK33nUvclBZsif8VcYorkeER ETSbSUu/LynzGfkisP4xfqBay/COrNB0gtMGiYnH+/GsmCpopJEJRyz8/WECCBzXpmV+ 2S3P0y2Qjg1ngTA+zowrQtp7OjS16U79QuhL+mwxM6ubbgAe3CM6+RePiTQ0uKPJeFbS xPNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678733586; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BnojVyyt2FXB20TtzuAtdUgKYpCl7d/BVPd/nZGWGd4=; b=jaF4GNnGgYHzUJP4n9+dld2Ad9mQ7ExFQ2SZmajz/0OtM94mLi3j8y0E5aX1mA7QhC 2Q4PtNgu4fDmDHTFM6W7GOmtxDyPaxWfsE7G+PDN0miBT+z3cVN4OSXJ1n0lDrCt5BUR imlHzL3Azpp1PyUGyo6/ugJ8C846Upk4t1FgADCFiLQTwOrKD6Od0BYsWvtIhCT9gnnN Io5Qbt9+4AqCQyKJ4OiGcYwUt8eedhlf4A5y9NiZQE0wRCnUm72OaRxW1N7IFWrzlIBI AqunGTWGQn5Nqd/CqnHfsCv64EPsSZqBPL9lI1TrejH78QeFBmOtIk1is77nMHGod58m 1c4g==
X-Gm-Message-State: AO0yUKUsYnIcvJoUFyCb3+fqgu61Cd8wDHV+k8XsIc01xykGHqbe0U+w qu9MIPG2wT2Hd+V+xFhJxT4=
X-Google-Smtp-Source: AK7set9D8qIp8xtBlX7+b80BXlEEVhCpZa8Ac2CtCOJd36XqvtNPOATgmoFQLm3fzo/VGLympxlR0g==
X-Received: by 2002:a17:902:ec81:b0:19c:f888:ad52 with SMTP id x1-20020a170902ec8100b0019cf888ad52mr44526873plg.49.1678733585464; Mon, 13 Mar 2023 11:53:05 -0700 (PDT)
Received: from smtpclient.apple (c-69-181-124-201.hsd1.ca.comcast.net. [69.181.124.201]) by smtp.gmail.com with ESMTPSA id ld8-20020a170902fac800b00194c90ca320sm188287plb.204.2023.03.13.11.53.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2023 11:53:04 -0700 (PDT)
From: Thomas Haynes <loghyr@gmail.com>
Message-Id: <224E7E7B-DB66-48D8-80DE-7DC0D0AC8750@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A9D860B4-78AC-4B1E-AA59-455461F64007"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
Date: Mon, 13 Mar 2023 11:52:53 -0700
In-Reply-To: <20230313175928.GA8491@lst.de>
Cc: David Noveck <davenoveck@gmail.com>, sorin.faibisj@cdsi.us.com, NFSv4 <nfsv4@ietf.org>
To: Christoph Hellwig <hch@lst.de>
References: <CADaq8jd9xw0MR4Egvd9GAddxOBNLNwy+Hwo=B223ZYn-bSqeXw@mail.gmail.com> <20230313175928.GA8491@lst.de>
X-Mailer: Apple Mail (2.3731.400.51.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/HNIDvp5SG7CMrwHUFPYWNUf_4f0>
Subject: Re: [nfsv4] Review of draft-ietf-nfsv4-scsi-layout-nvme-01
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Mar 2023 18:53:28 -0000


> On Mar 13, 2023, at 10:59 AM, Christoph Hellwig <hch@lst.de> wrote:
> 
> Hi Dave,
> 
> sorry for the delay.  I think I've addressed most comments in the just
> uploaded -02, but more comments below.
> 
> On Sat, Jan 21, 2023 at 01:24:51PM -0500, David Noveck wrote:
>> Although the details will be more completely discussed under *Per-section
>> Comments* there seem to  be  cases in which the wording suggests an
>> informational approach that is no longer appropriate  For example, the word
>> "explain" is used in many contexts where it is the job of a standards-track
>> document  to "define" or  "specify" something.
> 
> Agreed.
> 
>> *Issues with bcp14 Terms*
>> 
>> These terms will need to be wrapped in "<bcp14>...</bcp14>.
> 
> As far as I can tell these tags do not exist in the xml2rfc vocabulary.
> Can you provide a reference for this wrapping?
> 

So I’m no longer using xml2rfc at all - with the switch to version 3, I went to a straight .xml file.

You might still be using version 2 in your document?

Look at Section 2.9 of https://datatracker.ietf.org/doc/html/rfc7991





>> *Authors*
>> 
>> I think you need to designate an editor.
> 
> Done.
> 
>> *Title*
>> 
>> Given the decision to make this a standards-track document, feel something
>> like "Use of NVMe-based Transports to Access Block Devices using the SCSI
>> Layout Type" would be more appropriate.
> 
> I agree that the name isn't a little misleading now.  But your
> suggestion seems overly verbose and a little misleading as NVMe
> is not a transport for SCSI, but rather a different protocol
> family.
> 
> We'll look into a different title going forward but haven't agreed on
> one yet.
> 
>> 
>> *Abstract *
>> 
>> I feel "explains" is now inappropriate and suggest a replacement like the
>> following:
>> 
>> Defines the use of block devices accessed by NVMe-based Transports in
>> connection with the pNFS SCSI layout type.
> 
> Fixed.
> 
>> *1. Introduction *
>> 
>> I feel that the first paragraph presumes a lot of knowledge that the
>> authors and most working group members have but that many readers might not
>> have. An example is the use of the term MDS which is never defined in this
>> document.
> 
> Thanks, I've taken up all your suggestions for the introduction.
> 
>> *1.2 General Definitions*
>> 
>> With regard to the definition of "client", I have problems with the use of
>> the word "traditional" in connection with clients embedded within OS's that
>> support multiple applications.  I don't think this belongs here.
> 
> Agreed.
> 
>> With regard to "server", I note that "server" is defined here but never
>> really used in this document, except in the definition of "client".
>> Elsewhere there are references to the metadata server and to the data
>> server. I  think these need to be defined rather than the orphaned term
>> "server".
> 
> Agreed.
> 
>> 
>> *2. SCSI Layout Mapping to NVM*
>> 
>> In the first sentence,
>> 
>> Suggest replacing "only references few" by "references only a few".
>> 
>> Believe "SCSI specific" should be hyphenated.
> 
> Fixed.
> 
>> 
>> With regard to the use of the word  "SHOULD", It is unclear to whom this
>> recommendation is directed.
>> 
>> Recommendations are generally as to what an implementation might do or not
>> do and mapping of concepts doesn't fit that model.
>> 
>> It is hard to conceive of what might be "valid reasons" to do other than
>> what is recommended.
> 
> We've done a scrube of potentially problematic SHOULDs.  Please take
> a look if you still find some that looks problematic to you in -O2.
> 
>> Regarding the banning of the use serial numbers, I agree that they not be
>> allowed but I'm guessing that they were allowed in RFC8154, which calls
>> into question the idea that this spec does not amend RFC8154.  It seems
>> that it does, although for a good reason.
> 
> There is no ammendment here, as there is no equivalent to the SCSI
> Name string in NVMe.  The NVMe serial number is something very different.
> SCSI name string.  I hope the new version makes this a bit more clear.
> 
>> Along these lines, there might need to be some consideration of the case in
>> which the SCSI layout is used to support both SCSI and NVMe-connected
>> devices.  Is it possible that SCSI serial number might conflict with EUI64
>> or NGUID device ids.
> 
> Both of them are defined based on IEEE identifiers that shall be
> globally uniqueue, independent of how they are used.
> 
>> The third paragraph does not make it sufficiently clear what exactly  are
>> the "unique addressing needs" that need to be satisfied.
> 
> What additional information would you like to see here?
> 
>> 
>> *2.2 Client Fencing*
>> 
>> In the second sentence of the first paragraph, suggest replacing "For this"
>> by "For this to be achieved".
>> 
>> In the second paragraph suggest replacing "The following is" by "The
>> following sub-sections (Section 2.2.1 through 2.2.4) provides".
> 
> I've updated this, but without explicitly listing the sections.
> 
>> *2.3 Write Caches*
>> 
>> In this case, it appears that we are not, as with other subsections of *2.0
>> SCSI Layout Mapping to NVMe*, mapping a SCSI operation to an NVMe one. If
>> so,
>> this should be moved to its own top-level section and further tinkering
>> with the statement about not amending RFC8154 might be required.
> 
> This is the NVMe version of section 2.8 in RFC8154, and it is very
> much intendent to translate the SCSI concepts there.  I've added a blurb
> to make that more clear.
> 
>> 
>> *4. Security Considerations *
>> 
>> Think you need to add a new paragraph regarding the obligation of the
>> clients regarding the enforcement of MDS decisions.   I am proposing
>> something like the following after the current first paragraph:
>> 
>> Decisions regarding authorization of particular users to access file
>> objects are made by the MDS and communicated to the clients by the ranting,
>> recall, and revocation of layouts, as described in the definition of
>> the pNFS feature (see [RFC8881}, [RFC8534]).  As a result, the security of
>> the data made available to clients depends on clients not making
>> 
>> IO requests without the appropriate layout.   When clients cannot be
>> trusted to conform to this requirement, direct access to block devices MUST
>> NOT be provided.
> 
> This is all very much in the domain of 8154.  We've added reference
> to the relevant sections of 8154 instead of rehashing this here.
> 
>> 
>> 
>> *5.Normative References *
>> 
>> Feel RFC8534 should be added
>> 
>> 
> 
> RFC8534 is "Explicit Tracking with Wildcard Routes in Multicast VPN".
> Do you mean  RFC8434?  This is not a new layout type, so it's not
> really applicable.
> 
> Thanks a lot again for your review!
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org <mailto:nfsv4@ietf.org>
> https://www.ietf.org/mailman/listinfo/nfsv4