Re: [dhcwg] Alvaro Retana's Discuss on draft-ietf-dhc-dynamic-shared-v4allocation-07: (with DISCUSS)

[Qi Sun <[e-mail]>]

Dear Alvaro,

Thanks for the review. Please see inline.

On May 28, 2015, at 10:47 AM, Alvaro Retana <[e-mail]> wrote:

> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Section 2 (Applicability Statement) says that “this extension is only
> suitable for specific architectures based on the Address plus Port model
> (A+P) [RFC6346]”, which I take to mean that the components of the
> solution in RFC6346 must be present (PRR, for example).  In fact, if the
> functionality described in RFC6346 is not present, then the forwarding
> won’t work as standard destination-based protocols may not deliver the
> packets to the right place.  I think that RFC6346 should be a Normative
> Reference, which then results in a DOWNREF to an Experimental RFC.
> 
> IOW, if the functionality in RFC6346 is needed (which I think it is),
> then the status of this document should not be Standards Track.
> 
> 

IMO, RFC6346 provides an architecture of A+P, while [I-D.ietf-softwire-lw4over6] and [I-D.ietf-softwire-map] follow RFC6346 for sharing IPv4 in the context of IPv4-over-IPv6 tunnelling. Those two documents are being published as Standard Track by the IETF. 

This document intends to define a provisioning method (a DHCPv4 option used with DHCPv4 over DHCPv6 [RFC7341]), not another A+P IPv6 transition mechanism. In the Section 2, we’re trying to make it clear that this mechanism is not universally applicable. It’s only suitable for “[I-D.ietf-softwire-lw4over6] and certain configurations of  [I-D.ietf-softwire-map]”, which are on Standard Track and are normative referenced in this document. We think that would sufficiently avoid potential mis-use of this mechanism.

Hope the explanation could help to resolve your concern.

Thanks! 
Qi