Skip to main content

YANG Data Models for the Application-Layer Traffic Optimization (ALTO) Protocol
draft-ietf-alto-oam-yang-17

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, alto-chairs@ietf.org, alto@ietf.org, draft-ietf-alto-oam-yang@ietf.org, martin.h.duke@gmail.com, mohamed.boucadair@orange.com, rfc-editor@rfc-editor.org
Subject: 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/


Ballot Text

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.

RFC Editor Note