Subject: [Gen-art] A *new* batch of IETF LC reviews - 2016-04-18

From: "A. Jean Mahoney" <[email-masked]>
Date: Mon, 18 Apr 2016 13:06:26 -0500

Hi all,

The following reviewers have assignments:

Reviewer          LC end      Draft
---------------------------------------------------------------------
Elwyn Davies      2016-04-29  draft-ietf-i2rs-traceability-08 *

Francis Dupont    2016-04-29  draft-ietf-i2rs-pub-sub-requirements-06 *

Joel Halpern      2016-05-13  draft-sheffer-rfc6982bis-00

Meral Shirazipour 2016-04-29  draft-ietf-idr-add-paths-13 *

Paul Kyzivat      2016-04-29  draft-ietf-idr-route-oscillation-stop-02 *

Peter Yee         2016-04-29  draft-ietf-isis-node-admin-tag-08 *

* On the May 5th telechat

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The updated template is included below.

Thanks,

Jean

-------------------------------------------------------------------

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 22 Apr 2016 12:10:02 -0400

Document: draft-sheffer-rfc6982bis-00
     Improving Awareness of Running Code: The Implementation
         Status Section
Reviewer: Joel M. Halpern
Review Date: 22-April-2016
IETF LC End Date: 13-May-2016
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:
     The introduction describes RFC1264 as requiring at least one 
implementation.  The general requirement in RFC 1264 is multiple 
implementations, at least two independent.  While it is a minor issue, 
this document should characterize RFC 1264 more carefully.

     In the Alternative Formats section, it strikes me that there is an 
alternative that is sometimes useful that is de-emphasised by the text 
as written.  If there has been significant insight gained from the 
implementations, that may be useful to capture in a longer-lived 
context.  In that case, an RFC describing implementation may still be 
useful.  I would appreciate it if the authors would consider adding a 
short paragraph to this effect.

Nits/editorial comments:

---

From: Joel Halpern <[email-masked]>
Date: Fri, 22 Apr 2016 12:10:47 -0400

[Resending with the summary line filled in]

Summary: This document is ready for publication as a Best Current Practice.

Major issues: N/A

Minor issues:

Nits/editorial comments: N/A

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 22 Apr 2016 19:01:24 +0100

Hi Joel,

Thanks for your time.

> this document should characterize RFC 1264 more carefully.

I'm not opposed to the change you suggest but I quote from section 4.0 of RFC
1264

|    4) One or more implementations must exist.

> short paragraph to this effect.

Oh, it was certainly not our intention to persuade people not to add
documentation about implementations. I don't think the current text
de-emphasises anything (unless you consider that not talking about something is
de-emphasis). It would not hurt us to note how implementation reports have often
been written and how the IESG currently recommends that they are written.

Cheers,
Adrian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 22 Apr 2016 14:05:41 -0400

Interesting.  I was looking at bullet 4 in section 3, which reads "At 
least two [implementations] must be written independently."

Not a big deal.

And yes, I think a sentence or two on other value in implementation 
reports would be helpful.  My thought is that there are many cases where 
the BCP described here is all that is useful, and some cases where a 
longer term record is useful.

Yours,
Joel

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 23 Apr 2016 00:33:49 +0300

Hi Joel,

Thanks for your review!

I would appreciate an example of an existing RFC that documents an 
implementation, so we can refer to it in the text.

Best,
	Yaron

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 22 Apr 2016 22:31:10 -0400

I rather like RFC 1369 for its conclusions from the implementation 
experience.
Probably closer to the lines I was thinking of is RFC 5080.

There are many others.
Yours,
Joel