Re: [v6ops] Alissa Cooper's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and COMMENT)

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Thu, 10 January 2019 14:53 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 1185F130F1D; Thu, 10 Jan 2019 06:53:06 -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 KBAynxC5mvbM; Thu, 10 Jan 2019 06:53:03 -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 967D7130F1A; Thu, 10 Jan 2019 06:53:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1547131980; x=1547736780; 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=Pip62aIAB2JhyzXYr/YexAtC793dlq/Xu2gVAIHpM2c=; b=ihN7ss3SGrFfi 45UdbNhPiD46dtS+hKHwmC+GLkYnttJj3Y5L0eTj3YT+ZkeT9w+We6JLcnaSPRFD /2KMuvDhR0koc3MBGbuSKulqSrTgprQy2U/tvUtLya19bmxzk4a4YDDqASz2IH6O LxayG873Y/fdQCRJRiK8Kno5cvOZYo=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Thu, 10 Jan 2019 15:53:00 +0100
X-Spam-Processed: mail.consulintel.es, Thu, 10 Jan 2019 15:53:00 +0100
Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006104871.msg; Thu, 10 Jan 2019 15:52:59 +0100
X-MDRemoteIP: 2001:470:1f09:495:fcec:f8ce:9c9f:fd05
X-MDHelo: [10.10.10.140]
X-MDArrival-Date: Thu, 10 Jan 2019 15:52:59 +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 15:52:59 +0100
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Alissa Cooper <alissa@cooperw.in>, The IESG <iesg@ietf.org>
CC: draft-ietf-v6ops-transition-ipv4aas@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org
Message-ID: <2D4CAEDC-F02F-4BEB-8D80-DB0B461B6D30@consulintel.es>
Thread-Topic: [v6ops] Alissa Cooper's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and COMMENT)
References: <154713136049.30772.14214762331468539097.idtracker@ietfa.amsl.com>
In-Reply-To: <154713136049.30772.14214762331468539097.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/YlsD0q9-VE-YV7MpZbUZ7WSYrWA>
Subject: Re: [v6ops] Alissa Cooper's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and 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 14:53:06 -0000

Hi Alissa,

Thanks for the review.

See my inputs below, in-line.

Regards,
Jordi
 
 

-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de Alissa Cooper <alissa@cooperw.in>
Fecha: jueves, 10 de enero de 2019, 15:43
Para: The IESG <iesg@ietf.org>
CC: <draft-ietf-v6ops-transition-ipv4aas@ietf.org>, <v6ops-chairs@ietf.org>, <v6ops@ietf.org>
Asunto: [v6ops] Alissa Cooper's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and COMMENT)

    Alissa Cooper has entered the following ballot position for
    draft-ietf-v6ops-transition-ipv4aas-13: Discuss
    
    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/
    
    
    
    ----------------------------------------------------------------------
    DISCUSS:
    ----------------------------------------------------------------------
    
    (1) I think the standard RFC 8174 boilerplate is needed here. I think it was a
    mistake to use the 2119 keywords differently in RFC 7084, and that mistake need
    not be repeated. This document uses the normative keywords in the same ways as
    many other informational documents. RFC 2119 is not focused on
    interoperability, but rather on the requirements that the specification using
    the keywords is laying out.
    
    (2) I don't think it is appropriate for this document to defined a new
    normative keyword, "DEFAULT," in Section 1.1. The right place to do that would
    be an update to RFC 2119 or RFC 8174. This is especially problematic given that
    the one place in this document where it is used, it is in a paragraph that also
    uses other normative keywords. Since it's only used once, I would suggest just
    explaining what it means in that location (3.2.2) rather than defining it as a
    keyword.
    

I've no problem in proceeding as you indicated in (1) and (2) above.

    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    == Section 1 ==
    
    OLD
    This
       ensures that remote IPv4-only services continue to be accessible,
       from an IPv6-only Internet Service Provider access network (typically
       referred as WAN - Wide Area Network, even if in some cases it may be
       metropolitan, regional, etc.), from both, IPv4-only and IPv6-only
       applications or devices in the LAN side.
    
    NEW
    This ensures that remote IPv4-only services continue to be accessible
       from an IPv6-only Internet Service Provider (ISP) access network from both
       IPv4-only and IPv6-only applications and devices on the LAN side. These ISP
       access networks are typically referred to as Wide Area Networks (WANs), even
       if in some cases they may be metropolitan or regional.
    
    (Then you could deleted the parenthetical "(Internet Service Providers)" in the
    sentence below Figure 1.)

Thanks, this looks much better.
    
    It seems odd that Figure 1 appears in Section 1 but isn't referenced in the
    text until Section 12. I think you need a sentence in this section to describe
    what is depicted in the figure or why it is there, or you need to remove the
    figure.

Right, I think this is something that is related to the xml editor, and didn't realized that. The reference in section 12 is for Figure 2, not Figure 1 ... So it was incorrectly renumbered.
    
    s/devices or applications/devices and applications/
    
    == Section 3.2 ==
    
    s/an automated IPv6 transition mechanism provisioning/automated IPv6 transition
    mechanism provisioning/
    
    s/per interface/per interface/
    
    Would suggest dropping "(which may depend on each transition mechanism)" since
    it makes the sentence confusing and doesn't add anything.
    
    == Section 3.2.1 ==
    
    OLD
    If DNS64
       [RFC6147] is not used, or not trusted, as the DNS configuration at
       the CE (or hosts behind the CE) may be modified by the customer, then
       the service provider may opt to configure the NAT64 prefix either by
       means of [RFC7225] or [RFC8115], which also can be used if the
       service provider uses DNS64 [RFC6147].
    
    NEW
    It may be the case that the service provider does not use or does not trust
    DNS64 [RFC6147] because the DNS configuration at the CE (or hosts behind the
    CE) may be modified by the customer. In that case, the service provider may opt
    to configure the NAT64 prefix either by means of [RFC7225] or [RFC8115]. These
    can also be used if the service provider uses DNS64.
    
    == Section 7 ==
    
    I would suggest starting this section with "At the time of this writing, ..."
    
    == Section 12 ==
    
    The text that refers to Figure 1 I think is meant to refer to Figure 2. Or if
    not, text is needed to describe Figure 2.
    
Right, all the precented changes look fine to me.

Thanks!    
    _______________________________________________
    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.