Explicit Reverse Path Forwarding (RPF) Vector
draft-ietf-pim-explicit-rpf-vector-09

[Ballot comment]


Please take the comments below with a pinch of salt - I'm
not sure I understood what this was specifying so I may be
off base below. (Mind you, this caveat is also a comment
of sorts;-)

abstract: "RP" could be interpreted as reverse path or
rendezvous point, suggest expanding this in the abstract.

section 7: I don't understand: "A router processing
'Explicit' or 'Loose' RPF Vectors MUST verify that the
order in which RPF Vectors types appear in the PIM Join
Attribute list received from its downstream PIM neighbors
are equal." Seems like a bad plan to have a MUST in such a
hard to grok sentence. Or is that just me? (Actually, that
entire paragraph is hard to get.)

- section 12: couldn't this allow one node to try DoS
another by including it in the vector? Isn't that worth
noting?

- please also respond the secdir review [1] which raised a
couple more points.

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06295.html

[Ballot comment]
I may have missed it, but don't see a response to the SecDir review.  In particular, the last question would be good to see answered/elaborated on in the security considerations section.

https://www.ietf.org/mail-archive/web/secdir/current/msg06295.html
"Also, the security consideration section in ietf-pim-rfc4601bis document
discusses the impact of a forget Join message and its implication on the
multicast traffic. You might want to add some text to explain if this new
attribute, defined in this document, changes the implication of a forged
Join message or not; if it does, you might want to explain how."

[Ballot comment]
I find the use of the word "we" in this document to be confusing. Sometimes it seems to refer to the authors or the WG ("we're defining a new attribute") and sometimes to implementations ("we use the RPF Vector stack"). Particularly problematic is the use of a normative requirement on an ambiguous "we" (Section 1): "For these vectors we MUST NOT do a unicast route lookup." I would suggest replacing every instance of "we" with the appropriate subject, e.g., "the router" or "this document," or leaving the subject out altogether.

[Ballot comment]
I support the publication of this document, but I do have two points I would like you to consider...

1. The use of 2119 keywords in the Introduction are inappropriate. They can easily be changed to non-normative words and the meaning will not be lost.

2. While this approach is viable, and needed, in a subset of deployment scenarios, it is also inappropriate for other scenarios. I think some guidance on when to use, or not use, this option would be useful as an addendum to the motivation provided in section 3.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-pim-explicit-rpf-vector-07.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the PIM Join Attribute Types subregistry of the Protocol Independent Multicast (PIM) Parameters registry located at:

http://www.iana.org/assignments/pim-parameters/

a single, new attribute type is to be registered as follows:

Value: [ TBD-at-registration ]
Name: Explicit RPF Vector
Reference: [ RFC-to-be ]

IANA notes that the authors suggest the value of 4 for this registration.

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-pim-explicit-rpf-vector@ietf.org, aretana@cisco.com, mmcbride7@gmail.com, pim-chairs@ietf.org, pim@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Explicit RPF Vector) to Proposed Standard


The IESG has received a request from the Protocols for IP Multicast WG
(pim) to consider the following document:
- 'Explicit RPF Vector'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-12-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496
  can be included in a PIM Join Attribute such that the RPF neighbor is
  selected based on the unicast reachability of the RPF Vector instead
  of the Source or RP associated with the multicast tree.

  This document defines a new RPF Vector Attribute type such that an
  explicit RPF neighbor list can be encoded in the PIM Join Attribute,
  bypassing the unicast route lookup.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pim-explicit-rpf-vector/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pim-explicit-rpf-vector/ballot/


No IPR declarations have been submitted directly on this I-D.

(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?

Standards Track. This is clearly stated and is the agreed upon status between the WG, chairs and AD.

(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:
For some applications, it might be useful to have a way to specify the explicit path along which the PIM join is propagated. This document defines a new Reverse Path Forwarding (RPF) Vector TLV to build multicast trees via an explicit path sent in the PIM join.

Working Group Summary:

There was several comments on the mailing list during the working group last call. All comments have been addressed in this latest draft. The AD has given this draft a thorough review and made several comments including regarding Security. The security section has been updated to satisfy his comments. We have complete consensus for progressing this document.

Document Quality:

At least one vendor (Cisco) has indicted that they will implement the functionality documented in this draft.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Mike McBride, PIM WG co-chair. Alvaro Retana is the Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Mike McBride, PIM WG Co-Chair, is the document Shepherd. After thorough review by the working group, the chairs, and the AD (Alvaro), the document is ready for publication. My Co-Chair, Stig Venaas, has also reviewed the document and agrees that the document is ready for publication.

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

No, there were several comments made during the WGLC and all have been addressed.

(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.

No

(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? 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 WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no concerns about this document.

(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. If not, explain why?

Authors have confirmed no IPR

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The consensus is solid. We had many individuals, from a variety of companies, indicate their support and offered comments.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

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.

No additional nits found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

Not Applicable

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

Yes

(14) 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 plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Publication of this document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

A new attribute type from the PIM Join Attribute Types registry needs to be assigned by IANA for the Explicit RPF Vector attribute. The proposed value is 4.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registry, only a new attribute type from an existing registry

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

Not Applicable

(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?

Standards Track. This is clearly stated and is the agreed upon status between the WG, chairs and AD.

(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:
For some applications, it might be useful to have a way to specify the explicit path along which the PIM join is propagated. This document defines a new Reverse Path Forwarding (RPF) Vector TLV to build multicast trees via an explicit path sent in the PIM join.

Working Group Summary:

There was several comments on the mailing list during the working group last call. All comments have been addressed in this latest draft. The AD has given this draft a thorough review and made several comments including regarding Security. The security section has been updated to satisfy his comments. We have complete consensus for progressing this document.

Document Quality:

At least one vendor (Cisco) has indicted that they will implement the functionality documented in this draft.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Mike McBride, PIM WG co-chair. Adrian Farrel is the Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Mike McBride, PIM WG Co-Chair, is the document Shepherd. After thorough review by the working group, the chairs, and the AD (Alvaro), the document is ready for publication. My Co-Chair, Stig Venaas, has also reviewed the document and agrees that the document is ready for publication.

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

No, there were several comments made during the WGLC and all have been addressed.

(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.

No

(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? 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 WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no concerns about this document.

(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. If not, explain why?

Authors have confirmed no IPR

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The consensus is solid. We had many individuals, from a variety of companies, indicate their support and offered comments.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

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.

No additional nits found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

Not Applicable

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

Yes

(14) 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 plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Publication of this document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

A new attribute type from the PIM Join Attribute Types registry needs to be assigned by IANA for the Explicit RPF Vector attribute. The proposed value is 4.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registry, only a new attribute type from an existing registry

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

Not Applicable

Sent AD Review:

=====
Hi!

I just finished reading this document.  I have a couple of Mayor items that should be easy to resolve and a some Minor ones.

My main concern with this document is around the validation of the correctness of the information.  While  there is no specified mechanism to validate the correctness of the vectors, the Security Considerations section says that "the Explicit RPF Vector list should be subject to a policy to validate the list consists of a valid path before its used by a receiver to build a multicast tree"..so there seems to be a contradiction between that is expected and what is being specified.

Knowing that we're in a world where external agents (controllers/administrators/etc.) somehow "know everything", I am ok with the assumption that they came up with a valid path ("How the Explicit RPF Vector list is determined is outside the scope of this document.") as long as potential risks are explicitly outlined, and some of the basics are clarified. 

I expect at least some discussions and an update to the document.  When that is done I'll start the IETF Last Call and move this document forward.

Thanks!

Alvaro.



Major:
Indented Status.  The datatracker page and the Shepherd Writeup both mention that the document should be "Informational because its useful primarily in specific scenarios and it's what the WG agreed upon", but the header says "Standards Track".  It looks like the status on the document changed in –05, which came out after the current Shepherd Writeup, but it's not clear from the mailing list if that was discussed (and the datatracket/writeup are just outdated) or if the document needs to be updated.


Correctness and Validation.  As identified in Section 3. (Motivation), there are no "new mechanism in PIM to validate the correctness of the RPF vectors".
New?  Are there existing mechanisms?

Section 10. (Unsupported Explicit Vector Handling)
- The document expects "that the administrator computes the path to include routers that support explcit (sp) vector and check that the state is created correctly on each router along the path."  That is a very nice expectation, but what happens if something changes?
- What about the case where a mixed set of vectors exists, and the Explicit Vectors are the unsupported ones?
- Do changing conditions in the network with the potential of nodes not supporting the vectors, create a (security or operational) vulnerability?

Section 13. (Security Considerations) does say that "the Explicit RPF Vector list should be subject to a policy to validate the list consists of a valid path before its used by a receiver to build a multicast tree."  This is interesting specially because there's text that says that "how the Explicit RPF Vector list is determined is outside the scope of this document."  IOW, the document is not saying how to build the information, but it does say that it has to be validated.  I have several questions about this — it would go a long way if you could be more explicit.  I don't think we need to include all the answers or be too specific, but a little more clarity might help with any concerns from the SecDir or Security ADs.
- What do you mean by a "policy"?  Are you hinting at a gating function to either accept or not a vector list?  If so, how would/could that be coordinated across multiple nodes?
- What is a "valid path"?  I assume that means a path made of "valid addresses", but is the validity determined just by a reachable address?  Or should the validator be looking for the addresses to be reachable in a specific order (path)?  Or ??
- BTW, in 11. (Explicit RPF Vector Attribute TLV Format) the address is defined as "Value: … This could be a valid primary or secondary address."  "Could be", meaning it can be just that, or that it could be anything?  Maybe just don't be so specific (primary or secondary) and leave it at "valid address".

Section 11. (Explicit RPF Vector Attribute TLV Format)
"Length:  Length depending on the Address Family of the Encoded-Unicast address."  [I know this is the same text as in rfc5496.]  The description sounds like I need to know what type of address I have in the next field to determine if the length is correct..but there is no explicit indication of which AF is being used.  In fact, nowhere in the document is there a mention that the possible AFs are IPv4/IPv6 — it would be very nice if that was explicitly mentioned.  I don't think we need to change the encoding at thins point, but knowing that (today) there are only two expected lengths would help with determining validity.

Minor:
References:
- The reference to I-D.ietf-rtgwg-mofrr is outdated (now rfc7431).  I also think we could make it an Informational Reference.
- Change the reference to rfc4601 to I-D.ietf-pim-rfc4601bis.  Please take a look at the updated Security Considerations (in draft-ietf-pim-rfc4601bis wrt rfc4601) to make sure that the reference still works.

It looks like Section 5. (Explicit RPF Vector Attribute) is superfluous as the details of the TLV are defined elsewhere.  In fact, I would move Section 11 to this position (just a nit).

Section 7. (Conflicting RPF Vectors)
"…the content of the RPF Vectors MUST be compared ([RFC5384])."  It seems like this reference is out of place as rfc5384 was already positioned as not addressing the specific problem of mixed RPF vectors.
=====

I am returning this to the WG.  It has been many (6?) months since I sent my AD review.  No work has been done.  The WG should evaluate whether this work is actually needed and work on improving the draft, if so.

AD review
=======
Hi,

I have done my usual AD review of this document after receiving the
publication request. The purpose of the review is to catch and fix
any issues that might otherwise show up in IETF last call or IESG
review. This helps smooth the passage of the document later and also
increases the quality text.

This seems like a good and simple proposal, and I don't want to bog
it down. But there are a number of small editorial issues and a
couple of technical questions included below.

I have put the document into "Revised I-D Needed" state and will
wait to see an updated version before I start the IETF last call.
But please feel free to debate any of these points with me.

Thanks for the work.

Adrian

---

You need to fix the idnits before I can put this to IETF last call.

- Missing page breaks
- 2119 boilerplate broken (you have "SHALL" "NOT")
- there is a line too long
- missing reference for [draft-mofrr-karan]

[Shepherd - Your write-up says no nits found. How come?]

---                                                       

Conventionally we have used the term "strict" in counterpoint to
"loose" to describe hops, and termed the whole path "explicit". I
don't suppose this matters: you are defining your own terms for a
new application in PIM.

However, this has led to some confusion in the text because of the
normal use of the English word "explicit". For example, the Abstract
says:
  This document defines a new Reverse Path Forwarding (RPF) Vector
  TLV to build multicast trees via an explicit path sent in the PIM
  join.
...which doesn't give any clue to the distinction between this work
and RFC 5496. You might be better with something like:
  The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496
  can be included in a PIM Join Attribute to allow a leaf to apply
  controls to the path of a multicast tree. This document defines a
  new Vector Attribute type so that an RPF Vector TLV can be used to
  indicate that the unicast address indicated in the TLV must be used
  as the next hop in the multicast tree.

This kind of language could usefully be repeated throughout the
document.

---

Section 1

  For some applications, it might be useful to have a way to specify
  the explicit path along which the PIM join is propagated. 

Could you possibly be a little less vague? :-)
If this is the level of certainty you have for the utility of your work
then it shouldn't be on the Standards Track. Fortunately, you *do* have
a good use case later in the document.

I suggest re-ordering paragraphs:

3, 4, 2

...and delete paragraph 1.

---

Suggest to rename Section 3 "Motivation"

---

Section 3

As noted above, you need to provide the reference for
[draft-mofrr-karan]. But actually, I wonder whether you really need to
include the citation as the text in the paragraph seems to hold up well
without any further explanation.

---

Section 3

  It might be useful to have a way to specify the explicit path
  along which the PIM join is propagated.

I think you established that it *is* useful in the previous text.

---

Section 3

  How the Explicit RPF Vector list is determined is outside the
  scope of this document. It may either be manually configured by
  the network operator or procedures may be implemented on the
  egress router to dynamically calculate the vector list based on
  a link state database protocol, like OSPF or IS-IS.

I agree that this should be out of scope and you should say so.
However, having said it is out of scope, why do you go on to
discuss it?

---

You should give more clarity as to why an RPF list using 5496 list
entries would not be good enough. In Figure 1 it would appear that the
list {R4, R3, R6, R5, R2, R1} would work just fine using 5496.

---

Section 5

  This draft uses PIM join attribute type 4 for specifying an Explicit
  RPF Vector.

Please make this:

  This draft uses PIM join attribute type TBD by IANA for specifying an
  Explicit RPF Vector.

---

Section 7 is describing, for example, simple network with source S and
leafs R1 and R2...

  A  R1
/ \ /
S  C
\ / \
  B  R2

...where R1 sends explicit RPF TLVs {C, A} and that path is set up.
Then R2 sends explicit RPF TLVs {C, B}.

Section 3.3.3 of RFC 5384 is cited as the tie-breaker.
This is OK, but it appears to say that the Explicit RPF is not
mandatory. It would be nice to make it very clear that a receiver has
no expectations that the explicit RPF list it supplies will actually be
used.

---

Section 10

This is important material to include, but I think it needs some work.

  The F bit MUST be set to 0 by a downstream router in the join that
  is sent to the upstream router that does not support Explicit RPF
  vector.

But the downstream router doesn't know whether the upstream router
supports the new vector or not! So I think you need...

  The F bit MUST be set to 0 in all Explicit RPF vectors in case the
  upstream router receiving the join does not support the TLV. As
  described in section 3.3.2 of [RFC5384], routers that do not
  understand the type of a particular attribute that has the F bit
  clear will discard it and continue to process the join.
 
  This processing is particularly important when the routers that
  do not support the Explicit RPF TLV are identified as hops in the
  explicit RPF list, because failing to remove the RPF vectors could
  cause upstream routers to send the join back toward these routers
  causing loops.
                                     
However, this doesn't seem to be the only way that loops can be caused
(referring back to section 9).
I don't see this mentioned in RFC 5496 either, but surely:
- the RPF list could contain an explicit loop
- the use of loose hops with poorly ordered list entries could create a
  loop

It is fine to note that this is caught by normal PIM processing, but
you should say so, and you should say what happens to the join. It
seems to me that 3.3.4 of 5496 only catches the case where join is
targeting the same upstream neighbor. But the sequential list nature
of the RPF list means that the loop might not be "endless" but could
still be a loop. How is this caught and handled?

---

Section 11

Please replace...

OLD
  Type
  ----
  The Vector Attribute type is 4.
NEW
  Type
  ----
  The Vector Attribute type is TBD by IANA.
END

---

Section 13 seems light!

The RPF list (and especially the explicit RPF) provides a way to
cause traffic to take different routes through the network. This
could be used to cause traffic to take expensive paths, to be
routed through hot parts of the network, or to be directed to
snooping nodes.

This means that the existence of the RPF TLV makes the use of
security in PIM more important to prevent tampering with the RPF
list.

But it also raises a question of policy and authorization. Clearly,
when a receiver seeks to join a multicast tree, it must be
authenticated for that join. But additionally, you may want to note
that the inclusion of an RPF list by a receiver should be subject to
policy.

(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?

Informational because its useful primarily in specific scenarios and it's what the WG agreed upon.

(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:
For some applications, it might be useful to have a way to specify the explicit path along which the PIM join is propagated. This document defines a new Reverse Path Forwarding (RPF) Vector TLV to build multicast trees via an explicit path sent in the PIM join.

Working Group Summary:

There was several comments on the mailing list during the working group last call. All comments have been addressed in this latest draft. We have complete consensus for progressing this document.

Document Quality:

At least one vendor (Cisco) has indicted that they will implement the functionality documented in this draft.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Mike McBride, PIM WG co-chair. Adrian Farrel is the Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

Mike McBride, PIM WG Co-Chair, is the document Shepherd. After thorough review by the working group and the chairs, the document is ready for publication. My Co-Chair, Stig Venaas, has also reviewed the document and agrees that the document is ready for publication.

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

No, there were several comments made during the WGLC and all have been addressed.

(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.

No

(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? 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 WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no concerns about this document.

(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. If not, explain why?

Authors have confirmed no IPR

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The consensus is solid. We had many individuals, from a variety of companies, indicate their support and offered comments.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

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.

No additional nits found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

Not Applicable

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

Yes

(14) 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 plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Publication of this document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

A new attribute type from the PIM Join Attribute Types registry needs to be assigned by IANA for the Explicit RPF Vector attribute. The proposed value is 4.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registry, only a new attribute type from an existing registry

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

Not Applicable