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

["Yemin (Amy)" <[e-mail]>]

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:



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

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:

    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.

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:[e-mail]]
Sent: Thursday, December 14, 2017 6:13 PM
To: Loa Andersson <[e-mail]>; <[e-mail]> <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-ccamp-microwave-framework-04.txt



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







> -----Original Message-----

> From: Loa Andersson [mailto:[e-mail]]

> Sent: giovedì 14 dicembre 2017 10:44

> To: Daniele Ceccarelli <[e-mail]<mailto:[e-mail]>>;

> <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>>

> Cc: [e-mail]<mailto:[e-mail]>;

> [e-mail]<mailto:[e-mail]>;

> [e-mail]<mailto:[e-mail]>

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

> draft-ietf-ccamp-microwave-framework-

> 04.txt

>

> Daniele,

>

> On 2017-12-14 17:26, Daniele Ceccarelli wrote:

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

>

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

>

> Again, maybe a paragraph that explains why we sort references of an

> informational document into normative and informative

>

> /Loa

> >

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

> > other

> comments from Loa?

> >

> > Thank a lot.

> > Daniele

> >

> >> -----Original Message-----

> >> From: Loa Andersson [mailto:[e-mail]]

> >> Sent: giovedì 14 dicembre 2017 07:56

> >> To: <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>>

> >> Cc: [e-mail]<mailto:[e-mail]>; ccamp-

> >> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

> >> Subject: RtgDir review: draft-ietf-ccamp-microwave-framework-04.txt

> >>

> >> 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: [e-mail]<mailto:[e-mail]>

> >> Senior MPLS Expert

> >> Huawei Technologies (consultant)     phone: [phone]

>

> --

>

>

> Loa Andersson                        email: [e-mail]<mailto:[e-mail]>

> Senior MPLS Expert

> Huawei Technologies (consultant)     phone: [phone]