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. “ David Harrington ietfdbh at comcast.net On Oct 21, 2014, at 3:48 AM, Qi Sun < sunqi.csnet.thu at gmail.com > wrote: Dear Ted, David, As a co-author the the draft-sun-softwire-yang-00, I have to admit this draft is pre-mature and needs in-depth discussion before it can go forward. We don’t know how far it will have progressed since this original idea as well as the document structure needs feedback from both the Softwire WG and the netmod WG. We don’t hope this draft to be a potential blocking point of the doc that has got consensus of the WG, as the discussions might be long. Thanks, Qi On Oct 21, 2014, at 1:03 AM, Ted Lemon < ted.lemon at nominum.com > wrote: On Oct 20, 2014, at 9:43 AM, Black, David < david.black at emc.com > wrote: Whether adding an informative mention of the YANG model rises to the level of "required" would be up to the OPS ADs.  It may help implementers find the YANG model, which could be useful. The problem with this is that the informative reference would wind up being to a -00 draft of the yang data model; unless that document makes rapid progress, it's unlikely that the reference will be to a version of the document that anybody would find useful.   It might be worth asking the authors of that document where they think it will be in two or three months, since that's about the length of the RFC Editor queue at the moment, IIRC. _______________________________________________ OPS-DIR mailing list OPS-DIR at ietf.org https://www.ietf.org/mailman/listinfo/ops-dir