Subject: [savi] Publication request for "SAVI for Mixed Address Assignment Methods Scenario" (draft-ietf-savi-mix-11)

From: Jean-Michel Combes <[email-masked]>
Date: Sun, 12 Jun 2016 15:58:30 +0200

Dear Secretary,

This is a request to publish draft-ietf-savi-mix-11 as Standard track RFC.
Please find below the Shepherd Document write-up.

Thanks in advance.

Best regards,

JMC.

(1) The type of RFC requested is Proposed Standard. This is the proper type
because this document describes specifications for a mechanism being
implemented and deployed. The type of RFC is indicated in the title page
header.

(2) Here is the Document Announcement Write-Up,

Technical Summary:

In networks that use multiple techniques for address assignment, the
appropriate Source Address Validation Improvement (SAVI) methods must be
used to prevent spoofing of addresses assigned by each such technique. This
document reviews how multiple SAVI methods can coexist in a single SAVI
device and collisions are resolved when the same binding entry is
discovered by two or more methods.

Working Group Summary:

There was nothing noteworthy in the WG process.

Document Quality:

This document has been thorough reviewed and a dedicated language review
was done by one of the co-authors, Joel Halpern, native English speaker.

Personnel:

The document shepherd is Jean-Michel Combes ([email-masked]). The
Responsible Area Director is Suresh Krishnan ([email-masked]).

(3) The review of this document performed by the Document Shepherd includes:

- Comments regarding technical clarifications

- Comments regarding editorial modifications (e.g., references)

- A check of the English level (even if English is not the mother tongue of
the Document Shepherd).

The Responsible Area Director was always aware about the exchanges between
the Document Shepherd and the authors during the review

(4) The Document Shepherd has no concern about the deph or breadth of the
reviews that have been performed.

(5) The document needn’t review from a particular or from broader
perspective.

(6) The Document Shepherd has no specific concerns or issue with this
document.

(7) Each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
been filed.

(8) No IPR disclosure has been filed that references this document

(9) The WG consensus behind this document is mainly based of the agreement
of a small group with others being silent.

(10) Nobody threatened an appeal or otherwise indicated extreme discontent.

(11) The check done with ID Nits tool is not successful: there is one error
(cf. point 15).

(12) The document doesn’t need to meet any required format review criteria

(13) All references within this document have been identified as either
normative or informative but, as noted by the ID Nits check (cf. above), a
normative reference is in fact an Informational RFC.

(14) There are no references to documents that are not ready for
advancement or otherwise are in an unclear state.

(15) There is one downward normative reference (cf. ID Nits check). This
normative reference (i.e., [RFC7039]) should become informative reference.

(16) The publication of this document will not change the status of any
existing RFC.

(17) There is no request for an action from the IANA.

(18) There is no request for an action from the IANA.

(19) There is no formal language inside this document expecting a specific
review from the Document Shepherd.