IETF Logo Mail Archive

Re: [v6ops] transition-ipv4aas: positioning the draft

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Thu, 26 April 2018 18:14 UTC

Return-Path: <prvs=1654602c4e=jordi.palet@consulintel.es>
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 8AA89127978 for <v6ops@ietfa.amsl.com>; Thu, 26 Apr 2018 11:14:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 ez8U1LKfQsjx for <v6ops@ietfa.amsl.com>; Thu, 26 Apr 2018 11:14:42 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDEF5127873 for <v6ops@ietf.org>; Thu, 26 Apr 2018 11:14:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1524766479; x=1525371279; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=2p+OU/LM53Pma4mRoDWvV OxpD+DgEo7dzcnajkRbnaY=; b=uoaSIAaWal3xo1VUw4J+nfuQHzd8iC32xsac2 vPCTFyyHVUkQKyUvrC47IcMxMPuMFgEZobXbwG0afUGPonQrOHuaZ2IMviIUQMuq N3Zf5LQ7Ci8+mKjT2rMXR/9hBYKpNGe3179PjGGVd563uVe9C1nki98eqdtJdIsN P+H0qo=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Thu, 26 Apr 2018 20:14:39 +0200
X-Spam-Processed: mail.consulintel.es, Thu, 26 Apr 2018 20:14:38 +0200
Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005758804.msg for <v6ops@ietf.org>; Thu, 26 Apr 2018 20:14:38 +0200
X-MDRemoteIP: 2001:470:1f09:495:5004:edf7:d517:81bb
X-MDHelo: [10.10.10.129]
X-MDArrival-Date: Thu, 26 Apr 2018 20:14:38 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1654602c4e=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.c.0.180410
Date: Thu, 26 Apr 2018 20:14:36 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: V6 Ops List <v6ops@ietf.org>
Message-ID: <6A287B2F-EB6F-4AC5-A4A3-53E365181367@consulintel.es>
Thread-Topic: [v6ops] transition-ipv4aas: positioning the draft
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/40jMo6qmFui31SN40oSS-ERpR6E>
Subject: Re: [v6ops] transition-ipv4aas: positioning the draft
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: Thu, 26 Apr 2018 18:14:44 -0000

Hi Barbara, Lee, all,

Please, read and provide your inputs as we have here a couple of key questions:

1) Lee suggested a few days ago to make it short and instead of using "IPv6 Transition CE Router", use "CE Router".

I'm fine either way, so will love if both of you can confirm your preference, so I can amend that in the new WG version.

2) I also follow Barbara rationale and like what she is suggesting about making most of the SHOULDs a MUST. However, this is a key change, so will need to understand if the WG will accept that.

Thanks!

Regards,
Jordi
 
 
-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de "STARK, BARBARA H" <bs7652@att.com>
Fecha: miércoles, 25 de abril de 2018, 20:59
Para: V6 Ops List <v6ops@ietf.org>
Asunto: [v6ops] transition-ipv4aas: positioning the draft

    I have a number of comments for draft-palet-v6ops-transition-ipv4aas. I'm grouping comments under different email subject headers so it's easier to track the topic of any resulting discussion.
    
    The first area of comments I have is on how to position this draft relative to RFC 7084 and in a way that will maximize its impact and likelihood of achieving its goal (which I think is to drive availability of CE routers that support *all* of the included transition technologies).
    
    I notice the draft introduces the term "IPv6 transition CE". Sometimes this is "IPv6 transition CE router". I like this idea, but would suggest capitalizing and using the longer "IPv6 Transition CE Router". I think if this is a more formal term and this draft is positioned as defining requirements for an IPv6 Transition CE Router (rather than simply specifying "the transition requirements for an IPv6 Customer Edge (CE) router") then it becomes ok to make most of the SHOULD requirements into a MUST. That is, the draft is not an extension of a CE Router (RFC 7084). It's something new that is specified and defined here. And should be the title of the draft.
    
    Saying "MUST" is stronger than "SHOULD" and will increase likelihood of success. It will also increase likelihood that *all* of the included technologies are implemented (as currently written it would be possible to do one or 2 of the technologies and still claim compliance). And it will make it easier to create a subsequent certification program, if there is demand for one. If the MUST statements apply only to the IPv6 Transition CE Router this draft defines, then there is no problem with saying "MUST". The requirements have no scope outside this draft.
    
    ----------
    
    If taking this approach, requirements for DS-Lite would need to be included. Those can be copied from RFC 7084.
    
    ----------
    
    RFC 7084 can still be a basis for this new thing (MUST comply with RFC 7084).
    
    The current requirement for RFC 7084 compliance is "The IPv6 Transition CE router must comply with all the requirements stated in [RFC7084]." 
    I suggest staying away from "all the requirements", since the RFC 7084 SHOULD and MAY requirements are also requirements, and I don't think it's intended to mandate those. I recommend simply saying:
    The IPv6 Transition CE router MUST comply with [RFC7084].
    
    ---------
    
    If done this way, I don't think it's necessary to make mention of 6rd in any way. It's omission from this draft will make it clear that it's not a component of an IPv6 Transition CE Router.
    
    
    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 exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

v2.23.0 | Report a Bug | By Email