Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-slap-quadrant-00.txt
CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> Sun, 10 March 2019 16:07 UTC
Return-Path: <cjbc@it.uc3m.es>
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 1DCB61240D3 for <dhcwg@ietfa.amsl.com>; Sun, 10 Mar 2019 09:07:45 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.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 UaB00CfchlHQ for <dhcwg@ietfa.amsl.com>; Sun, 10 Mar 2019 09:07:40 -0700 (PDT)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 4AD591277DE for <dhcwg@ietf.org>; Sun, 10 Mar 2019 09:07:40 -0700 (PDT)
Received: by mail-ed1-x52d.google.com with SMTP id m35so1912349ede.10 for <dhcwg@ietf.org>; Sun, 10 Mar 2019 09:07:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=twJQUsYx94Ip8I9OUQTGSDdxAJu7aQHCvdFfSRh7pUU=; b=B81mPOq5PmLiKcjx5Da33FO2EbxHwuUXUlfRvZEbrjzqy5cNf2RqcY9EtmXuZb05qM jyUstRKqwx2gO4C8QjVO7VkrVWVsMlD0H/XGWysqLIQoKa32412OpWvRReEx8wGCw/f9 /z5PcHglt6OhVt17ThMjI0MYuecXYO/j+NelliGlKZ8JAhmzhSEVd6bg6KPVBE5rD7fr zRKhnP29wrMIm1B9+XZ3DTZxb+Xon/uXuIslpa6JYRQgQ7GiL6jFcYyFJa8A8KEcTHoc boZpoqzUvkel/yk6nBm6RVv1VxEKuryoFcJsAOpTo2Y9pMQ9OSdcjdz0ZX7cBKMBi2hs TYeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=twJQUsYx94Ip8I9OUQTGSDdxAJu7aQHCvdFfSRh7pUU=; b=GyMP2UXz2q0lreHM4QCdS+X5R1LI7nTRD7P9RF4Dz6/RjZ677W9IXRyQQCfCuksETn nSiUZZxs50vmy1wlJWAfD2iPGKPMd8qRow/XwD4OkR7GQ4/xvBwPtEnhikMlU02qG17C gGjYN357OjQgrdjPnm1DuwhJgOO6sgFYlaYb4BaxKSsE29YfLYZWxFGwdcv2vcOdlSSq aPhHvsCQlEo4h926O4VkkimvbkjgJGCUdtDXXqPW6mrNQa5eMsm3fBTODV0DUwZzUD4T rFp21Yp2Rs/SF46bXfj0LoFYB4pvI9C5uPWhoQsR/c3zjsHXyUNMykU94Ho26UGJTlqs 7nfw==
X-Gm-Message-State: APjAAAV+5TtaLI0v6ZjXu4FT79J3N7pj6ClrqHPMB2Fd0788msHBX6vG klEsKiBcogjXIYsWEK9TAHIVkoJDBHLM4yj0LbDi5Q==
X-Google-Smtp-Source: APXvYqzThbhhfZZMgcj/zsjr9CcOIY6zk38+j1RVLtX8+62tx7xySgFiuHmdQ6guuxaJjn5kVcJwD1ySzDN+fyc1i9Q=
X-Received: by 2002:a50:eb88:: with SMTP id y8mr5388190edr.262.1552234058224; Sun, 10 Mar 2019 09:07:38 -0700 (PDT)
MIME-Version: 1.0
References: <154874417588.3009.15379484544595638729@ietfa.amsl.com> <CALypLp_CuX33xKaNPhh2aAsDm52puM2fSGRXPGZLVD5g-dFgyA@mail.gmail.com> <6fecdfca802247268613ec1896ce21b9@XCH-ALN-003.cisco.com> <CALypLp_N1UyhVUi7r2t4Z_ZTn+4bqRMqXYm1W8jjuzhwUmzDEw@mail.gmail.com> <DABF61D8-C817-4E19-A5EE-F59F39E84789@cisco.com> <CALypLp_zxKsrfp2FO8qSqtECxC9q919NcAx-PM_5wCKtKp9S1A@mail.gmail.com>
In-Reply-To: <CALypLp_zxKsrfp2FO8qSqtECxC9q919NcAx-PM_5wCKtKp9S1A@mail.gmail.com>
From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Date: Sun, 10 Mar 2019 17:07:21 +0100
Message-ID: <CALypLp-0zse=6SxzOBWJY3deaXNV0XtnNZ-G1FyObSrpO-K+vw@mail.gmail.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a635620583bfa709"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/a6g6MhjLWAoI9bg4jrJhva1zswc>
Subject: Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-slap-quadrant-00.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 10 Mar 2019 16:07:45 -0000
Hi, We've posted a revision of the draft addressing the comments received. Additional comments are more than welcome. Thanks! Carlos On Mon, Feb 4, 2019 at 8:00 PM CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> wrote: > Thanks Bernie! > > Carlos > > On Mon, Feb 4, 2019 at 7:53 PM Bernie Volz (volz) <volz@cisco.com> wrote: > >> Great. See one response to your question (BV2). >> >> >> >> - Bernie >> >> >> >> *From: *CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> >> *Date: *Monday, February 4, 2019 at 1:37 PM >> *To: *Bernie Volz <volz@cisco.com> >> *Cc: *"dhcwg@ietf.org" <dhcwg@ietf.org> >> *Subject: *Re: [dhcwg] Fwd: I-D Action: >> draft-bernardos-dhc-slap-quadrant-00.txt >> >> >> >> Hi Bernie, >> >> >> >> Thanks a lot for your comments. Please see inline below. >> >> >> >> >> >> On Wed, Jan 30, 2019 at 7:42 PM Bernie Volz (volz) <volz@cisco.com> >> wrote: >> >> Hi: >> >> >> >> Below are some comments on this new individual submission draft: >> >> >> >> Abstract >> >> … >> >> >> >> The IEEE is working on mechanisms to allocate addresses in the one of >> >> these quadrants (IEEE 802.1CQ). There is work also in the IETF >> >> working on specifying new mechanism that extends DHCPv6 operation to >> >> BV> drop “working”, redundant? And, add “a” – specifying a new >> >> >> >> CB> Thanks. We'll fix this. >> >> >> >> handle the local MAC address assignments. In this document, we >> >> complement this IETF work by defining a mechanism to allow choosing >> >> the SLAP quadrant to use in the allocation of the MAC address to the >> >> requesting terminal/client. >> >> >> >> This document proposes extensions to DHCPv6 protocols to enable a >> >> DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant >> >> to the server, so that the server allocates correspondingly the MAC >> >> address to the given client or relay. >> >> BV> This correspondingly is a big awkward and the address(es) are always >> >> BV> allocated to the client, not the relay. Perhaps “so that the server >> >> BV> allocates the MAC address to the given client out of the quadrant >> >> BV> requested by relay or client”. I would assume relay’s should “win”? >> >> >> >> CB> Thanks for the proposal. It's definitely better than the original >> text. We'll update. >> >> >> >> >> >> … >> >> 1.1. Problem statement >> >> >> >> The IEEE is working on mechanisms to allocate addresses in the SAI >> >> quadrant (IEEE 802.1CQ project). There is also ongoing work in the >> >> IETF [I-D.bvtm-dhc-mac-assign] specifying new mechanism that extends >> >> BV> Add a – specifying a new >> >> >> >> CB> OK! >> >> >> >> DHCPv6 operation to handle the local MAC address assignments. In >> >> this document, we complement ongoing IETF work with mechanisms to >> >> BV> Add this - we complement this ongoing >> >> >> >> CB> OK! >> >> >> >> allow choosing the SLAP quadrant to use in the allocation of the MAC >> >> address to the requesting terminal/client. This document proposes >> >> extensions to DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 >> >> relay to indicate a preferred SLAP quadrant to the server, so that >> >> the server allocates correspondingly the MAC address to the given >> >> client or relay. >> >> BV> See Abstract comment. >> >> >> >> CB> OK! >> >> >> >> >> >> … >> >> >> >> 1.1.1. WiFi terminals >> >> >> >> Today, most of WiFi terminals come with interfaces that have a >> >> BV> Drop of – most WiFi terminals (perhaps devices may be better than >> >> BV> terminals – if changed, you need to do throughout) >> >> >> >> CB> OK, I'll replace interfaces with terminals in all the document. >> >> >> >> "burned" MAC address, allocated from the universal address space >> >> BV> “burned in”? >> >> >> >> CB> OK, thanks. >> >> >> >> … >> >> >> >> 1.1.2. Hypervisor: migratable vs non-migratable functions >> >> … >> >> >> >> o Migratable functions. If a VM (providing a given function) might >> >> need to be potentially migrated to another region of the data >> >> center (due to maintenance, resilience, end-user mobility, etc.) >> >> it is needed that this VM can keep its networking context in the >> >> new region, and this includes keeping its MAC addresses. >> >> Therefore, this makes better to allocate addresses from the ELI/ >> >> BV> “this makes better” is odd wording. “Therefore, for this case, it is >> better”? >> >> >> >> CB> OK, thanks. >> >> >> >> SAI SLAP quadrant, which can be centrally allocated by the DHCP >> >> server. >> >> >> >> o Non-migratable functions. If a VM will not be migrated to another >> >> region of the data center, then there are no requirements >> >> BV> can drop then. >> >> >> >> CB> OK! >> >> >> >> associated to its MAC address, and then it is more efficient to >> >> allocate it from the AAI SLAP quadrant, which does not need to be >> >> same for all the data centers (i.e., each region can manage its >> >> own, without checking for duplicates globally). >> >> >> >> 2. Terminology >> >> >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> >> document are to be interpreted as described in [RFC2119]. >> >> BV> Please use latest working for this. For example, see Section 2 of >> RFC8415? >> >> >> >> CB> OK, I'll fix that. >> >> >> >> >> >> >> >> The DHCPv6 terminology relevant to this specification from the DHCPv6 >> >> Protocol [RFC8415] applies here. >> >> >> >> client A device that is interested in obtaining link-layer >> >> addresses. It implements the basic DHCPv6 mechanisms >> >> needed by a DHCPv6 client as described in [RFC8415] and >> >> supports the new options (IA_LL and LLADDR) specified >> >> in this document. The client may or may not support >> >> BV> Isn’t this what is specified in [I-D.bvtm-dhc-mac-assign], not this document? >> >> >> >> CB> Yes, you got me. I think I abused copy & paste :D. I'll fix this. >> Sorry. >> >> >> >> address assignment and prefix delegation as specified >> >> in [RFC8415]. >> >> >> >> server Software that manages link-layer address allocation and >> >> is able to respond to client queries. It implements >> >> basic DHCPv6 server functionality as described in >> >> [RFC8415] and supports the new options (IA_LL and >> >> LLADDR) specified in this document. The server may or >> >> BV> Same issue as above here. >> >> >> >> CB> Same. >> >> >> >> may not support address assignment and prefix >> >> delegation as specified in [RFC8415]. >> >> >> >> … >> >> >> >> 3. Quadrant selection mechanisms >> >> >> >> … >> >> >> >> o Operation/battery lifetime: depending on the expected lifetime of >> >> the terminal a different quadrant might be preferred (as before, >> >> to minimize potential address collisions in the future). The >> >> BV> Shouldn’t a paragraph break go here? This seems to be different >> >> BV> material then operation/battery lifetime? >> >> >> >> CB> Yes, you are right. We'll fix this. >> >> >> >> previous are examples of parameters that an IoT terminal might use >> >> to select a given SLAP quadrant. IoT terminals are typically very >> >> resource constrained, so it might be as well that simple decisions >> >> are just taken, for example based on pre-configured preferences. >> >> >> >> … >> >> >> >> Additionally, the information can also be used to trigger subsequent >> >> changes of MAC address, to enhance location privacy. Besides, >> >> changing the SLAP quadrant used might also be used as an additional >> >> enhancement to make harder to track the user location. >> >> BV> Add it – to make it harder? >> >> >> >> CB> OK! >> >> >> >> >> >> Last, if we consider the data center scenario, an hypervisor might >> >> BV> Change “an” to “a”. >> >> >> >> CB> OK! >> >> >> >> request local MAC addresses to be assigned to virtual machines. As >> >> … >> >> >> >> >> >> +--------+ +--------+ >> >> | DHCPv6 | | DHCPv6 | >> >> | client | | server | >> >> +--------+ +--------+ >> >> | | >> >> +-------1. Solicit(IA_LL(quad))------->| >> >> | | >> >> |<--2. Advertise(IA_LL(LLADDR,quad))--+| >> >> | | >> >> +---3. Request(IA_LL(LLADDR,quad))---->| >> >> | | >> >> |<------4. Reply(IA_LL(LLADDR))--------+ >> >> | | >> >> . . >> >> . (timer expiring) . >> >> . . >> >> | | >> >> +------5. Renew(IA_LL(LLADDR))-------->| >> >> | | >> >> |<-----6. Reply(IA_LL(LLADDR))---------+ >> >> | | >> >> >> >> Figure 3: DHCPv6 signaling flow (client-server) >> >> >> >> 1. Link-layer addresses (i.e., MAC addresses) are assigned in >> >> blocks. The smallest block is a single address. To request an >> >> assignment, the client sends a Solicit message with a IA_LL >> >> option in the message. The IA_LL option MUST contain a LLADDR >> >> option. In order to indicate the preferred SLAP quadrant, the >> >> IA_LL option includes a new quad IA-LL-option, which contains the >> >> preferred quadrant. >> >> >> >> BV> I think you should just use QUAD (for OPTION_QUAD) and the text >> >> BV> should say “the IA_LL option includes the new OPTION_QUAD option >> >> BV> in the IA-LL-option field (with the LLAADR option). >> >> >> >> CB> OK, so you mean to replace for example "Solicit(IA_LL(quad))" with " >> Solicit(IA_LL(QUAD))" and then also fix the text according to your >> suggestion, right? >> >> >> >> BV2> YES. >> >> >> >> >> >> … >> >> >> >> 5. When the assigned addresses are about to expire, the client sends >> >> a Renew message. >> >> >> >> BV> I think the RENEW should also include the QUAD option. If the server >> >> BV> were unable to extend the lifetime on the existing address(es), it >> >> BV> would need to know what quadrant to use for any “new” addresses. >> >> >> >> CB> OK, that makes sense. Thanks for the suggestion. >> >> >> >> … >> >> >> >> 4.2. Address assignment from the SLAP quadrant indicated by the relay >> >> >> >> … >> >> 2. The DHCP relay receives the Solicit message and encapsulates it >> >> in a Relay-forw message. The relay, based on local knowledge >> >> and policies, includes in the Relay Agent Remote-ID Option the >> >> preferred quadrant. The relay might know which quadrant to >> >> request based on local configuration (e.g., the served network >> >> contains IoT devices only, thus requiring ELI/SAI) or other >> >> means such as based on analyzing the Solicit message from the >> >> client. >> >> >> >> BV> Use the QUAD option here to, but it is just added to Relay-Forw >> >> BV> message. Remove the text above about the “Relay Agent Remote-ID >> >> BV> option” and replace “The relay, based on local knowledge and >> >> BV> policies, includes in the Relay-Forw message the QUAD option >> >> BV> with the preferred quadrant.” >> >> >> >> CB> OK. This also makes sense. >> >> >> >> >> >> 3. The server, upon receiving the forwarded Solicit message >> >> including a IA_LL option, inspects its content and decide may >> >> offer an address or addresses for each LLADDR option according >> >> to its policy. The server sends back an Advertise message with >> >> an IA_LL option containing an LLADDR option that specifies the >> >> addresses being offered. This message is sent to the Relay in a >> >> Relay-reply message. If the server supports the semantics of >> >> the preferred quadrant included in the Relay Agent Remote-ID >> >> Option, and manages a block of addresses belonging to the >> >> requested quadrant, then the addresses being offered SHOULD >> >> belong to the requested quadrant. >> >> BV> Here, replace the Relay Agent Remote-ID option with the QUAD option. >> >> >> >> CB> OK. >> >> >> >> >> >> 4. The relay sends the received Advertise message to the client. >> >> >> >> 5. The client waits for available servers to send Advertise >> >> responses and picks one server as defined in Section 18.2.9 of >> >> [RFC8415]. The client then sends a Request message that >> >> includes the IA_LL container option with the LLADDR option >> >> copied from the Advertise message sent by the chosen server. >> >> >> >> 6. The relay forwards the received Request in a Relay-forw message. >> >> It adds in the Relay-forw a quad IA-LL-option with the preferred >> >> quadrant. >> >> BV> See step 2. >> >> >> >> CB> OK. >> >> >> >> … >> >> >> >> >> >> 5. DHCPv6 options definitions >> >> >> >> 5.1. Quad (IA-LL) option >> >> >> >> The quad option is used to specify the preferences for the selected >> >> quadrants within an IA_LL. The option must be encapsulated in the >> >> IA_LL-options field of an IA_LL option. >> >> >> >> BV> And, it can also be in a Relay-Forw message!!! So, “The option must >> >> BV> either be encapsulated in the IA-LL-options field of an IA_LL option >> >> BV> or in a Relay-Forw message in the options field. It MAY also be in >> >> BV> a Relay-Reply if the QUAD option code was specified in a ERO option >> >> BV> [RFC4994]. >> >> >> >> CB> OK, thanks a lot for this and all previous good suggestions. We'll >> include them in the next revision. >> >> >> >> Carlos >> >> >> >> >> >> - Bernie >> >> >> >> *From:* dhcwg <dhcwg-bounces@ietf.org> *On Behalf Of *CARLOS JESUS >> BERNARDOS CANO >> *Sent:* Tuesday, January 29, 2019 2:33 PM >> *To:* dhcwg@ietf.org >> *Subject:* [dhcwg] Fwd: I-D Action: >> draft-bernardos-dhc-slap-quadrant-00.txt >> >> >> >> Hi, >> >> >> >> We have submitted a new draft describing DHCP extensions to allow a >> client/relay specify which SLAP quadrant to use when requesting a MAC >> address/set of addresses. >> >> >> >> Comments are very much appreciated. >> >> >> >> Thanks, >> >> >> >> Carlos >> >> >> >> ---------- Forwarded message --------- >> From: <internet-drafts@ietf.org> >> Date: Tue, 29 Jan 2019 at 07:43 >> Subject: I-D Action: draft-bernardos-dhc-slap-quadrant-00.txt >> To: <i-d-announce@ietf.org> >> >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : SLAP quadrant selection options for DHCPv6 >> Authors : Carlos J. Bernardos >> Alain Mourad >> Filename : draft-bernardos-dhc-slap-quadrant-00.txt >> Pages : 14 >> Date : 2019-01-28 >> >> Abstract: >> The IEEE originally structured the 48-bit MAC address space in such a >> way that half of it was reserved for local use. Recently, the IEEE >> has been working on a new specification (IEEE 802c) which defines a >> new "optional Structured Local Address Plan" (SLAP) that specifies >> different assignment approaches in four specified regions of the >> local MAC address space. >> >> The IEEE is working on mechanisms to allocate addresses in the one of >> these quadrants (IEEE 802.1CQ). There is work also in the IETF >> working on specifying new mechanism that extends DHCPv6 operation to >> handle the local MAC address assignments. In this document, we >> complement this IETF work by defining a mechanism to allow choosing >> the SLAP quadrant to use in the allocation of the MAC address to the >> requesting terminal/client. >> >> This document proposes extensions to DHCPv6 protocols to enable a >> DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant >> to the server, so that the server allocates correspondingly the MAC >> address to the given client or relay. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-bernardos-dhc-slap-quadrant/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-bernardos-dhc-slap-quadrant-00 >> https://datatracker.ietf.org/doc/html/draft-bernardos-dhc-slap-quadrant-00 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> -- >> >> Sent from a mobile device, please excuse any brevity or typing errors. >> >>
- [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-slap… CARLOS JESUS BERNARDOS CANO
- Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-… Bernie Volz (volz)
- Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-… CARLOS JESUS BERNARDOS CANO
- Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-… CARLOS JESUS BERNARDOS CANO
- Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-… Bernie Volz (volz)
- Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-… CARLOS JESUS BERNARDOS CANO
- Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-… CARLOS JESUS BERNARDOS CANO
- Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-… CARLOS JESUS BERNARDOS CANO
- Re: [dhcwg] Fwd: I-D Action: draft-bernardos-dhc-… Bernie Volz (volz)