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

"STARK, BARBARA H" <bs7652@att.com> Fri, 21 July 2017 09:25 UTC

Return-Path: <bs7652@att.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 BEE8D13150C for <v6ops@ietfa.amsl.com>; Fri, 21 Jul 2017 02:25:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 Ng40qyw_x8ol for <v6ops@ietfa.amsl.com>; Fri, 21 Jul 2017 02:25:50 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2120127869 for <v6ops@ietf.org>; Fri, 21 Jul 2017 02:25:50 -0700 (PDT)
Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v6L9P9C9044213; Fri, 21 Jul 2017 05:25:43 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2bu7q084gc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 21 Jul 2017 05:25:42 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6L9Pfh8008366; Fri, 21 Jul 2017 05:25:41 -0400
Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v6L9PYe3008260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 21 Jul 2017 05:25:35 -0400
Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi131.aldc.att.com (RSA Interceptor); Fri, 21 Jul 2017 09:25:14 GMT
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.219]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0319.002; Fri, 21 Jul 2017 05:25:14 -0400
From: "STARK, BARBARA H" <bs7652@att.com>
To: "jordi.palet@consulintel.es" <jordi.palet@consulintel.es>, "v6ops@ietf.org" <v6ops@ietf.org>
CC: Tim Chown <Tim.Chown@jisc.ac.uk>, james woodyatt <jhw@google.com>
Thread-Topic: possible path forward with RFC7084 and transition/other stuff
Thread-Index: AQHTAfY6d5+T2L4jnUmXzScWDzQp/6JeACKw
Date: Fri, 21 Jul 2017 09:25:13 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DBD5815@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <1B7F3C44-B981-490C-9BE7-8FB6378142B9@consulintel.es>
In-Reply-To: <1B7F3C44-B981-490C-9BE7-8FB6378142B9@consulintel.es>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.10.252.246]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-21_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707210147
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/NU-fn0IAmpIZ9NB1Xv8jmY7P2nQ>
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 09:25:52 -0000


> 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