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
- [nfsv4] Review of draft-ietf-nfsv4-scsi-layout-nv… David Noveck
- Re: [nfsv4] Review of draft-ietf-nfsv4-scsi-layou… Christoph Hellwig
- Re: [nfsv4] Review of draft-ietf-nfsv4-scsi-layou… Thomas Haynes