Shepherd writeup
rfc7690-06

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in
the title page header?

This is an informational draft, identifying a problem and proposing
operational mitigations.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up.
Recent examples can be found in the "Action" announcements for
approved documents. The approval announcement contains the following
sections:

Technical Summary

   This document calls attention to the problem of delivering ICMPv6
   type 2 "Packet Too Big" (PTB) messages to the intended destination
   in ECMP load balanced or anycast network architectures.  It
   discusses operational mitigations that can be employed to address
   this class of failures.

Working Group Summary

  The draft has been accepted with enthusiasm.

Document Quality

  This is not a protocol. The operational mitigations proposed have
  been implemented in various places, but are not uniformly
  implemented.

Personnel

  The Document Shepherd is Fred Baker. Joel Jaeggli, one of the
  authors, is the obvious Area Director. He may prefer to defer to
  his co-AD.

(3) Briefly describe the review of this document that was performed
by the Document Shepherd.

I have read the draft in various incarnations, and discussed its
recommendations with Matt Mathis, the originator of RFC 4821, and
with some of his colleagues.

(4) Does the document Shepherd have any concerns about the depth
or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or
from broader perspective, e.g., security, operational complexity,
AAA, DNS, DHCP, XML, or internationalization? If so, describe the
review that took place.

Not really, as it is specifically operational. However, the topic
has come up in intarea and tsvwg. It would be worth asking for their
comments on it.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of?

No.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of
BCP 78 and BCP 79 have already been filed.

They have been asked, and are unaware of IPR issues.

(8) Has an IPR disclosure been filed that references this document?

No IPR disclosure has been filed as of 7/7/2015.

(9) How solid is the WG consensus behind this document?

There is widespread agreement.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to
be thorough.

The idnits tool identifies two issues. One is that the code snippet
in section 3.2 doesn't have brackets saying "<CODE BEGINS>" or
"<CODE ENDS>". The code is, however, clearly identified and delimited
in the text. I don't view this as an issue; if the IESG does, I'm
sure the authors can add it. The other is that the code contains
the string "pkt[Ether].dst", and the tool picks up [Ether] as an
apparent dangling reference. It's not.

(13) Have all references within this document been identified as
either normative or informative?

Yes. There is one reference, and it is informative.

(16) Will publication of this document change the status of any
existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section...

It is correct.
Back