Subject: [pim] Publication request for draft-ietf-pim-ecmp

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 17 Mar 2012 14:19:05 -0000

Forwarding a publication request on behalf of the PIM WG for an Experimental
RFC. 

> PROTO Writeup for draft-ietf-pim-ecmp-02
> =================================================
> 
> http://www.ietf.org/id/draft-ietf-pim-ecmp-02.txt
> 
>    (1.a)  Who is the Document Shepherd for this document?  Has the
>       Document Shepherd personally reviewed this version of the document
>       and, in particular, does he or she believe this version is ready
>       for forwarding to the IESG for publication?
> 
> Mike McBride is the document shepherd.  I have personally reviewed the
> document, and believe it is ready for publication as an Experimental RFC.
> 
>    (1.b)  Has the document had adequate review both from key members of
>       the interested community and others?  Does the Document Shepherd
>       have any concerns about the depth or breadth of the reviews that
>       have been performed?
> 
> The document has undergone thorough review within  IETF's  Multicast
> community.
> 
>    (1.c)  Does the Document Shepherd have concerns that the document
>       needs more review from a particular or broader perspective, e.g.,
>       security, operational complexity, someone familiar with AAA,
>       internationalization or XML?
> 
> No
> 
>    (1.d)  Does the Document Shepherd have any specific concerns or
>       issues with this document that the Responsible Area Director
>       and/or the IESG should be aware of?  For example, perhaps he or
>       she is uncomfortable with certain parts of the document, or has
>       concerns whether there really is a need for it.  In any event, if
>       the interested community has discussed those issues and has
>       indicated that it still wishes to advance the document, detail
>       those concerns here.
> 
> I have no concerns.
> 
>    (1.e)  How solid is the consensus of the interested community behind
>       this document?  Does it represent the strong concurrence of a few
>       individuals, with others being silent, or does the interested
>       community as a whole understand and agree with it?
> 
> There is consensus within the PIM WG to publish the document. The document
> has
> been actively discussed on the wg list and in wg meetings.
> 
> 
>    (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
>       discontent?  If so, please summarise the areas of conflict in
>       separate email messages to the Responsible Area Director.  (It
>       should be in a separate email because this questionnaire is
>       entered into the ID Tracker.)
> 
> No.
> 
>    (1.g)  Has the Document Shepherd personally verified that the
>       document satisfies all ID nits?  (See
>       http://www.ietf.org/ID-Checklist.html and
>       http://tools.ietf.org/tools/idnits/).  Boilerplate checks are not
>       enough; this check needs to be thorough.  Has the document met all
>       formal review criteria it needs to, such as the MIB Doctor, media
>       type and URI type reviews?
> 
> Yes.  We may need to have one update for Miscellaneous warnings if necessary:
>   ----------------------------------------------------------------------------
> 
>   == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
>      or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
>      use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
>      mean).
> 
>      Found 'MUST not' in this paragraph:
> 
>      If a PIM router supports this specification, it MUST send the Hello
>      option ECMP-Redirect-Supported TLV in its PIM Hello messages.  A PIM
>      router sends ECMP Redirects on an interface only when it detects that all
>      neighbors have sent this Hello option.  If a PIM router detects that any
>      of its neighbor does not support this Hello option, it MUST not send ECMP
>      Redirects, however, it SHOULD still process any ECMP Redirects received.
> 
> 
>    (1.h)  Has the document split its references into normative and
>       informative?  Are there normative references to documents that are
>       not ready for advancement or are otherwise in an unclear state
>       If such normative references exist, what is the strategy for their
>       completion?  Are there normative references that are downward
>       references, as described in [RFC3967]?  If so, list these downward
>       references to support the Area Director in the Last Call procedure
>       for them [RFC3967].
> 
> Yes. Normative references are all stable documents published as RFCs.
> 
> 
>    (1.i)  Has the Document Shepherd verified that the document IANA
>       consideration section exists and is consistent with the body of
>       the document?  If the document specifies protocol extensions, are
>       reservations requested in appropriate IANA registries?  Are the
>       IANA registries clearly identified?  If the document creates a new
>       registry, does it define the proposed initial contents of the
>       registry and an allocation procedure for future registrations?
>       Does it suggested a reasonable name for the new registry?  See
>       [I-D.narten-iana-considerations-rfc2434bis].  If the document
>       describes an Expert Review process has Shepherd conferred with the
>       Responsible Area Director so that the IESG can appoint the needed
>       Expert during the IESG Evaluation?
> 
> 
> The IANA Considerations section exists. A PIM Hello Option Type is
> requested to be assigned to the PIM ECMP Redirect Hello Option.  This
> document recommends 32 (0x20) as the "PIM ECMP Redirect Hello Option Type.
> 
> A PIM Message Type is requested to be assigned to the ECMP Redirect
> message.  The next available Type value is 11(0xB).
> 
> 
> 
>    (1.j)  Has the Document Shepherd verified that sections of the
>       document that are written in a formal language, such as XML code,
>       BNF rules, MIB definitions, etc., validate correctly in an
>       automated checker?
> 
> 
> Not applicable.
> 
> 
>    (1.k)  The IESG approval announcement includes a Document
>       Announcement Write-Up.  Please provide such a Document
>       Announcement Writeup.  Recent examples can be found in the
>       "Action" announcements for approved documents.
> 
> 
>    This document introduces the ECMP Redirect, a mechanism to improve
>    the RPF procedure over ECMPs.  It allows ECMP path selection to be
>    based on administratively selected metrics, such as data transmission
>    delays, path preferences and routing metrics.

---

From: Michael McBride <[email-masked]>
Date: Sun, 18 Mar 2012 06:04:13 +0000

Thanks Adrian,

One correction for 1.a. Please change to:

"Mike McBride is the document shepherd.  I have personally reviewed the
document, and believe it is ready for publication as a Standards Track RFC."

Standards track instead of Experimental.

Thanks,
mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Adrian Farrel
> Sent: Saturday, March 17, 2012 7:19 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [pim] Publication request for draft-ietf-pim-ecmp
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim