Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

I’m not sure to understand the problem here.

The transition mechanism in this document aren’t a “MUST” (same in the actual RFC7084), so if an ISP is using this document as a reference for an RFQ, and don’t need the transition mechanism, nothing change. If the ISP want to ask in the RFQ the transition mechanism they should reference to the RFC and add a MUST for those technologies that he is going to use for the deployment, or even say something generic such as “all the transition mechanism in this RFC MUST be supported if you intend to be our provider, in addition to …. (specific vendor requirements here)”.

Obsoleting and updating, will in any case have a reference such as “this document has been obsoleted or updated by …”, either in the header or in the document itself?

I think it makes more sense obsoleting if we still have the same view of “doing updated” to the current text, instead of working in two documents as I asked in my presentation (slide 8) in Chicago. Just to remind it, the alternative was:
- Downgrade actual RFC7084 so it doesn’t include any transition mechanism and have a new document with the transition mechanisms.

We could also add some more detailed text over-explaining that the main scope of the document is IPv6-only, and the transition mechanisms as there only for the initial phase of the IPv6 deployment while there is still a need to support access to IPv4-only devices/apps in the LAN or in the “remote-IPv4-only” Internet. I think it is already clear in the actual text but we can “stress” it a bit more …

Regards,
Jordi

-----Mensaje original-----
De: Fred Baker <fredbaker.ietf@gmail.com>
Responder a: <fredbaker.ietf@gmail.com>
Fecha: miércoles, 12 de abril de 2017, 19:10
Para: <mohamed.boucadair@orange.com>
CC: "STARK, BARBARA H" <bs7652@att.com>, "otroan@employees.org" <otroan@employees.org>, JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, "v6ops@ietf.org" <v6ops@ietf.org>
Asunto: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

    > On Apr 12, 2017, at 6:12 AM, mohamed.boucadair@orange.com wrote:
    > 
    > Hi Barbara, 
    > 
    > Wouldn't just be fine for those ISPs not interested in transition mechanisms to continue referring to RFC7084?

    The tricky bit tends to be in how we label the update. If it "obsoletes" or "updates" 7084, we mean that any reference to 7084 becomes a reference to the new thing, or 7084 plus the new thing. We would need to clearly label it so that a procurement could reference 7084 without it, or reference 7084 and the new thing separately.

    > Cheers,
    > Med
    > 
    >> -----Message d'origine-----
    >> De : STARK, BARBARA H [mailto:bs7652@att.com]
    >> Envoyé : mercredi 12 avril 2017 14:53
    >> À : BOUCADAIR Mohamed IMT/OLN; otroan@employees.org;
    >> jordi.palet@consulintel.es
    >> Cc : v6ops@ietf.org
    >> Objet : RE: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00
    >> 
    >>> I tend to agree with you but with a slightly different proposal:  pick
    >> ONE
    >>> mandatory stateful mechanism (DS-Lite) and ONE mandatory A+P
    >>> mechanism (MAP-E).
    >> 
    >> Because RFC 7084 is also used as a mandatory reference in BBF TR-124 (used
    >> by telco ISPs to help with CE router RFPs), and most ISPs have no interest
    >> in requiring capabilities that are not useful to or relevant in their
    >> deployment, there MUST NOT be any mandatory transition mechanisms included
    >> in a 7084-bis.
    >> Barbara
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
    > https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.