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.