| Hi, I think there are a few problems with this draft that should be looked at more closely. 1) I think there is a problem with having a MUST condition in the spec depending on a companion document that will be published later. "The consequence of this architecture is that the information maintained by the provisioning mechanism and the one maintained by the lwAFTR MUST be synchronized (See figure 2). The details of this synchronization depend on the exact provisioning mechanism and will be discussed in a companion document. “ There are additional synchronization requirements specified in 6.1 - Binding Table Maintenance. If the synchronization is that important that it deserves multiple MUSTs in the spec, and the details depend on the provisioning mechanism, then it sounds reasonable to consider the companion document to be required. It seems to me that, if synchronization is critical and we want interoperability, there should be a mandatory-to-implement synchronization spec defined before this spec is ready for publication. 2) I have a related concern: I don’t see discussion of how the implementation should be operated and monitored, remotely. Since this implementation is expected to reside in customer premises equipment, having a remote monitoring and management capability seems important. And since this is being developed in the IETF, where interoperability is important, it would seem an IETF standardized monitoring and management solution would be desirable. A MIB module would provide monitoring capability, but none is defined or suggested here. This is an extension to DS-LIte, and there is a DS-Lite MIB. There is no discussion of whetherr that DS-Lite MIB module would be applicable to lw4o6, or whether that MIB module would require changes to be applicable to lw4o6 monitoring. A YANG solution could address both the monitoring and provisioning requirements. But an operator cannot use it if it isn’t implemented, so there should be a mandatory-to-implement mechanism to allow for monitoring in an interoperable manner. (Operators can still choose to deploy different non-interoperable solutions fi they choose, but without a mandatory-to-implement baseline for interoperability, they cannot choose one known to be interoperable across all standard-compliant implementations.) 3) I have a concern with section 3.2.1, which is entitled “Changes to RFC2473 and RFC6333 Fragmentation Behavior”. The text says to follow the best current practices of a number of other documents, but it never actually discusses what the changes to fragmentation behavior would be. RFC2473 and RFC6333 are both standards-track. Is this document proposing to update those standards? It doesn’t say so in the I-D heading. The RFCs containing best current practices cover a lot of ground. This feels like hand-waving as a result. Are all of the best practices needed for this spec to work properly, or just some of them? Are some of these BCPs REQUIRED for this spec to work properly? This section is about changes in fragmentation behavior. Are there specific sections of the BCPs that are important to apply, for the changes in fragmentation behavior? The text specifies following the best current practices as a SHOULD; it doesn’t discuss why this is only a SHOULD and not a MUST. Under what circumstances would it be acceptable to NOT follow these best practices? What would happen to the network or the users of the network if an lwB4 implementation does NOT follow those guidelines? (This would be easier to discuss if the spec referred to specific best practices relevant to fragmentation.) 4) Section 7 suggests a number of additional provisioning mechanisms:
In addition to the DHCPv6 based mechanism described in section 5.1,
several other IPv4 provisioning protocols have been suggested. These
protocols MAY be implemented. These alternatives include:
o DHCPv4 over DHCPv6: [RFC7341] describes implementing DHCPv4
messages over an IPv6 only service providers network. This
enables leasing of IPv4 addresses and makes DHCPv4 options
available to the DHCPv4 over DHCPv6 client.
Cui, et al. Expires April 17, 2015 [Page 12]
Internet-Draft Lightweight 4over6 October 2014
o PCP[RFC6887]: an lwB4 MAY use [I-D.ietf-pcp-port-set] to retrieve
a restricted IPv4 address and a set of ports.
In a Lightweight 4over6 domain, the binding information MUST be
aligned between the lwB4s, the lwAFTRs and the provisioning server.How do we achieve interoperability if each implementation can choose different provisioning mechanisms? Especially, given that synchronization is critical, and is dependent on the provisioning mechanism used? 5) section 7 suggests provisioning mechanisms in addition to DHCPv6, so I checked to see if DHCPv6 was required (i.e. mandatory to implement). That also appears to merely be an option. So there apparently is no mandatory-to-implement way to address these MUSTs: " In lw4o6, a number of lw4o6 specific configuration parameters must be provisioned to the lwB4. “ On Oct 21, 2014, at 3:48 AM, Qi Sun <sunqi.csnet.thu@xxxxxxxxx> wrote: Dear Ted, David, |