Subject: [pim] Publication request for draft-ietf-pim-pop-count

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-pop-count-05
> =================================================
> 
> http://www.ietf.org/id/draft-ietf-pim-pop-count-05.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. Just two changes may be made if necessary. per idnits:
> 
>   == Outdated reference: A later version (-12) exists of
>      draft-ietf-mboned-auto-multicast-11
> 
>   -- Duplicate reference: RFC4601, mentioned in 'HELLO', was also mentioned
>      in 'RFC4601'.
> 
> 
>    (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 new PIM Hello Option type, 29,
> has been assigned. A new PIM Join Attribute type needs to be assigned.
> 2 is proposed in this draft.
> 
> 
> 
>    (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 specification defines a method for providing multicast
>    distribution-tree accounting data.  Simple extensions to the PIM
>    protocol allow a rough approximation of tree-based data in a scalable
>    fashion.