[RTG-DIR] RtgDir review: draft-ietf-ccamp-microwave-framework-04.txt

Loa Andersson <loa@pi.nu> Thu, 14 December 2017 06:56 UTC

Return-Path: <loa@pi.nu>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEC6126DFE; Wed, 13 Dec 2017 22:56:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lf8lGhmKrB1d; Wed, 13 Dec 2017 22:56:36 -0800 (PST)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 529D8124BE8; Wed, 13 Dec 2017 22:56:33 -0800 (PST)
Received: from [192.168.1.10] (unknown [119.94.161.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id EA4D1180133E; Thu, 14 Dec 2017 07:56:27 +0100 (CET)
From: Loa Andersson <loa@pi.nu>
To: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>
Cc: draft-ietf-ccamp-microwave-framework.all@ietf.org, "ccamp-chairs@ietf.org" <ccamp-chairs@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
Message-ID: <e696c089-3148-5730-4da7-36328d52a527@pi.nu>
Date: Thu, 14 Dec 2017 14:56:22 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/Z4SCcqh6bTZBisfF9VjMK4nNn-M>
Subject: [RTG-DIR] RtgDir review: draft-ietf-ccamp-microwave-framework-04.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Dec 2017 06:56:39 -0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and 
sometimes on special request. The purpose of the review is to provide 
assistance to the Routing ADs. For more information about the Routing 
Directorate, please see 
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-ccamp-microwave-framework-04
Reviewer: Loa Andersson
Review Date: 2017-12-14
IETF LC End Date: not known
Intended Status: Informational

Summary:

I have two major issue, number of authors on the front page and the
possibility to evaluate whether requirements are met , and some minor 
concerns, a few nits and as set of general comments. I think this
should be resolved before publication.

Even though I have quite a bit of comments, and I think there is more
work to do before publication, I think that the document in general is
well written and that it won't be too hard to fix my comments.


Comments:

Major Issues:
-------------
This document has 10 authors listed on the front page.

The directive from the RFC Editor says that there can be only 5 authors
listed on the front page, all other names should go into Contributors
section. Occasionally there have been 6 authors listed, but never as
many 10.

There is no motivation in the Shepherds Write-Up why there is such a
high number.

A second issue is the requirement section, requirements needs to be
written rather precise and specific to allow to evaluate if requirements
are met or not, I don't think this is the case in the requirements 
section of this document.

Minor issues:
------------
Abstract - if the blank lines are counted this abstract is more than the
allocated 20 lines.

I've not seen that we normally use RFC 2119 language in the abstract
OLD TEXT (last sentence in the abstract
Some part of the resulting model MAY
    be generic which COULD also be used by other technology.
NEW TEXT
Some part of the resulting model may
    be generic which could also be used by other technology.

I don't think that the meaning changes if the text is changed this way.


Introduction;
RFC 7322 says:

4.8.1.  Introduction Section

    The Introduction section should always be the first section following
    the TOC (except in the case of MIB module documents).  While
    "Introduction" is recommended, authors may choose alternate titles
    such as "Overview" or "Background".  These alternates are acceptable.

In this document the Introduction is section number 2.

Nits:
----
I've just listed a few nits, but it is possible that some nits are 
lurking among the general comments below.

Section 4.2. E2E is an acronym, it should be expanded at first
occurrence, but since it is only used once so it would be better to
use "end to end" rather than the acronym.

Security section first paragraph- 2 typos

OLD TEXT
In additon
NEW TEXT
In addition

OLD TEXT
transport netork domain
NEW TEXT
transport network domain

Security section second paragrap - typo
OLD TEXT
           charactersitics of
    of
NEW TEXT
    characteristics of



General comments:
-----------------

Paragraph 2 of section 1 says:

    Millimeter wave is also known as extremely high frequency (EHF) or
    very high frequency (VHF) by the International Telecommunications
    Union (ITU),

It is not clear from this if EHF and VHF are two different names for the
same thing or if they are different. I have limited access to ITU-T
documents, and has not been able to check. If my memory serves me right
VHF is a technology used for broadcast radio, but it is possible that 
the acronym has been "re-used".

Paragraph 3 of section 1 says:

    ETSI EN 302 217 series defines the characteristics and requirements
    of microwave/millimeter wave equipment and antennas. Especially ETSI
    EN 302 217-2 specifies the essential parameters for the systems
    operating from 1.4GHz to 86GHz.



I don't know ETSI documentation that well, but isn't a reference
possible so it would be easier to find.
Note: I found the reference later in the document, why not use it
already here??

Paragraph 6 of section 1 says:

    Radio Link Terminal is an interface providing packet capacity and/or
    TDM capacity

TDM is(surprisingly) not a well-known acronym and needs to be expanded
at first occurrence.

The last paragraph of section 1

First, this paragraph seems to be a bit tainted by marketing, RFCs are
supposed to stand for at least 25 years, what is conceived to be 
"extremely" dynamic will be stone age in just a few year, would be good
to drop most of the value words.
Also the paragraph seems to have an internal contradiction. The first
sentence say that SDN is an emerging technology, and the last sentence
that it is widely deployed; one or the other maybe, but not both.

First paragraph of the Introduction

The paragraph says:
    Network requirements vary between operators globally as well as
    within individual countries. The overall goal is however the same -
    to deliver the best possible network performance and quality of
    experience in a cost-efficient way.

Does this paragraph really contribute anything?

Second paragraph of the Introduction

The paragraphs says:
    Microwave/millimeter wave (hereafter referred to as microwave, but
    including the frequency bands represented by millimeter wave)

It might be a good idea to refer to microwave and millimeter wave with
a common name, but this convention is not used consistently throughout
te document. actually doubt that a common name can be used, there are
placs where microwave and millimeter wave needs to be explained
separately, would it cause any problem just removing this sentence.


Thought on figure 1 and figure 2:

Since we are talking models, with my modelling glasses on, figure 1
tells me that there is a 1:n relationship between a Radio Link
Terminal and Carrier Termination , and that a Carrier Termination
is part of the Radio Link Terminal. Figure 2 tells me that both the
Radio Link Terminal and Carrier Termination are independently part of
"Interface" and that the relation between them are 1:1. I suppose that
both can't be correct.

Section 3
It is quite a convention to place the section referring to RFC2119, as a
subsection to the Introduction. It is not consistently done, but I think
it is a good practice.

Section 4 and 5

I do not have much comments on section 4 and 5, I find both sections a
bit to sure about predicting the future and often claiming to know the
motivation why operators do things the way they do.
The document has been through wglc, so this is obviously what the wg
wants.

Section 6 Requirements

Since you have requirements in the document, it might be necessary for 
other documents to normatively reference this document. If they are 
normatively referenced from a Standards Track document this will cause a
down-ref. In itself not a problem, but the AD should be aware of this.

It is often said that it must be possible to verify if a requirement is
fulfilled, some of the requirement text in this document is not very 
precise.

If you say it must be possible to configure a Radio Link Terminal, what
exactly does that mean? Some of the lists seems to be examples of things
that could be configured; if in one implementation it is possible to 
configure 4 out of 5 parameters is the requirement met?


References
----------
You are using the RFC 2119 language in the Requirements section, I think 
this make RFC 2119 a normative reference even though this is an
Informational document

One other question about Normative and Informative references, at least 
on the face of it it looks like all existing RFC has been placed as
normative references, while all work in progress are informative.

It is not obvious that anything but RFC 2119 needs to be in the
normative section; or if some of the other docments need to be there,
why not e.g. [I-D.ahlberg-ccamp-microwave-radio-link]
[I-D.vallin-ccamp-alarm-module] should also be there.

Can you please explain the rationale behind the placement of a
reference in the normative or informative section.

Yes - I know that RFC 8022 is in the informative section.

-- 


Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert
Huawei Technologies (consultant)     phone: +46 739 81 21 64