Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Mon, 28 May 2018 09:07 UTC

Return-Path: <prvs=1686b21113=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 78E49126579 for <v6ops@ietfa.amsl.com>; Mon, 28 May 2018 02:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 Hk1mOqwqZrvl for <v6ops@ietfa.amsl.com>; Mon, 28 May 2018 02:07:02 -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 533781241F3 for <v6ops@ietf.org>; Mon, 28 May 2018 02:07:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1527498420; x=1528103220; 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=OqDGnerkJIw8YLEt87kMb 5+a1agepy+etMhuIDrxfdw=; b=c1ca6pQnvIXsKsk+FaxmZ7vDkdoqQ9FjIzcrt Xx4YHY5d+VWuEF6hWbUTcnNs93EqS5QCmGe19M5F7SqL5wgQtuIxFvD/BS2mCeY8 G+juzh4jdEFmBytPBYLDO1SXzm7R/dbH3rx8J0AsIVG3u2SpuYh/fWvsZdbSz21p E2G+rs=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Mon, 28 May 2018 11:07:00 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 28 May 2018 11:07:00 +0200
Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005778011.msg for <v6ops@ietf.org>; Mon, 28 May 2018 11:06:59 +0200
X-MDRemoteIP: 2001:470:1f09:495:89fa:173c:3df6:bba6
X-MDHelo: [10.10.10.129]
X-MDArrival-Date: Mon, 28 May 2018 11:06:59 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1686b21113=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.d.1.180523
Date: Mon, 28 May 2018 11:06:55 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: "STARK, BARBARA H" <bs7652@att.com>, V6 Ops List <v6ops@ietf.org>
Message-ID: <82CAB96F-B0FB-4E6F-A8FB-094C424F514F@consulintel.es>
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt
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/1jQ78LSIgQr-iRvcpW_wknyt8Ok>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt
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: Mon, 28 May 2018 09:07:06 -0000

Hi Barbara,

Sorry the late answer, last few weeks had been a non-stop traveling in 3 continents and too much work ...

I see what you mean and we have discussed about this among the coauthors and amended the document, including some other comments received in the list.

The new version has been published a few minutes ago:

https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/?include_text=1

Basically, we are keeping a MUST for retail product versions, but not for specific ISP versions. I hope you agree with this, as we believe it makes sense.

We don't update anymore the RFC7084, and we just use the same style to add the requirements for an IPv6 Transition CE Router (and we use this terminology across all the document).

The main changes are summarized in the Annex C:
1.  ID-Nits: IANA section.
2.  ID-Nits: RFC7084 reference removed from Abstract.
3.  This document no longer updates RFC7084.
4.  UPnP section reworded.
5.  "CE Router" changed to "IPv6 Transition CE Router".
6.  Reduced text in Annex A.

Hopefully everybody agrees now with this version, and in any case, will be very helpful if we can get any inputs.

Regards,
Jordi
 
 

-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de "STARK, BARBARA H" <bs7652@att.com>
Fecha: lunes, 30 de abril de 2018, 19:20
Para: V6 Ops List <v6ops@ietf.org>
Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt

    Hi Jordi,
    I was having a hard time understanding where you were headed with proposed changes, by following the email thread. So I was waiting for this update. My company's email server also refuses to deliver to me some emails sent to this list without telling me. That probably adds to my difficulty.
    
    My suggestion related to making requirements "MUST" were tied to also *not* making this an update to RFC 7084.
    
    Here is the problem:
    If this is an update to RFC 7084, then I cannot support any "MUST" statements.
    My employer makes use of RFC 7084. As is. Updating RFC 7084 with additional "MUST" statements impacts my employer's ability to use and reference RFC 7084 to get the CE routers it wants. An RFC 7084 update with "MUST" statements (that are not needed by many current deployments) would be harmful to the existing IPv6 ecosystem.
    
    For a device profile to be usable by the vendor and ISP community, it must contain "MUST" statements for all items that need to be required to achieve the profile's goal. Trying to get vendors to implement lots of "SHOULD" statements is futile. As an individual contributor, I do not support IETF publishing a futile device profile document with many "SHOULD" statements.
    
    The solution I have proposed is to create a brand new device profile. A device profile for something called an "IPv6 Transition CE Router". This device profile is not an update to RFC 7084. It is its own thing. It is free to make use of RFC 7084 any way it wants -- not at all, in whole, or by referencing sections it does or doesn't want to require as part of the "IPv6 Transition CE Router" device profile.
    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.