Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 8th

Marcin Siodelski <msiodelski@gmail.com> Wed, 20 July 2016 06:46 UTC

Return-Path: <msiodelski@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E02812D12D for <dhcwg@ietfa.amsl.com>; Tue, 19 Jul 2016 23:46:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Y37LVmXyji3x for <dhcwg@ietfa.amsl.com>; Tue, 19 Jul 2016 23:46:58 -0700 (PDT)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08B512D9B9 for <dhcwg@ietf.org>; Tue, 19 Jul 2016 23:46:57 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id i5so52885845wmg.0 for <dhcwg@ietf.org>; Tue, 19 Jul 2016 23:46:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:references:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=1ibVnrUIwJr0i2j25Y/p63W9zUCmtQrz5cVGBYTFp1w=; b=taSHCI3DM5g/sNPrcWVvhJpMGFN3CojP6eb8W6lwK/rh+YMHIRT886dwk+FT52r5ps ZHMwxBA5D99OkD9ePhBC0Qbqnx5vZT76KbZN+KRhC377K3eUWPT7ef2jBPWiX9izwYTO m++GsHRKb05W5lBc1+5Zv/mKlkJ814RXCT4HPrDeD1PQKLm05l6hVPDZAW89G11ozhI+ lGwGK/cWuC/cYDVqE4s2UQF/OlYbjy5DtYjWWyka9W7vRt99gVFmoN7lCf1Z4iQBeIVR oVROddhRll6VJien0ePZcxzha3HnWQ3as3uKFYzE7DYqdjoI4H2+tmQCaqJkinsArwhh 4wJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:references:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=1ibVnrUIwJr0i2j25Y/p63W9zUCmtQrz5cVGBYTFp1w=; b=GBt1A3AZV1b6k8IgBRo0+P0ik6gVHTwzcrD9pNML+kV9C2Zec4JOAXGFUKBmaw0/X0 Z/NeyNZKd7rl5htQ/UrZ8wxNQDqkyAvzCJeck+wt6ziqggdp8RPW3jkdOM1VpnMrmLhK VSI2ca7D1IQkS1cE4IZTwDu85buMRyrWg9Z7BDRPLIOx7zarlD2u/Jn4Dm4rdqJV9lMC VmPWlSt2Q69iyf3jfs1Imgp/6HSE9pWzxQLH4If4xdzqAmxeYRghs08GirxdknV4Ke6Z Ce0hIZ6LxYaY737CDEGDNdPPvxcq9p1rU4VpU51P58Z/PohnjZX6il21isNrkm50Nuaw MUGA==
X-Gm-Message-State: ALyK8tJEKeR7KN7ZvtDQExizkPPrIe/dQifQ+nxtf+4gA+hDDrtX3cyWMYzsSH6USbH5ug==
X-Received: by 10.28.69.14 with SMTP id s14mr9642227wma.49.1468997215901; Tue, 19 Jul 2016 23:46:55 -0700 (PDT)
Received: from dhcp-b3ee.meeting.ietf.org ([2001:67c:370:176:68cc:9749:f64c:fd7e]) by smtp.gmail.com with ESMTPSA id 207sm29499376wmb.7.2016.07.19.23.46.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jul 2016 23:46:55 -0700 (PDT)
From: Marcin Siodelski <msiodelski@gmail.com>
To: Lorenzo Colitti <lorenzo@google.com>
References: <577FDCCE.5090107@gmail.com> <CAKD1Yr16-awybeDPHjk7uRkesDtn8UfDewJ9_AwA3uxzR3KjhQ@mail.gmail.com>
Message-ID: <54cb972a-7fe3-0637-f6b1-7ac01ec794ef@gmail.com>
Date: Wed, 20 Jul 2016 08:46:55 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAKD1Yr16-awybeDPHjk7uRkesDtn8UfDewJ9_AwA3uxzR3KjhQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/WKaHUs89uqEywv9pZrNzxAwzegY>
Cc: dhcwg <dhcwg@ietf.org>, draft-ietf-v6ops-host-addr-availability@tools.ietf.org
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 8th
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jul 2016 06:46:59 -0000

On 20.07.2016 08:33, Lorenzo Colitti wrote:
> On Fri, Jul 8, 2016 at 7:03 PM, Tomek Mrugalski
> <tomasz.mrugalski@gmail.com <mailto:tomasz.mrugalski@gmail.com>> wrote:
>
>     This call initiates the working group last call
>     on draft-ietf-dhc-rfc3315bis-05 [1].
>
>
> rfc3315bis is written to assume that a client requesting a prefix via
> DHCPv6 prefix delegation is a router. The term "requesting router" is
> used throughout. But it is useful to delegate prefixes to hosts, as well.
>
> For example, draft-templin-aerolink and draft-herbert-nvo3-ila and
> draft-ietf-v6ops-unique-ipv6-prefix-per-host all mention assigning a /64
> prefix to a host. But because RFC3315 still talks about "requesting
> router", when we wrote draft-ietf-v6ops-host-addr-availability (now in
> AUTH48) we had to say:
>
>       While [RFC3633] assumes that the DHCPv6 client is a router, DHCPv6
>       PD itself does not require that the client forward IPv6 packets
>       not addressed to itself, and thus does not require that the client
>       be an IPv6 router as defined in [RFC2460].  Also, in many cases
>       (such as tethering, or hosting virtual machines), hosts are
>       already forwarding IPv6 packets and thus operating as IPv6 routers
>       as defined in [RFC2460].
>
> In 3315bis, can we use another term instead of "requesting router"?
> "Client"? "Requesting node"?
>

After merging RFC3633 into the RFC3315, many of the sections (in
particular those talking about the messages transmission and reception)
include common text for processing IA_NAs and IA_PDs and they use the
term "Client" (as it used to be in original RFC3315) for an entity that
can request addresses and prefixes. Hence, I'd suggest we continue using
the term "Client" where possible, which probably also means replacing
some of 72 occurrences of "delegating router". Perhaps we should also
update section "5.3.  DHCP for Prefix Delegation" to say that prefix
delegation is a mechanism that can be used to provide prefixes to
routers but also hosts.

Marcin