Subject: [CCAMP] AD review of [email-masked]

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 5 Dec 2018 14:50:22 +0000

Hi Authors,

As your document is discussing equipment related monitors (e.g. comparison of a measured received power level with a threshold value), alarms (e.g. low power alarm), power control loops, etc., it was necessary to inform SG15 and understand if any concerns. SG15 has replied that they found the use cases implementation specific and outside the scope of optical standards. They identified there is no list of proposed parameters, and so they were not able to review further.

The document's abstract states the purpose of this document is to identify the necessary information to be used by management protocols. I'm confused also - as SG15 identified, there is no list of specific parameters for these use cases to be used by management protocols. The document is primarily describing equipment related measurements, but not how it is to be managed. There is quite a bit of description on optical power control loops, but as SG15 says, this is outside of standards and equipment (implementation) specific. What is needed is the generalized (vs. vendor) management aspects.

I didn't see what Section 6 on Requirements was trying to identify:

Req 1: procedure to setup an optical connection MUST be defined. Are you saying that one procedure can be used for all the use cases? Considering as SG15 says, the procedures described in the use cases are implementation specific, I question why would IETF be defining such a procedure? I would expect the scope of IETF would be to define a generalized parameter set which can be used to manage setup for different use cases.
Req 2: MUST be aware of the "right set of parameters". When/where will this be defined?

On the following, I don't consider these requirements for IETF:
Req 3: both NETCONF/RESTCONF and SNMP needs to be supported.
Req 4: a data model MUST be supported.
Req 5: NETCONF SHOULD be used.
Req 11: LMP MAY be used.

These sentences appear to be putting requirements on WDM equipment. It is not for IETF to define what needs to be supported for equipment, e.g. WDM equipment needs to support a "standard-based northbound API", "a data model MUST be supported", etc. IETF can define what needs to be supported for a protocol to support a type of equipment functionality. But that would be a parameter list, there is no parameter list.

I find this document is an example of a document which may be helpful for the working group to understand implementation scenarios, but to have publication value, it needs to have more substance e.g. a gap analysis with SNMP/YANG identifying the information to be used for management. As the IESG has suggested previously, effort should be on the solution documents. If want visibility for a use case, it can be provided in an appendix.
https://www.ietf.org/blog/support-documents-ietf-working-groups/?primary_topic=7&

For now, I will put this document in a state "AD is watching". I recommend for CCAMP to either put their efforts on the solution documents (SNMP/YANG) or enhance this document to provide a concise gap analysis of what is needed for IETF protocol work.

If decide to continue with this document, be sure to address Q6's comments. When have completed a parameter list, provide a follow-up liaison to SG15.
For my review, can you clarify this statement w.r.t to IETF protocols in section 4.1.1:
"Note that a software update of the optical interface components of the client nodes must not lead obligatory to an update of the software of the EMS and vice versa."

Thanks,
Deborah