Skip to main content

Enhanced Feasible-Path Unicast Reverse Path Forwarding
draft-ietf-opsec-urpf-improvements-04

Revision differences

Document history

Date Rev. By Action
2020-02-03
04 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-01-30
04 (System) RFC Editor state changed to AUTH48 from TI
2020-01-28
04 (System) RFC Editor state changed to TI
2020-01-10
04 (System) RFC Editor state changed to TI from AUTH48
2019-12-23
04 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-10-18
04 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Carlos Martínez was marked no-response
2019-10-15
04 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-09-09
04 Wesley Eddy Request closed, assignment withdrawn: Brian Trammell Last Call TSVART review
2019-09-09
04 Wesley Eddy Closed request for Last Call review by TSVART with state 'Overtaken by Events'
2019-09-05
04 Tero Kivinen Assignment of request for Last Call review by SECDIR to Derek Atkins was marked no-response
2019-09-03
04 (System) RFC Editor state changed to EDIT
2019-09-03
04 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-09-03
04 (System) Announcement was received by RFC Editor
2019-09-03
04 (System) IANA Action state changed to No IANA Actions from In Progress
2019-09-03
04 (System) IANA Action state changed to In Progress
2019-09-03
04 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2019-09-03
04 Cindy Morgan IESG has approved the document
2019-09-03
04 Cindy Morgan Closed "Approve" ballot
2019-09-03
04 Cindy Morgan Ballot approval text was generated
2019-08-30
04 Alvaro Retana [Ballot Position Update] Position for Alvaro Retana has been changed to Yes from Discuss
2019-08-30
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-08-30
04 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2019-08-30
04 Kotikalapudi Sriram New version available: draft-ietf-opsec-urpf-improvements-04.txt
2019-08-30
04 (System) New version approved
2019-08-30
04 (System) Request for posting confirmation emailed to previous authors: Kotikalapudi Sriram , Doug Montgomery , Jeffrey Haas
2019-08-30
04 Kotikalapudi Sriram Uploaded new revision
2019-08-28
03 Pete Resnick Assignment of request for Last Call review by GENART to Pete Resnick was rejected
2019-08-22
03 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2019-08-22
03 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2019-08-22
03 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2019-08-21
03 Min Ye Request for Telechat review by RTGDIR Completed: Has Issues. Reviewer: Matthew Bocci.
2019-08-21
03 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-08-21
03 Benjamin Kaduk
[Ballot comment]
Thank you for this well-written document!  It will be beneficial to the
security of the internet as a whole to have effective BCP38 …
[Ballot comment]
Thank you for this well-written document!  It will be beneficial to the
security of the internet as a whole to have effective BCP38 protections
applied more widely.

I'm happy to see the discussion about Algorithm A vs. B as recommended
default, prompted by Alvaro's ballot position.  On the face of things I
do share his concern, as having "safe defaults" in the sense of not
dropping legitimate traffic seems pretty compelling, but I do recognize
that Algorithm A produces a stricter check, and that is in a different
sense "more safe".  I don't think I have much to add to the discussion,
though, so I'll continue to watch it play out.  (Perhaps some of the
discussion could make it into the security considerations of this
document once things get settled, though.)

Section 2.1

  dropped.  The ACLs for the ingress/egress filters need to be
  maintained to keep them up to date.  Updating the ACLs is an operator
  driven manual process, and hence operationally difficult or
  infeasible.

nit: hyphenate "operator-driven"

Section 2.2

In Figure 1, I'm having a hard time understanding why feasible-path uRPF
fails for case (2).  Or is the intent of the caption and terminology
note from above only to say that it fails for at least one of the
enumerated cases?  (On the other hand, there's a decent chance that the
lack of comprehension is entirely on my end...)

Section 2.3

  can be described as follows.  In Scenario 2 (described above,
  illustrated in Figure 2), it is possible that the second transit
  provider (ISP-b or AS3) does not propagate the prepended route for
  prefix P1 to the first transit provider (ISP-a or AS2).  This is
  because AS3's decision policy permits giving priority to a shorter
  route to prefix P1 via a lateral peer (AS2) over a longer route
  learned directly from the customer (AS1).  In such a scenario, AS3
  would not send any route announcement for prefix P1 to AS2 (over the

I expect this is just my lack of familiarity here, but does the decision
policy "giving priority" to shorter routes vs customer routes mean that
it won't propagate the customer advertisement at all or just that it
won't route traffic that way?

Section 3.2

  o  Additionally, from the routes it has learned from customers, a
      non-stub AS SHOULD announce at least one route per origin AS to
      each of its transit provider ASes.

What are the security consequences of this?  If, say, an AS only get
very specific prefixes with very short paths from a customer and is now
"forced" to advertise at least one of them by these practices, can that
have a negative impact on routing?  Would prepending itself in the path
be a usable mitigation?

Section 3.4

nit: there's perhaps room for harmonization of language between step (3)
here and step (1) of Algorithm A.

  4.  Create the set of all unique prefixes for which routes exist in
      Adj-RIB-Ins of all lateral peer and transit provider interfaces

Is the intention that "lateral peer and transiti provider interfaces" is
equivalent to "all interfaces that are not directly-connected customer
interfaces"?

Section 3.6.1

  The techniques described in this document require that there should
  be additional memory (i.e., TCAM) available to store the RPF lists in

nit: TCAM isn't listed as "well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt , so we
probably have to expand it.

  The following table shows the measured customer cone sizes for
  various types of ISPs [sriram-ripe63]:

The table contents make it seem like these are not "per-type" data, but
rather specific data from hopefully representative samples.  In
particular...

  +---------------------------------+---------------------------------+
  | Type of ISP                    | Measured Customer Cone Size in  |
  |                                | # Prefixes (in turn this is an  |
  |                                | estimate for RPF list size on  |
  |                                | line card)                      |
  +---------------------------------+---------------------------------+
  | Very Large Global ISP          | 32392                          |
  | ------------------------------- | ------------------------------- |
  | Very Large Global ISP          | 29528                          |

... perhaps these should be #1 and #2 to disambiguate.

Section 3.7

      *  In general, loose uRPF method for SAV SHOULD be applied on
          lateral peer and transit provider interfaces.  However, for
          lateral peer interfaces, in some cases an operator MAY apply
          EFP-uRPF method with Algorithm A if they deem it suitable.

Since step (1) of Algorithm A explicitly says "of customer interfaces",
we probably need a little bit more text here to say what it means to use
Algorithm A for lateral peer and/or transit provider interfaces.  (Or,
perhaps, some reworking of the text describing Algorithm A, but that
seems like a more invasive change.

Section 4

This is rather related to Alvaro's Discuss, but how is an AS operator to
know what type of peer and the nature of customer cone scenario that
applies to a given case?

Also, is there a way to know what the probability of dropping legitimate
data packets is other than experimenting and waiting for customer
complaints?

(I guess it's probably okay, given the references, to not bother
explicitly saying "erroneously dropping legitimate packets is bad".)
2019-08-21
03 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2019-08-21
03 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2019-08-21
03 Éric Vyncke
[Ballot comment]
Thank you for the hard work put into this extensive document which is usually well-written and easy to understand.

Sriram, also please to …
[Ballot comment]
Thank you for the hard work put into this extensive document which is usually well-written and easy to understand.

Sriram, also please to see this document completing its path after starting in OPSEC years ago ;-)

Nevertheless, I have a couple of easy-to-fix COMMENTs and NITs.

Regards,

-éric

== COMMENTS ==

-- Abstract --
The abstract reads like 'promises' but not as a summary of the document. Is there any chance to add 2 lines summarizing the 'how' ?

-- Section 1.1 --
I am sure that by now you know that you have to use RFC 8174 boilerplate ;-)

-- Section 2.2 --
For completeness and symmetry with section 2.3, please explain which packets will be dropped.

-- Section 2.3 --
Suggestion: define "RPF list" before first use (even if mostly obvious).

Please define "lateral peer" and why it is different to any other "peer".

-- Section 3.1 --
Please define the "cone" used in this section. First time that I ever read this term and the RIPE paper does not explain it either (of course I am not a routing expert).

== NITS ==

-- Section 1 --
Beside the intro, this section also introduces some terminology wording. May I suggest to have a (sub)section about "terminology" ?

-- Section 2.1 --
CMTS was introduced as an acronym but not DSLAM.
2019-08-21
03 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2019-08-21
03 Martin Vigoureux
[Ballot comment]
  Ingress/egress Access Control Lists (ACLs) are maintained which list
  acceptable (or alternatively, unacceptable) prefixes for the source
  addresses in the …
[Ballot comment]
  Ingress/egress Access Control Lists (ACLs) are maintained which list
  acceptable (or alternatively, unacceptable) prefixes for the source
  addresses in the incoming/outgoing Internet Protocol (IP) packets.
the beginning of that sentence is a bit hard to parse, but maybe it's just for me.

  Any packet with a source address that does not match the filter is
  dropped.
well, that really depend on the match criteria. If the list is of unacceptable addresses and you don't match on these, then you should forward the packet.

  Adj-RIB-Ins
did you mean Adj-RIBs-In?

Figures 1 and 2 claim that EFP-uRPF works best but it has still not been described at that stage so it is a bit difficult to understand that claim.
2019-08-21
03 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2019-08-20
03 Adam Roach
[Ballot comment]
Thanks for a clearly written document. My understanding of routing is pretty
simplistic, and I still found the technique well-explained and easy to …
[Ballot comment]
Thanks for a clearly written document. My understanding of routing is pretty
simplistic, and I still found the technique well-explained and easy to follow.
This is no small feat. The one term I had to go searching for was "stub AS". If
this is a generally known term, that's fine -- but if not, it may warrant a
short definition or citation.

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

§1.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in RFC 2119 [RFC2119].

Please use the boilerplate from RFC 8174.

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

§3.3:

I believe I understand how the described Algorithm B, is applied by AS4, will
result in acceptance of AS1's packets from AS2. I'm a bit lost, however, about
the means by which AS2 will accept them such that they could be delivered to
AS4.  Is there an assumption that AS2 is employing an ACL-based approach? If
so, this should probably be stated explicitly. (This might be implied by text
elsewhere, in which case I apologize for my confusion; although it may still be
worth explicitly explaining.)

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

§3.5:

>  It is worth emphasizing that an indirect part of the proposal in the
>  draft is that RPF filters may be augmented from secondary sources.

Nit: "the draft" won't age gracefully. I suggest changing to "this document"
or somesuch.

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

§3.6.1:

>  +---------------------------------+---------------------------------+
>  | Very Large Global ISP          | 32392                          |
>  | ------------------------------- | ------------------------------- |
>  | Very Large Global ISP          | 29528                          |
>  | ------------------------------- | ------------------------------- |

I suspect there was a transcription error copying these lines from the source
material, as the appearance of two rows with identical labels seems unlikely
to be intended. I skimmed the cited source material to see if I could figure
out what happened here, but found neither of these numbers (nor any mention of
"Mid-size Global ISP"), so I'm afraid I can't make a concrete suggestion for a
fix. I did find that adding the numbers in the first column on slide 6
yielded 32393, which is tantalizingly close to the first number, but that
might just be a coincidence.
2019-08-20
03 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2019-08-20
03 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-08-20
03 Roman Danyliw
[Ballot comment]
(1) I support Alvaro Retana’s DISCUSS point about the needed clarity on algorithm selection (A vs. B) and the security assumptions being made …
[Ballot comment]
(1) I support Alvaro Retana’s DISCUSS point about the needed clarity on algorithm selection (A vs. B) and the security assumptions being made about Algorithm A.

(2) Editorial

-- Document header: s/Updates: RFC3704/Updates: 3704/

-- Section 2.1.  Editorial.  s/are maintained which list/are maintained to list/
2019-08-20
03 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2019-08-19
03 Warren Kumari Forgot to change state.
2019-08-19
03 Warren Kumari IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2019-08-16
03 Alvaro Retana
[Ballot discuss]
I have significant concerns about the recommendation (in §3.7) to use Algorithm A.  I think that the considerations to select an Algorithm are …
[Ballot discuss]
I have significant concerns about the recommendation (in §3.7) to use Algorithm A.  I think that the considerations to select an Algorithm are not clear and potentially impossible to verify.  Also, the selection of Algorithm A creates a vulnerability that could result in legitimate traffic dropped.

§3.7 (Summary of Recommendations) says that "if the scenario does not involve complexity...(see Section 3.3, Figure 4), then...Algorithm A...SHOULD be applied on customer interfaces." 

From Figure 4, how does the operator of ISP4 know that it is not in a "challenging scenario" (§3.3)?  How can ISP4 tell the difference between ISP2 not propagating routes vs it not even being connected to AS1?  By definition, each autonomous system can have its own set of policies, which may not be known by any of their upstreams.  In short, I find the guidance provided in the document to select an algorithm not clear enough to really be actionable -- specially in a document tagged to be a BCP.

Still looking at Figure 4, if the operator of ISP4 uses Algorithm A (because he/she thinks they may not be in a "challenging scenario"), then it opens the door to ISP2 changing its policy so that the uRPF check in ISP4 fails, as shown in Figure 4.  IOW, an attacker in ISP2 could stop advertising reachability to some prefixes and cause ISP4 to fail the uRPF check and drop the traffic.  The victim in this case could be AS1, whose traffic (through ISP2 to ISP4) was flowing fine and then it stopped.

I am balloting DISCUSS because the guidance provided for the selection of an Algorithm is not clear enough to be certain that the selection is the correct one; and the election of Algorithm A creates a vulnerability (as explained in the text) that is not mentioned.
2019-08-16
03 Alvaro Retana
[Ballot comment]
(1) The implementation of the EFP-uRPF method is expected at a transit AS.  However, that AS has no control over what the origin …
[Ballot comment]
(1) The implementation of the EFP-uRPF method is expected at a transit AS.  However, that AS has no control over what the origin AS and others announce.  I find the use of rfc2119 keywords in §3.2 inappropriate because none of the actions are under the control of the AS implementing uRPF and can't be Normatively enforced.

(2) §3.5: "Prefixes from registered ROAs and IRR route objects that include ASes in an ISP's customer cone SHOULD be used to augment the appropriate RPF lists."  How?  Note that the Introduction already sets the stage by saying that "the routes under consideration are assumed to have been vetted based on prefix filtering [RFC7454] and possibly (in the future) origin validation [RFC6811]."  If ROAs SHOULD be used (§3.5), why is origin validation only "possibly (in the future)" considered (§1)?  Maybe a better statement would be that "routes SHOULD be validated using prefix filtering, origin validation and IRR route objects".

(3) How does EFP-uRPF work when multiple border routers are present in the AS, some customer facing and some not (which I assume to be the normal case)?  I'm asking because §3.1 describes the method when "prefixes with the same origin AS were received on different interfaces (at border routers)", and the example talks about the Local Adj-RIB-Ins.  I think there's a missing explanation of how the routers with the customer-facing interfaces learn about *all* the received routes if the local policy might select a single BGP best route.  OTOH, maybe I'm missing something.

(4) The document assumes familiarity with terminology such as "customer cone" or "lateral peer", that is not explained anywhere.  The average operator will most likely know what those terms mean and how they apply to their network. However, those operators are not the only people reviewing this document.  A short explanation or reference would be nice.

(5) Please use the rfc8174 template.

(6) [For the AD/Shepherd.] I'm assuming that the intent is for this document to be part of BCP 84, is that correct?  I'm not sure how to let the RFC Editor know that is the intent, but it should be made clear somewhere.
2019-08-16
03 Alvaro Retana [Ballot Position Update] New position, Discuss, has been recorded for Alvaro Retana
2019-08-15
03 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-08-15
03 Warren Kumari Ballot has been issued
2019-08-15
03 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2019-08-13
03 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Martínez
2019-08-13
03 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Martínez
2019-08-12
03 Min Ye Request for Telechat review by RTGDIR is assigned to Matthew Bocci
2019-08-12
03 Min Ye Request for Telechat review by RTGDIR is assigned to Matthew Bocci
2019-08-12
03 Alvaro Retana Requested Telechat review by RTGDIR
2019-08-08
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Derek Atkins
2019-08-08
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Derek Atkins
2019-08-08
03 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2019-08-08
03 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-opsec-urpf-improvements-03, which is currently in Last Call, and has the following comments:

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

The IANA Functions Operator has reviewed draft-ietf-opsec-urpf-improvements-03, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-08-05
03 Wesley Eddy Request for Last Call review by TSVART is assigned to Brian Trammell
2019-08-05
03 Wesley Eddy Request for Last Call review by TSVART is assigned to Brian Trammell
2019-08-01
03 Jean Mahoney Request for Last Call review by GENART is assigned to Pete Resnick
2019-08-01
03 Jean Mahoney Request for Last Call review by GENART is assigned to Pete Resnick
2019-08-01
03 Cindy Morgan Placed on agenda for telechat - 2019-08-22
2019-08-01
03 Cindy Morgan IANA Review state changed to IANA - Review Needed
2019-08-01
03 Cindy Morgan
The following Last Call announcement was sent out (ends 2019-08-15):

From: The IESG
To: IETF-Announce
CC: draft-ietf-opsec-urpf-improvements@ietf.org, opsec-chairs@ietf.org, Sandra Murphy , opsec@ietf.org, …
The following Last Call announcement was sent out (ends 2019-08-15):

From: The IESG
To: IETF-Announce
CC: draft-ietf-opsec-urpf-improvements@ietf.org, opsec-chairs@ietf.org, Sandra Murphy , opsec@ietf.org, sandy@tislabs.com, warren@kumari.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Enhanced Feasible-Path Unicast Reverse Path Filtering) to Best Current Practice


The IESG has received a request from the Operational Security Capabilities
for IP Network Infrastructure WG (opsec) to consider the following document:
- 'Enhanced Feasible-Path Unicast Reverse Path Filtering'
  as Best Current Practice

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 2019-08-15. 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


  This document identifies a need for improvement of the unicast
  Reverse Path Filtering techniques (uRPF) (see BCP 84) for detection
  and mitigation of source address spoofing (see BCP 38).  The strict
  uRPF is inflexible about directionality, the loose uRPF is oblivious
  to directionality, and the current feasible-path uRPF attempts to
  strike a balance between the two (see BCP 84).  However, as shown in
  this draft, the existing feasible-path uRPF still has shortcomings.
  This document describes an enhanced feasible-path uRPF technique,
  which aims to be more flexible (in a meaningful way) about
  directionality than the feasible-path uRPF.  It can potentially
  alleviate ISPs' concerns about the possibility of disrupting service
  for their customers, and encourage greater deployment of uRPF
  techniques.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsec-urpf-improvements/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-opsec-urpf-improvements/ballot/


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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc4271: A Border Gateway Protocol 4 (BGP-4) (Draft Standard - IETF stream)



2019-08-01
03 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2019-08-01
03 Cindy Morgan Last call was requested
2019-08-01
03 Cindy Morgan IESG state changed to Last Call Requested from Publication Requested
2019-08-01
03 Cindy Morgan Last call announcement was generated
2019-08-01
03 Cindy Morgan Removed from agenda for telechat
2019-08-01
03 Cindy Morgan Placed on agenda for telechat - 2019-08-08
2019-08-01
03 Warren Kumari Ballot has been issued
2019-08-01
03 Warren Kumari Ballot approval text was generated
2019-08-01
03 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2019-08-01
03 Warren Kumari Created "Approve" ballot
2019-08-01
03 Warren Kumari Ballot writeup was changed
2019-07-15
03 Ron Bonica
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

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

The document requests publication as Best Current Practice. This is indicated in the header.

BCP is appropriate. The document compares the effectiveness of various current techniques of reverse path filtering and presents an additional, enhanced technique.  The current techniques are expressed in RFC2827 and RFC3704, both themselves BCP.  The presented technique is an enhancement of a technique specified in RFC3704.  The document updates RFC3704.

(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 identifies a need for improvement of the unicast
  Reverse Path Filtering techniques (uRPF) (see BCP 84) for detection
  and mitigation of source address spoofing (see BCP 38). The strict
  uRPF technique is inflexible about directionality, the loose uRPF
  technique is oblivious to directionality, and the current
  feasible-path uRPF technique attempts to strike a balance between the
  two (see BCP 84). However, as shown in this draft, the existing
  feasible-path uRPF technique still has shortcomings. This document
  describes an enhanced feasible-path uRPF technique, which aims to be
  more flexible (in a meaningful way) about directionality than the
  feasible-path uRPF technique. It can potentially alleviate ISPs'
  concerns about the possibility of disrupting service for their
  customers, and encourage greater deployment of uRPF techniques..

Working Group Summary

  The document was discussed in grow and in opsec, and adopted by opsec.  Discussions
  in both working groups were incorporated into the document.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The shepherd sees no wg mail indicating that there are are current software implementations.  However, the draft containS a section “Implementation Considerations” that points to the similarity to current uRPF techniques that query a VRF table, so existing implementation methods could be leveraged for this new technique.  One wg comment explicitly said that the document was clear enough to “assist the operators to better implement the recommendations”. 

No MIB Doctor, Media Type, or other expert review was required.

Personnel

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

Document Shepherd: Sandra Murphy

Responsible Area Director: Warren Kumari


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

The document shepherd has reviewed the document, references, and
the wg discussions and presentations.  The draft was presented and
discussed in the grow wg, and those interactions were also reviewed. 
The authors have incorporated shepherd comments into the latest version.

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

No, there are no document portions that need additional review.

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

The shepherd has no concerns or issues with the current version of the
draft.

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

Yes.  All authors of this document have confirmed on the wg list that they know of 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.

The shepherd sees no IPR disclosure notice on the wg email list.

(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 wg adoption discussion was energetic.  That discussion appeared to have resolved most issues; the subsequent conversation was not as energetic.  The document as an individual contribution was first discussed in the grow wg.

This draft was presented as an individual submission at grow at IETF97, presented at opsec IETF 99, IETF100, IETF101, and as an opsec draft at IETF104

In total, there were 15 different individuals between the two groups, which is adequately broad support for these groups.

(10) 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 publicly available.)

The shepherd sees no threats of appeal in the wg discussions and no indications on the wg list of a discontented wg member.

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

The nits tool reports:
    Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--).

One warning concerns the format of the Updates line in the document header.  The other warnings are about strings in the text that the nits tool thinks are citations, but it appears the tool is just picking up on the use of “[“ in a notation.

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

None required.  There are no features of the draft that require formal review.

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

Yes.  All references are divided into normative and informative sections.


(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.  All IETF documents in the references are RFCs.

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

The document header notes that the document will update RFC3704.

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

None required.  There are no protocol extensions, no reference to IANA registries, no creation of new IANA registries in this document.

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

None required.  There are no new IANA registries created by this document.

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

None required.  There are no sections of the document that are XML code, BNF rules, MIM definitions, or any other formal language.
2019-07-15
03 Ron Bonica Responsible AD changed to Warren Kumari
2019-07-15
03 Ron Bonica IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2019-07-15
03 Ron Bonica IESG state changed to Publication Requested from I-D Exists
2019-07-15
03 Ron Bonica IESG process started in state Publication Requested
2019-07-11
03 Sandra Murphy
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

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

The document requests publication as Best Current Practice. This is indicated in the header.

BCP is appropriate. The document compares the effectiveness of various current techniques of reverse path filtering and presents an additional, enhanced technique.  The current techniques are expressed in RFC2827 and RFC3704, both themselves BCP.  The presented technique is an enhancement of a technique specified in RFC3704.  The document updates RFC3704.

(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 identifies a need for improvement of the unicast
  Reverse Path Filtering techniques (uRPF) (see BCP 84) for detection
  and mitigation of source address spoofing (see BCP 38). The strict
  uRPF technique is inflexible about directionality, the loose uRPF
  technique is oblivious to directionality, and the current
  feasible-path uRPF technique attempts to strike a balance between the
  two (see BCP 84). However, as shown in this draft, the existing
  feasible-path uRPF technique still has shortcomings. This document
  describes an enhanced feasible-path uRPF technique, which aims to be
  more flexible (in a meaningful way) about directionality than the
  feasible-path uRPF technique. It can potentially alleviate ISPs'
  concerns about the possibility of disrupting service for their
  customers, and encourage greater deployment of uRPF techniques..

Working Group Summary

  The document was discussed in grow and in opsec, and adopted by opsec.  Discussions
  in both working groups were incorporated into the document.

Document Quality

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The shepherd sees no wg mail indicating that there are are current software implementations.  However, the draft containS a section “Implementation Considerations” that points to the similarity to current uRPF techniques that query a VRF table, so existing implementation methods could be leveraged for this new technique.  One wg comment explicitly said that the document was clear enough to “assist the operators to better implement the recommendations”. 

No MIB Doctor, Media Type, or other expert review was required.

Personnel

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

Document Shepherd: Sandra Murphy

Responsible Area Director: Warren Kumari


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

The document shepherd has reviewed the document, references, and
the wg discussions and presentations.  The draft was presented and
discussed in the grow wg, and those interactions were also reviewed. 
The authors have incorporated shepherd comments into the latest version.

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

No, there are no document portions that need additional review.

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

The shepherd has no concerns or issues with the current version of the
draft.

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

Yes.  All authors of this document have confirmed on the wg list that they know of 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.

The shepherd sees no IPR disclosure notice on the wg email list.

(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 wg adoption discussion was energetic.  That discussion appeared to have resolved most issues; the subsequent conversation was not as energetic.  The document as an individual contribution was first discussed in the grow wg.

This draft was presented as an individual submission at grow at IETF97, presented at opsec IETF 99, IETF100, IETF101, and as an opsec draft at IETF104

In total, there were 15 different individuals between the two groups, which is adequately broad support for these groups.

(10) 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 publicly available.)

The shepherd sees no threats of appeal in the wg discussions and no indications on the wg list of a discontented wg member.

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

The nits tool reports:
    Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--).

One warning concerns the format of the Updates line in the document header.  The other warnings are about strings in the text that the nits tool thinks are citations, but it appears the tool is just picking up on the use of “[“ in a notation.

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

None required.  There are no features of the draft that require formal review.

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

Yes.  All references are divided into normative and informative sections.


(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.  All IETF documents in the references are RFCs.

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

The document header notes that the document will update RFC3704.

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

None required.  There are no protocol extensions, no reference to IANA registries, no creation of new IANA registries in this document.

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

None required.  There are no new IANA registries created by this document.

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

None required.  There are no sections of the document that are XML code, BNF rules, MIM definitions, or any other formal language.
2019-07-11
03 Sandra Murphy
{\rtf1\ansi\ansicpg1252\cocoartf1561\cocoasubrtf600
{\fonttbl\f0\fswiss\fcharset0 Helvetica;\f1\fnil\fcharset204 PTSerif-Regular;\f2\fmodern\fcharset0 Courier;
}
{\colortbl;\red255\green255\blue255;\red255\green0\blue0;\red251\green2\blue7;\red0\green0\blue0;
\red26\green26\blue26;\red0\green0\blue0;}
{\*\expandedcolortbl;;\csgenericrgb\c100000\c0\c0;\cssrgb\c100000\c14913\c0;\csgenericrgb\c0\c0\c0;
\cssrgb\c13333\c13333\c13333;\cssrgb\c0\c0\c0;}
\margl1440\margr1440\vieww10800\viewh8400\viewkind0
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0

\f0\fs24 \cf0 As required by RFC 4858, this is the current template …
{\rtf1\ansi\ansicpg1252\cocoartf1561\cocoasubrtf600
{\fonttbl\f0\fswiss\fcharset0 Helvetica;\f1\fnil\fcharset204 PTSerif-Regular;\f2\fmodern\fcharset0 Courier;
}
{\colortbl;\red255\green255\blue255;\red255\green0\blue0;\red251\green2\blue7;\red0\green0\blue0;
\red26\green26\blue26;\red0\green0\blue0;}
{\*\expandedcolortbl;;\csgenericrgb\c100000\c0\c0;\cssrgb\c100000\c14913\c0;\csgenericrgb\c0\c0\c0;
\cssrgb\c13333\c13333\c13333;\cssrgb\c0\c0\c0;}
\margl1440\margr1440\vieww10800\viewh8400\viewkind0
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0

\f0\fs24 \cf0 As required by RFC 4858, this is the current template for the Document \
Shepherd Write-Up.\
\
Changes are expected over time. This version is dated 24 February 2012.\
\
(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?\
\
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0
\cf2 The document requests publication as Best Current Practice. This is indicated in the header.\
\
BCP is appropriate. The document compares the effectiveness of various current techniques of reverse path filtering and presents an additional, enhanced technique.  The current techniques are expressed in RFC2827 and RFC3704, both themselves BCP.  The presented technique is an enhancement of a technique specified in RFC3704.  The document updates RFC3704.\cf0 \
\
(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\
\
\pard\pardeftab720\partightenfactor0
\cf2 \expnd0\expndtw0\kerning0
  This document identifies a need for improvement of the unicast\
  Reverse Path Filtering techniques (uRPF) (see BCP 84) for detection\
  and mitigation of source address spoofing (see BCP 38). The strict\
  uRPF technique is inflexible about directionality, the loose uRPF\
  technique is oblivious to directionality, and the current\
  feasible-path uRPF technique attempts to strike a balance between the\
  two (see BCP 84). However, as shown in this draft, the existing\
  feasible-path uRPF technique still has shortcomings. This document\
  describes an enhanced feasible-path uRPF technique, which aims to be\
  more flexible (in a meaningful way) about directionality than the\
  feasible-path uRPF technique. It can potentially alleviate ISPs'\
  concerns about the possibility of disrupting service for their\
  customers, and encourage greater deployment of uRPF techniques..\cf0 \
\kerning1\expnd0\expndtw0 \
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0
\cf0 Working Group Summary\
\
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0
\cf2  The document was discussed in grow and in opsec, and adopted by opsec.  Discussions\
  in both working groups were incorporated into the document.\cf0 \
\
Document Quality\
\
\pard\pardeftab720\partightenfactor0
\cf0 Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? \
\
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0
\cf2 The shepherd sees no wg mail indicating that there are are current software implementations.  However, the draft containS a section \'93Implementation Considerations\'94 that points to the similarity to current uRPF techniques that query a VRF table, so existing implementation methods could be leveraged for this new technique.  One wg comment explicitly said that the document was clear enough to \'93\expnd0\expndtw0\kerning0
assist the operators to better implement the recommendations\'94.  \cf3 \
\pard\pardeftab720\partightenfactor0
\cf2 \
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0
\cf2 \kerning1\expnd0\expndtw0 No MIB Doctor, Media Type, or other expert review was required.\
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0
\cf0 \
Personnel\
\
  Who is the Document Shepherd? Who is the Responsible Area\
  Director?\
\
\cf3 Document Shepherd: Sandra Murphy\cf0 \
\
Responsible Area Director: {\field{\*\fldinst{HYPERLINK "mailto:warren@kumari.net"}}{\fldrslt \cf4 \expnd0\expndtw0\kerning0
Warren Kumari}}\cf4 \expnd0\expndtw0\kerning0

\f1\fs30 \cf5 \

\f0\fs24 \cf0 \kerning1\expnd0\expndtw0 \
\
(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.\
\
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0
\cf2 The document shepherd has reviewed the document, references, and \
the wg discussions and presentations.  The draft was presented and \
discussed in the grow wg, and those interactions were also reviewed.  \
The authors have incorporated shepherd comments into the latest version.\cf0 \
\
(4) Does the document Shepherd have any concerns about the depth or\
breadth of the reviews that have been performed?\
\
\cf2 No.\cf0 \
\
\
(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.\
\
\cf2 No, there are no document portions that need additional review.\cf0 \
\
(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.\
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0
\cf3 \
The shepherd has no concerns or issues with the current version of the\
draft.\
\cf0 \
(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.\
\
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0
\cf2 Yes.  All authors of this document have confirmed on the wg list that they know of no IPR.\cf0 \
\
(8) Has an IPR disclosure been filed that references this document?\
If so, summarize any WG discussion and conclusion regarding the IPR\
disclosures.\
\
\cf2 The shepherd sees no IPR disclosure notice on the wg email list.\cf0 \
\
(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?  \
\
\cf2 The wg adoption discussion was energetic.  That discussion appeared to have resolved most issues; the subsequent conversation was not as energetic.  The document as an individual contribution was first discussed in the grow wg.\cf0 \
\cf2 \
This draft was presented as an individual submission at grow at IETF97, presented at opsec IETF 99, IETF100, IETF101, and as an opsec draft at IETF104\
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0
\cf0 \
\cf3 In total, there were 15 different individuals between the two groups, which is adequately broad support for these groups.\
\cf0 \
(10) 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 publicly available.) \
\
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0
\cf2 The shepherd sees no threats of appeal in the wg discussions and no indications on the wg list of a discontented wg member.\cf0 \
\
(11) Identify any ID nits the Document Shepherd has found in this\
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts\
Checklist). Boilerplate checks are not enough; this check needs to be\
thorough.\
\
\cf2 The nits tool reports:\
\pard\pardeftab720\partightenfactor0
\cf3 \expnd0\expndtw0\kerning0
    Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--).
\f2\fs26 \
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0

\f0\fs24 \cf2 \kerning1\expnd0\expndtw0 \
One warning concerns the format of the Updates line in the document header.  The other warnings are about strings in the text that the nits tool thinks are citations, but it appears the tool is just picking up on the use of \'93[\'93 in a notation.\cf0 \
\
(12) Describe how the document meets any required formal review\
criteria, such as the MIB Doctor, media type, and URI type reviews.\
\
\cf2 None required.  There are no features of the draft that require formal review.\
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0
\cf0 \
(13) Have all references within this document been identified as\
either normative or informative?\
\
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0
\cf2 Yes.  All references are divided into normative and informative sections.\
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0
\cf0 \
\
(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?\
\
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0
\cf2 No.  All IETF documents in the references are RFCs.\cf0 \
\
(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. \
\
\cf2 No.\cf0 \
\
(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.\
\
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0
\cf3 The document header notes that the document will update RFC3704.\cf0 \
\
(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).\
\
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0
\cf2 None required.  There are no protocol extensions, no reference to IANA registries, no creation of new IANA registries in this document.\cf0 \
\
(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.\
\
\cf2 None required.  There are no new IANA registries created by this document.\cf0 \
\
(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.\
\
\cf2 None required.  There are no sections of the document that are XML code, BNF rules, MIM definitions, or any other formal language.\cf0 \
}
2019-07-08
03 Kotikalapudi Sriram New version available: draft-ietf-opsec-urpf-improvements-03.txt
2019-07-08
03 (System) New version approved
2019-07-08
03 (System) Request for posting confirmation emailed to previous authors: Kotikalapudi Sriram , Doug Montgomery , Jeffrey Haas
2019-07-08
03 Kotikalapudi Sriram Uploaded new revision
2019-04-23
02 Ron Bonica IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2019-04-08
02 Ron Bonica Notification list changed to Sandra Murphy <sandy@tislabs.com>
2019-04-08
02 Ron Bonica Document shepherd changed to Sandra L. Murphy
2019-04-08
02 Ron Bonica IETF WG state changed to In WG Last Call from WG Document
2019-04-08
02 Ron Bonica Changed consensus to Yes from Unknown
2019-04-08
02 Ron Bonica Intended Status changed to Best Current Practice from None
2019-04-04
02 Kotikalapudi Sriram New version available: draft-ietf-opsec-urpf-improvements-02.txt
2019-04-04
02 (System) New version approved
2019-04-04
02 (System) Request for posting confirmation emailed to previous authors: Kotikalapudi Sriram , Doug Montgomery , Jeffrey Haas
2019-04-04
02 Kotikalapudi Sriram Uploaded new revision
2018-10-21
01 Kotikalapudi Sriram New version available: draft-ietf-opsec-urpf-improvements-01.txt
2018-10-21
01 (System) New version approved
2018-10-21
01 (System) Request for posting confirmation emailed to previous authors: Kotikalapudi Sriram , Doug Montgomery , Jeffrey Haas
2018-10-21
01 Kotikalapudi Sriram Uploaded new revision
2018-04-20
00 Ron Bonica This document now replaces draft-sriram-opsec-urpf-improvements instead of None
2018-04-20
00 Kotikalapudi Sriram New version available: draft-ietf-opsec-urpf-improvements-00.txt
2018-04-20
00 (System) WG -00 approved
2018-04-20
00 Kotikalapudi Sriram Set submitter to "Kotikalapudi Sriram ", replaces to (none) and sent approval email to group chairs: opsec-chairs@ietf.org
2018-04-20
00 Kotikalapudi Sriram Uploaded new revision