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

[Daniele Ceccarelli <[e-mail]>]

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]>; <[e-mail]>
> <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [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]> <[e-mail]>
> >> Cc: [e-mail]; ccamp-
> >> [e-mail]; [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]
> >> Senior MPLS Expert
> >> Huawei Technologies (consultant)     phone: [phone]
> 
> --
> 
> 
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert
> Huawei Technologies (consultant)     phone: [phone]