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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Mon, 14 January 2019 09:57 UTC

Return-Path: <prvs=1917413931=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 CFE2D130FC4; Mon, 14 Jan 2019 01:57:01 -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 uuPihGBCPqX8; Mon, 14 Jan 2019 01:56:59 -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 7528812896A; Mon, 14 Jan 2019 01:56:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1547459816; x=1548064616; 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=SfABPpnWlhkGjd1lfhyYh+vKrujnOZ/DeRzc/1oqYWI=; b=kinefhtksbtP3 bm8LpBUdkphRTj/sjbY2alAW0McQiV0eLV3MPez1UBK76dcjWdrdKD0zE39ijv3S GKUwMuKUj2yAdEOj6jJsKZbJEKqmsFTpkAarfjGA8pa2gsvoQKap0RhxvuHuWSqm wsyNjrHLNUpRUWSizqLt7PiAQo3Chw=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Mon, 14 Jan 2019 10:56:56 +0100
X-Spam-Processed: mail.consulintel.es, Mon, 14 Jan 2019 10:56:56 +0100
Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006110207.msg; Mon, 14 Jan 2019 10:56:55 +0100
X-MDRemoteIP: 2001:470:1f09:495:11dc:eed9:dd0f:218c
X-MDHelo: [10.10.10.139]
X-MDArrival-Date: Mon, 14 Jan 2019 10:56:55 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1917413931=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
User-Agent: Microsoft-MacOutlook/10.10.5.181209
Date: Mon, 14 Jan 2019 10:56:54 +0100
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: draft-ietf-v6ops-transition-ipv4aas@ietf.org, v6ops-chairs@ietf.org, The IESG <iesg@ietf.org>, v6ops@ietf.org
Message-ID: <CD046FFE-A7B8-428F-A70F-8CCB0C92F074@consulintel.es>
Thread-Topic: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and COMMENT)
References: <154713179023.30772.10696284348809827591.idtracker@ietfa.amsl.com> <16C30688-747B-4723-BBD7-FF82FCAA6A26@consulintel.es> <20190110223633.GS28515@kduck.mit.edu> <35F9A19F-DC78-470F-B104-3BA764508D09@consulintel.es> <20190111212500.GQ28515@kduck.mit.edu>
In-Reply-To: <20190111212500.GQ28515@kduck.mit.edu>
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/QvMW4mv-gwxAiIV607qOiSkidP4>
Subject: Re: [v6ops] Benjamin Kaduk'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: Mon, 14 Jan 2019 09:57:02 -0000

Thanks Bejamin,

I just uploaded a new version resolving all the discuss and comments.

Regards,
Jordi
 
 

-----Mensaje original-----
De: Benjamin Kaduk <kaduk@mit.edu>
Fecha: viernes, 11 de enero de 2019, 22:25
Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
CC: <draft-ietf-v6ops-transition-ipv4aas@ietf.org>, <v6ops-chairs@ietf.org>, The IESG <iesg@ietf.org>, <v6ops@ietf.org>
Asunto: Re: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and COMMENT)

    On Fri, Jan 11, 2019 at 11:51:57AM +0100, JORDI PALET MARTINEZ wrote:
    > Hi Benjamin,
    > 
    > Responses below, in-line.
    > 
    > Regards,
    > Jordi
    >  
    >  
    > 
    > -----Mensaje original-----
    > De: Benjamin Kaduk <kaduk@mit.edu>
    > Fecha: jueves, 10 de enero de 2019, 23:36
    > Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
    > CC: The IESG <iesg@ietf.org>, <draft-ietf-v6ops-transition-ipv4aas@ietf.org>, <v6ops-chairs@ietf.org>, <v6ops@ietf.org>
    > Asunto: Re: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and COMMENT)
    > 
    >     On Thu, Jan 10, 2019 at 05:43:32PM +0100, JORDI PALET MARTINEZ wrote:
    >     > Hi Benjamin,
    >     > 
    >     > Thanks again for your detailed review.
    >     > 
    >     > I'm already working in a draft for a new version including all the nits that you mention (some already were corrected in -13).
    >     > 
    >     > Some clarifications to some of your comments.
    >     >  
    >     >     Section 3.2
    >     >     
    >     >        TRANS-2:  The IPv6 Transition CE Router MUST have a GUI, CLI and/or
    >     >                  API option to manually enable/disable each of the supported
    >     >                  transition mechanisms.
    >     >     
    >     >     Do we really need to pick and name interfaces, or can we just say "MUST
    >     >     have a configuration interface"?
    >     > 
    >     > Yes, the point here is to make sure that at least there is a GUI and CLI (or API). The idea is that the customer is able to buy a CE and later on use it in a different ISP. So, having both facilitate that, even in the case of a manual configuration required by the user. Normally DHCP-based mechanisms should do it, and also is currently very common that both are already supported, so not a big issue.
    >     
    >     Er, do you require both GUI and CLI, or not?  The current text only
    >     requires at least one.  (But yes, I agree it's common to support both
    >     already, so this is not likely to be a burdensome requirement.)
    >  
    > Yes, the idea is "GUI and CLI" or "GUI and API" or all them. I was reading that correctly, but may be (once more) is a problem between Spanish-English ...
    > 
    > What about:
    > "The IPv6 Transition CE Router MUST have a GUI and either a CLI or API (or both) to manually enable/disable each of the supported transition mechanisms."
    
    That says what you want, yes.
    
    >     >     
    >     >     Section 3.2.1
    >     >     
    >     >                                                      If 464XLAT is
    >     >        supported, it MUST be implemented according to [RFC6877].  [....]
    >     >     
    >     >     Do we want to consider adding "or a successor document"?
    >     > 
    >     > I think if we do that, we could need doing that for every RFC ... that's why we have documents updating previous ones, so I don't think so.
    >     
    >     Well, another alternative is (as Ben suggests) to just not include this
    >     sentence at all.  Which would of course also address my point here :)
    > 
    > We have this text for every transition mechanism. The transition mechanisms have "2/3" pieces. One is the transition mechanism itself, another one is what is needed in the operator network, and then what is needed in the CE. I think for clarity, even if looks like a repetition, we decided to keep using the same wording on this that was used in RFC7084.
    > 
    > For example, DS-Lite is the mechanism, AFTR is the operator part, B4 is the CE part. If you look at the text (section 3.2.2), we are referring first to the overall DS-Lite, then we say that the CE must implement the B4 following what is said about that in the RFC.
    > 
    > I still believe is good to keep that way.
    
    Well, this is a non-blocking comment, so I can't get in your way.
    
    -Benjamin
    



**********************************************
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.