Return-Path: 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 14883C14F70B for ; Sat, 17 Aug 2024 05:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 1YEX9K7esKbD for ; Sat, 17 Aug 2024 05:17:33 -0700 (PDT) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5D2C14F5FA for ; Sat, 17 Aug 2024 05:17:33 -0700 (PDT) Received: by mail-yb1-xb31.google.com with SMTP id 3f1490d57ef6-e02b79c6f21so3098582276.2 for ; Sat, 17 Aug 2024 05:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723897052; x=1724501852; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Wg5rpiTQq7WRuBi9qmqRGLqdkAogHuAGkxa9y6M8xus=; b=BP1nCNZdYaCZtQ471yCwUMJCOOVBAvlY+hffR1iO018jGRugF80WIbc8JARSHS8oJH 84/+pL6eHq0moDQJOtkV5Qbk0dcjHOov5TZXuhvoC+yHB+304BTXbV08hYUjDv2Wh/jV McpdSUY9bQ92OHMUkK/fh23WHDQ9OYlfdLt9wFgDslWGWQWTWVeRX8C8fOu8+MrMzGfD cRo9Xnfb+rsB5Is6sNE50r0kjvAL70vHMmPmZvoTLj0d9PEeBOQiXX0Cx6SHqBxxbF5H QQ3oeRFOsSGiT79GEwbj/AJW7RIIhoSLuqhJI/xDO9deEm5eFXaTQdracsenXhB/u/bp 0rkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723897052; x=1724501852; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Wg5rpiTQq7WRuBi9qmqRGLqdkAogHuAGkxa9y6M8xus=; b=Qm1fMeHJvRMMjiTqxuHn9C3tggBhKngnCWj0nLa2Pj/y6j8iJMfdCIPIMOitvqtpe/ sIqzkxv1lxgFEUU6QERJ/w/ONbVZHDNOa4rcwhfiDTHliCnbGgSElZ8a1IaiVo0Z7xA8 nCPw5ebLo6+B9M+LCvBmVN6D/+6mFKeuWNEGmXU3Q9oI9llHVMSvYwzLgcZhauTWm0Bd FHh6ZJuk04nvwtlpFbfyjR6385gA/jDqvBXG3e78sXMj6Q2TwvCrhVLcjtTD4xw6on7s kx4Uh2dOeaOTrU4pGn55eCBWCU2YEMaDjwzUMu6zHCdA94+Ske+z4k41UIPJ6wziMIPn UuBQ== X-Gm-Message-State: AOJu0YwoaFA7cLMEMy1TiNboLis39qomceArNu5i/OECXQkyUXHbHkD3 s4lPDuD8WgYDMbzXqj6HsC6vQMvWM1hoWAP0tr2rJqsNlSETtAsolbuu1rH4T2+9rkK7XfCrjjs val69DZ+NNTFNgIa2Q3oq71fel0Y= X-Google-Smtp-Source: AGHT+IE+tgr1djY+Zd6Io+/EPGNJ39zpy4T3kGdF99pEdyV8tPKIjgIhMaVDNaBDUmgFcj49tcvSufJm0HIJ+v+26S4= X-Received: by 2002:a05:6902:13c2:b0:e0b:a5c3:828b with SMTP id 3f1490d57ef6-e1180fc5496mr6556954276.53.1723897052263; Sat, 17 Aug 2024 05:17:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Noveck Date: Sat, 17 Aug 2024 08:17:21 -0400 Message-ID: To: Zaheduzzaman Sarker Content-Type: multipart/alternative; boundary="0000000000006dff90061fe00fb4" Message-ID-Hash: XS54RYGOBEVZSL63HT37EZ7H4F4ETGPO X-Message-ID-Hash: XS54RYGOBEVZSL63HT37EZ7H4F4ETGPO X-MailFrom: davenoveck@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-nfsv4.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: NFSv4 X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bnfsv4=5D_Re=3A_AD_review_=3A_draft-ietf-nfsv4-layoutwcc-02?= List-Id: NFSv4 Working Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000006dff90061fe00fb4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 14, 2024, 11:56=E2=80=AFAM Zaheduzzaman Sarker < zahed.sarker.ietf@gmail.com> wrote: > Hi, > > > > I have now reviewed the draft-ietf-nfsv4-layoutwcc and I think this > document need to improve the writing. Hence please respond to the comment= s > and resolve them. > > > > I have done this review as If I don't really understand NFSv4 and NFSv3 > (which might be anyway true) and tried to reflect on things that was > unclear in the description. > > > > I hope this review helps and feel free to take the opportunity to educate > me. > > > > //Zahed > > > > > > > > My section by section comments are below - > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > # Abstract > > s/This document presents a refinement to RFC8435 to allow the client > to update the metadata server to changes on the data server/ This documen= t > updates RFC8435 to allow the client to update the metadata server to > changes on the data server. > > > > This makes it clear that the current specification will update RFC > 8435. > > > > However, to me it is still not super clear if we are updating RFC 843= 5 > or extending RFC 7862. > I think both are done. What is the rationale here for the update tag? > I believe it is necessary since, anyone implementing RFC8435 needs to know about the additions in this document. > > # Section 1 > > > > My initial assumption was that we have a useful feature with WCC for > NFv3 that we would like to allow for NFv4 with LAYOUT-WCC. However, the > more I read Section 1 and Section 2, I am getting more confused as the > description of NFSv4 and NFv3 is very intertwined. Either my assumption i= s > wrong > It isn't. or the text should be improved, either case I think the following would > help. > > - let=E2=80=99s assume the reader will read this as a starting do= cument (I > think this will be true for the most of the reviewers in the process) > True but I think that the people Tom was writing for are very different from the reviewers. I believe he was writing for those who had or might implement RFC8435. > hence, let's describe the scenario better for them and not assume they > understand and know the difference between NFv4 and NFSv3 by heart. Hence= , > providing right reference is the right tools here. Also make sure we writ= e > > - the version of NFS the metadata server is running or does i= t > even matter > It matters. It has to be NFSv4.2, at least. - short description of the WCC and reference the RFC for the details > - Lets keep all the NFv3 related details in the Introduction > section. This means describe some of the basic concepts those are describ= ed > in different sub-sections of section 2 in Section 1, and focus on NFSv4 > specifics in section 2 and 3. This means already in introduction we write > the relation of NFSv3 GETATTR to NFv4 GETATRR and who sends them , etc. a= s > a base to understand the extension are doing in the rest of the sections. > > - Make sure we are specific about the extension we are doing in > this specification - are we writing this specification only for NFSv4 > client or the client's NFV version does not matter? If the client learns > gid and uid from via NFSv3 how that is done and why that is important her= e. > This pops up if I read the following sentence - > > > > "In this document, we introduce a new operation > called LAYOUT_WCC which allows the client to periodically report the > attributes of the data files to the metadata server." > My impression was that the attribute were the ones changed by doing WRITEs, not including uid and gid. Not sure what to make of later references to these. > > > > # Section 2.1 > > > > Please provide the reference to the data types of the structs > > > > # Section 2.3 > > > > It not clear if the extension is for NFSv4 only or it can also replac= e > WCC for NFSv3. > It can't. > > Why are first 3 paragraph relevant at all? what is the relation of > this description to the extension? > > > > Overall, sometimes it is not clear in the text on who does what. I > think we can do a better job of stating what is client's responsibility a= nd > what is metadata server's. This might be get cleared automatically when w= e > have a better split between the section 1 and section 2 > > > > # Section 2.4.1 > > > > - Please provide reference to mtime, atime and all the attribute > mentioned (size, space_used, change, time_access, time_metadata, and > time_modify.). > > - it says - > > > > Whenever it sends an NFS4ERR_ACCESS error via LAYOUTRETURN or > LAYOUTERROR - it could have already gotten the NFSv3 uid and gid values > back in the WCC of the WRITE, READ, or COMMIT operation which got the err= or. > > > > I am a bit confused here, just reading the text here, are you > saying the client had got some attributes via NFSv3 but when error occurs > it uses NFv4 LAYOUT-WCC to report? > > > > # Section 2.5 > > > > We should be very clear that we are not defining any new ERROR for > LAYOUT_WCC if that is the case and reference to where the errors are > defined. Otherwise, we need to explain each and every errors here in this > document, that would be cumbersome or repeating. > > > > # Section 5 IANA considerations : > > > > Please provide more details on which IANA registry to be > updated/amended for the new entries. > _______________________________________________ > nfsv4 mailing list -- nfsv4@ietf.org > To unsubscribe send an email to nfsv4-leave@ietf.org > --0000000000006dff90061fe00fb4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Aug 14, 2024, 11:56=E2=80=AFAM Zaheduzzaman Sa= rker <zahed.sarker.ietf@g= mail.com> wrote:

Hi,

=C2= =A0

I hav= e now reviewed the draft-ietf-nfsv4-layoutwcc and I think this document need to improve the writing. Hence please respond to th= e comments and resolve them.

=C2= =A0

I hav= e done this review as If I don't really understand NFSv4 and NFSv3 (which might be anyway true) and tried to reflect on things that was unclear in the description.

=C2= =A0

I hop= e this review helps and feel free to take the opportunity to educate me.

=C2= =A0

//Zah= ed

=C2= =A0

=C2= =A0

=C2= =A0

My se= ction by section comments are below -

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=C2= =A0

# Abs= tract

=C2= =A0 =C2=A0 s/This document presents a refinement to RFC8435 to allow the client to update the metadata server to changes on the data server/ This document updates RFC8435 to allow the client to update th= e metadata server to changes on the data server.

=C2= =A0

=C2= =A0 =C2=A0 This makes it clear that the current specification will update RFC 8435.

=C2= =A0

=C2= =A0 =C2=A0 However, to me it is still not super clear if we are updating RFC 8435 or extending RFC 7862.


I think both are do= ne.

What is the rationale he= re for the update tag?

I believe it is necessary since, anyone implementi= ng RFC8435 needs to know about the additions in this document.

=C2= =A0

# Sec= tion 1

=C2= =A0

=C2= =A0 =C2=A0 My initial assumption was that we have a useful feature with WCC for NFv3 that we would like to allow for NFv4 with LAYOUT-WCC. However, the more I read Section 1 and Section 2, I am getting = more confused as the description of NFSv4 and NFv3 is very intertwined. Either m= y assumption is wrong

It isn't.

or the text should be improved, either case I think the following would help.

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 - let=E2=80=99s assume the reader will read this as a starting document (I think this will be true for the mo= st of the reviewers in the process)


True but I think that the people Tom = was writing for are very different from the reviewers.=C2=A0 I believe he w= as writing for those who had or might implement RFC8435.=C2=A0 =C2=A0
=

hence, let's describe the scenario better for them and not assume they understand and know the difference between NFv4 an= d NFSv3 by heart. Hence, providing right reference is the right tools here. A= lso make sure we write

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - the version of NFS the metadata server is running or does it even matter


It matter= s. It has to be NFSv4.2, at least.

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- short description of the WCC and reference the RFC for the details
<= div dir=3D"ltr">

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 - Lets keep all the NFv3 related details in the Introduction section. This means describe some of th= e basic concepts those are described in different sub-sections of section 2 i= n Section 1, and focus on NFSv4 specifics in section 2 and 3. This means alre= ady in introduction we write the relation of NFSv3 GETATTR to NFv4 GETATRR and = who sends them , etc. as a base to understand the extension are doing in the re= st of the sections.

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 - Make sure we are specific about the extension we are doing in this specification - are we writing thi= s specification only for NFSv4 client or the client's NFV version does no= t matter? If the client learns gid and uid from via NFSv3 how that is done an= d why that is important here. This pops up if I read the following sentence -=

=C2= =A0

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"In this document, we introduce a new opera= tion called LAYOUT_WCC which allows the client to periodically report the attrib= utes of the data files to the metadata server."


My impression was that= the attribute were the ones changed by doing WRITEs, not including uid and= gid. Not sure what to make of later references to these.

=C2= =A0

=C2= =A0

# Sec= tion 2.1

=C2= =A0

=C2= =A0 =C2=A0 Please provide the reference to the data types of the structs

=C2= =A0

# Sec= tion 2.3

=C2= =A0

=C2= =A0 =C2=A0 It not clear if the extension is for NFSv4 only or it can also replace WCC for NFSv3.


It can't.

=C2= =A0

=C2= =A0 =C2=A0 Why are first 3 paragraph relevant at all? what is the relation of this description to the extension?

=C2= =A0 =C2=A0

=C2= =A0 =C2=A0 Overall, sometimes it is not clear in the text on who does what. I think we can do a better job of stating what is client's responsibility and what is metadata server's. This might b= e get cleared automatically when we have a better split between the section 1 and section 2

=C2= =A0

# Sec= tion 2.4.1

=C2= =A0

=C2= =A0 =C2=A0 - Please provide reference to mtime, atime and all the attribute mentioned (size, space_used, change, time_access, time_metadata, and time_modify.).

=C2= =A0 =C2=A0 - it says -

=C2= =A0

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Whenever it sends an NFS4ERR_ACCESS error via LAYOUTRETURN or LAYOUTERROR - it could ha= ve already gotten the NFSv3 uid and gid values back in the WCC of the WRITE, R= EAD, or COMMIT operation which got the error.

=C2= =A0 =C2=A0

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 I am a bit confused here, just reading the text here, are you saying the client had got some attribut= es via NFSv3 but when error occurs it uses NFv4 LAYOUT-WCC to report?

=C2= =A0

# Sec= tion 2.5

=C2= =A0

=C2= =A0 =C2=A0 We should be very clear that we are not defining any new ERROR for LAYOUT_WCC if that is the case and reference to where the errors are defined. Otherwise, we need to explain each and every errors here in this document, that would be cumbersome or repeating.

=C2= =A0

# Sec= tion 5 IANA considerations :

=C2= =A0

=C2= =A0 =C2=A0 Please provide more details on which IANA registry to be updated/amended for the new entries.=C2=A0

_______________________________________________
nfsv4 mailing list -- nfsv4@ietf.org
To unsubscribe send an email to nfsv4-leave@ietf.org
--0000000000006dff90061fe00fb4--