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

Ben Campbell <ben@nostrum.com> Wed, 23 May 2018 17:56 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: ccamp@ietf.org
Delivered-To: ccamp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 148E4127867; Wed, 23 May 2018 10:56:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ben Campbell <ben@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ccamp-microwave-framework@ietf.org, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, ccamp-chairs@ietf.org, daniele.ceccarelli@ericsson.com, ccamp@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.80.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152709816207.26876.3185653840829970396.idtracker@ietfa.amsl.com>
Date: Wed, 23 May 2018 10:56:02 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/8HIIARcNhACDy22uQ0kP5AEMePw>
Subject: [CCAMP] Ben Campbell's No Objection on draft-ietf-ccamp-microwave-framework-06: (with COMMENT)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 May 2018 17:56:02 -0000

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://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-microwave-framework/



----------------------------------------------------------------------
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.