[Gen-art] Review Assignments

2018-06-21 Thread Jean Mahoney 
Hi all,

The following reviewers have assignments:

For telechat 2018-07-05

Reviewer   Type  LC end Draft
Linda Dunbar   Last Call 2018-06-18 
draft-ietf-bfd-multipoint-active-tail-09
Francis Dupont Telechat  2018-05-21 draft-ietf-bfd-multipoint-18 *

Last calls:

Reviewer   Type  LC end Draft
Vijay Gurbani  Last Call 2018-06-25 draft-ietf-6man-rfc6434-bis-08
Joel Halpern   Last Call 2018-06-29 draft-ietf-netmod-schema-mount-10
Erik Kline Last Call 2018-06-28 draft-ietf-netconf-rfc7895bis-06

Early review requests:

Reviewer   DueDraft
Matthew Miller 2018-06-30 draft-ietf-cellar-ffv1-03

* Other revision previously reviewed
** This revision already reviewed

Next in the reviewer rotation:

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

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] [taugh.com-standards] Re:Re: Genart last call review of draft-ietf-dcrup-dkim-crypto-12

2018-06-21 Thread John R. Levine 

Please post a new revision. The document is approved pending a new revision (or 
an email from you saying that none is needed).


I posted -14 which I think addresses the comments.

Changed security section to point to 8032 for ed25519 rather than RSA.

Added a sentence noting the two independent signatures.

Fixed the MUSTard boiletplate.

Whew!


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [Gen-art] [taugh.com-standards] Re: Genart last call review of draft-ietf-dcrup-dkim-crypto-12

2018-06-21 Thread Alexey Melnikov 
Hi John,

On Wed, Jun 20, 2018, at 8:38 PM, John R. Levine wrote:
> > Pete, thanks for your review. I think the whole point of chartering DCRUP 
> > was to produce documents such as this.
> > John, thanks for updating to reference RFC 8174, although I agree with Adam 
> > that the boilerplate should match 8174.
> 
> It's fixed in the copy I have here, waiting to see what other nits to 
> fix show up in LC before posting the final.

Please post a new revision. The document is approved pending a new revision (or 
an email from you saying that none is needed).

Thank you,
Alexey

> By the way, there are comments in the XML pointing out the stuff to 
> remove, which have been there all along.

___
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-pals-ethernet-cw-06

2018-06-21 Thread Alissa Cooper 
Thanks!

> On Jun 19, 2018, at 5:35 AM, Stewart Bryant  wrote:
> 
> Hi Alissa
> 
> Yes, we will address all review comments that we receive.
> 
> - Stewart
> 
> 
> On 18/06/2018 18:44, Alissa Cooper wrote:
>> Brian, thanks for your review. Andy, thanks for your response; hopefully it 
>> means Brian’s comments will be addressed? I have entered a No Objection 
>> ballot.
>> 
>> Alissa
>> 
>>> On Jun 12, 2018, at 1:50 PM, Andrew G. Malis >> > wrote:
>>> 
>>> Brian,
>>> 
>>> Thanks, your comments are much appreciated.
>>> 
>>> Cheers,
>>> Andy
>>> 
>>> 
>>> On Mon, Jun 11, 2018 at 11:30 PM, Brian Carpenter 
>>> mailto:brian.e.carpen...@gmail.com>> wrote:
>>> Reviewer: Brian Carpenter
>>> Review result: Ready with Nits
>>> 
>>> Gen-ART Last Call review of draft-ietf-pals-ethernet-cw-06
>>> 
>>> 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-pals-ethernet-cw-06.txt
>>> Reviewer: Brian Carpenter
>>> Review Date: 2018-06-12
>>> IETF LC End Date: 2018-06-15
>>> IESG Telechat date: 2018-06-21
>>> 
>>> Summary: Ready with nits
>>> 
>>> 
>>> Comments: 
>>> -
>>> 
>>> This (with RFC4928) is a wonderful example of why layer violations are a 
>>> Bad Thing.
>>> 
>>> Nits:
>>> -
>>> 
>>> > 1.  Introduction
>>> 
>>> >   This document recommends the use of the Ethernet pseudowire control
>>> >   word in all but exceptional circumstances.
>>> 
>>> That's wrong, it *mandates* this usage with a MUST (first paragraph of 
>>> section 4).
>>> 
>>> > 3.  Background
>>> 
>>> >   A recent posting on the Nanog email list has highlighted this
>>> >   problem:
>>> >
>>> >   https://mailman.nanog.org/pipermail/nanog/2016-December/089395.html 
>>> > 
>>> 
>>> No, it's no longer recent. How about:
>>> 
>>>For example, a posting on the Nanog email list highlighted this
>>>problem:
>>> 
>>> > 7.  Operational Considerations
>>> >
>>> >   CW presence on the PW is controlled by the configuration and may be
>>> >   subject to default operational mode of not being enabled. 
>>> 
>>> That sentence is hard to parse. Try this:
>>> 
>>>A configuration switch might determine whether the CW is used on the PW. 
>>>The default configuration might be to disable use of the CW.
>>> 
>>> 
>>> ___
>>> 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] [taugh.com-standards] Genart last call review of draft-ietf-dcrup-dkim-crypto-12

2018-06-21 Thread Alissa Cooper 

> On Jun 20, 2018, at 3:38 PM, John R. Levine  wrote:
> 
>> Pete, thanks for your review. I think the whole point of chartering DCRUP 
>> was to produce documents such as this.
>> John, thanks for updating to reference RFC 8174, although I agree with Adam 
>> that the boilerplate should match 8174.
> 
> It's fixed in the copy I have here, waiting to see what other nits to fix 
> show up in LC before posting the final.
> 
> By the way, there are comments in the XML pointing out the stuff to remove, 
> which have been there all along.

Ok. I don’t read the XML when doing my IESG reviews.

Alissa

> 
> R's,
> John

___
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-ippm-2330-ipv6-04

2018-06-21 Thread Alissa Cooper 
Francesca, thanks for your reviews. Al, thanks for addressing Francesca’s 
review. I have entered a No Objection ballot.

Alissa


> On May 25, 2018, at 4:24 AM, Francesca Palombini 
>  wrote:
> 
> Hi Al,
> 
> Thanks for addressing my comments, it looks good.
> 
> Francesca
> 
>> -Original Message-
>> From: MORTON, ALFRED C (AL) 
>> Sent: den 23 maj 2018 15:39
>> To: Francesca Palombini ; gen-
>> a...@ietf.org
>> Cc: i...@ietf.org; i...@ietf.org; draft-ietf-ippm-2330-ipv6@ietf.org
>> Subject: RE: Genart last call review of draft-ietf-ippm-2330-ipv6-04
>> 
>> Hi Francesca,
>> one last item to resolve, we should be good now.
>> see below,
>> Al
>> 
>>> -Original Message-
>>> From: Francesca Palombini [mailto:francesca.palomb...@ericsson.com]
>>> Sent: Friday, April 27, 2018 3:44 AM
>>> To: MORTON, ALFRED C (AL) ; gen-art@ietf.org
>>> Cc: i...@ietf.org; i...@ietf.org;
>>> draft-ietf-ippm-2330-ipv6@ietf.org
>>> Subject: RE: Genart last call review of draft-ietf-ippm-2330-ipv6-04
>>> 
>>> Hi Al,
>>> 
>>> Thanks for your reply.
>>> I cut selected parts of the email to detail some of my comments, see
>>> inline.
>>> 
>>> Francesca
>>> 
>> ...snip...
> To be consistent with the first bullet of the list above ("It
> includes a valid IP header: see below for version-specific
> criteria."), I would rephrase the text above with something on the lines
>> of:
> 
> "For an IPvX (...) packet to be standard-formed, the IPvX-specific
> criteria for a valid IP header are:"
 [acm]
 Your wording suggestion dropped the clear indication of a requirement.
 We are using the RFC2119 terms consistently for requirements.
 
>>> 
>>> I was trying to point out that the first part of the section (first
>>> bullet
>>> list) does not use RFC2119 terms. I read the second bullet list as a
>>> "sub- list" of the first one, which is why I was suggesting removing
>>> the REQUIRED term. Or you could rephrase the first list to use REQUIRED
>> too.
>>> Anyway, this is nit-picking. Feel free to disregard.
>>> 
>> [acm]
>> I see your point now, and I changed the sentence introducing the initial (IP
>> version-agnostic list) to read:
>> 
>> A packet is standard-formed if it meets all of the following REQUIRED 
>> criteria:
> 
> ___
> 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-sfc-hierarchical-08

2018-06-21 Thread Alissa Cooper 
Vijay, thanks for your review. I have entered an Abstain ballot position due to 
concerns about Section 4.1.

Alissa

> On Jun 8, 2018, at 12:00 PM, Vijay Gurbani  wrote:
> 
> Reviewer: Vijay Gurbani
> Review result: 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-sfc-hierarchical-08
> Reviewer: Vijay Gurbani
> Review Date: 2018-06-08
> IETF LC End Date: 2018-05-21
> IESG Telechat date: 2018-06-21
> 
> Summary: This draft is ready for publication as an Informational.
> 
> Major issues: None.
> 
> Minor issues: None.
> 
> Nits/editorial comments:  None.
> 
> 
> ___
> 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 telechat review of draft-ietf-ippm-twamp-yang-11

2018-06-21 Thread Alissa Cooper 
Pete, thanks for your reviews. Mahesh, thanks for your responses. I have 
entered a No Objection ballot.

Alissa

> On Jun 20, 2018, at 3:39 PM, Mahesh Jethanandani  
> wrote:
> 
> Hi Pete,
> 
> Trimming it down even more.
> 
>> On Jun 20, 2018, at 5:18 AM, Pete Resnick  wrote:
>> 
>> Hi Mahesh,
>> 
>> Trimming a bit:
>> 
>> On 20 Jun 2018, at 0:36, Mahesh Jethanandani wrote:
>> 
>> 
 3.1 - s/The test session name that MUST be identical/The test session name,
 which MUST be identical (Unless you mean something really weird that I 
 don't
 think you mean. If you don't see the difference, then trust me, you mean
 "which", not "that”.)
>>> 
>>> You mean in Section 3.3.
>> 
>> Yes, sorry about that. Section 3.1 has a similar problem:
>> 
>> s/The test session name that uniquely identifies/The test session name, 
>> which uniquely identifies
>> 
>> and I forgot to note that one.
>> 
>>> How about s/The test session name that MUST be identical with the/The test 
>>> session name MUST be identical to the/?
>> 
>> That's not quite right. You are giving a list of fields (as you say, 
>> "Primary configuration fields include:"), so you don't want something in 
>> that list that is a rule. The field is "the test session name", and that 
>> field MUST be identical to the client name.
> 
> What we are trying to say is that “the test session name” on the 
> Session-Sender side must correspond to “the test session name” on the 
> Control-Client side (not the client's name).
> 
>> 
>> When you say, "the test session name that MUST be identical with...", it 
>> sounds like there is more than one test session name,
> 
> That is not what we are trying to say. Each test session has only one name. 
> And that is why I reworded it say “the test session name MUST be identical to 
> the”, hopefully implying that there is only one name.
> 
>> and you're talking about the one that MUST be identical with the client name.
> 
> What we are trying to say is that every test session in the Session-Sender 
> has a corresponding test session on the Control-Client. The name of the test 
> session on the Session-Sender side has to match the name of the test session 
> on the Control-Client.
> 
>> Similarly with the above, it sounds like there's one test session name which 
>> uniquely identifies it, and one that doesn't uniquely identify it. That's 
>> not what you mean.
> 
> As I say above, the test sessions on either side have only one name.
> 
> Having said all that, if you feel that your suggested edit is better, we can 
> go with that. I just feel my suggested edit is crisper. 
> 
> Thanks.
> 
> Mahesh Jethanandani
> mjethanand...@gmail.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