RE: [dhcwg] dhcpv6 'zone suffix' option
"Bernie Volz" <volz@cisco.com> Wed, 10 November 2004 15:27 UTC
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19813; Wed, 10 Nov 2004 10:27:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRuFX-0007Ub-2C; Wed, 10 Nov 2004 10:19:07 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRuAP-0005KH-7o for dhcwg@megatron.ietf.org; Wed, 10 Nov 2004 10:13:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17350 for <dhcwg@ietf.org>; Wed, 10 Nov 2004 10:13:47 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRuBM-0004Z9-Q7 for dhcwg@ietf.org; Wed, 10 Nov 2004 10:14:50 -0500
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 10 Nov 2004 07:25:06 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAAFD3nC013140; Wed, 10 Nov 2004 07:13:03 -0800 (PST)
Received: from volzw2k ([161.44.65.168]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMX99249; Wed, 10 Nov 2004 10:13:07 -0500 (EST)
From: Bernie Volz <volz@cisco.com>
To: 'Ted Lemon' <Ted.Lemon@nominum.com>, dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6 'zone suffix' option
Date: Wed, 10 Nov 2004 10:13:07 -0500
Organization: Cisco
Message-ID: <000501c4c737$c8b832a0$a8412ca1@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <901AB2B0-3325-11D9-AA52-000A95D6A618@nominum.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: quoted-printable
Cc: 'Mark Stapp' <mjs@cisco.com>
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable
I agree that using a separate option is the best (and we might as well let the author of that separate draft continue that work). This also benefits the case for putting the FQDN in the IA_* options area. About the location of the FQDN option, yeah ... I keep forgetting the complexities involved, since we have to handle client to server and server to client communication and if the option is allowed to appear in multiple places, it gets very messy. For example, if the option were just in the IAADDR options area, many client to server messages don't include any IAADDRs. So, this would force the option to also be allowed in other places (IA_* options or message options). This greatly complicates the client and server processing code. By putting it in the IA_* options, we're restricting it to stateful (PD or NA) but I don't think that's an issue (especially if we don't use it to communicate the zone name). For Information-Request, the separate option can be used to communicate the zone. There's no reason to use the FQDN option for this as the server can't do any updates for the client since it has no idea what the client's addresses are. So, this means that there is NO immediate reason for me to revise draft-ietf-dhc-dhcpv6-fqdn-00.txt. Therefore, PLEASE REVIEW THIS DRAFT and provide me comments -- good and bad -- so we can determine whether to revise it or start the WG Last-Call. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Ted Lemon > Sent: Wednesday, November 10, 2004 9:34 AM > To: Bernie Volz > Cc: dhcwg@ietf.org; 'Mark Stapp' > Subject: Re: [dhcwg] dhcpv6 'zone suffix' option > > > If we're going to use a flag bit, then it's better to just have a > different option that means "this is your zone." It's silly to > overload it with a bit. The format for the options can be > identical, > if it makes sense, but there's no reason to complicate the > option with > control bits. I see your point about putting the option in the IA, > Bernie - that makes sense. I think that's what we talked about > before, although I admit I hadn't mentally made the distinction. > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] dhcpv6 'zone suffix' option Mark Stapp
- Re: [dhcwg] dhcpv6 'zone suffix' option Ted Lemon
- RE: [dhcwg] dhcpv6 'zone suffix' option Bernie Volz
- Re: [dhcwg] dhcpv6 'zone suffix' option Ted Lemon
- RE: [dhcwg] dhcpv6 'zone suffix' option Bernie Volz
- [dhcwg] dhcpv6 source address selection policy op… (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏 )
- Re: [dhcwg] dhcpv6 'zone suffix' option Ted Lemon
- RE: [dhcwg] dhcpv6 'zone suffix' option Bernie Volz
- re: [dhcwg] dhcpv6 'zone suffix' option CTO YAN Renxiang
- RE: [dhcwg] dhcpv6 'zone suffix' option Bernie Volz
- RE: [dhcwg] dhcpv6 'zone suffix' option CTO YAN Renxiang
- Re: [dhcwg] dhcpv6 'zone suffix' option Joe Quanaim
- RE: [dhcwg] dhcpv6 'zone suffix' option CTO YAN Renxiang
- re: [dhcwg] dhcpv6 'zone suffix' option CTO YAN Renxiang
- [dhcwg] dhcpv6 'zone suffix' option CTO YAN Renxiang
- RE: [dhcwg] dhcpv6 'zone suffix' option Bernie Volz