Hi John Scudder, Lars Eggert, and Éric Vyncke, I sincerely appreciate your comment to improve our Registration Interface YANG Data Model. Patrick and I have addressed your comments with the following revision:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-registration-interface-dm-24 I attach the revision letter. If you have further questions and comments, please let me know. Thanks. Best Regards, Paul On Wed, Apr 12, 2023 at 8:10 PM Lars Eggert via Datatracker < [email protected]> wrote: > Lars Eggert has entered the following ballot position for > draft-ietf-i2nsf-registration-interface-dm-23: Discuss > > 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://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-registration-interface-dm/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > # GEN AD review of draft-ietf-i2nsf-registration-interface-dm-23 > > CC @larseggert > > ## Discuss > > ### Section 5.2, paragraph 21 > ``` > container cpu { > description > "The Central Processing Unit (CPU) specification of the NSF"; > leaf model { > type string; > description > "The model name of the CPU used in the NSF."; > } > ``` > There seems to be an assumption here that an NSF will have a single CPU. > Modern > systems can have several, and they can be of different models (e.g., ARM > big.LITTLE). How does this model represent such systems? > > ### Section 5.2, paragraph 20 > ``` > leaf clock-speed { > type uint16; > units "MHz"; > description > "The number of cycles the CPU executes per second, > measured in MHz (MegaHertz)."; > } > ``` > First, CPUs execute instructions, not cycles, and different instructions > require different amounts of cycles to execute. So I think you mean "clock > speed" here. Second, modern CPUs dynamically vary their clock speed > dynamically > on short timescales. Is this supposed to capture the current clock speed > or a > (theoretical) maximum? What about features such as turbo-boost? > > ### Section 5.2, paragraph 19 > ``` > leaf cores { > type uint8; > description > "The number of independent CPU in a single computing > component."; > } > ``` > A core is not the same as a CPU. Do you mean "cores per CPU" or "CPUs per > chassis"? Or "cores per chassis"? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ## Comments > > ### Section 5.2, paragraph 20 > ``` > leaf speed { > type uint32; > units "MHz"; > description > "The data transfer rate of the memory in MegaHertz (MHz)."; > } > ``` > Why does RAM bandwidth matter but not RAM latency? Also, modern > packet-processing software is written to avoid going over the memory bus > and is > trying to execute in L3 as much as possible - so why does this matter? > > ### Section 5.2, paragraph 20 > ``` > leaf capacity { > type uint32; > units "MB"; > description > "The disk or storage maximum capacity in Megabytes (MB)."; > } > ``` > This only scales to ~4000TB, which seems too small. > > ### Section 5.2, paragraph 22 > ``` > container bandwidth { > description > "Network bandwidth available on an NSF > in the unit of Bps (Bytes per second)"; > > leaf outbound { > type uint64; > units "Bps"; > description > "The maximum outbound network bandwidth available to the > NSF in bytes per second (Bps)"; > } > > leaf inbound { > type uint64; > units "Bps"; > description > "The maximum inbound network bandwidth available to the > NSF in bytes per second (Bps)"; > } > } > } > ``` > Is this per interface or the aggregate ingress/egress bandwidth across all > interfaces? > > ## Nits > > All comments below are about very minor potential issues that you may > choose to > address in some way - or ignore - as you see fit. Some were flagged by > automated tools (via https://github.com/larseggert/ietf-reviewtool), so > there > will likely be some false positives. There is no need to let me know what > you > did with these suggestions. > > ### Typos > > #### Section 5.2, paragraph 6 > ``` > - //RFC Ed.: replace occurences of XXXX with actual RFC number and > + //RFC Ed.: replace occurrences of XXXX with actual RFC number and > + + > ``` > > #### Section 5.2, paragraph 21 > ``` > - "The number of independent CPU in a single computing > + "The number of independent CPUs in a single computing > + + > ``` > > ### Uncited references > > Uncited references: `[RFC7348]` and `[I-D.ietf-nvo3-vxlan-gpe]`. > > ## Notes > > This review is in the ["IETF Comments" Markdown format][ICMF], You can use > the > [`ietf-comments` tool][ICT] to automatically convert this review into > individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. > > [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md > [ICT]: https://github.com/mnot/ietf-comments > [IRT]: https://github.com/larseggert/ietf-reviewtool > > > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf >
Revision-for-draft-ietf-i2nsf-registration-interface-dm-24-20230412.docx.pdf
Description: Adobe PDF document
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
