Re: [CCAMP] Ben Campbell's No Objection on draft-ietf-ccamp-microwave-framework-06: (with COMMENT)

["BRUNGARD, DEBORAH A" <[e-mail]>]

Hi Ben,

Thanks for the careful read:-)

On the charter, the first paragraph includes non-packet technologies, listing microwave links.

I understand the reluctance to publish “extra” informational documents (and I agree), on this one, it was important as this was a first on this data plane technology and it was critical to understand technology specific vs. generic information for the modeling. As noted by the author and contributor list, the document had much involvement, first as a design team, then working group. And so I supported its publication.

Thanks!
Deborah 

Sent from my iPhone

> On May 23, 2018, at 1:56 PM, Ben Campbell <[e-mail]> wrote:
> 
> Ben Campbell has entered the following ballot position for
> draft-ietf-ccamp-microwave-framework-06: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=xXzys-quL32jzZ69uxnTkdPlqORkV3rtzQU21dt4mX8&s=0vyMs3CJKHFuFIeyKiRUNFqp8X4pjM4sjjeRPTb7oSU&e=
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dccamp-2Dmicrowave-2Dframework_&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=xXzys-quL32jzZ69uxnTkdPlqORkV3rtzQU21dt4mX8&s=XcCJ_hj0WYB6dkxnyI_fqQOEEaKwHCtedbxN8xcfSRA&e=
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I agree with other comments that this document doesn't seem to need to be an
> RFC. It seems like, once the YANG model is complete, the content here will no
> longer be needed. It would be better documented outside of the RFC series (for
> example, in a wiki or left as an internet-draft). I further note that this
> document doesn't seem to be in the WG charter, but it's entirely possible I
> missed something.
> 
> Otherwise, I have some mostly editorial comments. In general, I think this
> could use more proofreading prior to publication.
> 
> §1.1
> - 2nd paragraph: This contradicts the boilerplate that says these terms are
> used as defined in 8174 and 2119. I don't think using the terms in this way
> adds clarity to the document. In fact, I think it reduces clarity in some
> cases; e.g. the difference of SHOULD vs MUST clearly isn't as described in
> 2119, so it's not clear how SHOULD should be interpreted when designing the
> YANG model.  For example, should SHOULD items be interpreted as "desirable but
> not required"?
> 
> - 3rd paragraph: The paragraph gives an incorrect interpretation of the meaning
> of "normative references" The lack of protocol definition does not suggest that
> there should be no normative references. I suggest simply deleting the
> paragraph.
> 
> §3, last paragraph:
> -  " It’s noted that there’s idea that the NMS and SDN are evolving towards a
> component, and the distinction between them is quite vague. " I don't
> understand that sentence. Are there missing words? - Please consider defining
> the operative difference between "management" and "control" plan in the context
> of this discussion, especially given the previous comment that the distinction
> between NMS and SDN is vague.
> 
> §3.2:
> - 4th paragraph: s/potential/potentially
> - Last paragraph: "Effort on a standardizing operation mode is required to
> implement a smoothly operator environment." I don't understand that sentence.
> Are there missing or incorrect words?
> 
> §4.11 and following sections: Many of these sections start out with a sentence
> fragment for the use case description  That would be reasonable in a table or
> list of cases, but is jarring to read in paragraph form.
> 
> §4.1.2, first paragraph: The normative "MAY" seems wrong in context. I think
> it's a statement of fact, not a grant of permission. (In general, I don't see
> how normative keywords make sense in use cases like these.)
> 
> §4.1.4: "Radio link terminals comprising a group of carriers ..."
> I don't think the terminals comprise carriers per se. Perhaps they are shared
> by a group of carriers, or provide access for a group of carriers?
> 
> §4.4.1: The text is convoluted. Please consider simplifying it. Active voice
> might help.
> 
> §4.5.2:
> - I don't understand what "should be supported accordingly" means in context.
> Please describe how they should be supported. - The last sentence seems like a
> non sequitur, given that the last sentence explicitly said that these items
> were _not_ specific to a particular radio link interface.
> 
> §6,
> - "The purpose of the gap analysis is to identify and recommend what
>   existing and established models as well as draft models under
>   definition to support the use cases and requirements specified in the
>   previous chapters. "
> I don't understand the wording after "as well".
> The antecedent of "It" is unclear in the second sentence.
> 
> §6.1: Please proofread this section for missing articles and ambiguous pronoun
> antecedents. "IM is to model managed objects at a conceptual
>   level for designers and operators, DM is defined at a lower level and
>   includes many details for implementers."  - comma splice
> 
> - " To ensure better interoperability, it is better to
>   focus on DM directly."
> That sentence needs to be contextualized. It's not globally true.
> 
> - paragraph starting with "[RFC8343] describes..." Please clarify whether the
> mentioned models are IMs or DMs.
> 
> -7: "Security issue concerning the access control to Management interfaces
>   can be generally addressed..."
> Please describe what those issues are. The security consideration section
> should discuss protections in the context of the threats that they mitigate.
> For example, what would be the consequences of violations of origin
> authentication, integrity protection, or confidentiality?
> 
> §9.2: At least [I-D.ietf-ccamp-mw-yang] should be normative.
> 
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ccamp&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=xXzys-quL32jzZ69uxnTkdPlqORkV3rtzQU21dt4mX8&s=qMI-ND9KLcm0yTYyMS-okteCoin4IxlWeVoaOfILUJw&e=