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

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.

Brian Carpenter's Gen-ART review comments may be worth observing (though are minor; do not prevent approval).

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