Application-Layer Traffic Optimization (ALTO) Deployment Considerations
draft-ietf-alto-deployments-16

[Ballot comment]
Carlos pignataros opsdir review.

Hi!

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of the
IETF drafts. Comments that are not addressed in last call may be included in AD reviews
during the IESG review.  Document editors and WG chairs should treat these comments
just like any other last call comments.

Summary: Ready with issues

This is a very comprehensive (verbose) document, very well written. It considers operational issues throughout, and expires them in detail.

Major:

1. I came across two patent applications in which the examiners add this document as a non-patent citation. The document has no IPR disclosures, and authors seem to have responded to IPR calls.

I will submit 3rd party disclosures for these now, there may be more:
http://www.google.com/patents/EP2913979A1#npl-citations
http://www.google.com/patents/WO2016039798A1#npl-citations


Minor:

Section 3.2.2

1. Should PCE be a clear data source here?

2. Figure 8 — This figure lists the data sources, and where to retrieve data (the “how” via BGP/I2RS/NETCONF), but not too much about the “what data”. Is it only Topology? The BGP and I2RS sources are clear in terms of what information can provide, but SNMP/NETCONF can be pretty much anything, and then there’s IPFIX for flow info. Making explicit that this is Topology would help.

3. Figure 8 — NMS/OSS —> RESTCONF?

4. Page 23, first bullet — From an Operational standpoint, in the context of I2RS as a data source, it would be useful to reference draft-ietf-i2rs-traceability. Additionally, in terms of collecting topological data, I wonder if it would help to reference draft-ietf-i2rs-yang-network-topo.

5. Page 23, second bullet — says:
      Information Export (IPFIX), as well as other Operations,
      Administration, and Maintenance (OAM) information (e.g., syslog).
But syslog (and traceability in general) is not OAM. Would ALTO benefit from reading information from or using actions from OAMs (BFD, performance management, etc)?

Section 3.2.4

6. “Performance-related criteria” — it would be beneficial, from an Operational standpoint, to show or list IPPM specifics or other PM as OAMs which can be used.

Section 3.4.4

7. The first “poet nail source” says “OAM”, but it really is referring to OSS which in turn can use OAM. Interestingly, the monitoring only reads data; however, a missed opportunity here is to actually trigger OAM and generate actions to generate OAM to test topology or traffic. I do not know enough about ALTO to conclusively know if this is a gap or not.

8. Section 10, Acknowledgements. Some Authors are Acknowledged in the Acknowledgements section. Others are not. It is not clear the contribution scope.


Nits:

1. Acronyms — the document contains an immense amount of acronyms. They are all, it appears, very well expanded on first use. It would help, however, to have an Acronyms section.

2. Section 6.1. Thank you *very* much for explaining clearly what is meant by “VPN”!

I hope these are clear and useful.

Best,

Carlos Pignataro.


_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

[Ballot comment]
There's a 2 day old (at the time of this writing) IPR disclosure. It seems rather unusual, and I am not sure of the intent.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-alto-deployments-15.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: alto@ietf.org, mls.ietf@gmail.com, ietf@kuehlewind.net, draft-ietf-alto-deployments@ietf.org, alto-chairs@ietf.org, vkg@bell-labs.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (ALTO Deployment Considerations) to Informational RFC


The IESG has received a request from the Application-Layer Traffic
Optimization WG (alto) to consider the following document:
- 'ALTO Deployment Considerations'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-06-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Many Internet applications are used to access resources such as
  pieces of information or server processes that are available in
  several equivalent replicas on different hosts.  This includes, but
  is not limited to, peer-to-peer file sharing applications.  The goal
  of Application-Layer Traffic Optimization (ALTO) is to provide
  guidance to applications that have to select one or several hosts
  from a set of candidates, which are able to provide a desired
  resource.  This memo discusses deployment related issues of ALTO.  It
  addresses different use cases of ALTO such as peer-to-peer file
  sharing and CDNs and presents corresponding examples.  The document
  also includes recommendations for network administrators and
  application designers planning to deploy ALTO, such recommendations
  how to generate ALTO map information.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-alto-deployments/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-alto-deployments/ballot/


No IPR declarations have been submitted directly on this I-D.

PROTO writeup for alto-deployment-considerations

1. Summary.

Vijay K. Gurbani is the document shepherd for draft-alto-deployments draft.
Spencer Dawkins was the responsible AD throughout the last few versions of the
draft, however, that benefit transferred to Mirja Kuhlewind around IETF 95
(Buenos Aires).

The document itself has a long and varied history, having started life off as
a -00 document targeted to the ALTO WG as an individual (original authors:
Martin Stiemerling and Sebsatian Kiesel, March 1, 2010).  It transitioned to a
WG document in February 2011 with the original two authors and continued on
revision trajectory until version -04 when new authors were added.

The document distills and prescribes recommendations for network
administrators and application designers planning to deploy ALTO, including
recommendations on how to generate the ALTO map information and known
limitations of the ALTO protocol (rfc7285).  Furthermore, the document
provides guidance for the use of ALTO in diverse environments, including P2P
traffic optimization, CDN considerations, application guidance in VPNs, to
name a few examples.

The working group is targeting this document as an Informational, which is the
appropriate track the document should be on based on the nature of its
prescriptions and recommendations.  The document does not introduce any new
protocol elements, nor does it subvert --- positively or negatively --- the
usage of the protocol in any given particular environment (i.e., CDNs, VPNs,
or P2P environments).

2. Review and Consensus.

The draft has consensus from the WG and has been well-reviewed.  There have
been two WGLCs for this draft: Version -11 of the draft was last-called
between the time period of April 28, 2015 to May 17, 2015.  During this
period, the draft was reviewed in detail by Wendy Roome.  Wendy found several
minor issues and nits and a couple of major issues, all of which were
readily addressed in version -12 (June 2015).

Pursuant to an ALTO virtual meeting held on October 27, 2015, it became
apparent that draft-siedel-alto-map-calculation could inform
draft-ietf-alto-deployments.  The authors of the two drafts were requested to
make a determination whether portions of the former could be included in the
latter.  By November 2015, a determination was made that relevant portions
from the map-calculation draft could be put into the deployment-considerations
draft.  The issue at hand after this was done was whether the changes
percolated widely enough to have a second WGLC.  By Jan 2016, it was decided
that a second WGLC was likely, and thus a second one was issued that ended
on February 3, 2016.  The second WGLC was reviewed by Sabine Randriamasy,
resulting in version -14 that addressed her review.

In summary, the deployment draft has had excellent support from the working
group, has been reviewed on multiple occasions by various members of the
working group and has been last-called twice to account for the expanded role
it took on as the working group became aware of the growing deployment of the
ALTO protocol.

3. Intellectual Property.

The shepherd confirms that each author has stated to him (and ALTO co-chairs)
their direct, personal knowledge that the authors are not aware of any IPR
related to this document.

To the best of the shepherd's knoweldge, there has not been any discussions on
IPR related to this document on the ALTO WG mailing list.

4. Other Points.
The following should be fixed during Auth48:
  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  == Outdated reference: draft-ietf-dnsop-edns-client-subnet has been
    published as RFC 7871

  == Outdated reference: A later version (-15) exists of
    draft-ietf-i2rs-architecture-13