Problem Statement, Gap Analysis, and Requirements for Intra-domain Source Address Validation
draft-ietf-savnet-intra-domain-problem-statement-25

[Ballot comment]
Thanks for addressing (partly) my DISCUSS points (see https://mailarchive.ietf.org/arch/msg/savnet/lXvPRzPjJ0V0r97rKHToQx1Zyds/ for archive).

By "partly addressing my DISCUSS point", I mean that, while the clarity is vastly better, I had to read 3 times the section 1 to eventually understand it. The term "intra-domain SAV" is still heavily misleading.

The authors have selected to address my non-blocking COMMENTs, while this is disapointing, it is not blocking.

Finally, I still support Roman Danyliw's DISCUSS related to the vague use of "fewer" in section 5.1

[Ballot comment]
Hi Dan, Jianping, Lancheng, Mingqing, and Nan,

Thank you for the discussion and for taking care of the comments.

The changes [1] made since my first ballot [2] are really great.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-savnet-intra-domain-problem-statement-22&url2=draft-ietf-savnet-intra-domain-problem-statement-24&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/savnet/s0128azyYuCAVcU-1wgR9BZrkNk/

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

Also thanks for the productive discussions and the updates to address the discussion points and comments in my original ballot.

[Ballot comment]
Hi Dan, Jianping, Lancheng, Mingqing, and Nan,

Thank you for the effort put into this document. The changes made in -23 are good one. There are some follow-up questions that I trust the authors will take care of.

Thanks to Chongfeng Xie for the OPSDIR review and the authors for engaging.

To complete this ballot, I also read draft-ietf-savnet-inter-domain-problem-statement, draft-ietf-savnet-intra-domain-architecture, and draft-ietf-savnet-inter-domain-architecture.

With all due respect to the WG participants and authors, I don’t think this document has enough technical contributions that would justify to be published as a standalone RFC. I still think that the digest be merged as a section of draft-ietf-savnet-intra-domain-architecture. I won't reiterate my points about ACL and "automation by design.

I'm changing my position to ABSTAIN for reasons explained in https://mailarchive.ietf.org/arch/msg/savnet/s0128azyYuCAVcU-1wgR9BZrkNk/.

Cheers,
Med

[Ballot discuss]

# Éric Vyncke INT AD comments for draft-ietf-savnet-intra-domain-problem-statement-23
CC @evyncke

Thank you for the work put into this document. As you will read below, it needs some work, but I do not mind its publication as an informational RFC.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Xueyan Song for the shepherd's write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Intra or inter domain ?

I find the title and some of the text confusing about intra-domain and inter-domain. My assumption when reading 'intra-domain' would have been to enforce SAV
*inside* a domain and not at the *perimeter* of a domain. The introduction does not really help the reader to understand the problem scope.

### Section 1

`The goal of intra-domain SAV at such interfaces is to prevent traffic using unauthorized source addresses from entering the domain` is too vague. By whom is it unauthorized ? I.e., allocated to an intra host or ?

### Section 3.2

An informative reference for `This can occur in deployments such as Direct Server Return (DSR)` will be useful. Honestly, I have no clue what it is about.

`Existing uRPF-based mechanisms (strict uRPF or loose uRPF)` but what about feasible path uRPF ?

[Ballot comment]

## COMMENTS (non-blocking)

### Whether to publish it as RFC

I do not mind publishing this I-D as a RFC, it could be useful.

### Title

Let's be logical and s/Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement, and Requirements/Source Address Validation in Intra-domain Networks *Problem Statement, Gap Analysis,* and Requirements/

### Abstract

Please make the abstract understandable by not-SAVI (punt intended) readers. At the bare minimum expand SAV and be clear about the layer of the address (i.e., MAC, IP, ...).

### Section 1

`These mechanisms typically are deployed on *switches* in the access network and prevent hosts from using the source address of another host on the *Internet* [RFC5210].`  I wonder whether a layer-2 local switch can actually prevent address spoofing on the Internet. Please rephrase.

`This document provides a gap analysis of the current operational intra-domain SAV mechanisms` I would expect that a gap analysis is between two states, i.e., the sentence would benefit from adding "with respect to ...".

### Section 1.1

Rather than using `proper` and `improper`, should the document use 'false positive', 'false negative', ... ?

### Section 2

The titla is misleading, let's rather s/Problem Statement of Current Operational Intra-domain SAV Mechanisms/*Issues with the* Current Operational Intra-domain SAV Mechanisms/

### Section 3

Based on `The following subsections describe two specific gap scenarios that arise when using strict uRPF for intra-domain SAV.` it seems that the whole section 3 is about strict uRPF. This should be clear in the title section, and then what about loose mode uRPF ?

### Section 3.1

Reference to RFC 6890 is useless, i.e., no need to add an informative reference when using example/documentation code points/addresses.

### Section 4.1

Like Roman, I find `result in fewer improper blocks` too vague to be a requirement, i.e., how many is "fewer" ?

### Section 4.4

`such mechanism MUST NOT transmit excessive SAV-specific` is more about scalability rather than `fast convergence`. This part probably needs its own sub-section.

## NITS (non-blocking / cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

[Ballot discuss]
One sentence summary: I would like to discuss why the authors and WG believe this needs to be published as an RFC, and if that results in a good reason to do so, how the current hand waving of security requirements can be improved.

I echo what other ADs are raising. In my experience, WGs do well with having their own requirements document with WG consensus but not publishing as an RFC. For example, add and deleg both took this approach. It would save going through the much more stringent bar of IESG review over what the WG knows they need to define success amongst themselves for future documents.

However, I am reviewing as if there are good reasons to publish as an RFC that I'm not aware of. As such, I want to bring up the same bit Roman did, which jumped out at me:

>  Any new intra-domain SAV mechanism MUST NOT introduce additional
>  security vulnerabilities to existing intra-domain architectures or
>  protocols.

As a WG document, I would say this is underspecified but maybe the WG knows what they mean. As an RFC, I do not think this is appropriate at all. Combining this with the Security Considerations that says this introduces no new considerations and I do not think this document says much that is meaningful to people outside your very specific context. It's possible some of this may be obvious to your WG even if not written down because of context for terminology (i.e. "vulnerability" means something specific like "attack surface represented by the presence of a node" to say "MUST NOT introduce additional hops to existing..."). If so, that needs to be defined here, as it currently could be interpreted as "MUST NOT introduce the potential for CVEs" or a number of other things that are quite difficult to mandate normatively.

For an example of how security considerations can still apply to a requirements document, check out Section 4 of the add WG's requirements document (which is what their Security Considerations section links to): https://datatracker.ietf.org/doc/html/draft-ietf-add-requirements-00

All this becomes non-applicable if this is a document the WG writes for themselves, setting aside that then my review isn't needed anyway, because there's some wiggle room for WGs to "know what they meant" since the WG itself can shift its take on requirements as work on drafts meeting those requirements proceeds. This isn't a flexibility given once it is published as an RFC however.

[Ballot comment]
No additional commentary; I do not wish to waste the authors' time fine tuning the document since I think this document is probably reasonable as WG self-guidance for to measure how their drafts meet these requirements as it is. I highly encourage consideration of not publishing this as an RFC.

[Ballot comment]
Thank you to Robert Sparks and Ben Schwartz for the reviews.  They were very helpful.

I will echo the comment of both reviewers and other ADs - this document doesn't appear to need to be published.  It really seems most useful as a document guiding the design of any additional SAV mechanisms or enhancements.  That is material useful for inside the WG.

[Ballot comment]
Thanks to Ben Schwartz for their multiple secdir reviews.

It is unusual to have this many reviewers suggest that the draft should not be an RFC.  I count at least three (Art, Secdir, Opsdir) plus at least a couple of ADs.

I support the discuss positions of Roman, Med and Ketan.

[Ballot comment]
I want to thank Robert Sparks for his ARTART review, and echo his comment about the need for this to be published as an RFC (also mentioned by Charles and Med).
I have no objection to this document proceeding.

[Ballot comment]
I want to thank Robert Sparks for the ARTART review. I agree with his suggestion to consider using the document to refine the group's charter text rather than publishing it as an informational RFC. That said, I do not have any ART-related concerns, nor do I object to the publication of this document if there is working group consensus that it is helpful to do so.

The document provides a gap analysis and identifies requirements for new intra-domain SAV solutions; however, I find these requirements to be subjective and difficult to prove that a given solution or mechanism will necessarily address them. Roman has already provided more detailed feedback for this as part of his DISCUSS, which I support.

[Ballot discuss]
Thanks to the authors and the WG for their work on this document.

Since this document is driving the architecture and solution work for intra-domain SAV, there are some basic premises in this document that I would like to discuss. My intention is to arrive at very precise scope of intra-domain SAV and not to mix up inter-domain SAV that is using BGP and between ASes.

What exactly is a non-BGP ISP and a non-BGP Customer?

I am missing how this ties up with prefix advertisement/origination and routing. BGP has a very specific and important function for prefix advertisement and routing over the Internet. Can these functions be met by "non-BGP" routing? If, so, how are these prefixes getting advertised further to the Internet?

154   Non-BGP Customer Network: A stub network (i.e., a network that only
155   originates traffic) connected to its provider network for Internet
156   connectivity and does not participate in eBGP peering with its
157   provider network.

"originates traffic" is misleading as this network is connected to the
Internet, the application session maybe initiated from within or to this network.
Further, once the application session starts, traffic goes both ways. Is the
intention here to characterize a network that does not have its own public IP
prefixes and instead it uses IP from its provider's prefix pool? As such, the
prefixes for this network are announced by its ISP (or upstream provider).

159   Non-BGP Internet Service Provider (ISP) Network: A network that
160   forwards traffic from its customer network to the Internet and does
161   not participate in eBGP peering with its customer network.

Here as well, "forwards traffic" is misleading. Is this a network that
has its own IP Prefixes but is not using eBGP peering to announce it; its prefixes
are instead announced to the provider via other protocols? I am not sure about
this and whether such a practice is prevalent. How are its AS and ROAs done
without BGP?

The "a set of hosts" or more broadly segments of a network that have their own
IP subnets carved out from that network operators address space (all within an
AS) is something that I can understand. These are "leaf or stub" networks.
The other two, I am not able to follow.

What is a "timely manner"?
448 4.4.  Fast Convergence

450   If any new intra-domain SAV mechanism requires disseminating SAV-
451   specific information among intra-domain routers via a protocol, two
452   considerations are essential.  First, such mechanism MUST allow
453   routers to learn updated SAV-specific information in a timely manner.
454   Second, such mechanism MUST NOT transmit excessive SAV-specific
455   information via a protocol, as this could significantly increase the
456   burden on the routers’ control planes and potentially degrade the
457   performance of existing protocols.

Is this on the lines of normal IGP convergence which is generally order of a
few seconds? Or is it fast convergence in IGPs that is expected to be order
of sub-seconds? Or is it fast-reroute/LFA that is expected to order of
sub-50msec? These timings are dependent on implementation and also to an
extent the scale and other deployment aspects.

How about saying something on the lines that the SAV mechanisms MUST NOT
affect IGP convergence and the functioning of LFA/fast-reroute in the network?

What about the requirement that SAV solution MUST work when
LFA/fast-reroute is deployed and operational in a network and MUST coexist
with it. This probably makes the application of the SAV rules only on the
edges (non-IGP adjacencies) and not on internal IGP adjacencies?

[Ballot comment]
I also have one comment.

348 3.2.  Hidden Prefix Scenario

350   The intra-domain hidden prefix scenario refers to situations in which
351   a host or non-BGP customer legitimately originates traffic using
352   source addresses that are not visible to the intra-domain routing
353   protocol within the domain.

355   *  A host (for example, a cloud server instance operated by a tenant)
356       may originate traffic using a source address not allocated by the
357       AS operator.  This can occur in deployments such as Direct Server
358       Return (DSR), where return traffic is sent directly from the
359       server using a service IP address that is not part of the
360       operator’s internal routing view.

Please provide an informative reference for DSR. I would suggest
draft-ietf-sidrops-bar-sav even if it is describing this technique in the case
of inter-domain which AFAIK is the widely prevalent use. Is there any evidence
of DSR being used in non-BGP deployments?

[Ballot discuss]
** Section 5.1
  Any new intra-domain SAV mechanism MUST improve the accuracy of
  source address validation compared to existing uRPF-based mechanisms.
  In particular, it MUST reduce the occurrence of improper blocks
  (i.e., blocking legitimate traffic), improper permits (i.e., allowing
  spoofed traffic), or both.  Specifically, it MUST satisfy the
  following conditions:

  *  result in fewer improper blocks than strict uRPF, particularly in
      scenarios involving asymmetric routes or hidden prefixes;

  *  result in fewer improper permits than loose uRPF.

How would the measurement of this approach be computed?  Would the accuracy have to hold for any arbitrary configuration?  Would it be possible for some configuration to make strict+loose uPRF equivalent to this new mechanism?

** Section 5.2
  Any new intra-domain SAV mechanism MUST be capable of automatically
  generating and updating SAV rules on routers, rather than relying
  entirely on manual updates as in ACL-based SAV.  Automation helps
  reduce operational complexity and maintenance overhead, while
  allowing some initial configuration to improve SAV accuracy.  This
  ensures the mechanism is deployable in practical networks without
  introducing excessive management burden.

I think I understand the requirement in the sense that there is a desire to add automation to the process.  What I’m hoping the text could clarify is why automation can’t be added to ACL-based SAV, and why it is considered entirely manual.

** Section 5.4
  Second, such mechanism MUST NOT transmit excessive SAV-specific
  information via a protocol, as this could significantly increase the
  burden on the routers’ control planes and potentially degrade the
  performance of existing protocols.

How would one know that they aren’t transmitting “excessive” to meet this requirement?

[Ballot comment]
Thank you to Tim Evens for the GENART review.

** Section 5
  These informational
  requirements can not be used to initiate standards-track protocol
  changes.

The intent of this text is not clear.  Procedurally, when can any informational status document initiate changes in another document?

** Section 5.5
  Any new intra-domain SAV mechanism SHOULD verify the authenticity and
  trustworthiness of information before using it.

When would it be appropriate for this new intra-domain SAV mechanism NOT verify the information?

** Section 5.6
  Any new intra-domain SAV mechanism MUST NOT introduce additional
  security vulnerabilities to existing intra-domain architectures or
  protocols. 

How would one show that this condition was met?

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-savnet-intra-domain-problem-statement-22

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-savnet-intra-domain-problem-statement-22.txt

# Thank you for fixing all the comments and issues from the prior Telechat. This document has improved significantly, is easy to read and is well written.

# Detailed Review
# ===============

166   Improper Block: The validation results that the packets with
167   legitimate source addresses are blocked improperly due to inaccurate
168   SAV rules.
169
170   Improper Permit: The validation results that the packets with spoofed
171   source addresses are permitted improperly due to inaccurate SAV
172   rules.

GV> Maybe trivial and mostly editorial, is it possible to add a few words on "proper block (or simply 'block')" and "proper permit (or simply 'permit')". The above explains the improper beg=havior without specifying what is proper behavior.


177 1.2.  Requirements Language

179   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
180   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
181   "OPTIONAL" in this document are to be interpreted as described in
182   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
183   capitals, as shown here.

GV> This is an informational document and BCP14 keywords do not necessary apply.
Potentially you want to add the following paragraph for clarity:

"
  The requirements language is used in Section 5 and applies to
  implementations of SAV conformant to the listed requirements.
"

231   requires manual maintenance.  Operators must update them promptly to
232   reflect changes in prefixes or topology.  Failure to do so may result
233   in outdated ACLs that inadvertently block legitimate traffic.

GV> The larger security issue is not an improper block, but a improper permit. Could be worthwile to add to the paragraph.

Thanks for this write-up.

Gunter Van de Velde
RTG Area Director

[Ballot discuss]
Hi Dan, Jianping, Lancheng, Mingqing, and Nan,

Thank you for the effort put into this document.

Thanks to Chongfeng Xie for the OPSDIR review and the authors for engaging.

To complete this ballot, I also read draft-ietf-savnet-inter-domain-problem-statement, draft-ietf-savnet-intra-domain-architecture, and draft-ietf-savnet-inter-domain-architecture.

With all due respect to the WG participants and authors, I don’t think this document has enough technical contributions that would justify to be published as a standalone RFC. I would recommend that the digest be merged as a section of draft-ietf-savnet-intra-domain-architecture.

I will be changing my position to ABSTAIN.

Till then, please find below some points for DISCUSSion:

# What is the purpose of the requirements?

CURRENT:
  These informational
  requirements can not be used to initiate standards-track protocol
  changes.

I spent several cycles on this specific text.

Without diving into the requirements language itself, I really don’t know why are we doing this exercise, then. One way to fix this, is instead of saying why we don’t do this, say what we will be doing.

# Practice as a Gap

The document includes many statements about how ACL are enforced, see the example below:

CURRENT:
      not match the ACL entries are blocked.
      Since ACLs are configured and updated manually,

Or

  The main drawback of ACL-based SAV is that it
  requires manual maintenance. 

Or

      ACL-based SAV relies
      entirely on manual maintenance, resulting in high operational
      overhead in dynamic networks. 

Or

  generating and updating SAV rules on routers, rather than relying
  entirely on manual updates as in ACL-based SAV.

Automation is place in several operations I’m aware of for managing ACLs distributed over a network.

These above statements are misleading as this is not something that is inherent to the design.

This also question this requirement:

CURRENT:
  Any new intra-domain SAV mechanism MUST be capable of automatically
  generating and updating SAV rules on routers, rather than relying
  entirely on manual updates as in ACL-based SAV.

# Beyond the scope set for this doc: mixing architectural patterns and design recommendations

CURRENT:
  Consequently, addressing these gaps requires the introduction of SAV-
  specific, authoritative information and the design of automated
  mechanisms that can consume this information directly, rather than
  relying only on routing or forwarding state.

and

  However, if SAV relies on routing information or other contextual
  information, it is highly recommended that such information be
  validated before being used for SAV.

The problem statement part includes recommendations and architectural considerations that are not appropriate here given the scope set for this doc. Such discussions are not an issue if present in the same doc that sketches the new architecture.

# authenticity and trustworthiness is a MUST

CURRENT:
  Any new intra-domain SAV mechanism SHOULD verify the authenticity and
  trustworthiness of information before using it. 

Any reason why this is set to SHOULD?

# Understand all the following is needed to do the gap analysis. These should be normative:

  [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
              May 2000, .

  [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
              2004, .

  [RFC5210]  Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams,
              "A Source Address Validation Architecture (SAVA) Testbed
              and Deployment Experience", RFC 5210,
              DOI 10.17487/RFC5210, June 2008,
              .

  [RFC8704]  Sriram, K., Montgomery, D., and J. Haas, "Enhanced
              Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
              RFC 8704, DOI 10.17487/RFC8704, February 2020,
              .

  [RFC7513]  Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address
              Validation Improvement (SAVI) Solution for DHCP",
              RFC 7513, DOI 10.17487/RFC7513, May 2015,
              .

[Ballot comment]
# Taxonomy

CURRENT:
  Source Address Validation (SAV) defends against source address
  spoofing.  Network operators can enforce SAV at the following levels
  (see [RFC5210]):

  *  Within the access network

  *  Within the domain (i.e., the autonomous system)

  *  Between domains (i.e., autonomous systems)

## An “access network” is no more than a (administrative) domain. I quite don’t see the difference between the first and second bullet.

I guess you meant at “access nodes” at the first place. If so, then the taxonomy should be: access nodes, within a network, border nodes (e.g., ASBRs).

## Why are we implying that a domain is an autonomous system? A domain may be BGP-free. I would not use “i.e.”

# Universal Deployment

CURRENT:
  However, access-network SAV mechanisms are not universally deployed.

Maybe include a reference.

For example, is this statement aligned with https://spoofer.caida.org/summary.php?

# Scope

CURRENT:
  This document provides a gap analysis of the current operational
  intra-domain SAV mechanisms, identifies key problems to solve, and
  proposes basic requirements for any new intra-domain SAV solutions.

## The order is a bit broken as the gap analysis requires checking first the problem to be solved and an inventory of tools/capabilities out there.

## The text above says “inter-domain” is required, while the scope is limited to intra. Please explain the rationale? Can the overall problem be solved by looking separately on each segment? Which one is operationally viable?

## How to interpret “basic”?

## s/proposes/identifies

# Why focus on BGP?

CURRENT:
  In this document, intra-domain SAV refers to SAV at external
  interfaces that do not carry external BGP (eBGP) sessions (i.e.,
  external non-BGP interfaces). 

I don’t quite parse this.

Couldn’t this be simply about reasoning about customer-facing interface and the like?

# Within a domain

CURRENT:
  Within a domain, as
  illustrated in Figure 1, an external non-BGP interface may connect to
  a set of hosts, a non-BGP customer network, or a non-BGP Internet
  Service Provider (ISP) network.  The goal of intra-domain SAV at such
  interfaces is to prevent traffic using unauthorized source addresses
  from entering the domain.

But that all the routers in that figure is about  access routers to me.

Also, the limitation of such case are already documented, e.g., rfc5210 already says:

      When the edge router of an access network performs
      source address validation (e.g., using [RFC2827] and [RFC3704]),
      hosts are prevented from spoofing an arbitrary address, but
      unless access network SAV is employed, they may be able to spoof
      an address of a host in the same network segment. 

What is new here?

# what is “local domain” in the following?

CURRENT:
  Non-BGP Internet Service Provider (ISP) Network: A network that
  forwards traffic from the local domain to the Internet and does not
  participate in eBGP peering with the local domain.

# ACL Match

CURRENT:
      permitted or prohibited prefixes.  When applied on a router
      interface, packets that do not match the ACL entries are blocked.
      Since ACLs are configured and updated manually, timely updates are

An ACL entry may have an action of deny, accept, etc. The formulation in the except above assumes that the action is defined outside of the ACL/ACE iself, while that is part of the definition of the ACL itself.

The wording should be revisited for accuracy.

# Asymmetric routing is the rule

The discussion in Section 3.1 can be shortened as that is already discussed in other document, but more importantly that is well know patter.

For example, all this part can replaced by a pointer to rfc8704#figure-1.

CURRENT:
  For example, a non-BGP customer network connected to multiple routers
  of the AS may need to perform load balancing on incoming traffic,
  thereby resulting in asymmetric routing.  Figure 2 illustrates an
  example of asymmetric routing.  The non-BGP customer network owns
  prefix 2001:db8::/55 [RFC6890] and connects to two routers of the AS,
  Router 1 and Router 2.  Router 1, Router 2, and Router 3 exchange
  routing information via the intra-domain routing protocol.  To
  achieve load balancing for inbound traffic, the non-BGP customer
  network expects traffic destined for 2001:db8:0::/56 to enter through
  Router 1, and traffic destined for 2001:db8:0:100::/56 to enter
  through Router 2.  To this end, Router 1 advertises 2001:db8:0::/56
  and Router 2 advertises 2001:db8:0:100::/56 through the intra-domain
  routing protocol.  Figure 2 also shows the corresponding FIB entries
  of Router 1 and Router 2 for the two prefixes.

    +----------------------------------------------------------+
    |Domain                                                    |
    |                      +----------+                        |
    |                      | Router 3 |                        |
    |                      +----------+                        |
    |                      /      \                          |
    |                      /        \                        |
    |                    /          \                        |
    |            +----------+      +----------+              |
    |            | Router 1 |      | Router 2 |              |
    |            +-----*----+      +----------+              |
    |                  /\              /                      |
    |                  \              /                      |
    +--------------------\------------/------------------------+
    Traffic with        \          / Traffic with
    source IP addresses  \        /  destination IP addresses
    of 2001:db8:0:100::/56 \      \/  of 2001:db8:0:100::/56
                      +----------------+
                      |Non-BGP Customer|
                      |    Network    |
                      |(2001:db8::/55) |
                      +----------------+

    FIB of Router 1                FIB of Router 2
    Dest                Next_hop  Dest                Next_hop
    2001:db8:0::/56    Non-BGP    2001:db8:0:100::/56 Non-BGP
                        Customer                      Customer
                        Nestwork                      Network
    2001:db8:0:100::/56 Router 3  2001:db8:0::/56    Router 3

    The legitimate traffic originated from non-BGP customer network
    with source addresses in 2001:db8:0:100::/56 will be improperly
    blocked by strict uRPF on Router 1.

                Figure 2: An example of asymmetric routing

# Can we please elaborate these “valid operational reasons”?

CURRENT:
  *  A non-BGP customer network that originates traffic with a source
      address not advertised to the AS operator, also for valid
      operational reasons.

Cheers,
Med

The following Last Call announcement was sent out (ends 2026-03-09):

From: The IESG
To: IETF-Announce
CC: draft-ietf-savnet-intra-domain-problem-statement@ietf.org, james.n.guichard@futurewei.com, savnet-chairs@ietf.org, savnet@ietf.org, song.xueyan2@zte.com.cn
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement, and Requirements) to Informational RFC


The IESG has received a request from the Source Address Validation in
Intra-domain and Inter-domain Networks WG (savnet) to consider the following
document: - 'Source Address Validation in Intra-domain Networks Gap Analysis,
  Problem Statement, and Requirements'
  as Informational
  RFC

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
last-call@ietf.org mailing lists by 2026-03-09. 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 provides a gap analysis of existing intra-domain source
  address validation mechanisms, describes the fundamental problems,
  and defines the basic requirements for technical improvements.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-savnet-intra-domain-problem-statement/



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

# Document Shepherd Write-Up for Group Documents

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has received a broad and good support from the WG participants interested in this area concern.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Nothing notable.

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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document provides a gap analysis and problem statement of existing SAV mechanisms. It's not related to protocol design.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is mainly about problem statement for SAVNET in intra-domain networks, and its corresponding solutions may be related to IGP protocols. The co-authors have sent emails to collect comments and lauch discussions in LSR WG.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A. There are no features of the document that require formal review.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A. There are no sections of the document that contains a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A. There are no sections of the document that are written in a formal language.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

This problem draft is necessary. The working group has broad discussions on identifing problem scenarios and balancing between solutions and probem scenarios. Both problem and requirement sections have been revised to reflect the comments received after the first WGLC. I believe the current version is complete and ready to be handled to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

This document has been reviewed and assessed by multiple IETF Area Directorates, including OPS, SEC, GEN, RTG and ART during the first WGLC of this draft. The SEC and ART have confirmed that the draft is ready for publication, while responses from OPS, RTG and GEN point out that the document still has unresolved issues or is not yet ready. Additional reviews and assessments from these three areas are needed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document intended status is Informational. This is the appropriate status because its content is limted to problem statement and requirements.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. All authous has confirmed all appropriate IPR disclosure required.

Dan Li: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/jYaRYMF0hWgA2QPYVTmuuWJTziI/

Jianping Wu: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7ClxQL9j5j9vRmvrTNzgVKMy_2Y/

Mingqing Huang: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/gotYmKmNqczcAfq8BxeSj7HwI_4/

Lancheng Qing: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/cAFguG5coXyjLp3_wSoLdYvOQW0/

Nan Geng: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7DTSRqHL7OOwXrMuz9bHDKKHgQw/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There is no argument regarding the author, editor and contributor lists in the working group mailing list. The total number of authors on the front page is five, which satisfies the criteria.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Idnits finds section 3.1.1 using IPv4 example instead of IPv6 example. The current version has addressed it.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The Shepherd reviewed the reference part and suggested the authors move some normative references to informative references. The current version has addressed it.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA actions are required.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No IANA actions are required.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has received a broad and good support from the WG participants interested in this area concern.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Nothing notable.

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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document provides a gap analysis and problem statement of existing SAV mechanisms. It's not related to protocol design.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is mainly about problem statement for SAVNET in intra-domain networks, and its corresponding solutions may be related to IGP protocols. The co-authors have sent emails to collect comments and lauch discussions in LSR WG.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A. There are no features of the document that require formal review.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A. There are no sections of the document that contains a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A. There are no sections of the document that are written in a formal language.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

This problem draft is necessary. The working group has broad discussions on identifing problem scenarios and balancing between solutions and probem scenarios. Both problem and requirement sections have been revised to reflect the comments received after the first WGLC. I believe the current version is complete and ready to be handled to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

This document has been reviewed and assessed by multiple IETF Area Directorates, including OPS, SEC, GEN, RTG and ART during the first WGLC of this draft. The SEC and ART have confirmed that the draft is ready for publication, while responses from OPS, RTG and GEN point out that the document still has unresolved issues or is not yet ready. Additional reviews and assessments from these three areas are needed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document intended status is Informational. This is the appropriate status because its content is limted to problem statement and requirements.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. All authous has confirmed all appropriate IPR disclosure required.

Dan Li: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/jYaRYMF0hWgA2QPYVTmuuWJTziI/

Jianping Wu: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7ClxQL9j5j9vRmvrTNzgVKMy_2Y/

Mingqing Huang: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/gotYmKmNqczcAfq8BxeSj7HwI_4/

Lancheng Qing: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/cAFguG5coXyjLp3_wSoLdYvOQW0/

Nan Geng: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7DTSRqHL7OOwXrMuz9bHDKKHgQw/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There is no argument regarding the author, editor and contributor lists in the working group mailing list. The total number of authors on the front page is five, which satisfies the criteria.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Idnits finds section 3.1.1 using IPv4 example instead of IPv6 example. The current version has addressed it.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The Shepherd reviewed the reference part and suggested the authors move some normative references to informative references. The current version has addressed it.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA actions are required.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No IANA actions are required.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has received a broad and good support from the WG participants interested in this area concern.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Nothing notable.

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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document provides a gap analysis and problem statement of existing SAV mechanisms. It's not related to protocol design.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is mainly about problem statement for SAVNET in intra-domain networks, and its corresponding solutions may be related to IGP protocols. The co-authors have sent emails to collect comments and lauch discussions in LSR WG.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A. There are no features of the document that require formal review.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A. There are no sections of the document that contains a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A. There are no sections of the document that are written in a formal language.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

This problem draft is necessary. The working group has broad discussions on identifing problem scenarios and balancing between solutions and probem scenarios. Both problem statement section and requirements section are revised thoroughly after the first WGLC. I believe the current version is complete and ready to be handled to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

This document has been reviewed and assessed by multiple IETF Area Directorates, including OPS, SEC, GEN, RTG and ART duiring the first WGLC of this draft. The SEC and ART have confirmed that the draft is ready for publication, while responses from OPS, RTG and GEN point out that the document still has unresolved issues or is not yet ready. Additional reviews and assessments from these three areas are needed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document intended status is Informational. This is the appropriate status because its content is limted to problem statement and requirements.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. All authous has confirmed all appropriate IPR disclosure required.

Dan Li: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/jYaRYMF0hWgA2QPYVTmuuWJTziI/

Jianping Wu: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7ClxQL9j5j9vRmvrTNzgVKMy_2Y/

Mingqing Huang: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/gotYmKmNqczcAfq8BxeSj7HwI_4/

Lancheng Qing: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/cAFguG5coXyjLp3_wSoLdYvOQW0/

Nan Geng: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7DTSRqHL7OOwXrMuz9bHDKKHgQw/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There is no argument regarding the author, editor and contributor lists in the working group mailing list. The total number of authors on the front page is five, which satisfies the criteria.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Idnits finds section 3.1.1 using IPv4 example instead of IPv6 example. The current version has addressed it.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The Shepherd reviewed the reference part and suggested the authors move some normative references to informative references. The current version has addressed it.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA actions are required.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No IANA actions are required.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has received a broad and good support from the WG participants interested in this area concern.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Nothing notable.

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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document provides a gap analysis and problem statement of existing SAV mechanisms. It's not related to protocol design.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is mainly about problem statement for SAVNET in intra-domain networks, and its corresponding solutions may be related to IGP protocols. The co-authors have sent emails to collect comments and lauch discussions in LSR WG.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A. There are no features of the document that require formal review.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A. There are no sections of the document that contains a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A. There are no sections of the document that are written in a formal language.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

This problem draft is necessary. The working group has broad discussions on identifing problem scenarios and balancing between solutions and probem scenarios. Both problem statement section and requirements section are revised thoroughly after the first WGLC. I believe the current version is complete and ready to be handled to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No. The Shepherd did not find any other working areas have identified the same issues addressed in this docment.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document intended status is Informational. This is the appropriate status because its content is limted to problem statement and requirements.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. All authous has confirmed all appropriate IPR disclosure required.

Dan Li: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/jYaRYMF0hWgA2QPYVTmuuWJTziI/

Jianping Wu: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7ClxQL9j5j9vRmvrTNzgVKMy_2Y/

Mingqing Huang: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/gotYmKmNqczcAfq8BxeSj7HwI_4/

Lancheng Qing: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/cAFguG5coXyjLp3_wSoLdYvOQW0/

Nan Geng: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7DTSRqHL7OOwXrMuz9bHDKKHgQw/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There is no argument regarding the author, editor and contributor lists in the working group mailing list. The total number of authors on the front page is five, which satisfies the criteria.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Idnits finds section 3.1.1 using IPv4 example instead of IPv6 example. The Shepherd raised this issue to authors and the latest version has addressed it.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The Shepherd reviewed the reference part and suggested the authors move some normative references to informative references. The latest version has been modified accordingly.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA actions are required.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No IANA actions are required.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-savnet-intra-domain-problem-statement-11
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. I am balloting ABSTAIN because I have too many 'near DISCUSS' points.

I am strongly supporting Gunter's DISCUSS about the lack of reference to RFC8704 (Enhanced Feasible-RPF), especially as we were the two OPSEC WG chairs ;-)

Special thanks to Xueyan Song for the shepherd's write-up including the WG consensus *and* the justification of the intended status. But, I find `The Shepherd did not find any other working areas have identified the same issues addressed in this document` a little light.

Please note that Wassim Haddad is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well when it will be available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-savnet-intra-domain-problem-statement/reviewrequest/21463/

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Host vs. node

"Host" is mainly used for plain node without forwarding capability and "node" is any node with or without forwarding capability. AFAIK, this document should rather use "node" than "host".

### Section 1

Like Erik Kline, I find the use of domain = AS a little limiting.

s/a host must use the source IP address assigned to the host/a *node* must use *one* source IP address assigned to the *node*/

`access network SAV (i.e., IP address)` mainly applies to IPv4 only as it is typical in IPv6 network to assign one prefix for one client. Strongly suggest rewriting.

s/This document focuses on the analysis of intra-domain SAV/This document focuses *only* on the analysis of intra-domain SAV/

Isn't this a solved problem: `blocking source-spoofed packets coming from other ASes using a source address of this AS` ?

### Section 2

What is the "INSIDE access list" in `If the source address of a packet is in the INSIDE access list` ?

### Section 3.1

I was about to raise a DISCUSS on this point as several routers are able to prevent spoofing based on snooped DHCP-PD prefix delegation. I fear this I-D has only IPv4 in mind :-(

### Section 3.1.1

As noted, this is only an issue with strict mode URPF.

### Section 5

This would be nice to have a link between requirements in this section and the issues of section 3.

### Section 5.1

The 2nd paragraph is not about requirements but more about solution space, suggest removing it.

### Section 5.2

I was also about to ballot a DISCUSS... this section is underspecified, e.g., it should include DHCP-PD snooping to get the delegated prefix in some cases (in addition to routing). Should PCE be mentioned ?

## NITS (non-blocking / cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try ;-)

[Ballot discuss]
Thanks for working on this document. I have to agree with Roman's observation on the it is not clear on the protocol requirements. I would like to understand more.

I would like to discuss - what are the  particular protocol requirements imposed by 5.3 and 5.4?

I could infer some requirements from other sections even though they are a obfuscated but the mentioned sections seems more like deployment/operation considerations rather protocol design requirements.

[Ballot discuss]
Thanks for working on this document. I have to agree with Roman's observation on the it is not clear on the protocol requirements. I would like to understand more.

I would like to discuss - what are the  particular protocol requirements imposed by 5.3 and 5.4?

I could infer some requirements from other sections even though there are a obfuscated but the mentioned sections seems more like deployment/operation considerations rather protocol design requirements.

[Ballot comment]
I concur with the ARTART review (thanks to Robert Sparks) and Roman's observations that it's unclear that this should be published.  I also concur with the observation that was made about the peculiarity of a problem statement document making normative assertions about something.

(Note that I have not reviewed its apparent companion "-inter-" document.)

These are things that should be confirmed with or reviewed prior to the document moving forward.  I can't support its progress in its current form, but I won't obstruct progress either, hence I'm balloting ABSTAIN.

[Ballot comment]
Thank you to Tim Evan for the GENART review.

I am balloting ABSTAIN because I am challenged in understanding how the requirements portion of this document is to be interpreted given their normative guidance but extremely vague details.  As written, I question if the current text is sufficient to guide the “design [of a] … new intra-domain SAV mechanism.” (per Section 5).

I am equally confused by this statement in the shepherd review “This document provides a gap analysis and problem statement of existing SAV mechanisms. It's not related to protocol design.”  If the requirements aren’t related to a protocol, who are they for?  Why are they here?

I acknowledge that the SAVNET charter calls for a “Problem Statement, Use Cases, and Requirements” document.  It remains silent whether it should be published.

Below are areas of clarity that would benefit the document:

** Section 1.  The term “multi-fence architecture” is used a few times.  Can this concept be explained more clearly.  I thought this might be a term of art, but the few search engines I tried reference this document.  Is this a “defense in depth” term?

** Section 1.
  Given numerous access networks managed by different operators
  throughout the world, it is difficult to require all access networks
  to deploy SAV
.
Perhaps a reference on the difficulty of implementing SAV on access networks would be helpful.

** Section 2.  Editorial.  Why is the Carrier Grade NAT text the only one that discusses limitations of the technology as a solution?  Is there nothing to say about uRFP or ACLs?

** Section 3.1.2.
  For special business purposes, a host/customer network will originate
  data packets using a source address that is not distributed through
  intra-domain routing protocol. 

What is “special business purposes”?

** Section 4.  This section is titled “Problem Statement” which I typically interpret as a statement of the problem to solve.  However, the text seems to be discussing the inadequacy of existing solutions.

** Section 5.1
  Improper permit SHOULD be reduced as
  much as possible so that data packets with spoofed source addresses
  can be effectively blocked.

-- What is an “improper permit”?

-- What does it mean to “reduce as much as possible” with an already non-mandatory “SHOULD”?  How does one know one has satisfied “as much as possible”?  When can one ignore this sentence since it is only a “SHOULD”?

** Section 5.1
  When the network changes, the new
  mechanisms MUST efficiently update SAV rules to guarantee the
  accuracy of SAV.

What is the definition of “efficient”?  How will know it has been realized?  Is the definition contextual?

** Section 5.3
  The new intra-domain SAV mechanism SHOULD NOT assume pervasive
  adoption.

When is it acceptable to assume there is pervasive adoption (since this text is written as a SHOULD not a MUST)?

** Section 5.3
  In
  addition, it SHOULD outperform the current ones in the same
  incremental deployment scenario.

What is the metric of performance what must be “outperformed”? 

** Section 5.3.  How is this section specifying a requirement if all of the text is describing behavior which is optional (i.e., only SHOULDs)

** Section 5.4
  To this end, routers MUST NOT
  signal too much information

How does an implementer use this requirement if “too much” is quantified or contextualized?

** Section 5.5
  Necessary security tools SHOULD be considered in the new intra-domain
  SAV mechanism.

-- What are “necessary security tools”?

-- Why would be acceptable to ignore “necessary security tools” in the design (again because this is a SHOULD)?

[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-savnet-intra-domain-problem-statement-10

# Big thanks to Linda Dunbar for the RTGDIR review!

# I really appreciate the effort put into writing this document. That said, I found it a bit tricky to follow because some of the terminology feels underspecified.

# Before jumping into a detailed, line-by-line review, I’d like to see the blocking DISCUSS observations addressed first. Looking forward to the updates

# DISCUSS
# =======

# I would like to see confirmation from Linda that the proposed changes resolved her RTGDIR concern

# The most important DISCUSS observation is that this draft does not consider RFC8704 (Enhanced Feasible-RPF) which was developed to strike a balance between being full or oblivious to directionality of traffic. It is important to understand if or why this solution is not good enough, and understand if remaining functional gaps exist.

# The text includes use cases where ASBRs are involved. These routers sit at the edge of a network, acting as the boundary between intra-domain and inter-domain connectivity. To properly define the problem and solution space in the context of SAV, it's important to have a clear and accurate description of what qualifies as intra-domain communication, especially when traffic crossing these boundary devices is concerned. This helps ensure the discussion stays well-framed and aligned with the intended scope.

# similar with the observation above is that the understanding of what is exactly an "Intra-domain host network" and "intra-domain customer network" is underspecified or not accurately defined. The draft talks about VPN and makes me wonder about the relationship of VPN usage is with intra-domain SAV?

Many thanks for this document and looking forward to a fresh revision to address the observed discuss items.

Gunter Van de Velde
RTG Area Director

[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-savnet-intra-domain-problem-statement-10

# Big thanks to Linda Dunbar for the RTGDIR review!

# I really appreciate the effort put into writing this document. That said, I found it a bit tricky to follow because some of the terminology feels underspecified.

# Before jumping into a detailed, line-by-line review, I’d like to see the blocking DISCUSS observations addressed first. Looking forward to the updates

# DISCUSS
# =======

# I would like to see confirmation from Linda that the proposed changes resolved her RTGDIR concern

# The most important DISCUSS observation is that this draft does not consider RFC8704 (Feasible RPF) which was developed to strike a balance between being full or oblivious to directionality of traffic. It is important to understand if or why this solution is not good enough, and understand if remaining functional gaps exist.

# The text includes use cases where ASBRs are involved. These routers sit at the edge of a network, acting as the boundary between intra-domain and inter-domain connectivity. To properly define the problem and solution space in the context of SAV, it's important to have a clear and accurate description of what qualifies as intra-domain communication, especially when traffic crossing these boundary devices is concerned. This helps ensure the discussion stays well-framed and aligned with the intended scope.

# similar with the observation above is that the understanding of what is exactly an "Intra-domain host network" and "intra-domain customer network" is underspecified or not accurately defined. The draft talks about VPN and makes me wonder about the relationship of VPN usage is with intra-domain SAV?

Many thanks for this document and looking forward to a fresh revision to address the observed discuss items.

Gunter Van de Velde
RTG Area Director

[Ballot comment]
# Internet AD comments for draft-ietf-savnet-intra-domain-problem-statement-10
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S1

* "intra-domain SAV does not require collaboration between different
  Autonomous Systems (ASes)"

  Perhaps some slight rewording to emphasize Autonomous Systems in different
  administrative domains, since I believe it's possible for a single
  administrative domain to span multiple ASes.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-savnet-intra-domain-problem-statement-09, 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.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-01-17):

From: The IESG
To: IETF-Announce
CC: draft-ietf-savnet-intra-domain-problem-statement@ietf.org, james.n.guichard@futurewei.com, savnet-chairs@ietf.org, savnet@ietf.org, song.xueyan2@zte.com.cn
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Source Address Validation in Intra-domain Networks Gap Analysis, Problem Statement, and Requirements) to Informational RFC


The IESG has received a request from the Source Address Validation in
Intra-domain and Inter-domain Networks WG (savnet) to consider the following
document: - 'Source Address Validation in Intra-domain Networks Gap Analysis,
  Problem Statement, and Requirements'
  as Informational
  RFC

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
last-call@ietf.org mailing lists by 2025-01-17. 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 provides the gap analysis of existing intra-domain
  source address validation mechanisms, describes the fundamental
  problems, and defines the requirements for technical improvements.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-savnet-intra-domain-problem-statement/



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

# Document Shepherd Write-Up for Group Documents

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has received a broad and good support from the WG participants interested in this area concern.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Nothing notable.

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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document provides a gap analysis and problem statement of existing SAV mechanisms. It's not related to protocol design.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is mainly about problem statement for SAVNET. The shepherd sees no necessity for reviews from other IETF working groups or external organizations.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A. There are no features of the document that require formal review.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A. There are no sections of the document that contains a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A. There are no sections of the document that are written in a formal language.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The Shepherd reviewed the document after WGLC of this document and provided comments to authors. The latest version has addressed all Shepherd's comments and no issues found. The document has good quality. It's written clearly and identified all the possible scenarios and gaps and ready to be handled to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No. The Shepherd did not find any other working areas have identified the same issues addressed in this docment.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document intended status is Informational. This is the appropriate status because its content is limted to problem statement and requirements.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. All authous has confirmed all appropriate IPR disclosure required.

Dan Li: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/jYaRYMF0hWgA2QPYVTmuuWJTziI/

Jianping Wu: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7ClxQL9j5j9vRmvrTNzgVKMy_2Y/

Mingqing Huang: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/gotYmKmNqczcAfq8BxeSj7HwI_4/

Lancheng Qing: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/cAFguG5coXyjLp3_wSoLdYvOQW0/

Nan Geng: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7DTSRqHL7OOwXrMuz9bHDKKHgQw/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There is no argument regarding the author, editor and contributor lists in the working group mailing list. The total number of authors on the front page is five, which satisfies the criteria.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Idnits finds section 3.1.1 using IPv4 example instead of IPv6 example. The Shepherd raised this issue to authors and the latest version has addressed it.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The Shepherd reviewed the reference part and suggested the authors move some normative references to informative references. The latest version has been modified accordingly.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA actions are required.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No IANA actions are required.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has received a broad and good support from the WG participants interested in this area concern.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Nothing notable.

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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document provides a gap analysis and problem statement of existing SAV mechanisms. It's not related to protocol design.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is mainly about problem statement for SAVNET. The shepherd sees no necessity for reviews from other IETF working groups or external organizations.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A. There are no features of the document that require formal review.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A. There are no sections of the document that contains a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A. There are no sections of the document that are written in a formal language.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The Shepherd reviewed the document after WGLC of this document and provided comments to authors. The latest version has addressed all Shepherd's comments and no issues found. The document has good quality. It's written clearly and identified all the possible scenarios and gaps and ready to be handled to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No. The Shepherd did not find any other working areas have identified the same issues addressed in this docment.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document intended status is Informational. This is the appropriate status because its content is limted to problem statement and requirements.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. All authous has confirmed all appropriate IPR disclosure required.

Dan Li: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/jYaRYMF0hWgA2QPYVTmuuWJTziI/

Jianping Wu: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7ClxQL9j5j9vRmvrTNzgVKMy_2Y/

Mingqing Huang: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/gotYmKmNqczcAfq8BxeSj7HwI_4/

Lancheng Qing: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/cAFguG5coXyjLp3_wSoLdYvOQW0/

Nan Geng: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7DTSRqHL7OOwXrMuz9bHDKKHgQw/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There is no argument regarding the author, editor and contributor lists in the working group mailing list. The total number of authors on the front page is five, which satisfies the criteria.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Idnits finds section 3.1.1 using IPv4 example instead of IPv6 example. The Shepherd raised this issue to authors and the latest version has addressed it.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The Shepherd reviewed the reference part and suggested the authors move some normative references to informative references. The latest version has been modified accordingly.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA actions are required.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No IANA actions are required.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has received a broad and good support from the WG participants interested in this area concern.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Nothing notable.

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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document provides a gap analysis and problem statement of existing SAV mechanisms. It's not related to protocol design.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is mainly about problem statement for SAVNET. The shepherd sees no necessity for reviews from other IETF working groups or external organizations.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A. There are no features of the document that require formal review.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A. There are no sections of the document that contains a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A. There are no sections of the document that are written in a formal language.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The Shepherd reviewed the document after WGLC of this document and provided comments to authors. The latest version has addressed all Shepherd's comments and no issues found. The document has good quality. It's written clearly and identified all the possible scenarios and gaps and ready to be handled to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No. The Shepherd did not find any other working areas have identified the same issues addressed in this docment.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document intended status is Informational. This is the appropriate status because its content is limted to problem statement and requirements.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. All authous has confirmed all appropriate IPR disclosure required.

Dan Li: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/jYaRYMF0hWgA2QPYVTmuuWJTziI/

Jianping Wu: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7ClxQL9j5j9vRmvrTNzgVKMy_2Y/

Mingqing Huang: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/gotYmKmNqczcAfq8BxeSj7HwI_4/

Lancheng Qing: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/cAFguG5coXyjLp3_wSoLdYvOQW0/

Nan Geng: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7DTSRqHL7OOwXrMuz9bHDKKHgQw/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There is no argument regarding the author, editor and contributor lists in the working group mailing list. The total number of authors on the front page is five, which satisfies the criteria.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Idnits finds section 3.1.1 using IPv4 example instead of IPv6 example. The Shepherd raised this issue to authors and the latest version has addressed it.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The Shepherd reviewed the reference part and suggested the authors move some normative references to informative references. The latest version has been modified accordingly.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA actions are required.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No IANA actions are required.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has received a broad and good support from the WG participants interested in this area concern.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Nothing notable.

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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document provides a gap analysis and problem statement of existing SAV mechanisms. It's not related to protocol design.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is mainly about problem statement for SAVNET. The shepherd sees no necessity for reviews from other IETF working groups or external organizations.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A. There are no features of the document that require formal review.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A. There are no sections of the document that contains a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A. There are no sections of the document that are written in a formal language.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The Shepherd reviewed the document after WGLC of this document and provided comments to authors. The latest version has addressed all Shepherd's comments and no issues found. The document has good quality. It's written clearly and identified all the possible scenarios and gaps and ready to be handled to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No. The Shepherd did not find any other working areas have identified the same issues addressed in this docment.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document intended status is Informational. This is the appropriate status because its content is limted to problem statement and requirements.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. All authous has confirmed all appropriate IPR disclosure required.

Dan Li: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/jYaRYMF0hWgA2QPYVTmuuWJTziI/

Jianping Wu: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7ClxQL9j5j9vRmvrTNzgVKMy_2Y/

Mingqing Huang: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/gotYmKmNqczcAfq8BxeSj7HwI_4/

Lancheng Qing: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/cAFguG5coXyjLp3_wSoLdYvOQW0/

Nan Geng: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7DTSRqHL7OOwXrMuz9bHDKKHgQw/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There is no argument regarding the author, editor and contributor lists in the working group mailing list. The total number of authors on the front page is five, which satisfies the criteria.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Idnits finds section 3.1.1 using IPv4 example instead of IPv6 example. The Shepherd raised this issue to authors and the latest version has addressed it.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The Shepherd reviewed the reference part and suggested the authors move some normative references to informative references. The latest version has been modified accordingly.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA actions are required.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No IANA actions are required.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has received a broad and good support from the WG participants interested in this area concern.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Nothing notable.

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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document provides the gap analysis of existing SAV mechanisms and states problems to support working group's future work. The new SAV mechanism is expected to improve upon the current ones and may be implemented based-on leveraging the existing mechanisms. But the design of new SAV mechanism is not in the scope of the document and implementations are not concerned.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is mainly about problem statement for SAVNET. The shepherd sees no necessity for reviews from other IETF working groups or external organizations.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A. There are no features of the document that require formal review.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A. There are no sections of the document that contains a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A. There are no sections of the document that are written in a formal language.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The Shepherd reviewed the document after WGLC of this document and provided comments to authors. The latest version has addressed all Shepherd's comments and no issues found. The document has good quality. It's written clearly and identified all the possible scenarios and gaps and ready to be handled to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No. The Shepherd did not find any other working areas have identified the same issues addressed in this docment.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document intended status is Informational. This is the appropriate status because its content is limted to problem statement and requirements.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. All authous has confirmed all appropriate IPR disclosure required.

Dan Li: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/jYaRYMF0hWgA2QPYVTmuuWJTziI/

Jianping Wu: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7ClxQL9j5j9vRmvrTNzgVKMy_2Y/

Mingqing Huang: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/gotYmKmNqczcAfq8BxeSj7HwI_4/

Lancheng Qing: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/cAFguG5coXyjLp3_wSoLdYvOQW0/

Nan Geng: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7DTSRqHL7OOwXrMuz9bHDKKHgQw/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There is no argument regarding the author, editor and contributor lists in the working group mailing list. The total number of authors on the front page is five, which satisfies the criteria.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Idnits finds section 3.1.1 using IPv4 example instead of IPv6 example. The Shepherd raised this question to authors and they have addressed this issue in latest version.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The Shepherd reviewed the references and suggested the authors move some normative references to informative references. The latest version has been modified accordingly.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA actions are required.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No IANA actions are required.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has received a broad and good support from the WG participants interested in this area concern.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Nothing notable.

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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document provides the gap analysis of existing SAV mechanisms and states problems to support working group's future work. The new SAV mechanism is expected to improve upon the current ones and may be implemented based-on leveraging the existing mechanisms. But the design of new SAV mechanism is not in the scope of the document and implementations are not concerned.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is mainly about problem statement for SAVNET. The shepherd sees no necessity for reviews from other IETF working groups or external organizations.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A. There are no features of the document that require formal review.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A. There are no sections of the document that contains a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A. There are no sections of the document that are written in a formal language.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The Shepherd reviewed the version (-06) after WGLC of this document and provided comments to authors. The latest version (-07) has addressed all Shepherd's comments and no issues found. The document has good quality. It's written clearly and identified all the possible scenarios and gaps and ready to be handled to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No. The Shepherd did not find any other working areas have identified the same issues addressed in this docment.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document intended status is Informational. This is the appropriate status because its content is limted to problem statement and requirements.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. All authous has confirmed all appropriate IPR disclosure required.

Dan Li: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/jYaRYMF0hWgA2QPYVTmuuWJTziI/

Jianping Wu: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7ClxQL9j5j9vRmvrTNzgVKMy_2Y/

Mingqing Huang: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/gotYmKmNqczcAfq8BxeSj7HwI_4/

Lancheng Qing: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/cAFguG5coXyjLp3_wSoLdYvOQW0/

Nan Geng: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7DTSRqHL7OOwXrMuz9bHDKKHgQw/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There is no argument regarding the author, editor and contributor lists in the working group mailing list. The total number of authors on the front page is five, which satisfies the criteria.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

TBD. Idnits finds section 3.1.1 with IPv4 example instead of IPv6 example. The Shepherd raised this question to authors and they have addressed this issue in version [-08]. Waiting to check the new version [-08].

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

TBD. The Shepherd asked authors to make changes for normative references. The corresponding changes were reflected in version [-07]. Waiting to check the new version [-08].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA actions are required.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No IANA actions are required.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has received a broad and good support from the WG participants interested in this area concern.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Nothing notable.

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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document provides the gap analysis of existing SAV mechanisms and states problems to support working group's future work. The new SAV mechanism is expected to improve upon the current ones and may be implemented based-on leveraging the existing mechanisms. But the design of new SAV mechanism is not in the scope of the document and implementations are not concerned.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is mainly about problem statement for SAVNET. The shepherd sees no necessity for reviews from other IETF working groups or external organizations.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A. There are no features of the document that require formal review.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A. There are no sections of the document that contains a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A. There are no sections of the document that are written in a formal language.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The Shepherd reviewed the version (-06) after WGLC of this document and provided comments to authors. The latest version (-07) has addressed all Shepherd's comments and no issues found. The document has good quality. It's written clearly and identified all the possible scenarios and gaps and ready to be handled to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No. The Shepherd did not find any other working areas have identified the same issues addressed in this docment.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document intended status is Informational. This is the appropriate status because its content is limted to problem statement and requirements.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. All authous has confirmed all appropriate IPR disclosure required.

Dan Li: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/jYaRYMF0hWgA2QPYVTmuuWJTziI/

Jianping Wu: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7ClxQL9j5j9vRmvrTNzgVKMy_2Y/

Mingqing Huang: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/gotYmKmNqczcAfq8BxeSj7HwI_4/

Lancheng Qing: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/cAFguG5coXyjLp3_wSoLdYvOQW0/

Nan Geng: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7DTSRqHL7OOwXrMuz9bHDKKHgQw/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There is no argument regarding the author, editor and contributor lists in the working group mailing list. The total number of authors on the front page is five, which satisfies the criteria.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

TBD. Waiting to check the new version [-07].

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

TBD. Waiting to check the new version [-07].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA actions are required.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No IANA actions are required.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has received a broad and good support from the WG participants interested in this area concern.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Nothing notable.

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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document provides the gap analysis of existing SAV mechanisms and states problems to support working group's future work. The new SAV mechanism is expected to improve upon the current ones and may be implemented based-on leveraging the existing mechanisms. But the design of new SAV mechanism is not in the scope of the document and implementations are not concerned.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is mainly about problem statement for SAVNET. The shepherd sees no necessity for reviews from other IETF working groups or external organizations.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A. There are no features of the document that require formal review.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A. There are no sections of the document that contains a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A. There are no sections of the document that are written in a formal language.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

TBD. Waiting to check the new version [-07].

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No. The Shepherd did not find any other working areas have identified the same issues addressed in this docment.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document intended status is Informational. This is the appropriate status because its content is limted to problem statement and requirements.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. All authous has confirmed all appropriate IPR disclosure required.

Dan Li: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/jYaRYMF0hWgA2QPYVTmuuWJTziI/

Jianping Wu: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7ClxQL9j5j9vRmvrTNzgVKMy_2Y/

Mingqing Huang: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/gotYmKmNqczcAfq8BxeSj7HwI_4/

Lancheng Qing: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/cAFguG5coXyjLp3_wSoLdYvOQW0/

Nan Geng: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7DTSRqHL7OOwXrMuz9bHDKKHgQw/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There is no argument regarding the author, editor and contributor lists in the working group mailing list. The total number of authors on the front page is five, which satisfies the criteria.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

TBD. Waiting to check the new version [-07].

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

TBD. Waiting to check the new version [-07].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA actions are required.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No IANA actions are required.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document has received a broad and good support from the WG participants interested in this area concern.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

Nothing notable.

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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document provides the gap analysis of existing SAV mechanisms and states problems to support working group's future work. The new SAV mechanism is expected to improve upon the current ones and may be implemented based-on leveraging the existing mechanisms. But the design of new SAV mechanism is not in the scope of the document. The potential implementations of the new SAV mechanism are not discussed and concerned in this document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is mainly about problem statement for SAVNET. The shepherd sees no necessity for reviews from other IETF working groups or external organizations.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A. There are no features of the document that require formal review.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A. There are no sections of the document that contains a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A. There are no sections of the document that are written in a formal language.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

TBD. Waiting to check the new version [-07].

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No. The Shepherd did not find any other working areas have identified the same issues addressed in this docment.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document intended status is Informational. This is the appropriate status because its content is limted to problem statement and requirements.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. All authous has confirmed all appropriate IPR disclosure required.

Dan Li: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/jYaRYMF0hWgA2QPYVTmuuWJTziI/

Jianping Wu: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7ClxQL9j5j9vRmvrTNzgVKMy_2Y/

Mingqing Huang: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/gotYmKmNqczcAfq8BxeSj7HwI_4/

Lancheng Qing: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/cAFguG5coXyjLp3_wSoLdYvOQW0/

Nan Geng: No IPR
https://mailarchive.ietf.org/arch/msg/savnet/7DTSRqHL7OOwXrMuz9bHDKKHgQw/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There is no argument regarding the author, editor and contributor lists in the working group mailing list. The total number of authors on the front page is five, which satisfies the criteria.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

TBD. Waiting to check the new version [-07].

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

TBD. Waiting to check the new version [-07].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA actions are required.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No IANA actions are required.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/