Subject: [savi] Publication request for "SAVI Solution for DHCP" (draft-ietf-savi-dhcp-29)

From: Jean-Michel Combes <[email-masked]>
Date: Wed, 23 Jul 2014 00:05:28 +0200

Dear Secretary,

This is a request to publish draft-ietf-savi-dhcp-29 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:

This document specifies the procedure for creating a binding between a
DHCPv4/DHCPv6 assigned IP address and a binding anchor on a SAVI (Source
Address Validation Improvements) device. The bindings set up by this
procedure is used to filter out packets with forged source IP address in
DHCP scenario. This mechanism is proposed as a complement to ingress
filtering to provide finer-grained source IP address validation.

Working Group Summary:

Even if IPR have been disclosed, there is no concern from the WG to move
forward this document as Proposed Standard.

Document Quality:

This document has been thorough reviewed.

Personnel:

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

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

-          Comments from IESG regarding the other SAVI documents (i.e.,
FCFS SAVI, SEND SAVI) are taken into account inside this document

-          Specifications described inside this document are following,
when possible, the same framework as the other SAVI documents (i.e., FCFS
SAVI, SEND SAVI) to ease the implementation of many SAVI mechanism inside a
same SAVI device.

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

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

(5)   As the mechanism specified in this document is strongly based on
DHCPv4/DHCPv6, the dhc WG has been associated to the WGLC.

(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)   An IPR disclosure has been filed that references this document. After
the disclosure, a new WGLC has been launched to know if any member of the
WG would have concerns to move forward the document: there was no concern.

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

(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 2 normative references (i.e., ietf-opsec-dhcpv6-shield,
ietf-dhc-dhcpv4-over-dhcpv6) that are not ready for advancement. Finally,
the Document Shepherd believes these references should become informative
references as they don’t impact critically the mechanism specified in this
document.

(15) There is one downward normative reference (cf. ID Nits check). This
normative reference 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.