Re: [Gen-art] Genart telechat review of draft-ietf-anima-reference-model-08

[Brian E Carpenter]

Joel,

On 2018-10-12 15:17, Joel Halpern wrote:


> Nits/editorial comments:
> The reference [IDevID] still appears to me to be a normative reference.

It is normative in draft-ietf-anima-bootstrapping-keyinfra, where it really 
matters. Seems like a marginal point in an Informational document, but of course
we'll follow the IESG's guidance.

>In 3.3.3, the new parenthetical e.g. (replacing the wording "For example",
>seems to have no closing parenthesis.

Ack.

Thanks
 Brian

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

[Gen-art] Genart telechat review of draft-ietf-bess-mvpn-expl-track-12

[Brian Carpenter]

Reviewer: Brian Carpenter
Review result: Ready

Gen-ART telechat review of draft-ietf-bess-mvpn-expl-track-12

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-bess-mvpn-expl-track-12.txt
Reviewer: Brian Carpenter
Review Date: 2018-10-12
IETF LC End Date: 2018-10-09
IESG Telechat date: 2018-10-25 

Summary: Ready


Comments: 
-
Thank you for handling my Last Call comments.

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

[Gen-art] Genart telechat review of draft-ietf-anima-reference-model-08

[Joel Halpern]

Reviewer: Joel Halpern
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-anima-reference-model-08
Reviewer: Joel Halpern
Review Date: 2018-10-11
IETF LC End Date: 2018-08-21
IESG Telechat date: 2018-10-25

Summary: This document is ready for publication as a Informational RFC.

I appreciate the author's work in addressing my concerns.

Major issues: N/A

Minor issues: N/A

Nits/editorial comments:
The reference [IDevID] still appears to me to be a normative reference.

   In 3.3.3, the new parenthetical e.g. (replacing the wording "For example",
   seems to have no closing parenthesis.


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

[Gen-art] Review Assignments

[Jean Mahoney]

Hi all,

The following reviewers have assignments:

For telechat 2018-10-25

Reviewer   Type  LC end Draft
Stewart Bryant Telechat  2018-10-08 draft-ietf-regext-org-11 *
Brian CarpenterTelechat  2018-10-09 draft-ietf-bess-mvpn-expl-track-12 *
Fernando Gont  Last Call 2018-09-20 
draft-ietf-teas-assoc-corouted-bidir-frr-06
Joel Halpern   Telechat  2018-08-21 draft-ietf-anima-reference-model-08 
*
Pete Resnick   Telechat  2018-10-03 draft-ietf-detnet-use-cases-19 *
Robert Sparks  Last Call 2018-10-16 draft-ietf-extra-imap-replace-01

Last calls:

Reviewer   Type  LC end Draft
Stewart Bryant Last Call 2018-10-17 draft-ietf-isis-reverse-metric-13
Francis Dupont Last Call 2018-10-17 draft-ietf-clue-protocol-17
Roni Even  Last Call 2018-10-22 draft-ietf-netconf-zerotouch-25
Fernando Gont  Last Call 2018-10-19 draft-ietf-ntp-mac-05
Matthew Miller Last Call 2018-10-03 
draft-ietf-detnet-problem-statement-07
Pete Resnick   Last Call 2018-10-17 draft-ietf-bfcpbis-rfc4583bis-26
Robert Sparks  Last Call 2018-10-17 draft-ietf-clue-signaling-13

* Other revision previously reviewed
** This revision already reviewed

Next in the reviewer rotation:

  Vijay Gurbani
  Wassim Haddad
  Joel Halpern
  Christer Holmberg
  Russ Housley
  Erik Kline
  Jouni Korhonen
  Paul Kyzivat
  Matthew Miller
  Francesca Palombini

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

Re: [Gen-art] Gen-ART Telechat Call review of draft-ietf-httpbis-rand-access-live-03

[Alissa Cooper]

Meral, thanks for the review. I have entered a DISCUSS ballot on a process 
point and pointed the authors to your review.

Alissa

> On Oct 9, 2018, at 1:32 AM, Meral Shirazipour 
>  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 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-httpbis-rand-access-live-03
> Reviewer: Meral Shirazipour
> Review Date: 2018-10-08
> IETF LC End Date: NA
> IESG Telechat date: 2018-10-12
>  
> Summary: This draft is ready to be published as Experimental Track RFC ..
>  
> Major issues:
> Minor issues:
> Nits/editorial comments:
> -[Page 5], "accessable"--->"accessible"
> -[Page 5], "providing a">"providing an"
>  
> Best Regards,
> Meral
> ---
> Meral Shirazipour
> Ericsson Research
> www.ericsson.com 
> ___
> 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] Genart last call review of draft-ietf-tsvwg-fecframe-ext-04

[Alissa Cooper]

Christer, thanks for your review. Vincent, thanks for your response. I entered 
a No Objection ballot.

Alissa

> On Sep 19, 2018, at 8:30 AM, Vincent Roca  wrote:
> 
> Hello Christer,
> 
> Thanks a lot for the review.
> 
>> Le 14 sept. 2018 à 18:26, Christer Holmberg  
>> a écrit :
>> 
>> Reviewer: Christer Holmberg
>> 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 treat these comments just
>> like any other last call comments.
>> 
>> For more information, please see the FAQ at
>> 
>> .
>> 
>> Document: draft-ietf-tsvwg-fecframe-ext-04
>> Reviewer: Christer Holmberg
>> Review Date: 2018-09-14
>> IETF LC End Date: 2018-09-24
>> IESG Telechat date: Not scheduled for a telechat
>> 
>> Summary: The document is well written, but there is an issue regarding 
>> backward
>> compatibility that I want the authors to address.
>> 
>> Major issues:
>> 
>> Q1_MAJ:
>> 
>> Regarding backward compatibility, it's difficult for me to parse the second
>> bullet in Section 1.
>> 
>> The text seems to assume that SDP, and RFC 6364, are used to negotiate FEC.
>> But, RFC 6364 is only an informative reference, and I assume FEC does not 
>> even
>> mandate SDP?
>> 
>> Is there a generic requirement that the endpoints must negotiate the usage of
>> this mechanism before it is used? Or, can the mechanism be used towards an
>> endpoint that does not support it?
> 
> You’re right, the use of SDP is not mandatory, I’ve used a shortcut that may 
> be
> wrong in some environments. In fact the only application I have in mind, 3GPP 
> MBMS,
> relies on SDP to carry the so-called « FEC Framework Configuration 
> Information » that
> includes the FEC Scheme identifier, hence the mistake.
> Also, this is not, strictly speaking, a negotiation since there is usually no 
> feedback.
> The sender uses one or more FEC Scheme(s), the receiver chooses to join or not
> (hopefully there will be a repair flow it can process).
> 
> OLD:
>   o  any receiver, for instance a legacy receiver that only supports
>  block FEC schemes, can easily identify the FEC Scheme used in a
>  FECFRAME session thanks to the associated SDP file and its FEC
>  Encoding ID information (i.e., the "encoding-id=" parameter of a
>  "fec-repair-flow" attribute, [RFC6364]).  This mechanism is not
>  specific to this extension but is the basic approach for a
>  FECFRAME receiver to determine whether or not it supports the FEC
>  Scheme used in a given FECFRAME session;
> 
> NEW:
>   o  any receiver, for instance a legacy receiver that only supports
>  block FEC schemes, can easily identify the FEC Scheme used in a
>  FECFRAME session.  This is made possible with the FEC Encoding ID
>  that identifies the FEC Scheme used and which is carried in the
>  FEC Framework Configuration Information (see section 5.5 of
>  [RFC6363]).  For instance, when the Session Description Protocol
>  (SDP) is used to carry the FEC Framework Configuration
>  Information, the FEC Encoding ID can be communicated in the
>  "encoding-id=" parameter of a "fec-repair-flow" attribute
>  [RFC6364].  This mechanism is the basic approach for a FECFRAME
>  receiver to determine whether or not it supports the FEC Scheme
>  used in a given FECFRAME session;
> 
> 
> 
>> Minor issues:
>> 
>> N/A
>> 
>> Nits/editorial comments:
>> 
>> Q2_ED.
>> 
>> The document uses "extends RFC 6363" terminology in a couple of places. I
>> suggest to use "updates" instead.
> 
> Agreed. Update is the right term.
> 
> 
>> Q3_ED.
>> 
>> Section 1 says:
>> 
>>'This document is fully backward compatible with [RFC6363] that it extends
>>but does not replace."
>> 
>> I don't think you need the "extends but does not replace" part.
> 
> Done.
> 
> Cheers,
> 
>   Vincent
> ___
> 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] Genart last call review of draft-ietf-tsvwg-rlc-fec-scheme-07

[Alissa Cooper]

Russ, thanks for your review. Vincent, thanks for your responses. I entered a 
No Objection ballot supporting Mirja’s DISCUSS about the copyright claim in 
Appendix A.

Alissa

> On Sep 14, 2018, at 5:52 PM, Russ Housley  wrote:
> 
> Reviewer: Russ Housley
> 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-tsvwg-rlc-fec-scheme-07
> Reviewer: Russ Housley
> Review Date: 2018-09-14
> IETF LC End Date: 2018-09-24
> IESG Telechat date: unknown
> 
> Summary: Almost Ready
> 
> 
> Major Concerns:
> 
> None.
> 
> 
> Minor Concerns:
> 
> Section 2: Please update the first paragraph to reference RFC 8174
> in addition to RFC 2119, as follows: 
> 
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>   "OPTIONAL" in this document are to be interpreted as described in BCP
>   14 [RFC2119] [RFC8174] when, and only when, they appear in all
>   capitals, as shown here.
> 
> Section 2: Please add the definition of ^^.
> 
> Section 12.1: Please add a normative reference to RFC 8174.
> 
> The code in Appendix A will not compile using gcc unless you add:
> 
>   #include 
> 
> 
> ___
> 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] review of draft-ietf-ospf-lls-interface-id-06.txt

[Peter Psenak]

Hi Francis,

I have included your comments in the new version (8) that has been 
published.


thanks,
Peter

On 11/10/18 10:27 , 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-ospf-lls-interface-id-06.txt
Reviewer: Francis Dupont
Review Date: 20181005
IETF LC End Date: 20181010
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues:

Nits/editorial comments:
  I reviewed the version 06 but the version 07 is available so I am
trying to update my comments to the last version:
  - Abstract page 1: add "(LLS)" after "link-local signalling"

  - Requirement Language: usually it is in its own section in the body.
   I leave this to the RFC Editor, i.e. if it should be moved (s)he
   will do this.

  - ToC page 3 and 7 page 5: Acknowledgements -> Acknowledgments

  - 1 page 2: in theory you should introduce the LSA abbrev but as the
   whole document is about OSPF IMHO there is no strict requirement to
   introduce OSPF specific common abbrevs...

  - 1 page 3: add "(LLS)" after "link-local signalling"
   (note the Abstract is independent so the LLS abbrev should be introduced
twice and at its first use).

  - Authors' page 7: BE -> Belgium (for consistency with other addresses)

Regards

francis.dup...@fdupont.fr
.



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

[Gen-art] review of draft-ietf-ospf-lls-interface-id-06.txt

[Francis Dupont]

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-ospf-lls-interface-id-06.txt
Reviewer: Francis Dupont
Review Date: 20181005
IETF LC End Date: 20181010
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues:

Nits/editorial comments: 
 I reviewed the version 06 but the version 07 is available so I am
trying to update my comments to the last version:
 - Abstract page 1: add "(LLS)" after "link-local signalling"

 - Requirement Language: usually it is in its own section in the body.
  I leave this to the RFC Editor, i.e. if it should be moved (s)he
  will do this.

 - ToC page 3 and 7 page 5: Acknowledgements -> Acknowledgments

 - 1 page 2: in theory you should introduce the LSA abbrev but as the
  whole document is about OSPF IMHO there is no strict requirement to
  introduce OSPF specific common abbrevs...

 - 1 page 3: add "(LLS)" after "link-local signalling"
  (note the Abstract is independent so the LLS abbrev should be introduced
   twice and at its first use).

 - Authors' page 7: BE -> Belgium (for consistency with other addresses)

Regards 

francis.dup...@fdupont.fr

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