[nfsv4] Re: Gunter Van de Velde's No Objection on draft-ietf-nfsv4-delstid-05: (with COMMENT)

["Gunter van de Velde (Nokia)" <[e-mail]>]

Thanks for the update.

Be well,
G/

-----Original Message-----
From: Thomas Haynes <[e-mail]> 
Sent: Thursday, August 22, 2024 6:03 PM
To: Gunter van de Velde (Nokia) <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; nfsv4-chairs <[e-mail]>; [e-mail]
Subject: Re: [nfsv4] Gunter Van de Velde's No Objection on draft-ietf-nfsv4-delstid-05: (with COMMENT)

[You don't often get email from [e-mail]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



> On Aug 19, 2024, at 10:15 AM, Gunter Van de Velde via Datatracker <[e-mail]> wrote:
>
> Gunter Van de Velde has entered the following ballot position for
> draft-ietf-nfsv4-delstid-05: No Objection
>
> When responding, please keep the subject line intact and reply to all 
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
>
>
> Please refer to 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positi
> ons%2F&data=05%7C02%7Cgunter.van_de_velde%40nokia.com%7C2f7d4fb6d77f40
> b61ae308dcc2c3e62b%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638599
> 393848912006%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=l%2Bfzm4lcAj8Ebnn
> ZRO27Wcz0ym0Ls4S458FzrT3jr9k%3D&reserved=0
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-nfsv4-delstid%2F&data=05%7C02%7Cgu
> nter.van_de_velde%40nokia.com%7C2f7d4fb6d77f40b61ae308dcc2c3e62b%7C5d4
> 717519675428d917b70f44f9630b0%7C0%7C0%7C638599393848927958%7CUnknown%7
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
> CI6Mn0%3D%7C0%7C%7C%7C&sdata=qHjFsejXpZGRa%2F2g871Hp1XQClojWC9eKWWUvNg
> Cglw%3D&reserved=0
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> # Gunter Van de Velde, RTG AD, comments for 
> draft-ietf-nfsv4-delstid-05
>
> Many thanks for writing this document.
>
> Please find next some observations and non-blocking comments 
> encountered during my processing of this work. I am not very familiar 
> with NFS technologies, hence maybe some of my observations and comments could be due to unexperienced.
>


Hi Gunter,

Thanks for the review, responses inline.


> Please find 
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fblog%2Fhandling-iesg-ballot-positions%2F&data=05%7C02%7Cgun
> ter.van_de_velde%40nokia.com%7C2f7d4fb6d77f40b61ae308dcc2c3e62b%7C5d47
> 17519675428d917b70f44f9630b0%7C0%7C0%7C638599393848939010%7CUnknown%7C
> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> I6Mn0%3D%7C0%7C%7C%7C&sdata=2xRIOYyHppguDyaV8kJ6hPoadHg%2F%2B9cbybVyE7
> sO6tw%3D&reserved=0
> documenting the handling of ballots.
>
> #DETAILED COMMENTS
> #=================
> ##classified as [minor] and [major]
>
> 10      Abstract
> 11
> 12         The Network File System v4 (NFSv4) allows a client to both open a
> 13         file and be granted a delegation of that file.  This delegation
> 14         provides the client the right to authoritatively cache metadata on
> 15         the file locally.  This document presents several extensions for both
> 16         the opening and delegating of the file to the client.  This document
> 17         extends both NFSv4.1 (see RFC8881) and NFSv4.2 (see RFC7863).
>
> [major]
> The title of the document says "Extending the Opening of Files in NFSv4.2"
> however the abstract says that this works extends both NFSv4.1 (see 
> RFC8881) and NFSv4.2 (see RFC7863)


I had a big argument to support this, but I realized it was wrong.

So I have fixed this to just mention NFSv4.2.



>
> 88         authority for the file's metadata and data.  This document presents a
> 89         number of extensions which enhance the functionality of opens and
> 90         delegations.  These allow the client to:
>
> [minor]
> cosmetic rewrite textblob proposal
>
> "
> This document introduces a set of extensions designed to enhance the 
> functionality of file opens and delegations. These extensions enable 
> the client
> to: "
>
> 98         *  during the OPEN procedure, get either the open or delegation
> 99            stateids, but not both.
> 100
> 101        *  cache both the access and modify times, reducing the number of
> 102           times the client needs to go to the server to get that
> 103           information.
>
> [minor]
> stateid is speciefied in
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Frfc7530%23section-9.1.4&data=05%7C02%7
> Cgunter.van_de_velde%40nokia.com%7C2f7d4fb6d77f40b61ae308dcc2c3e62b%7C
> 5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638599393848947998%7CUnknow
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> JXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Tjme3XNw3a7%2BGm4hgDzS8yxrU4yZW%2B7SjG
> IAgHUs87E%3D&reserved=0

I’ve pointed to Section 1.7 of RFC8881 - ehh, strike that 9.1.4 of RFC7530 is better.



>
> [minor]
> cosmetic rewrite textblob proposal
>
> "
> * During the OPEN procedure, retrieve either the open stateid or 
> delegation stateid, but not both simultaneously.
>
> * Cache both the access and modify timestamps, thereby reducing the 
> frequency with which the client must query the server for this information. "
>


I’ve taken the above changes.




> 105        Using the process detailed in [RFC8178], the revisions in this
> 106        document become an extension of NFSv4.2 [RFC7862].
>
> [major]
> See earlier in the abstract where is indicated that NFS4.1 is extended 
> too


Already fixed the abstract.


>
> 147        A compound with a GETATTR or READDIR can report the file's attributes
> 148        without bringing the file online.  However, either an OPEN or a
> 149        LAYOUTGET might cause the file server to retrieve the archived data
> 150        contents, bringing the file online.  For non-pNFS systems, the OPEN
> 151        operation requires a filehandle to the data content.  For pNFS
> 152        systems, the filehandle retrieved from an OPEN need not cause the
> 153        data content to be retrieved.  But when the LAYOUTGET operation is
> 154        processed, a layout type specific mapping will cause the data content
> 155        to be retrieved from offline storage.
>
> [minor]
> I am not familiar with terminology as GETATTR, READDIR, LAYOUTGET, 
> pNFS Should refereces be added if these are not wellknown in the technology area?


I added references….


>
> 157        If the client is not aware that the file is offline, it might
> 158        inadvertently open the file to determine what type of file it is
> 159        accessing.  By interrogating the new attribute FATTR4_OFFLINE, a
>
> [minor]
> Is FATTR4_OFFLINE a particular abbreviation for something of meaning?
> (i have no NFS experience)


Yes, it is how we define an id for an attribute.

FATTR - file attribute
4 - major version number
OFFLINE - specific attribute.

NFS implementors would easily understand this point.



>
> 170        /// typedef bool            fattr4_offline;
>
> [minor]
> Here lower case is used, while earlierand later the same with upper 
> case is used? Is this intentional?


Again, yes.

Sadly, there is no reference to provide for this.

Basically, we have an attribute type, in all lower case and an attribute id, all in upper case.


>
> 189        The fattr4_open_arguments attribute is a new XDR extension which
>
> [minor]
> Should this attribute be upper case FATTR4_OPEN_ARGUMENTS ?

Looking at RFC8881, it appears that to be consistent, I should be using the attribute in all lower case.

I will modify the document to reflect that convention.

I really want to thank you on this one!

>
> 465        only supports NFSv4.2.  An implementation could add a NFSv3 server
> 466        which is a NFSv4.2 client gateway the two incompatible systems.  As
>
> [minor]
> The phrase seems wrong? What about:
>
> "
> An implementation may introduce an NFSv3 server that functions as an 
> NFSv4.2 client, serving as a gateway between the two otherwise incompatible systems. "
>
>


Ack



>
> _______________________________________________
> nfsv4 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]