Re: [Gen-art] [Anima] Gen-art LC Review of? draft-ietf-anima-autonomic-control-plane-13

2018-05-18 Thread Toerless Eckert 
Definitely, just works better for me when not having to multi-thread,
and still trying to finalize feedback for Joel Halperns excellent feedback

Cheers
Toerless

On Fri, May 18, 2018 at 01:08:55PM -0400, Alissa Cooper wrote:
> Hi,
> 
> I was wondering if any response to Elwyn???s review besides Brian???s is 
> forthcoming and if so when the authors or shepherd expect to send it.
> 
> Thanks,
> Alissa
> 
> > On Apr 18, 2018, at 8:50 PM, Toerless Eckert  wrote:
> > 
> > Sorry, trying to get through backlog. Took longer than expected...
> > 
> > On Thu, Apr 19, 2018 at 01:04:53AM +0100, Elwyn Davies wrote:
> >> Hi.
> >> It has been about 6 weeks since responses to the review were postponed 
> >> till after IETF 101 any thoughts yet?
> >> Regards,Elwyn
> >> 
> >> 
> >> Sent from Samsung tablet.
> >>  Original message From: Elwyn Davies 
> >>  Date: 02/03/2018  12:04  (GMT+00:00) To: Brian E 
> >> Carpenter , gen-art@ietf.org Cc: 
> >> draft-ietf-anima-autonomic-control-plane@ietf.org Subject: Re: 
> >> [Gen-art] Gen-art LC Review of
> >>   draft-ietf-anima-autonomic-control-plane-13 
> >> Just taking up one point for the time being  
> >> Even if the reference model is informational, I was relying on RFC 8067, 
> >> s1, para 3:
> >>Section 2 of [RFC3967] lists some conditions under which downrefs may
> >>make sense.  In addition to those, it has become common for working
> >>groups to produce foundational documents (which contain important
> >>information such as terminology definitions and architectural design
> >>and considerations) at Informational status, and those documents are
> >>often needed as normative references in the Standards Track protocol
> >>documents that follow. 
> >> I would say that sombody implementing ACP really needs to have read and 
> >> understood the reference model and so I would argue:1. That it needs to be 
> >> normative,and2. The downref is sanctioned by the language in RFC 8067. 
> >> I am on holiday for a week and others are fighting the draft deadline so 
> >> perhaps we can postpone discussion of the other points until the draft 
> >> panic has subsided.
> >> Cheers,Elwyn
> >> Sent from Samsung tablet.
> > 
> > -- 
> > ---
> > t...@cs.fau.de
> > 
> > ___
> > Gen-art mailing list
> > Gen-art@ietf.org
> > https://www.ietf.org/mailman/listinfo/gen-art
> 
> ___
> Anima mailing list
> an...@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
t...@cs.fau.de

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

Re: [Gen-art] Genart last call review of draft-ietf-bess-evpn-prefix-advertisement-10

2018-05-18 Thread Rabadan, Jorge (Nokia - US/Mountain View) 
Elwyn,

Thank you very much for your thorough review.
We addressed all your comments.. see below for more details, with [JORGE].

Thx
Jorge


-Original Message-
From: Elwyn Davies 
Date: Saturday, April 14, 2018 at 12:59 PM
To: "gen-art@ietf.org" 
Cc: "draft-ietf-bess-evpn-prefix-advertisement@ietf.org" 
, "i...@ietf.org" 
, "b...@ietf.org" 
Subject: Genart last call review of draft-ietf-bess-evpn-prefix-advertisement-10
Resent-From: 
Resent-To: , , 
, , , 
, , 
, , , 
Zhaohui Zhang , 
Resent-Date: Saturday, April 14, 2018 at 12:59 PM

Reviewer: Elwyn Davies
Review result: Almost Ready

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-bess-evpn-prefix-advertisement-10
Reviewer: Elwyn Davies
Review Date: 2018-04-14
IETF LC End Date: 2018-04-10
IESG Telechat date: 2018-05-10

Summary:  Almost ready.  My main concerns are the lack of a good 
introduction
and a rather weak definition of the format of the new EVPN route option
(looking back on RFC 7342, I think this could be said about that document
also!).  This is very technical material and  a good introduction would help
readers who are not  already deeply into the Data Center area to understand
what is going on.  Also this document has some remaining vestiges of being
written like an academc paper (some were fixed in the previous revision),
particularly the spurious notion of having 'conclusions' (material actually
deserves to be in the Intro)

Major issues:

None

Minor issues:
Lack of a proper introduction: An introduction should precede the 
terminology
section and needs to be somewhat clearer about the context (presumably
multi-tenant data centers). A reference to RFC 7365 which describes the data
center model in which the EVPN mechanism is expected to be employed would be
very useful. A somewhat expanded version of the text in s2 would be a good
basis for the introduction. The ss2.1 and 2.2 with a short new header would
become a new section (3) which is the Problem Statement.
[JORGE] OK, I shifted the intro and terminology sections, and expanded the 
introduction as you suggested.

s5: Associated with my previous comment... An RFC is not a scientific paper 
and
does not have 'conclusions'.  On reading s5, it strikes me that this text 
would
actually make quite a nice part of the introduction, probably interpolated
after the first paragraph of the current s2.
[JORGE] ok, removed the conclusions section and took the content to the 
introduction.

Terminology import: The current s1 contains a number of terms that are 
actually
defined in RFC 7365 (Data Center, Tenant System, Network Virtualization 
Edge,
etc). Pointing to RFC 7365 s1.1 would be helpful.
[JORGE] Added this in the terminology section:
"This document also assumes familiarity with the terminology of
 [RFC7432], [RFC8365] and [RFC7365]."


s1, VNI: There is some difference between the usage of VNI in RFC 8365 
(Section
5.1), in RFC 7365 (s3.1.2) where it means Virtual Network Instance and in 
this
draft (... Identifier). This is potentially confusing to the naive reader 
and
definitely confusing with the usage of VNI in item (4) of s4.1 where the 
VNI is
the VXLAN Network Identifier. It would be better if VNI meant the same 
thing in
all this closely related work. Please review all instances of VNI in the 
draft
to make sure they are talking about the same thing.
[JORGE] Done. I also added:
   "VNI: Virtual Network Identifier. As in [RFC8365], the term is used as
  a representation of a 24-bit NVO instance identifier, with the
  understanding that VNI will refer to a VSID in NVGRE, or VNI in
  VXLAN, etc. unless it is stated otherwise."


s2.1:
>[RFC7432] is used as the control plane for a Network Virtualization
>Overlay (NVO3) solution in Data Centers (DC),
The acronym NVO3 is used here as opposed to NVO which is used elsewhere in 
the
document. NVO3 is used in RFC 7365 to refer to an overlay with an L3 
underlay
network. It is not quite clear to me whether this is a typo with EVPN NOT 
being

Re: [Gen-art] Gen-art LC Review of? draft-ietf-anima-autonomic-control-plane-13

2018-05-18 Thread Alissa Cooper 
Hi,

I was wondering if any response to Elwyn’s review besides Brian’s is 
forthcoming and if so when the authors or shepherd expect to send it.

Thanks,
Alissa

> On Apr 18, 2018, at 8:50 PM, Toerless Eckert  wrote:
> 
> Sorry, trying to get through backlog. Took longer than expected...
> 
> On Thu, Apr 19, 2018 at 01:04:53AM +0100, Elwyn Davies wrote:
>> Hi.
>> It has been about 6 weeks since responses to the review were postponed till 
>> after IETF 101 any thoughts yet?
>> Regards,Elwyn
>> 
>> 
>> Sent from Samsung tablet.
>>  Original message From: Elwyn Davies  
>> Date: 02/03/2018  12:04  (GMT+00:00) To: Brian E Carpenter 
>> , gen-art@ietf.org Cc: 
>> draft-ietf-anima-autonomic-control-plane@ietf.org Subject: Re: [Gen-art] 
>> Gen-art LC Review of
>>   draft-ietf-anima-autonomic-control-plane-13 
>> Just taking up one point for the time being  
>> Even if the reference model is informational, I was relying on RFC 8067, s1, 
>> para 3:
>>Section 2 of [RFC3967] lists some conditions under which downrefs may
>>make sense.  In addition to those, it has become common for working
>>groups to produce foundational documents (which contain important
>>information such as terminology definitions and architectural design
>>and considerations) at Informational status, and those documents are
>>often needed as normative references in the Standards Track protocol
>>documents that follow. 
>> I would say that sombody implementing ACP really needs to have read and 
>> understood the reference model and so I would argue:1. That it needs to be 
>> normative,and2. The downref is sanctioned by the language in RFC 8067. 
>> I am on holiday for a week and others are fighting the draft deadline so 
>> perhaps we can postpone discussion of the other points until the draft panic 
>> has subsided.
>> Cheers,Elwyn
>> Sent from Samsung tablet.
> 
> -- 
> ---
> t...@cs.fau.de
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

Re: [Gen-art] [xrblock] Genart telechat review of draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-09

2018-05-18 Thread Alissa Cooper 
Robert, thanks for your review. Rachel, thanks for the edit. I have entered a 
No Objection ballot.

Alissa


> On May 1, 2018, at 12:15 PM, Huangyihong (Rachel)  
> wrote:
> 
> Hi Robert,
> 
> I believe I have responded you in February, if you check the mail archive of 
> xrblock.
> 
> Follows was my response before. And I uploaded a new version to reflect that 
> since I didn't get your further email. Sorry for assuming that you received 
> my response.
> 
> "
>Hi Robert, 
> 
>Thanks for the comment.
> 
> I propose to change the last paragraph of 5.2.2 from
> 
>"
>   The following metrics can also be considered for WebRTC's Statistics
>   API: number of discarded key frames, number of lost key frames,
>   number of discarded derived frames, number of lost derived frames.
>   These metrics can be used to calculate Media Loss Rate (MLR) of MDI.
>   Details of the definition of these metrics are described in
>   [RFC7003].  Additionally, the metric provides the rendered frame
>   rate, an important parameter for quality estimation.
>"
> 
>To
> 
>"
> The metrics in this category includes
>: number of discarded key frames, number of lost key frames,
>   number of discarded derived frames, number of lost derived frames.
>   These metrics can be used to calculate Media Loss Rate (MLR) of MDI.
>   Details of the definition of these metrics are described in
>   [RFC7003].  Additionally, the metric provides the rendered frame
>   rate, an important parameter for quality estimation.
>"
> 
>This change is to just talk about the metrics itself, so as to avoid any 
> confusion that readers may have. The fact is that the W3C has already 
> included the metrics, and made an informational reference to this document.
> 
>If the proposal looks good to you, we'll reflect it in the new version.
> 
> "
> 
> BR,
> Rachel
> 
> -邮件原件-
> 发件人: Robert Sparks [mailto:rjspa...@nostrum.com] 
> 发送时间: 2018年5月2日 0:04
> 收件人: gen-art@ietf.org
> 抄送: draft-ietf-xrblock-rtcweb-rtcp-xr-metrics@ietf.org; i...@ietf.org; 
> xrbl...@ietf.org
> 主题: Genart telechat review of draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-09
> 
> Reviewer: Robert Sparks
> Review result: Ready with Nits
> 
> 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 wait for direction from your document shepherd or AD 
> before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-09
> Reviewer: Robert Sparks
> Review Date: 2018-05-01
> IETF LC End Date: 2018-02-23
> IESG Telechat date: 2018-05-24
> 
> Summary: Ready for publication as an Informational RFC, but with nits to 
> consider before publication
> 
> Note that this is identical to my last call review, which I don't think I've 
> seen a response to.
> 
> The document argues to include things in the W3C statistics API in the last 
> paragraph of 5.2.2. Section 7 seems to say those have been included already. 
> It would be good to rework both of these mentions to reflect what's true at 
> the time of the publication of the RFC, in a way that the text will make 
> sense when read years from now.
> 
> ___
> xrblock mailing list
> xrbl...@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock

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

[Gen-art] Review Assignments

2018-05-18 Thread Jean Mahoney 
Hi all,

The following reviewers have assignments:

For telechat 2018-05-24

Reviewer   Type  LC end Draft
Jouni Korhonen Telechat  2018-04-24 
draft-ietf-idr-bgp-gr-notification-15
Peter Yee  Telechat  2018-04-30 draft-ietf-teas-actn-framework-14 *

For telechat 2018-06-07

Reviewer   Type  LC end Draft
Roni Even  Telechat  2018-04-19 
draft-ietf-mtgvenue-meeting-policy-06 *
Roni Even  Last Call 2018-05-21 draft-ietf-extra-imap-unauth-00
Fernando Gont  Last Call 2018-05-21 draft-ietf-httpbis-h2-websockets-05
Erik Kline Telechat  2018-04-23 draft-ietf-httpbis-replay-03 *

Last calls:

Reviewer   Type  LC end Draft
Francis Dupont Last Call 2018-05-21 draft-ietf-bfd-multipoint-16
Vijay Gurbani  Last Call 2018-05-21 draft-ietf-sfc-hierarchical-08
Wassim Haddad  Last Call 2018-05-21 draft-ietf-v6ops-conditional-ras-04
Christer Holmberg  Last Call 2018-05-25 
draft-ietf-tsvwg-iana-dscp-registry-05

* Other revision previously reviewed
** This revision already reviewed

Next in the reviewer rotation:

  Paul Kyzivat
  Matthew Miller
  Francesca Palombini
  Pete Resnick
  Ines Robles
  Dan Romascanu
  David Schinazi
  Meral Shirazipour
  Robert Sparks
  Dale Worley

The LC and Telechat review templates are included below:
---

-- Begin LC Template --
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:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments: 

-- End LC Template --

-- Begin Telechat Template --
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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

-- End Telechat Template --


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