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

From: Loa Andersson <[email-masked]>
Date: Thu, 14 Dec 2017 14:56:22 +0800

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: [email-masked]
Senior MPLS Expert
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 14 Dec 2017 09:26:37 +0000

Hi Loa,

thanks for the review. 
On the major issues:

- Number of authors: we were planning to list just the editors on the front page and the rest of the authors in the body of the draft. This is a modification we wanted to ask to the RFC editor but can be done now. 
- requirements: it happens when requirements and solutions are progressed in parallel. However the approach we've been usually following is: high level requirements in a framework document and detailed list of requirements if a requirements documents is produced. We thought this level of requirements was fair enough for a framework document and as I guideline for the writing of the YANG model. If you have suggestions on how to improve them we can discuss (together with the authors).

On the references:
- good point. I always find it had to define what is normative and what is informative for an informational document. When defining protocols extensions it's much easier and we have clear guidelines, since it's considered normative everything that the engineer need to have read and understood before implementing the extensions. In the case of a framework there is  number of references that it could be a good idea to read to better understand the documents...are they normative or informative? Hence the list of drafts and RFC that would be very helpful to better understand the document and that become a MUST if you want to write the YANG models (e.g. difference between a YANG model and a data model, the YANG model RFC, the YANG model for interface management etc.).
That sounded a good idea, also because it's more or less the approach used in RFC7698, RFC7260 and RFC7062...but if you/Deborah have a better one we're open. Also, i don't have any issue to move everything to informative and keep just RC2119 as normative.

Authors, while discussing these issues, could you please fix the other comments from Loa?

Thank a lot.
Daniele  

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: giovedì 14 dicembre 2017 07:56
> To: <[email-masked]> <[email-masked]>
> Cc: [email-masked]; ccamp-
> [email-masked]; [email-masked]
> Subject: RtgDir review: draft-ietf-ccamp-microwave-framework-04.txt
> 
> Hello,
> 
> 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.
> 
> 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:
> -------------
> 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
> 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.
> 
> 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".
> 
> 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??
> 
> TDM is(surprisingly) not a well-known acronym and needs to be expanded at
> first occurrence.
> 
> 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.
> 
> 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.
> 
> 
> 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
> 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
> ----------

---

From: Loa Andersson <[email-masked]>
Date: Thu, 14 Dec 2017 17:43:55 +0800

Daniele,

> - Number of authors: we were planning to list just the editors on the front page and the rest of the authors in the body of the draft. This is a modification we wanted to ask to the RFC editor but…

I'd be in favor of doing the change early, it simplify the processing

> - requirements: it happens when requirements and solutions are progressed in parallel. However the approach we've been usually following is: high level requirements in a framework document and deta…

I guess it would be a good idea to be explicit abour what you are doing,
some type of text like the one you have here

> That sounded a good idea, also because it's more or less the approach used in RFC7698, RFC7260 and RFC7062...but if you/Deborah have a better one we're open. Also, i don't have any issue to move ev…

Again, maybe a paragraph that explains why we sort references of an
informational document into normative and informative

/Loa

--

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 14 Dec 2017 10:13:20 +0000

HI Loa,

i'm ok with your suggestions. Authors?

So:

1. authors on the front page: authors, discuss among yourselves how you want to proceed, this is up to you:
	- option 1: the 5-6 people that mostly contributed on the front page, the others listed in the body. Or maybe 1 per vendor should decrease the number to 5-6?
	- option 2: the editors in the front page (I guess Amy and Jonas) and the others in the body.

2. Requirements. I would modify the statement in section 3 as follows:

   While [RFC2119] describes interpretations of these key words in
   terms of protocol specifications and implementations, they are used
   in this document to describe high level requirements to be met when defining the YANG Data Model
   for Microwave Radio Link.

3. References. I'm not sure it is possible to add text to section 10, maybe we can add a consideration on the references at the end section 3 (conventions used in this document), something like:

"This document does not define any protocol extension, hence only RFC2119 can be considered as a normative reference. However, the list of normative references includes a number of documents that can be useful for a better understanding of the context."

Thanks
Daniele  

> Sent: giovedì 14 dicembre 2017 10:44
> To: Daniele Ceccarelli <[email-masked]>; <[email-masked]>
> <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ccamp-microwave-framework-
> 04.txt
> 
> Daniele,
> 
> > - Number of authors: we were planning to list just the editors on the front
> page and the rest of the authors in the body of the draft. This is a modification
> we wanted to ask to the RFC editor but can be done now.
> 
> > - requirements: it happens when requirements and solutions are progressed
> in parallel. However the approach we've been usually following is: high level
> requirements in a framework document and detailed list of requirements if a
> requirements documents is produced. We thought this level of requirements
> was fair enough for a framework document and as I guideline for the writing of
> the YANG model. If you have suggestions on how to improve them we can
> discuss (together with the authors).
> 
> I guess it would be a good idea to be explicit abour what you are doing, some
> type of text like the one you have here
> 
> >
> > On the references:
> > - good point. I always find it had to define what is normative and what is
> informative for an informational document. When defining protocols
> extensions it's much easier and we have clear guidelines, since it's considered
> normative everything that the engineer need to have read and understood
> before implementing the extensions. In the case of a framework there is
> number of references that it could be a good idea to read to better understand
> the documents...are they normative or informative? Hence the list of drafts and
> RFC that would be very helpful to better understand the document and that
> become a MUST if you want to write the YANG models (e.g. difference between
> a YANG model and a data model, the YANG model RFC, the YANG model for
> interface management etc.).
> > That sounded a good idea, also because it's more or less the approach used in
> RFC7698, RFC7260 and RFC7062...but if you/Deborah have a better one we're
> open. Also, i don't have any issue to move everything to informative and keep
> just RC2119 as normative.
> 
> >> 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.
> >> 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.
> >>
> >> 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:
> >> -------------
> >> 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.
> >> 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:
> >> ------------
> >> OLD TEXT (last sentence in the abstract Some part of the resulting model
> MAY
> >> Security section second paragrap - typo OLD TEXT
> >>             charactersitics of
> >>      of
> >> NEW TEXT
> >>      characteristics of
> >>
> >>
> >>
> >> General comments:
> >> -----------------
> >>
> supposed
> sentence
> other
> exactly

---

From: "Yemin (Amy)" <[email-masked]>
Date: Fri, 15 Dec 2017 06:27:05 +0000

Hi Loa and Daniele,

Thanks for your comments and suggestions.

1. Author number: we will discuss among the authors to find a way to limit the number.

2. I like the text Daniele proposed related RFC2119. As an informational draft, this framework draft doesn't introduce any protocol. Those list as normative references are helpful to understand the draft. We will add those text to the draft.

@Loa, please see our reply in blue to other comments:

1. Paragraph 2 of section 1 says:

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

Thanks for pointing it out. We double check on the ITU definition.

Very high frequency (VHF) is the ITU designation for the range of radio frequency from 30 to 300 Megahertz (MHz), with corresponding wavelengths of ten to one meters.

Extremely high frequency (EHF) is (ITU) designation for the band of radio frequencies from 30 to 300 gigahertz (GHz) with corresponding wavelengths from ten to one millimeter.

EHF seems to be a correct reference but it must be a mistake to refer to VHF. We will remove VHF.

2. Second paragraph of the Introduction

The paragraphs says:

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.

We will only use microwave and state it covers frequency bands from single GHz to + 100 GHz.

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

Figure 2 needs to be updated to keep 1:n relationship.

4. We thank you for rest comments, and will address them in updated version.

BR,

Amy(on behalf of co-authors)

-----Original Message-----
From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Thursday, December 14, 2017 6:13 PM
To: Loa Andersson <[email-masked]>; <[email-masked]> <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-ccamp-microwave-framework-04.txt

HI Loa,

So:

Thanks

Daniele

> To: Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>;

> <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>

> Cc: [email-masked]<mailto:[email-masked]>;

> [email-masked]<mailto:[email-masked]>;

> [email-masked]<mailto:[email-masked]>

> Subject: Re: [RTG-DIR] RtgDir review:

> draft-ietf-ccamp-microwave-framework-

> > - Number of authors: we were planning to list just the editors on

> > the front

> page and the rest of the authors in the body of the draft. This is a

> modification we wanted to ask to the RFC editor but can be done now.

> > - requirements: it happens when requirements and solutions are

> > progressed

> in parallel. However the approach we've been usually following is:

> high level requirements in a framework document and detailed list of

> requirements if a requirements documents is produced. We thought this

> level of requirements was fair enough for a framework document and as

> I guideline for the writing of the YANG model. If you have suggestions

> on how to improve them we can discuss (together with the authors).

> I guess it would be a good idea to be explicit abour what you are

> doing, some type of text like the one you have here

> > - good point. I always find it had to define what is normative and

> > what is

> extensions it's much easier and we have clear guidelines, since it's

> considered normative everything that the engineer need to have read

> and understood before implementing the extensions. In the case of a

> framework there is number of references that it could be a good idea

> to read to better understand the documents...are they normative or

> informative? Hence the list of drafts and RFC that would be very

> helpful to better understand the document and that become a MUST if

> you want to write the YANG models (e.g. difference between a YANG

> model and a data model, the YANG model RFC, the YANG model for interface management etc.).

> > That sounded a good idea, also because it's more or less the

> > approach used in

> RFC7698, RFC7260 and RFC7062...but if you/Deborah have a better one

> we're open. Also, i don't have any issue to move everything to

> informative and keep just RC2119 as normative.

> > Authors, while discussing these issues, could you please fix the

> comments from Loa?

> >> To: <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>

> >> Cc: [email-masked]<mailto:[email-masked]>; ccamp-

> >> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> >> review, and sometimes on special request. The purpose of the review

> >> is to

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

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

> >> authors listed on the front page, all other names should go into

> >> Contributors

> >> There is no motivation in the Shepherds Write-Up why there is such

> >> a high number.

> >> Abstract - if the blank lines are counted this abstract is more

> >> than the allocated

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

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

> >> possible so

> it

> >> TDM is(surprisingly) not a well-known acronym and needs to be

> >> expanded at first occurrence.

> >> First, this paragraph seems to be a bit tainted by marketing, RFCs

> >> are

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

> >> say that SDN is an emerging technology, and the last sentence that

> >> it is

> widely

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

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

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

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

> >> The document has been through wglc, so this is obviously what the

> >> wg

> >> Since you have requirements in the document, it might be necessary

> >> for

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

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

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

> >> normative section; or if some of the other docments need to be

> >> there, why not e.g. [I-D.ahlberg-ccamp-microwave-radio-link]

> >> Loa Andersson                        email: [email-masked]<mailto:[email-masked]>

> Loa Andersson                        email: [email-masked]<mailto:[email-masked]>