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.