Re: [v6ops] Adam Roach's No Objection on draft-ietf-v6ops-transition-ipv4aas-12: (with COMMENT)

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Thu, 10 January 2019 11:24 UTC

Return-Path: <prvs=1913f26ae7=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 7B86F130E13; Thu, 10 Jan 2019 03:24:33 -0800 (PST)
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 obloHY9tKQz2; Thu, 10 Jan 2019 03:24:31 -0800 (PST)
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 24F17130E0E; Thu, 10 Jan 2019 03:24:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1547119467; x=1547724267; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=xKtF/jQoyKntFwJ0xagn2kWbs8HIrqOvoOp38Vr0HFw=; b=A0oqrW1c+pJEZ 6fUSfGWQIrL21yZJsZY0OIiJRVxXWRTRmF9FB+LfWDusG71+a2iSgKWkgBGjWx41 y37Cgffe++m+VdppXJAyYldGWjcTjPPBreDvMfZgHyPOaESSnbUnWNr6azoQUDK8 7gV7Rky5XhvJ/rDzLG2fBEFo5pbveU=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Thu, 10 Jan 2019 12:24:27 +0100
X-Spam-Processed: mail.consulintel.es, Thu, 10 Jan 2019 12:24:27 +0100
Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006104666.msg; Thu, 10 Jan 2019 12:24:26 +0100
X-MDRemoteIP: 2001:470:1f09:495:6d25:fb99:feb6:ac39
X-MDHelo: [10.10.10.140]
X-MDArrival-Date: Thu, 10 Jan 2019 12:24:26 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1913f26ae7=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
User-Agent: Microsoft-MacOutlook/10.10.5.181209
Date: Thu, 10 Jan 2019 12:24:24 +0100
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Adam Roach <adam@nostrum.com>, The IESG <iesg@ietf.org>
CC: draft-ietf-v6ops-transition-ipv4aas@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org
Message-ID: <355A2033-7CF0-4B4F-B9AA-22D81D8C8FF3@consulintel.es>
Thread-Topic: [v6ops] Adam Roach's No Objection on draft-ietf-v6ops-transition-ipv4aas-12: (with COMMENT)
References: <154710474949.4881.472024069770211091.idtracker@ietfa.amsl.com>
In-Reply-To: <154710474949.4881.472024069770211091.idtracker@ietfa.amsl.com>
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/ti6l4ID4nsyQiWKQH-B8p8F1388>
Subject: Re: [v6ops] Adam Roach's No Objection on draft-ietf-v6ops-transition-ipv4aas-12: (with COMMENT)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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, 10 Jan 2019 11:24:33 -0000

Hi Adam,

I just replied to Ben comments, and I already did to Mirja, so don't think I can add anything else on that point.

I missed the BCP point on the response to Ben, so here is it.

My understanding is that BCP is a "current practices". Some of the considerations in the document are new. No new protocols (that's why is info), but new requirements to put "together" in a CE existing protocols and how to take advantage of "coordinating" them, so the operator can deploy IPv4aaS, or even change from dual-stack to IPv4aaS, or one IPv4aaS technology to another or have different customers with different IPv4aaS technologies, etc.

This means that, for clarity, we have text that may seem redundant if you already know all the details of each of the IPv4aaS technologies, but it makes very easy for an operator to have a single document to "follow the path" in a coherent way.

This is part of the scope of v6ops chapter, providing guidance for the deployment of and operation of new and existing IPv6 networks.

Let me know if this clarify your point on this.

Thanks!

Regards,
Jordi
 
 

-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de Adam Roach <adam@nostrum.com>
Fecha: jueves, 10 de enero de 2019, 8:19
Para: The IESG <iesg@ietf.org>
CC: <draft-ietf-v6ops-transition-ipv4aas@ietf.org>, <v6ops-chairs@ietf.org>, <v6ops@ietf.org>
Asunto: [v6ops] Adam Roach's No Objection on draft-ietf-v6ops-transition-ipv4aas-12: (with COMMENT)

    Adam Roach has entered the following ballot position for
    draft-ietf-v6ops-transition-ipv4aas-12: No Objection
    
    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)
    
    
    Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.
    
    
    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/
    
    
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    I share Ben and Mirja's question about the formal relationship between this
    document and RFC 7084.
    
    I also share Ben's confusion about the document's status as not being a BCP --
    statements like the following are, by my understanding of the term, specifying
    practices that are considered to be "best" at the present time:
    
    * "The IPv6 Transition CE Router MUST implement a DNS proxy as
      described in [RFC5625] (DNS Proxy Implementation Guidelines)."
    
    * "The IPv6 Transition CE Router MUST support the DHCPv6 S46
       priority options described in [RFC8026]."
    
    * "The IPv6 Transition CE Router MUST have a GUI, CLI and/or
       API option to manually enable/disable each of the supported
       transition mechanisms."
    
    If these (and similarly phrased) statements are not recommending best current
    practices, then I don't understand the purpose of this document.
    
    
    _______________________________________________
    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.theipv6company.com
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.