While I appreciate the functional modularity in understanding the solution space, I do wish that DT had come up with a way to make this one document to present to the world rather than four. I fear organ rejection when tossing a list of RFCs for one function to the CPE industry.
In current form, each document has more or less than 10 pages of substantive text, with considerable overlap between them (how many "framework" and "architecture" sections do we really need for what are really just two variants of something 95% the same?). As further evidence of the problem, there are no less than 19 references to mdt-softwire-mapping-address-and-port from draft-mdt-softwire-map-translation-00. One page has 5 references alone. It's is like reading a single book with every other page in a different binding. Could we not eliminate the overlap, and just boil this down to one less than 40 page document? In fact, I bet if you tried you could get it down to half that. Looks like Remi's new document is on the right track in this regard. I'm in favor of the chairs stating that we will adopt a WG document based on the text in these documents, but I would like to see a stipulation that they be combined into one (perhaps two but with only the DHCP option separate) and the overlap eliminated among MAP, T and E eliminated. - Mark On Jan 30, 2012, at 12:31 PM, Ole Trøan wrote: > hi, > > the MAP (Mapping of address and port) design team has now written and > published the following sets of drafts. > > the base document (port mapping algorithm): > http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-03 > > http://tools.ietf.org/rfcdiff?url2=draft-mdt-softwire-mapping-address-and-port-03.txt > > the encapsulation document (MAP-E): > http://tools.ietf.org/html/draft-mdt-softwire-map-encapsulation-00 > > the translation document (MAP-T): > http://tools.ietf.org/html/draft-mdt-softwire-map-translation-00 > > the DHCP option (MAP-DHCP): > http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-02 > > there is a MAP deployment document coming soon. > > the solution described in this set of documents, are written to satisfy the > following from the softwires charter: > 4. Developments for stateless legacy IPv4 carried over IPv6 > - develop a solution motivation document to be published as an RFC > - develop a protocol specification response to the solution > motivation document; this work item will not be taken through > > in the design team's view, this set of documents are ready to be adopted as > working group documents. > > comments? > > for the MAP design team, > Ole > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
