Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt

Med,

I didn't think that unified CPE draft is to govern specific solution. But I find out that MAP must refer unified CPE draft as a normative ref in the case of MAP IS the unified solution, make sense?

cheers,
--satoru

On 2013/08/13, at 22:46, <mohamed.boucadair@orange.com> wrote:

> Re-,
> 
> It seems we are in disagreement here. Looking to have more feedback for the list.
> 
> Thanks for engaging.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Ole Troan [mailto:otroan@employees.org]
>> Envoyé : mardi 13 août 2013 15:00
>> À : BOUCADAIR Mohamed OLNC/OLN
>> Cc : softwires@ietf.org
>> Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt
>> 
>> Med,
>> 
>>> We both agree there is no justification to maintain the dhcp draft in the
>> normative section. I consider that point closed and will wait to see this
>> fixed in the document. Given that this document does not rely on how
>> provisioning is achieved and given the unified CPE is where this is
>> supposed to be discussed, I do still think any reference to provisioning
>> should refer to the unified CPE.
>> 
>> "not necessarily against...", is quite far from agree. ;-)
>> MAP doesn't discuss the details of provisioning, but it does have a SHOULD
>> to implement the MAP DHCP option. the reason for this is so that all MAP
>> implementations at least support one provisioning mechanism in common.
>> 
>> does the unified CPE propose something conflicting with the current text in
>> MAP?
>> (the temptation is of course to remove the normative reference, given that
>> progress on a 'unified' DHCP option is slow).
>> 
>>> It really does not make sense to not require the CE to follow the unified
>> CPE behavior (in particular http://tools.ietf.org/html/draft-ietf-softwire-
>> unified-cpe-01#section-3.2) if we want a minimum of coherency among the
>> solutions discussed so far.
>> 
>> that's for the unified CPE document to say.
>> 
>>> I don't think that referring to the unified CPE draft will block the
>> publication of the MAP document. This is not a technical reason BTW.
>> 
>> no, it is not a technical reason. it is a design goal to keep MAP
>> independent of the other mechanisms, i.e. it must be possible to implement
>> routers that only support MAP and no other of the mechanisms.
>> 
>>> If we maintain the same positive energy as we have started to do in the
>> Atlanta meeting, I do think that we will be able to deliver all these
>> documents as a package.
>> 
>> positive energy is good! might be a little misplaced here though. ;-)
>> to me it looks like we've moved the contentious parts that led to all of
>> DS-lite, MAP-E, MAP-T, 4rd, LW46, Public 4over6 and no consensus to the
>> DHCP/unified CPE documents.
>> 
>> cheers,
>> Ole
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires