Re: [Gen-art] draft-ietf-sacm-requirements-15.txt

[Nancy Cam-Winget (ncamwing)]

Thanks for including the Gen-Art feedback.
For some reason, I have not received either the gen-art nor the “discuss” so am 
trying to resolve and respond through this 
Email (for the gen-art) and will see on how to better respond to the “discuss” 
in a bit.

To Alissa’s comment: I have made the general substitution of “transport” to 
“transfer” where applicable (apologies as the inconsistency is an oversight).

For gen-art, please see below with my annotations marked as “[NCW]”:

On 6/21/17, 9:44 AM, "Alissa Cooper"  wrote:

Francis, thank you for your review. I have indicated in my ballot that no 
response has been received yet.

Alissa

> On Jun 11, 2017, at 5:13 AM, Francis Dupont  
wrote:
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-sacm-requirements-15.txt
> Reviewer: Francis Dupont
> Review Date: 20170607
> IETF LC End Date: 20170605
> IESG Telechat date: unknown
> 
> Summary: Almost Ready
> 
> Major issues: None
> 
> Minor issues: ambiguous uses of lowercase keywords:
> RFC 2119 is very ambiguous about the required case of keywords so even
> of 1.1 includes a "uppercase keyword only" statement I strongly recommend
> to avoid use of lowercase keywords in numbered requirements (and to
> add a statement about this in 1.1). Note there are a few "required" and
> at least a "shall". In a few case this should avoid further questions
> about whether to promote a lower case verb (e.g., a may) to a keyword.
[NCW] There was another comment/question to the actual applicability of
2119.  As this is a requirements document, the uppercase keywords are meant
to indicate what is an actual requirement (MUST) vs. recommendation (SHOULD);
as such, I will remove the 2119 and update the requirements language to better
reflect intent.

> 
> Nits/editorial comments: 
> - ToC page 2 and 3 page 15: Acknowledgements -> Acknowledgments
[NCW] Done.

> 
> - 1 page 2: expand the SACM abbrev at the first use in the boday
[NCW] Done.

> 
> - 2.1 page 5 G-002: first example of a lowercase keyword (a must)
>  which is both ambiguous and a candidate to uppercase (note as
>  there is no keywords in G-002 it is even a strong candidate).
[NCW] candidates for adoption have to ensure interoperability, so I’ve made 
this a capital MUST.

> 
> - 2.1 page 5 G-003: ambiguous "must" in "Scalability must be addressed..."
>  (I propose to replace it by "has to")
[NCW] Fair enough, though the MUST is to reflect that is has to address 
this…but the recommendation to include a section should suffice so will have 
the “MUST” to “has to”

> 
>  I counted 30 ambiguous keywords in numbered requirements
>  (I can give details if you need)
[NCW] Hopefully with new “intent” of use of capitalization should have helped, 
if not, do please let me know.

> 
> - 2.1 page 6 (G-006 & G-009 (twice)), 2.3 page 9 (IM-006), 2.6 page 14
>  (T-004):  i.e. -> i.e.,
> 
> - 2.2 page 8 (ARCH-007), 2.4 pages 10 (DM-002) and 11 (DM-004, DM-010
>  and DM-011), 2,5 page 13 (OP-007 (twice)), 2.6 page 14 (T-003 and T-005),
>  5.2 page 17:  e.g. -> e.g.,
> 
> - 2.6 page 14 (proposal): hyperText -> hypertext
>  BTW HTTP is a well known abbrev so you can simply leave HTTP
>  (cf http://www.rfc-editor.org/materials/abbrev.expansion.txt)
[NCW] LoL….I was told to add it in a previous review, but will remove it (again 
since I can reference the link above!) 
> 
> - 5 pages 15-17: lowercase keywords (so not to be interpreted as keywords)
>  are fine here as there are not in numbered requirements.
> 
> - 5.2 page 17: unecessary -> unnecessary
> 
> - 7.1 page 18: draft-ietf-sacm-terminology is (intented to be)
>  informational so to have it as a normative reference is questionable.
>  Same for RFC 5209 and RFC 7632. Note according to the RFC 7322 the
>  rule for normative vs informative references is flexible so you can
>  argue these documents bring important or even critical information.
[NCW] Oops, will move them to informational.  Though, I will leave 7632 as they
were used to exemplify and tease out the requirements.

> 
> - Addresses page 10: (more for the RFC Editor) please try to move the
>  title to the next page.
> 
> Regards
> 
> francis.dup...@fdupont.fr
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> 

[Gen-art] Genart last call review of draft-ietf-bier-architecture-07

[Dan Romascanu]

Reviewer: Dan Romascanu
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-bier-architecture-??
Reviewer: Dan Romascanu
Review Date: 2017-06-25
IETF LC End Date: 2017-06-29
IESG Telechat date: 2017-07-06

Summary:

This document specifies a new architecture known as "Bit Index Explicit
Replication" (BIER) for the forwarding of multicast data packets through a
"multicast domain".  It does not require a protocol for explicitly building
multicast distribution trees, nor does it require intermediate nodes to
maintain any per-flow state. This architecture is .  While the Abstract and
Introduction of the document mentions Architecture as the principal scope, this
document goes well beyond the scope of a typical architectural document.
including detailed definitions of the procedures, terminology and normative
algorithms required for BIER.

The document is clear and detailed. Because of its structure, I am missing some
information that usually can be found in architecture documents. I included
these in the 'minor issues' list. Although none of these may be a show-stopper,
I believe that addressing these before document approval can improve the
quality of the document and of the overall BIER work.

Major issues:

Minor issues:

1. As the document is targeting 'Experimental' it would be useful to mention
what is the scope of the experiment. The charter actually says:

' The scope of the experiment will be
documented in the output of the Working Group.'

Would not the Architecture document be the right place for this? If not, is
there another document that deals or is planned to define the scope of the
experiment?

2. While the Abstract and Introduction of the document mentions Architecture as
the principal scope, this document is different from a typical architectural
document. While it defines well the procedures, terminology and normative
algorithms required for BIER Intra-domain forwarding, it goes well beyond the
level of detail that other similar documents go. Specifications of the
procedures and normative algorithm should be mentioned in Abstract and
Introduction, they occupy the same or more space than architecture.

3. On the other hand I am missing the relationship with other work items in the
BIER charter - there is no manageability section for example, there is no
reference to the performance impact in networks. Maybe these are dealt with in
a different document or documents or BIER, if so it would be good at least to
mention and reference these here.

4. I also would have expected the architecture document to refer the use cases
document and note which of the use cases are being addressed and how -
draft-ietf-bier-use-cases is not even included in the references.

5. Sections 3 to 6 mentioned repeatedly provisioning. As there is no Operations
and Manageability section as in many other Routing Area documents, it is not
clear how this is expected to happen. For example draft-ietf-bier-bier-yang is
not mentioned or referred. I suggest adding a note (and maybe references) for
clarity.

6. In section 8 I found:

'Every BFR must be provisioned to know which of its interfaces lead to
   a BIER domain and which do not.  If two interfaces lead to different
   BIER domains, the BFR must be provisioned to know that those two
   interfaces lead to different BIER domains. '

It seems that the two 'must' in these sentences would rather be capitalized.

Nits/editorial comments:


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art