Last Call Review of draft-ietf-alto-deployments-14
review-ietf-alto-deployments-14-opsdir-lc-pignataro-2016-06-29-00

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.