IETF Logo Mail Archive

Re: [dhcwg] I-DAction:draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt

Shwetha <shwethab@cisco.com> Tue, 27 September 2011 02:24 UTC

Return-Path: <shwethab@cisco.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 5FD2E21F8CE2 for <dhcwg@ietfa.amsl.com>; Mon, 26 Sep 2011 19:24:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.901
X-Spam-Level:
X-Spam-Status: No, score=-9.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAcVTg0IdIbv for <dhcwg@ietfa.amsl.com>; Mon, 26 Sep 2011 19:24:03 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id D184921F8CD6 for <dhcwg@ietf.org>; Mon, 26 Sep 2011 19:24:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shwethab@cisco.com; l=6720; q=dns/txt; s=iport; t=1317090407; x=1318300007; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=Zj9hoBbocEUF58hf9DfzKuxZBRHEcHdBSKGPs0HtItQ=; b=SOgH1iFrCQ5tVjI9zn5qeItHe9m1GCEeKZ5RRj3suoTpkko535ujKhhQ L7VbtWPjkah9bagAMzXJORRbEQ7ZCjzynPjmVBiOzMGI/kqqOe7xrNiz0 ya5/vLdkQm7FFZHXfVJVUHgwT5JFMhRA2SQeBwlsClqVGgkqCjK8Sq5b1 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArgAACU0gU5Io8UT/2dsb2JhbAA4BwOYaY4cb3iBTAcBAQEBAgEBAQEPASkBMQsFBwYBCBEDAQEBARQTLh8JBwEBAQEDAQoDBQkZh1YGmwABnlqDYQoQgxAEh0IuhGCHAoUri0NO
X-IronPort-AV: E=Sophos;i="4.68,447,1312156800"; d="scan'208";a="56292971"
Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 27 Sep 2011 02:26:45 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8R2QiEL004726; Tue, 27 Sep 2011 02:26:44 GMT
Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Sep 2011 07:56:44 +0530
Received: from 10.65.75.192 ([10.65.75.192]) by XMB-BGL-417.cisco.com ([72.163.129.213]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Sep 2011 02:26:44 +0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Tue, 27 Sep 2011 07:59:08 +0530
From: Shwetha <shwethab@cisco.com>
To: "Bernie Volz (volz)" <volz@cisco.com>, Andre Kostur <akostur@incognito.com>, "Prashant Jhingran (pjhingra)" <pjhingra@cisco.com>
Message-ID: <CAA732CC.24F10%shwethab@cisco.com>
Thread-Topic: [dhcwg] I-DAction:draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt
Thread-Index: Acx8YK/5aLJmwdAGTzyfr5jbPjHUUAAHyDwgAAAQYFAAD0pVgA==
In-Reply-To: <D9B5773329187548A0189ED650366789092D9744@XMB-RCD-101.cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-OriginalArrivalTime: 27 Sep 2011 02:26:44.0907 (UTC) FILETIME=[E675AFB0:01CC7CBC]
Cc: dhcwg@ietf.org, "Wojciech Dec (wdec)" <wdec@cisco.com>
Subject: Re: [dhcwg] I-DAction:draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 27 Sep 2011 02:24:04 -0000

Thanks for the review.

> Regarding Section 6, I wonder whether it is wise to recommend that the server
> first look at the client's message and then the relay's. Which do you think is
> more trustworthy? I certainly would at least change the "it MUST first" to a
> SHOULD. You could always add a discussion that indicates that in some
> situations it may be preferable to use the Relay's information over the
> client's. For example, with DOCSIS 3.0, we really trust the relay's
> information (if the client's matches, the client is considered a Cable Modem
> (CM) - if not, it probably isn't a 'valid' CM).

Yes, it makes sense, we will update the draft.

Thanks,
Shwetha 


On 9/27/11 12:42 AM, "Bernie Volz (volz)" <volz@cisco.com> wrote:

> Ignore the comment:
> 
> "Why the prohibition against a "DHCPv6 LDRA" adding this information? Seems
> that in that environment the relay could never provide it as the 2nd hop relay
> would likely not have the information and it isn't the first hop either."
> 
> I had misread this part.
> 
> - Bernie
> 
> -----Original Message-----
> From: Bernie Volz (volz)
> Sent: Monday, September 26, 2011 3:10 PM
> To: 'Andre Kostur'; Prashant Jhingran (pjhingra)
> Cc: dhcwg@ietf.org
> Subject: RE: [dhcwg]
> I-DAction:draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt
> 
> Had just sent this to the authors but probably best I include the DHC WG too
> ...
> 
> FYI - You include a reference for RFC 4580 and RFC 4361 but never use either
> of these.
> 
> Regarding Section 6, I wonder whether it is wise to recommend that the server
> first look at the client's message and then the relay's. Which do you think is
> more trustworthy? I certainly would at least change the "it MUST first" to a
> SHOULD. You could always add a discussion that indicates that in some
> situations it may be preferable to use the Relay's information over the
> client's. For example, with DOCSIS 3.0, we really trust the relay's
> information (if the client's matches, the client is considered a Cable Modem
> (CM) - if not, it probably isn't a 'valid' CM).
> 
> Why the prohibition against a "DHCPv6 LDRA" adding this information? Seems
> that in that environment the relay could never provide it as the 2nd hop relay
> would likely not have the information and it isn't the first hop either.
> 
> - Bernie
> 
> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of
> Andre Kostur
> Sent: Monday, September 26, 2011 11:26 AM
> To: Prashant Jhingran (pjhingra)
> Cc: dhcwg@ietf.org
> Subject: Re: [dhcwg]
> I-DAction:draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt
> 
> I've read the draft and I think it could be useful on the
> client-initated messages.   How does this interact with the Remote ID
> (RFC 4580).  Does it make sense that the option means "this device's
> MAC addr" when in everything but a Relay-Forward, and "the relayed
> devices's MAC addr" when in a Relay-Forward?   Why not leave this
> option as the device's MAC address (which could theoretically allow
> the relay agent to mention its own MAC addr for whatever reason), and
> let the Remote ID continue to be used to identify the downstream
> device.  Which could be the client's MAC address.  Configurable on the
> relay agent as to what it wants to populate the remote ID with.
> 
> 
> On Mon, Sep 26, 2011 at 08:18, Prashant Jhingran (pjhingra)
> <pjhingra@cisco.com> wrote:
>> 
>> +1 ...very useful from both BB & Enterprise perspective.
>> 
>> PS: Perhaps can be elaborated by few topology diagrams
>> 
>> -
>> Regards,
>> Prashant Jhingran
>> 
>> 
>> -----Original Message-----
>> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf
>> Of Chuck Anderson
>> Sent: Monday, September 26, 2011 5:37 PM
>> To: Gaurav Halwasia (ghalwasi)
>> Cc: dhcwg@ietf.org; Wojciech Dec (wdec)
>> Subject: Re: [dhcwg] I-DAction:
>> draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt
>> 
>> I've read and support this draft for adoption by the wg.
>> 
>> Thanks,
>> Chuck
>> 
>> On Mon, Sep 26, 2011 at 01:12:51PM +0530, Gaurav Halwasia (ghalwasi)
>> wrote:
>>> Hello All,
>>> 
>>> We have submitted this draft to define hardware address option in
>> DHCPv6
>>> messages. Please review the same and provide us with your feedback.
>>> 
>>> We would also request dhc wg to consider adoption of this draft as a
>> wg
>>> draft.
>>> 
>>> Thanks,
>>> Gaurav
>>> 
>>> From: <internet-drafts@ietf.org>
>>> Reply-To: <internet-drafts@ietf.org>
>>> Date: Sun, 25 Sep 2011 23:07:05 -0700
>>> To: <i-d-announce@ietf.org>
>>> Subject: I-D Action:
>> draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> 
>>>  Title           : Client Hardware Address Option in DHCPv6
>>>  Author(s)       : Gaurav Halwasia
>>>                           Shwetha Bhandari
>>>                           Wojciech Dec
>>>  Filename        : draft-halwasia-dhc-dhcpv6-hardware-addr-opt-00.txt
>>>  Pages           : 6
>>>  Date            : 2011-09-25
>>> 
>>>    This document specifies the format and mechanism that is to be used
>>>    for encoding client hardware address in DHCPv6 messages by defining
>> a
>>>    new DHCPv6 Client Hardware Address option.
>>> 
>>> 
>>> 
>>> A URL for this Internet-Draft is:
>>> 
>>> 
>> http://www.ietf.org/internet-drafts/draft-halwasia-dhc-dhcpv6-hardware-a
>>> ddr-opt-00.txt
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> This Internet-Draft can be retrieved at:
>>> 
>> ftp://ftp.ietf.org/internet-drafts/draft-halwasia-dhc-dhcpv6-hardware-ad
>>> dr-opt-00.txt
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> 
> 
> --
> Andre Kostur
> Senior Product Design Engineer
> P: 604-678-2864
> E: akostur@incognito.com
> Toll-Free: 1-800-877-1856
> 
> 
> F: 604-678-2864
> VoIP: sip:864@sip.incognito.com
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

v2.23.0 | Report a Bug | By Email