+1. Making another new document might cause more confusion. But if 4rd work is stopped and merged to MAP, it might be good. But from the implementation point of view, I would like to eliminate the complicated code as much as possible such as
if (MAP-E) ... else if (MAP-T) ... else if (MAP-H) ... But this is the implementation/deployment choice. So, from the standard perspective, it might be good to merge H solution to MAP which has already merged both E and T. Thanks, Tetsuya Murakami On 2012/06/23, at 1:52, Satoru Matsushima wrote: > Dear Remi, > > Thank you for a kind offer. It would be a very positive compromise for us. > > However, in the context of making another new stream document, which MAP-bis > as you said, I decline it. Nevertheless, if you abandon 4rd work, I'm very > welcome you as an author of MAP. > > Best regards, > --satoru > > On 2012/06/23, at 1:52, Rémi Després wrote: > >> Yong, Suresh, Ralph, >> >> For mesh stateless v4/v6, we have so far a choice between only two >> solutions, MAP as is and 4rd. >> On can hope that the consensus that couldn't be reached in Paris will be >> achievable in Vancouver, but this isn't sure, each "camp" keeping its own >> expectation. >> >> Looking at recent history, we can remember that, not long ago, the chair's >> approach was to have 3 specifications completed (MAP-T, MAP-E, and MAP-H, as >> Alain called it with H for Hybrid), and then to choose only one for >> standardization. >> >> After that, promoters of either -T and -E decided to merge -T and -E in a >> non-separable specification, as reflected in draft-ietf-softwire-map-00. >> Thus, the choice has become between a "two-variants" specification (MAP) and >> a "single-variant" specification (4rd). >> >> In this context, a larger choice might well be the best chance for a WG >> consensus. It would include a MAP specification in which the forwarding mode >> of 4rd would be added as 3rd, say a "MAP-bis" . >> With this MAP-bis: >> - vendors have to support 3 forwarding modes, which isn't ideal, but most of >> the design, in particular in what concerns mapping rules, remains common >> (Alain once said, possibly with optimism, the three were 99% identical!) >> - operators have a free choice between T, E, or H, based on their >> operational preferences. >> - we have (at last) a stabilized design with no one badly frustrated. >> >> If this approach makes sense for the WG, I can do the work of editing a >> MAP-bis proposal (taking the current MAP specification, adding a section >> that describes the hybrid forwarding mode, and adding a third variant in the >> address-format section). >> >> My personal preference remains for 4rd as single standard, but a choice >> between MAP-as-is, MAP-bis, and 4rd, is IMHO a sounder choice for the WG >> than just between MAP-as-is and 4rd. >> >> Hoping that this will be found constructive, >> Best regards, >> RD >> >> >> >> >> >> >> >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
