Protocol Action: 'Using the Parallel NFS (pNFS) SCSI Layout to access NVMe storage devices' to Proposed Standard (draft-ietf-nfsv4-scsi-layout-nvme-07.txt)
The IESG has approved the following document: - 'Using the Parallel NFS (pNFS) SCSI Layout to access NVMe storage devices' (draft-ietf-nfsv4-scsi-layout-nvme-07.txt) as Proposed Standard This document is the product of the Network File System Version 4 Working Group. The IESG contact person is Zaheduzzaman Sarker. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-nfsv4-scsi-layout-nvme/ Technical Summary This document specifies how to use the Parallel Network File System (pNFS) Small Computer System Interface (SCSI) Layout Type to access storage devices using the Non-Volatile Memory Express (NVMe) protocol family. Working Group Summary Working group consensus was sufficiently broad across the working group to progress this document. The only controversy about this draft was if IETF and NFSv4 was the right forum and if this draft was in scope. There are agreement within the WG and with the AD that this is within scope. Document Quality 2 independent implementations have been created. This is draft presents an evolution of storage layouts as storage advances and should be implemented more over time. The relevant technical experts to understand NVMe and SCSI are also members of the NFSv4 working group. This document uses NVMe and SCSI but only extends the usage of NFSv4 to newer NVMe and SCSI protocol devices. Personnel The Document Shepherd for this document is Christopher Inacio. The Responsible Area Director is Zaheduzzaman Sarker. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Call for feedback: IESG appointment to the IETF Trust
The IESG is responsible for appointing one person to the IETF Trust for a two-year term that begins in March 2024. Following the call for nominations [1], the following candidates have accepted a nomination: • Kristin Berdan • Donald Eastlake • Stephan Wenger Please send feedback about these candidates to iesg-o...@ietf.org. This feedback will be held in confidence by the IESG. Please provide the feedback by 23:59 UTC on Monday, February 19, 2024. We thank you in advance for your help. IESG Secretary, on behalf of the IESG [1] https://mailarchive.ietf.org/arch/msg/ietf-announce/uAKomeff8C0k0yRmUGv6Ba3QGkY/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
The Tools Team (tools) TEAM Virtual Meeting: 2024-03-05
The The Tools Team (tools) Team will hold a virtual interim meeting on 2024-03-05 from 13:00 to 14:00 America/Chicago (19:00 to 20:00 UTC). Agenda: https://notes.ietf.org/tools-team-20240305 Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=9395eece-168b-4290-bf48-0ca6cd85ed1d -- A calendar subscription for all tools meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=tools ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'YANG Data Models for the Application-Layer Traffic Optimization (ALTO) Protocol' to Proposed Standard (draft-ietf-alto-oam-yang-17.txt)
The IESG has approved the following document: - 'YANG Data Models for the Application-Layer Traffic Optimization (ALTO) Protocol' (draft-ietf-alto-oam-yang-17.txt) as Proposed Standard This document is the product of the Application-Layer Traffic Optimization Working Group. The IESG contact persons are Warren Kumari, Robert Wilton and Martin Duke. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-alto-oam-yang/ Technical Summary This document defines a YANG data model for Operations, Administration, and Maintenance (OAM) & Management of the Application-Layer Traffic Optimization (ALTO) Protocol. The operator of an ALTO server can use this data model to (1) set up the ALTO server, (2) configure server discovery, (3) create, update and remove ALTO information resources, (4) manage the access control of each ALTO information resource, and (5) collect statistical data from the ALTO server. The application provider can also use this data model to configure ALTO clients to communicate with known ALTO servers. Working Group Summary No controversy was raised during the development of this specification. The authors were very responsive in taking care of all the comments and making the required changes. However, there were some aspects that required some cycles before proceeding with the current design in the spec, e.g.,: * How to handle data types defined in ALTO IANA registries and whether to consider an IANA-maintained YANG module based upon these registries. The decision was to make use of plain identities directly into the base ALO module. The reasoning for this decision was that many WG participants think that the registries won't be updated frequently and that having an IANA-maintained module is "overdesign". The Shepherd disagrees with that argument as this questions the value of having the registry in the first place, but this is not a blocking point. Let's hope that netmod WG can revise the YANG Authors Guidelines to include guidelines for IANA-maintained YANG modules. * Whether and how to supply server-to-server communication for multi-domain settings: the decision was to restrict the scope of the discovery, but leave the communication out of scope. * Whether and how to model how ALTO data is aggregated and stored: The decision is to consider these as implementation-specific and out of the scope of the base model. * Notifications for resource limits: the base module includes specific data nodes (notify-res-mem-limit, notify-upd-stream-limit) to trigger notifications. There was an alternate proposal to build on RFC 8632 but that was considered as more complex to integrate. * During the AD review, text about data sources was removed as out of scope for the working group. Document Quality There is one known implementation. Personnel The Document Shepherd for this document is Mohamed Boucadair. The Responsible Area Director is Martin Duke. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
New Non-WG Mailing List: bof-srv6ops (BoF-SRv6-Operations)
A new IETF non-working group email list has been created. List address: bof-srv6...@ietf.org Archive: https://mailarchive.ietf.org/arch/browse/bof-srv6ops/ To subscribe: https://www.ietf.org/mailman/listinfo/bof-srv6ops Purpose: This list is for planning and preparation for a possible BoF on SRv6 Operations at IETF119 (Brisbane). The BoF request is here: https://datatracker.ietf.org/doc/bofreq-liu-srv6-operations/ Note: This is a temporary list for the BoF planning, preparation, discussion, etc., and will be deleted at some point in the future. If a WG is formed, there will be a new list created for that purpose. This list belongs to IETF area: OPS For additional information, please contact the list administrators. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Conclusion of Light-Weight Implementation Guidance (lwig)
The Light-Weight Implementation Guidance (lwig) WG in the Internet Area has concluded. The IESG contact persons are Erik Kline and Éric Vyncke. LWIG is now closed. The one working group document (draft-ietf-lwig-curve-representations) will become AD-sponsored but retain its current datatracker state. Any significant discussion about this document will find a suitable forum, if needed. The working group mailing list will remain open, but discussion is recommended to move to other fora, such as IOTOPS WG (iot...@ietf.org). Thanks to all who participated, contributed text, and chaired. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
