IETF Logo Mail Archive

Re: [v6ops] possible path forward with RFC7084 and transition/other stuff

<mohamed.boucadair@orange.com> Fri, 21 July 2017 10:51 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A86129B3A for <v6ops@ietfa.amsl.com>; Fri, 21 Jul 2017 03:51:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level:
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeS5xI0mt4Va for <v6ops@ietfa.amsl.com>; Fri, 21 Jul 2017 03:51:52 -0700 (PDT)
Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C50127337 for <v6ops@ietf.org>; Fri, 21 Jul 2017 03:51:52 -0700 (PDT)
Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id DBD2260611; Fri, 21 Jul 2017 12:51:50 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id B646818005A; Fri, 21 Jul 2017 12:51:50 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0352.000; Fri, 21 Jul 2017 12:51:50 +0200
From: mohamed.boucadair@orange.com
To: "STARK, BARBARA H" <bs7652@att.com>, "jordi.palet@consulintel.es" <jordi.palet@consulintel.es>, "v6ops@ietf.org" <v6ops@ietf.org>
CC: james woodyatt <jhw@google.com>
Thread-Topic: possible path forward with RFC7084 and transition/other stuff
Thread-Index: AQHTAfYvm5fd7PB/t0WGdt3Tc+v7nqJd4Q+AgAA4ofA=
Date: Fri, 21 Jul 2017 10:51:49 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A011AC7@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <1B7F3C44-B981-490C-9BE7-8FB6378142B9@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DBD5815@GAALPA1MSGUSRBF.ITServices.sbc.com>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DBD5815@GAALPA1MSGUSRBF.ITServices.sbc.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/eG2I9WquKsMW9qDAHD8qOnLGgbg>
Subject: Re: [v6ops] possible path forward with RFC7084 and transition/other stuff
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jul 2017 10:51:55 -0000

Hi Jordi, all,

I agree with Barbara, here. 

I do see a vale in not obsoleting 7084. So scoping your document accordingly is the right approach to adopt here.  

I would not add the flow to restate what is already in 8026. Citing it would be sufficient, IMO.

Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de STARK, BARBARA H
> Envoyé : vendredi 21 juillet 2017 11:25
> À : jordi.palet@consulintel.es; v6ops@ietf.org
> Cc : james woodyatt
> Objet : Re: [v6ops] possible path forward with RFC7084 and
> transition/other stuff
> 
> 
> 
> > 1) Not change/update the existing RFC7084.
> > 2) Use my “Transition Requirements for IPv6 Customer Edge Routers”
> > document (draft-palet-v6ops-rfc7084-bis-transition-00) as a starting
> point,
> > which “extend” the requirements of RFC7084 towards supporting actual
> > world transition requirements.
> > 3) In this updated document, the transition requirements can then be a
> > MUST, so vendors take it seriously.
> > 4) I will include the reference to RFC8026 (some more text, as this
> reference
> > is already in all my docs regarding this topic), so there is a “flow” of
> how the
> > pair “ISP-CE” can get working IPv6 and then IPv4 if it is available from
> the ISP
> > “as a service”. I think this can have also what Fred was suggesting as
> “IPv6
> > must be on by default”, right?
> 
> I would support this. If your goal really is encouraging the availability
> of CE routers with these v4 over v6 technologies, this is the approach I
> would recommend.
> 
> > CHOICE 2 (to make it clear, my own toughs after waking up this morning,
> not
> > discussed with the other folks yesterday):
> > Same as choice 1 above, but include also support for HNCP and may be
> > something else if we believe it is required during the development of
> this
> > document (for example it seems clear that if we offer IPv4 as a service,
> > because actual multicast-based IPTV services run on IPv4, we need to
> keep
> > supporting that on top of an IPv6-only access).
> > So then the document will be renamed to something such as “Transition
> and
> > extended requirements for IPv6 CE routers”.
> 
> I would not support this. I think it would make the document less focused
> and therefore more likely to be ignored.
> 
> Barbara
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email