From mailman-bounces@ietf.org Wed Sep 1 09:50:59 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12791
for ; Wed, 1 Sep 2004 09:50:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C2RSE-0008U0-Il
for dhc-archive@lists.ietf.org; Wed, 01 Sep 2004 05:30:58 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: ietf.org mailing list memberships reminder
From: mailman-owner@ietf.org
To: dhc-archive@ietf.org
X-No-Archive: yes
Message-ID:
Date: Wed, 01 Sep 2004 05:08:38 -0400
Precedence: bulk
X-BeenThere: mailman@lists.ietf.org
X-Mailman-Version: 2.1.5
List-Id: Mailman site list
X-List-Administrivia: yes
Sender: mailman-bounces@ietf.org
Errors-To: mailman-bounces@ietf.org
Content-Transfer-Encoding: 7bit
This is a reminder, sent out once a month, about your ietf.org mailing
list memberships. It includes your subscription info and how to use
it to change it or unsubscribe from a list.
You can visit the URLs to change your membership status or
configuration, including unsubscribing, setting digest-style delivery
or disabling delivery altogether (e.g., for a vacation), and so on.
In addition to the URL interfaces, you can also use email to make such
changes. For more info, send a message to the '-request' address of
the list (for example, mailman-request@ietf.org) containing just the
word 'help' in the message body, and an email message will be sent to
you with instructions.
**********************************************************************
NOTE WELL:
Any submission to the IETF intended by the Contributor for publication
as all or part of an IETF Internet-Draft or RFC and any statement made
within the context of an IETF activity is considered an "IETF
Contribution". Such statements include oral statements in IETF
sessions, as well as written and electronic communications made at any
time or place, which are addressed to:
o the IETF plenary session, o any IETF working group or portion
thereof, o the IESG, or any member thereof on behalf of the IESG, o
the IAB or any member thereof on behalf of the IAB, o any IETF mailing
list, including the IETF list itself, any working group
or design team list, or any other list functioning under IETF
auspices,
o the RFC Editor or the Internet-Drafts function
All IETF Contributions are subject to the rules of RFC 3667 and RFC
3668.
Statements made outside of an IETF session, mailing list or other
function, that are clearly not intended to be input to an IETF
activity, group or function, are not IETF Contributions in the context
of this notice.
Please consult RFC 3667 for details.
*******************************************************************************
If you have questions, problems, comments, etc, send them to
mailman-owner@ietf.org. Thanks!
Passwords for dhc-archive@lists.ietf.org:
List Password // URL
---- --------
dhcwg@ietf.org aCBd
https://www1.ietf.org/mailman/options/dhcwg/dhc-archive%40lists.ietf.org
From dhcwg-bounces@ietf.org Wed Sep 1 10:53:04 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22218;
Wed, 1 Sep 2004 10:53:04 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C2SF1-0006IZ-M0; Wed, 01 Sep 2004 06:21:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C2NQ4-0003Ul-Ls
for dhcwg@megatron.ietf.org; Wed, 01 Sep 2004 01:12:28 -0400
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 BAA07133
for ; Wed, 1 Sep 2004 01:12:28 -0400 (EDT)
Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com)
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2NSB-0000Tu-Sm
for dhcwg@ietf.org; Wed, 01 Sep 2004 01:14:40 -0400
Received: from emily (huawei.com [172.17.1.62])
by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep
8 2003)) with ESMTPA id <0I3C007M4J3WMG@mta0.huawei.com> for
dhcwg@ietf.org; Wed, 01 Sep 2004 12:57:34 +0800 (CST)
Date: Wed, 01 Sep 2004 10:25:04 +0530
From: mao shanxiang
Subject: Re: [dhcwg] dhcp6 verndor class option
To: Bernie Volz , "'Keshava'" ,
dhcwg@ietf.org
Message-id: <000601c48fdf$d93bf240$db04120a@emily>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
X-imss-version: 2.7
X-imss-result: Passed
X-imss-approveListMatch: *@huawei.com
References: <000101c48fc3$748d79c0$6401a8c0@amer.cisco.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Content-Transfer-Encoding: 7BIT
X-Mailman-Approved-At: Wed, 01 Sep 2004 06:21:21 -0400
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7BIT
Hi Bernie,
if relay includes such option, what is the behavior of the server? the
server can return information in the Relay-Reply, but what is the usage for
server to analyze such option info? give different policy?
can you please clarify me?
Regards,
Emily
----- Original Message -----
From: "Bernie Volz"
To: "'Keshava'" ; ;
Cc:
Sent: Wednesday, September 01, 2004 7:01 AM
Subject: RE: [dhcwg] dhcp6 verndor class option
If there's relay specific information that could be used by a server (or
other relay), there is no reason the relay can't include this in its
Relay-Forw message (and the server return information in the Relay-Reply).
Note that Appendix A, Appearance of Options in Message Types, indicates that
these are valid:
Status Rap. User Vendor Vendor Inter. Recon. Recon.
Code Comm. Class Class Spec. ID Msg. Accept
R-forw. * * * *
R-repl. * * * *
- Bernie
-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of
Keshava
Sent: Friday, August 27, 2004 10:10 AM
To: dhcwg@ietf.org; ipv6@ietf.org
Cc: keshavaak@huawei.com; maoshx@huawei.com
Subject: [dhcwg] dhcp6 verndor class option
Hi,
Can you please clarify in he RFC 3315 (DHCP6)
"Appearance of Options in Message Types" section mentions that the dhcp6
relay should support
vendor class option.
But in the message processing in the "Section 22.16 Vendor Class Option"
does not mention any
thing about this for relay . It only mentions about how the client
should process this.
Can some one please clarify this what should be done for dhcp6 relay ?
regards,
keshava
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Wed Sep 1 12:27:17 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05169;
Wed, 1 Sep 2004 12:27:17 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C2XMS-0005cG-Rk; Wed, 01 Sep 2004 11:49:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C2VFi-00046A-9h
for dhcwg@megatron.ietf.org; Wed, 01 Sep 2004 09:34:19 -0400
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 JAA06191
for ; Wed, 1 Sep 2004 09:34:13 -0400 (EDT)
Received: from tyholt.uninett.no ([158.38.60.10])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2UJ2-0001JM-6O
for dhcwg@ietf.org; Wed, 01 Sep 2004 08:33:41 -0400
Received: from sverresborg.uninett.no (sverresborg.uninett.no
[IPv6:2001:700:e000:0:204:75ff:fee4:423b])
by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i81CUXOK000613;
Wed, 1 Sep 2004 14:30:33 +0200
Received: (from venaas@localhost)
by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i81CUThF015683;
Wed, 1 Sep 2004 14:30:29 +0200
X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to
Stig.Venaas@uninett.no using -f
Date: Wed, 1 Sep 2004 14:30:29 +0200
From: Stig Venaas
To: "JINMEI Tatuya / ?$B?@L@C#:H"
Subject: Re: [dhcwg] behavior on lifetime expiration (Re:
comments on draft-ietf-dhc-lifetime-01.txt)
Message-ID: <20040901123029.GI15000@sverresborg.uninett.no>
References:
<20040803033357.GA20506@sverresborg.uninett.no>
<6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: dhcwg@ietf.org, Ted Lemon
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
On Wed, Sep 01, 2004 at 01:01:51AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> >>>>> On Tue, 24 Aug 2004 11:08:14 -0400,
> >>>>> Ted Lemon said:
>
> > However, let's consider your scenario a little more closely. You
> > acquire some information from the DHCP server. Subsequently, for some
> > reason, it becomes impossible for the server to respond to the client.
>
> > I have a couple of observations about this. First, the time at which
> > it becomes impossible for the server to respond is not the same as the
> > time at which the client attempts to refresh its configuration
> > information. The two events are unrelated.
>
> Okay, I concur on this. I also see that the scenario might differ
> based on whether the client moves to a new link or it stays in the
> same link.
What you write sounds reasonable, but I'm still not sure we should go
into the details. The reason is that we don't know in general what
the behaviour should be, and it's a generic issue. It's obviously a
related issue though. We could as Ted suggests, specify this later
when we have more information. That could either be as an update to
the lifetime RFC, or IMO perhaps better, add some text if an update
to RFC 3315 is done. There seems to be other reasons to update RFC
3315 too (draft-jinmei-dhc-dhcpv6-clarify-auth-00?).
In general I agree with your distinction between still and moving
clients. What worries me though, is that it might not be possible for
a client to distinguish between movement and renumbering. The fact
that a new prefix is announced in RAs is not sufficient.
Stig
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Wed Sep 1 12:32:46 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05609;
Wed, 1 Sep 2004 12:32:46 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C2XMd-0005p1-3C; Wed, 01 Sep 2004 11:49:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C2VGM-0004FR-4R
for dhcwg@megatron.ietf.org; Wed, 01 Sep 2004 09:35:00 -0400
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 JAA06726
for ; Wed, 1 Sep 2004 09:34:54 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
id 1C2Tl0-0000q1-M3
for dhcwg@ietf.org; Wed, 01 Sep 2004 07:58:32 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
by sj-iport-3.cisco.com with ESMTP; 01 Sep 2004 05:03:43 +0000
X-BrightmailFiltered: true
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
[161.44.122.62])
by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i81BteKX013164;
Wed, 1 Sep 2004 04:55:41 -0700 (PDT)
Received: from volzw2k (che-vpn-cluster-2-207.cisco.com [10.86.242.207])
by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALF80427;
Wed, 1 Sep 2004 07:55:39 -0400 (EDT)
From: "Bernie Volz"
To: "'mao shanxiang'" , "'Keshava'" ,
Subject: RE: [dhcwg] dhcp6 verndor class option
Date: Wed, 1 Sep 2004 07:55:40 -0400
Organization: Cisco
Message-ID: <000401c4901a$9a2434b0$6401a8c0@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.5709
In-Reply-To: <000601c48fdf$d93bf240$db04120a@emily>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Content-Transfer-Encoding: quoted-printable
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable
Well, as we have no DHCPv6 option to carry a subscriber ID, perhaps the
relay wants to communicate that to the server? So, it could send this in =
the
vendor-specific option.
Or, if the relay is on a switch, it could include the port on which the
client is located.
There's all sorts of possibilities.
- Bernie
> -----Original Message-----
> From: mao shanxiang [mailto:maoshx@huawei.com]=20
> Sent: Wednesday, September 01, 2004 12:55 AM
> To: Bernie Volz; 'Keshava'; dhcwg@ietf.org
> Subject: Re: [dhcwg] dhcp6 verndor class option
>=20
>=20
> Hi Bernie,
>=20
> if relay includes such option, what is the behavior of the=20
> server? the server can return information in the Relay-Reply,=20
> but what is the usage for server to analyze such option info?=20
> give different policy?
>=20
> can you please clarify me?
>=20
> Regards,
> Emily
>=20
> ----- Original Message -----=20
> From: "Bernie Volz"
> To: "'Keshava'" ; ;=20
>
> Cc:
> Sent: Wednesday, September 01, 2004 7:01 AM
> Subject: RE: [dhcwg] dhcp6 verndor class option
>=20
>=20
> If there's relay specific information that could be used by a=20
> server (or other relay), there is no reason the relay can't=20
> include this in its Relay-Forw message (and the server return=20
> information in the Relay-Reply).
>=20
> Note that Appendix A, Appearance of Options in Message Types,=20
> indicates that these are valid:
>=20
> Status Rap. User Vendor Vendor Inter. Recon. Recon.
> Code Comm. Class Class Spec. ID Msg. Accept
> R-forw. * * * *
> R-repl. * * * *
>=20
> - Bernie
>=20
> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20
> On Behalf Of Keshava
> Sent: Friday, August 27, 2004 10:10 AM
> To: dhcwg@ietf.org; ipv6@ietf.org
> Cc: keshavaak@huawei.com; maoshx@huawei.com
> Subject: [dhcwg] dhcp6 verndor class option
>=20
>=20
> Hi,
> Can you please clarify in he RFC 3315 (DHCP6)
>=20
> "Appearance of Options in Message Types" section mentions=20
> that the dhcp6 relay should support
> vendor class option.
>=20
> But in the message processing in the "Section 22.16=20
> Vendor Class Option" does not mention any
> thing about this for relay . It only mentions about how=20
> the client should process this.
>=20
> Can some one please clarify this what should be done=20
> for dhcp6 relay ?
>=20
>=20
> regards,
> keshava
>=20
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Wed Sep 1 13:01:45 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10611;
Wed, 1 Sep 2004 13:01:45 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C2XTU-0002iP-FR; Wed, 01 Sep 2004 11:56:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C2VxY-0004YZ-Si
for dhcwg@megatron.ietf.org; Wed, 01 Sep 2004 10:19:37 -0400
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 KAA17436
for ; Wed, 1 Sep 2004 10:19:34 -0400 (EDT)
Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Vzk-0002An-1o
for dhcwg@ietf.org; Wed, 01 Sep 2004 10:21:53 -0400
Received: from ocean.jinmei.org (unknown [2001:200:0:8002:9d66:8cbb:c45e:52c1])
by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP
id A1BFD15265; Wed, 1 Sep 2004 23:19:26 +0900 (JST)
Date: Wed, 01 Sep 2004 23:19:27 +0900
Message-ID:
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
To: Ted Lemon
Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt
In-Reply-To: <8789608F-FB6B-11D8-8C0B-000D93C4B69A@fugue.com>
References: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com>
<6493.1093586912@munnari.OZ.AU>
<20040831120208.GM2203@sverresborg.uninett.no>
<8789608F-FB6B-11D8-8C0B-000D93C4B69A@fugue.com>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0
(SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
>>>>> On Tue, 31 Aug 2004 09:33:46 -0700,
>>>>> Ted Lemon said:
>> I don't know what people think, I have no strong feelings myself, but
>> we could relax things a bit perhaps. But there is some added complexity
>> and it isn't essential. It could also be extended later if necessary.
>>
>> We could tweak the spec to allow what you say, if there's agreement on
>> that. But most of all, I want to come to some conclusion really soon.
> I think using the IRT option in a context where there is a lifetime
> already doesn't make sense, and should not be allowed. I don't mean
> the client should drop the packet if it gets both - just that the
> option has no meaning in the context of a stateful DHCP message.
I basically agree with this.
Regarding complexity, different people may have different image on it,
so I suspect we can easily get a consensus.
But I think we all at least agreed on the following points:
it isn't not that useful to have a separate lifetime when we already
have lifetimes (or lease times) for addresses in the stateful case.
(almost the same thing what Ted said above)
In addition to that, as an implementor, if we explicitly allow this
case, it means we'll need to implement it anyway to be compliant to
the RFC(-to-be), even though we know we have no practical case where
it is useful. Opinions on whether the implementation will be
complicated or not may differ among people (see above), but it's a
real issue for me as an implementor.
If we need a compromise for future possibility, we could explicitly
say this case is beyond the scope of the document as I mentioned
earlier.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
jinmei@isl.rdc.toshiba.co.jp
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Wed Sep 1 13:16:06 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11971;
Wed, 1 Sep 2004 13:16:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C2XZE-0000ZR-2r; Wed, 01 Sep 2004 12:02:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C2WTS-0003II-KI
for dhcwg@megatron.ietf.org; Wed, 01 Sep 2004 10:52:34 -0400
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 KAA22133
for ; Wed, 1 Sep 2004 10:52:31 -0400 (EDT)
Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2WVe-0003xy-26
for dhcwg@ietf.org; Wed, 01 Sep 2004 10:54:51 -0400
Received: from ocean.jinmei.org (unknown [2001:200:0:8002:9d66:8cbb:c45e:52c1])
by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP
id 5293415265; Wed, 1 Sep 2004 23:52:31 +0900 (JST)
Date: Wed, 01 Sep 2004 23:52:32 +0900
Message-ID:
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
To: Stig Venaas
Subject: Re: [dhcwg] behavior on lifetime expiration (Re:
comments on draft-ietf-dhc-lifetime-01.txt)
In-Reply-To: <20040901123029.GI15000@sverresborg.uninett.no>
References:
<20040803033357.GA20506@sverresborg.uninett.no>
<6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com>
<20040901123029.GI15000@sverresborg.uninett.no>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0
(SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: dhcwg@ietf.org, Ted Lemon
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
>>>>> On Wed, 1 Sep 2004 14:30:29 +0200,
>>>>> Stig Venaas said:
> What you write sounds reasonable, but I'm still not sure we should go
> into the details. The reason is that we don't know in general what
> the behaviour should be, and it's a generic issue. It's obviously a
> related issue though. We could as Ted suggests, specify this later
> when we have more information. That could either be as an update to
> the lifetime RFC, or IMO perhaps better, add some text if an update
> to RFC 3315 is done. There seems to be other reasons to update RFC
> 3315 too (draft-jinmei-dhc-dhcpv6-clarify-auth-00?).
I would first like to note that the suggestion by Ted of leaving it to
a later document was followed by his response to me where he agreed
(or at least seemed to agree) with my proposal.
Secondly, if I understand the sense in this list correctly, I believe
my proposal reflects some level of consensus here.
Third, I personally think we can reflect the proposal without making
the document unnecessarily long. (If you want, I'll try to contribute
to some text.)
So, I personally think it makes sense to clarify the points at this
chance even though the points can be extended to general issues.
...but I don't want to delay this important work due to my pedantic
ego. If others still want to leave those points to other documents,
I'll obey that decision (but at least I want the "lifetime" document
to mention those a bit and to say that those are beyond the scope of
the doc).
> In general I agree with your distinction between still and moving
> clients. What worries me though, is that it might not be possible for
> a client to distinguish between movement and renumbering. The fact
> that a new prefix is announced in RAs is not sufficient.
As I said in my previous message, I basically think we can concentrate
on the "still" clients in this document, and do not have to worry
too much about miscellaneous subtle cases of moving vs
not-actually-moving. Movement detection is itself a difficult
challenge (we even have a dedicated wg on this!), so I think it is
enough in the scope of dhc wg to show some preliminary considerations
on the moving clients (e.g., as shown in Section 18.1.2 of RFC3315.).
Besides, I don't see an actual problem in that particular case you
raised above, along with my proposed approach. If the client
misunderstands that it has moved to a different link while it
actually stays in the same link, the client will resend an
Information-request message immediately based on the proposed
scenario. In this case, however, the legitimate DHCPv6 server should
still be there and will respond to the Information-request with valid
configuration information. (request storm might be an issue, but
confusing events like renumbering should be rare).
On the other hand, if the client misunderstands that it stays in the
same link while it has actually moved, the client will perhaps have a
trouble. Along with the proposed approach, however, I think we don't
have to worry about that within the scope of this document; we'll
basically note that issues regarding moving clients are difficult and
will need future analysis.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
jinmei@isl.rdc.toshiba.co.jp
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Wed Sep 1 13:18:06 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12281;
Wed, 1 Sep 2004 13:18:06 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C2Xa0-0002sz-0L; Wed, 01 Sep 2004 12:03:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Wk0-0002VQ-7M
for dhcwg@megatron.ietf.org; Wed, 01 Sep 2004 11:09:40 -0400
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 LAA24981
for ; Wed, 1 Sep 2004 11:09:37 -0400 (EDT)
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2WmD-00051B-8l
for dhcwg@ietf.org; Wed, 01 Sep 2004 11:11:57 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13)
by rtp-iport-1.cisco.com with ESMTP; 01 Sep 2004 11:21:37 -0400
X-BrightmailFiltered: true
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
[161.44.122.62])
by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i81F91ZQ008187;
Wed, 1 Sep 2004 11:09:06 -0400 (EDT)
Received: from volzw2k (dhcp-10-86-160-46.cisco.com [10.86.160.46])
by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALF94279;
Wed, 1 Sep 2004 11:09:00 -0400 (EDT)
From: "Bernie Volz"
To: "'mao shanxiang'" , "'Keshava'" ,
Subject: RE: [dhcwg] dhcp6 verndor class option
Date: Wed, 1 Sep 2004 11:09:00 -0400
Organization: Cisco
Message-ID: <000501c49035$9c60ea00$2ea0560a@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.5709
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
In-Reply-To: <000601c48fdf$d93bf240$db04120a@emily>
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Content-Transfer-Encoding: 7bit
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7bit
This is completely up to the server. See DHCP Relay Agent Information Option
(RFC 3046) for more details as to how this is may be used in DHCPv4. This
really is no different for DHCPv6, just that the way the information is
carried is different and is vendor-specific -- though likely there will be
standardized relay agent options to carry information in the future.
- Bernie
> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]
> On Behalf Of mao shanxiang
> Sent: Wednesday, September 01, 2004 12:55 AM
> To: Bernie Volz; 'Keshava'; dhcwg@ietf.org
> Subject: Re: [dhcwg] dhcp6 verndor class option
>
>
> Hi Bernie,
>
> if relay includes such option, what is the behavior of the
> server? the server can return information in the Relay-Reply,
> but what is the usage for server to analyze such option info?
> give different policy?
>
> can you please clarify me?
>
> Regards,
> Emily
>
> ----- Original Message -----
> From: "Bernie Volz"
> To: "'Keshava'" ; ;
>
> Cc:
> Sent: Wednesday, September 01, 2004 7:01 AM
> Subject: RE: [dhcwg] dhcp6 verndor class option
>
>
> If there's relay specific information that could be used by a
> server (or other relay), there is no reason the relay can't
> include this in its Relay-Forw message (and the server return
> information in the Relay-Reply).
>
> Note that Appendix A, Appearance of Options in Message Types,
> indicates that these are valid:
>
> Status Rap. User Vendor Vendor Inter. Recon. Recon.
> Code Comm. Class Class Spec. ID Msg. Accept
> R-forw. * * * *
> R-repl. * * * *
>
> - Bernie
>
> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]
> On Behalf Of Keshava
> Sent: Friday, August 27, 2004 10:10 AM
> To: dhcwg@ietf.org; ipv6@ietf.org
> Cc: keshavaak@huawei.com; maoshx@huawei.com
> Subject: [dhcwg] dhcp6 verndor class option
>
>
> Hi,
> Can you please clarify in he RFC 3315 (DHCP6)
>
> "Appearance of Options in Message Types" section mentions
> that the dhcp6 relay should support
> vendor class option.
>
> But in the message processing in the "Section 22.16
> Vendor Class Option" does not mention any
> thing about this for relay . It only mentions about how
> the client should process this.
>
> Can some one please clarify this what should be done
> for dhcp6 relay ?
>
>
> regards,
> keshava
>
>
> _______________________________________________
> 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
From dhcwg-bounces@ietf.org Wed Sep 1 14:21:05 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17964;
Wed, 1 Sep 2004 14:21:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C2ZIB-0006ki-Am; Wed, 01 Sep 2004 13:53:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Yfv-0005r6-41
for dhcwg@megatron.ietf.org; Wed, 01 Sep 2004 13:13:35 -0400
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 NAA11674
for ; Wed, 1 Sep 2004 13:13:31 -0400 (EDT)
Received: from toccata.fugue.com ([204.152.186.142])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Yi8-00062O-76
for dhcwg@ietf.org; Wed, 01 Sep 2004 13:15:53 -0400
Received: from [10.0.2.8] (neubayern.net [66.93.162.100])
by toccata.fugue.com (Postfix) with ESMTP id 125E41B225E
for ; Wed, 1 Sep 2004 12:11:50 -0500 (CDT)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <20040901123029.GI15000@sverresborg.uninett.no>
References:
<20040803033357.GA20506@sverresborg.uninett.no>
<6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com>
<20040901123029.GI15000@sverresborg.uninett.no>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <3EA34C4F-FC3A-11D8-8C0B-000D93C4B69A@nominum.com>
Content-Transfer-Encoding: 7bit
From: Ted Lemon
Subject: Re: [dhcwg] behavior on lifetime expiration (Re:
comments on draft-ietf-dhc-lifetime-01.txt)
Date: Wed, 1 Sep 2004 10:13:29 -0700
To: dhcwg@ietf.org
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Content-Transfer-Encoding: 7bit
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7bit
On Sep 1, 2004, at 5:30 AM, Stig Venaas wrote:
> What worries me though, is that it might not be possible for
> a client to distinguish between movement and renumbering. The fact
> that a new prefix is announced in RAs is not sufficient.
I would like to point out the work that they're doing in the DNA
working group. This is what I had in mind when I spoke earlier about
detecting that the client had moved. This work does not depend on
noticing differences in RA messages.
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Thu Sep 2 05:45:11 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16753;
Thu, 2 Sep 2004 05:45:11 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C2o1G-0000Yo-IW; Thu, 02 Sep 2004 05:36:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C2nm7-0001QA-L3
for dhcwg@megatron.ietf.org; Thu, 02 Sep 2004 05:20:59 -0400
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 FAA15271
for ; Thu, 2 Sep 2004 05:20:57 -0400 (EDT)
Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2noT-0000AD-4k
for dhcwg@ietf.org; Thu, 02 Sep 2004 05:23:26 -0400
Received: from ocean.jinmei.org (unknown
[3ffe:501:100f:1048:79b7:3eeb:f7f7:b9ee])
by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP
id 47DA615272; Thu, 2 Sep 2004 18:20:56 +0900 (JST)
Date: Thu, 02 Sep 2004 18:20:57 +0900
Message-ID:
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
To: "Bernie Volz"
Subject: Re: [dhcwg] Re: one more comment about the lifetime option
In-Reply-To: <001401c48a3e$2ededf20$6401a8c0@amer.cisco.com>
References:
<001401c48a3e$2ededf20$6401a8c0@amer.cisco.com>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0
(SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: dhcwg@ietf.org, "'Ted Lemon'"
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
(forgot to reply to this...)
I've changed the order of the citation below.
>>>>> On Tue, 24 Aug 2004 20:55:14 -0400,
>>>>> "Bernie Volz" said:
>> > We should also restrict the position where the lifetime option can
>> > appear: it should only be able to appear at the "top level"
>> of option
>> > hierarchy.
>>
>> I think this is a good idea.
> If it is restricted to a REPLY to an INFORMATION-REQUEST, there is
> no need for this explicit statement as that's all that is currently
> possible - there are no IA_NA, IA_TA, or IA_PD options for these
> messages.
I don't think this is really the case. An authentication option can
be used with Information-request and can have sub-options.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
jinmei@isl.rdc.toshiba.co.jp
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Thu Sep 2 08:46:22 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29306;
Thu, 2 Sep 2004 08:46:22 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C2qq0-0002hi-Hb; Thu, 02 Sep 2004 08:37:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C2qds-0004Wg-3Y
for dhcwg@megatron.ietf.org; Thu, 02 Sep 2004 08:24:40 -0400
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 IAA27569;
Thu, 2 Sep 2004 08:24:39 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
id 1C2qgE-0006nz-Qh; Thu, 02 Sep 2004 08:27:08 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
by sj-iport-3.cisco.com with ESMTP; 02 Sep 2004 05:31:35 +0000
X-BrightmailFiltered: true
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
[161.44.122.62])
by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i82CNK2l021526;
Thu, 2 Sep 2004 05:23:21 -0700 (PDT)
Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-16.cisco.com
[10.86.242.16]) by flask.cisco.com (MOS 3.4.6-GR)
with ESMTP id ALG62578; Thu, 2 Sep 2004 08:23:19 -0400 (EDT)
Message-Id: <4.3.2.7.2.20040902082231.0200cbe8@flask.cisco.com>
X-Sender: rdroms@flask.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 02 Sep 2004 08:23:17 -0400
To: proceedings@ietf.org
From: Ralph Droms
Mime-Version: 1.0
Content-Type: multipart/mixed;
boundary="=====================_54347367==_"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25eb6223a37c19d53ede858176b14339
Cc: dhcwg@ietf.org
Subject: [dhcwg] Minutes from IETF 60 dhc WG meeting
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
--=====================_54347367==_
Content-Type: text/plain; charset="us-ascii"; format=flowed
The minutes from the dhc WG meeting at IETF 60 are attached.
- Ralph Droms
--=====================_54347367==_
Content-Type: text/html; name="IETF_60_dhc_WG_minutes.html"
Content-Disposition: attachment; filename="IETF_60_dhc_WG_minutes.html"
Content-Transfer-Encoding: base64
PHhtcD4KCQkJICAgTWVldGluZyBTdW1tYXJ5CgkJCSAgIGRoYyBXRywgSUVURiA2MAoJCQkgICAy
MDA0LTA4LTAzLCAwOTAwCgkJCSAgIC0tLS0tLS0tLS0tLS0tLS0KCkFkbWluaXN0cml2aWEKLS0t
LS0tLS0tLS0tLQoKVGhlIGNoYWlyIGdyYXRlZnVsbHkgYWNrbm93bGVkZ2VzIEtpbSBLaW5uZWFy
LCBKb2huIFNjaG5pemxlaW4gZm9yCnByb3ZpZGluZyBub3RlcyBhbmQgVGltIENob3duIGZvciBh
Y3RpbmcgYXMgamFiYmVyIHNjcmliZSwgd2hpY2ggdGhlCmNoYWlyIHVzZWQgaW4gcHJlcGFyaW5n
IHRoZXNlIG1pbnV0ZXMuCgpUaGUgY2hhaXIgYW5ub3VuY2VkIHRoYXQgU2FtdW5nIGhhcyBwdWJs
aXNoZWQgYSB6ZXJvLWNvc3QgbGljZW5zaW5nCklQUiBjbGFpbSBvbiBkcmFmdC1pZXRmLWRoYy1y
YXBpZC1jb21taXQtb3B0LTA1LnR4dC4gVGhlcmUgd2FzIG5vCm9iamVjdGlvbiBpbiB0aGUgV0cg
dG8gbW92aW5nIHRoZSBkcmFmdCBkcmFmdCBmb3J3YXJkLgoKVGhlIGNoYWlyIGFubm91bmNlZCB0
aGF0IHRoZXJlIHdhcyBubyByZXNwb25zZSBmcm9tIFBhY2tldEZyb250IHRvIGEKcmVxdWVzdCBm
cm9tIHRoZSBJRVRGIGZvciBjbGFyaWZpY2F0aW9uIG9mIElQUiBjbGFpbSBhbmQgYSByZXF1ZXN0
CmZyb20gdGhlIGNoYWlyIGZvciBhIHplcm8tY29zdCBsaWNlbnNpbmcgSVBSIGNsYWltIG9uCmRy
YWZ0LWlldGYtZGhjLXN1YnNjcmliZXItaWQtMDYudHh0LiAgVGhlIGNvbnNlbnN1cyBvZiB0aGUg
V0cgd2FzIHRvCm1vdmUgdGhlIGRyYWZ0IGZvcndhcmQgZGVzcGl0ZSB0aGUgY3VycmVudCBJUFIg
Y2xhaW0uCgpUaGUgREhDUHY2IENsaWVudCBGUUROIE9wdGlvbiA8ZHJhZnQtdm9sei1kaGMtZGhj
cHY2LWZxZG4+Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0KClRoZSBhdXRob3IgZ2F2ZSBhIHNob3J0IHByZXNlbnRhdGlvbiBvbiB0aGUg
ZHJhZnQgYW5kIGFza2VkIGZvcgpjb21tZW50cy4KCktpbSBLaW5uZWFyIHN1Z2dlc3RlZCB0aGF0
IHdlIHNwZWxsIG91dCBob3cgdG8gaGFuZGxlIHRoZSBjYXNlKHMpCndoZXJlIHRoZSBjbGllbnQg
ZG9lc24ndCBzZW5kIGluIHRoZSBGUUROIG9wdGlvbi4gIE9uZSBpc3N1ZSBpcywgY2FuCnRoZSBz
ZXJ2ZXIgcmVwbHkgd2l0aCB0aGUgRlFETiB0byB0aGUgY2xpZW50IGlmIHRoZSBjbGllbnQgZG9l
c24ndApzZW5kIGl0IGluPyAgVGhlIGRyYWZ0IGN1cnJlbnRseSBzYXlzIG5vLiAgQW5vdGhlciBp
c3N1ZSBpcyB3aGF0IHRvIGRvCmlmIHRoZSBjbGllbnQgc2VuZCBpbiBhbiBGUUROIG9wdGlvbiwg
YW5kIHRoZW4gZG9lc24ndCBmb3Igb25lIHRpbWUsCndoYXQgc2hvdWxkIHRoZSBzZXJ2ZXIgZG8/
CgpQZWtrYSBTYXZsb2EgYXNrZWQgd2hhdCBhYm91dCBhIGNsaWVudCB0aGF0IHRyaWVzIHRvIHVw
ZGF0ZSBETlMKaXRzZWxmLCBhbmQgd2hhdCBpcyB0aGUgb3BlcmF0aW9uYWwgcmVhc29ucyBmb3Ig
dGhlIERIQ1Agc2VydmVyIHRvIGRvCnRoZSB1cGRhdGUgaW5zdGVhZCBvZiB0aGUgREhDUCBjbGll
bnQuICBCZXJuaWUgYW5kIE1hcmsgc3VnZ2VzdGVkIHRoYXQKdXNpbmcgdGhlIGNsaWVudCBGUURO
IG9wdGlvbiBkb2Vzbid0IGNoYW5nZSB0aGUgZmFjdCB0aGF0IHlvdSBoYXZlCm9wZW5lZCB1cCB0
aGUgRE5TIHNlcnZlciB0byBkeW5hbWljIHVwZGF0ZXMuICBUZWQgc3VnZ2VzdGVkIHRoYXQgdGhp
cwpESENQdjYgYXBwcm9hY2ggcGFyYWxsZWxzIHRoZSBESENQdjQgYXBwcm9hY2gsIGFuZCB0aGF0
IHRoZSBxdWVzdGlvbmVyCnNob3VsZCBwZXJoYXBzIHJldmlldyB0aGUgREhDUHY0IGRyYWZ0cyBv
biB0aGlzIHN1YmplY3QgdG8gYmV0dGVyCnVuZGVyc3RhbmQgaG93IHRoZSBlbnRpcmUgYXBwcm9h
Y2ggb3BlcmF0ZXMuCgpUZWQgTGVtb24gYXNrZWQgaWYgdGhlcmUgaXMgYSBwb3RlbnRpYWwgZXhw
bG9zaW9uIG9mIHNlbmRpbmcgbG90cyBvZgpuYW1lcyBiYWNrIHdpdGggYSBzaW5nbGUgcmVxdWVz
dD8gIEJlcm5pZSBzYWlkIHllcywgdGhlIHNlcnZlciBtaWdodApvZmZlciBtdWx0aXBsZSBuYW1l
cy4KCk1hcmdhcmV0IFdhYXNzZXJtYW4gYXNrZWQgaWYgcmV2aWV3IG9mIHRoaXMgZHJhZnQgd291
bGQgdGhpcyBiZQpjb29yZGluYXRlZCB3aXRoIHRoZSBkbnNleHQgV0c/ICBUaGUgY2hhaXIgYW5z
d2VyZWQgeWVzIGFsb25nIHdpdGggdGhlCm90aGVycyBpbiB0aGlzIHBhY2thZ2UgKHNlZSBiZWxv
dyBmb3IgbGlzdCkgdGhhdCBhcmUgYmVpbmcgY29vcmRpbmF0ZWQuCgpBZnRlciBzb21lIGRpc2N1
c3Npb24gb2YgdGhlIHRlY2huaWNhbCBkZXRhaWxzLCB0aGUgY29uc2Vuc3VzIG9mIHRoZQpXRyBh
dCB0aGUgbWVldGluZyB3YXMgdG8gYWNjZXB0IGRyYWZ0LXZvbHotZGhjLWRoY3B2Ni1mcWRuIGFz
IGEgV0cKd29yayBpdGVtLiAgSXQgd2lsbCBiZSBwYXJ0IG9mIGEgcGFja2FnZSBvZiBkcmFmdHMg
dG8gYmUgc3VibWl0dGVkIHRvCnRoZSBJRVNHOgoKICBkcmFmdC12b2x6LWRoYy1kaGNwdjYtZnFk
bgogIGRyYWZ0LWlldGYtZGhjLWZxZG4tb3B0aW9uCiAgZHJhZnQtaWV0Zi1kbnNleHQtZGhjaWQt
cnItMDcudHh0CiAgZHJhZnQtaWV0Zi1kaGMtZGRucy1yZXNvbHV0aW9uLTA3LnR4dAogIGRyYWZ0
LWlldGYtZGhjLTMzMTVpZC1mb3ItdjQtMDMudHh0CgpUaGUgY29uc2Vuc3VzIHRvIGFjY2VwdCB0
aGUgZHJhZnQgd2lsbCBiZSBjb25maXJtZWQgb24gdGhlIFdHIG1haWxpbmcKbGlzdC4KClRoZSBE
SENQIENsaWVudCBGUUROIE9wdGlvbiAgPGRyYWZ0LWlldGYtZGhjLWZxZG4tb3B0aW9uPgotLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KClRo
ZSBhdXRob3Igc3VtbWFyaXplZCB0aGUgZWRpdG9yaWFsIGNoYW5nZXMuICBUaGUgV0cgbWVldGlu
ZyBjb25zZW5zdXMKd2FzIHRoYXQgdGhpcyBkcmFmdCBpcyByZWFkeSBmb3IgV0cgbGFzdCBjYWxs
LiAgSXQgd2lsbCBnbyB0byBsYXN0CmNhbGwgd2hlbiBvdGhlciBkcmFmdHMgaW4gdGhlIHBhY2th
Z2UgYXJlIHJlYWR5LiAgVGhlIGNvbnNlbnN1cyB0aGF0CnRoZSBkcmFmdCBpcyByZWFkeSBmb3Ig
V0cgbGFzdCBjYWxsIHdpbGwgYmUgY29uZmlybWVkIG9uIHRoZSBXRwptYWlsaW5nIGxpc3QuCgpE
SENQIE9wdGlvbiBmb3IgQ29uZmlndXJpbmcgSVB2Ni1vdmVyLUlQdjQgVHVubmVscyA8ZHJhZnQt
ZGFuaWVsLWRoYy1pcHY2aW40LW9wdD4KQ29uZmlndXJlZCBUdW5uZWwgRW5kLVBvaW50IENvbmZp
Zy4gdXNpbmcgREhDUHY0IDxkcmFmdC1kYW5pZWwtZGhjLWRoY3B2NC10ZXAtY29uZj4KLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0KCkRpc2N1c3Npb24gZm9jdXNlZCBvbiA8ZHJhZnQtZGFuaWVs
LWRoYy1pcHY2aW40LW9wdD4uICBUZWQgTGVtb24Kc3VnZ2VzdGVkIHRoYXQgdGhlIGRyYWZ0IHNw
ZWNpZmljYWx5IHJlcXVpcmUgdGhhdCB0aGlzIG9wdGlvbiBvbmx5IGJlCnNlbnQgd2hlbiB0aGUg
Y2xpZW50IGhhcyByZXF1ZXN0ZWQgdGhlIG9wdGlvbi4gIFRoZSBXRyBtZWV0aW5nCmNvbmNlbnN1
cyB3YXMgdG8gdGFibGUgZGlzY3Vzc2lvbiB1bnRpbCBkaGMgYW5kIHY2b3BzIFdHIGNoYWlycwpk
aXNjdXNzIHdoaWNoIFdHIHNob3VsZCB0YWtlIG9uIHRoZXNlIGRyYWZ0cyBhbmQgaG93IHRoZSBk
cmFmdHMgZml0CmludG8gdGhlIHY2b3BzIFdHIGRpc2N1c3Npb24gb2YgdHVubmVsIGRpc2NvdmVy
eSBtZXRob2RzLgoKVmVuZG9yLVNwZWNpZmljIEluZm9ybWF0aW9uIFN1Ym9wdGlvbiBmb3IgUkFJ
TyA8ZHJhZnQtc3RhcHAtZGhjLXZlbmRvci1zdWJvcHRpb24+Ci0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLQoKVGhlIFdHIG1lZXRpbmcgY29uc2Vuc3VzIHdhcyB0byBhY2NlcHQgdGhpcyBkcmFmdCBh
cyBhIGRoYyBXRyB3b3JrCml0ZW0uICBUaGUgY29uc2Vuc3VzIHdpbGwgYmUgY29uZmlybWVkIG9u
IHRoZSBXRyBtYWlsaW5nIGxpc3QuCgpSZW51bWJlcmluZyBSZXF1aXJlbWVudHMgZm9yIFN0YXRl
bGVzcyBESENQdjYgPGRyYWZ0LWlldGYtZGhjLXN0YXRlbGVzcy1kaGNwdjYtcmVudW1iZXJpbmc+
Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KClRoZSBhdXRob3Igc3VtbWFyaXpl
ZCB0aGUgY2hhbmdlcyBzaW5jZSB0aGUgZHJhZnQgd2FzIGxhc3QgZGlzY3Vzc2VkCmluIFNlb3Vs
LiAgSXQgaXMgcmVsYXRlZCB0byB0aGUgcmVudW1iZXJpbmcgZHJhZnQgYnkgQmFrZXIsIGV0IGFs
LiwgaW4KdGhlIHY2b3BzIFdHLiAKClRoZSBXRyBtZWV0aW5nIGNvbnNlbnN1cyB3YXMgdGhhdCB0
aGUgZHJhZnQgaXMgdG8gYmUgc3VibWl0dGVkIHRvIHRoZQpJRVNHIGluZGVwZW5kZW50IG9mIGFu
eSBzcGVjaWZpYyBzb2x1dGlvbiwgZm9yIHB1YmxpY2F0aW9uIGFzIGFuCkluZm9ybWF0aW9uYWwg
UkZDLiAgVGhlIFdHIG1lZXRpbmcgY29uc2Vuc3VzIHdhcyB0aGF0IGRyYWZ0IGlzIHJlYWR5CmZv
ciBXRyBsYXN0IGNhbGwgKHRvIGJlIGNvbmZpcm1lZCBvbiB0aGUgV0cgbWFpbGluZyBsaXN0KS4K
CkxpZmV0aW1lIE9wdGlvbiBmb3IgREhDUHY2IDxkcmFmdC1pZXRmLWRoYy1saWZldGltZT4KLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKVGhlIGF1
dGhvciBwcmVzZW50ZWQgdGhlIHVwZGF0ZWQgZHJhZnQgYW5kIGFza2VkIHRocmVlIHF1ZXN0aW9u
czoKCiAgV2hhdCBpZiB0aGUgY2xpZW50IGFza3MgZm9yIG9wdGlvbiBhbmQgZG9lc24ndCBnZXQg
aXQgZnJvbSB0aGUKICBzZXJ2ZXI/ICBTdGlnJ3MgYW5zd2VyIGlzIHRoYXQgaWYgeW91IGdldCBp
dCBvbmNlIGFuZCBkb24ndCBnZXQgaXQKICBhZ2FpbiwgaXQgc2hvdWxkIGJlIGxpa2UgaXQgbmV2
ZXIgY2FtZSBpbi4KCiAgV2hhdCBzaG91bGQgaGFwcGVuIGlmIHRoZSBjbGllbnQgY2FuJ3QgcmVu
ZXcgaW5mb3JtYXRpb24uICBEb24ndAogIGZvcmdldCB3aGF0IHlvdSd2ZSBnb3Qgd2hpbGUgeW91
IGFyZSB3YWl0aW5nIGZvciB0aGUgdXBkYXRlLgoKICBTaG91bGQgd2Ugc3VwcG9ydCBzdGF0ZWZ1
bCBESENQPyAgSWYgeW91IGdldCB0aGlzIG9wdGlvbiB3aGVuIGRvaW5nCiAgc3RhdGVmdWwgYWxv
bmcgd2l0aCBhIGxlYXNlIHRpbWUsIHdoYXQgc2hvdWxkIHlvdSBkbz8gIElmIHRoaXMgdGltZQog
IGlzIGRpZmZlcmVudCB0aGFuIHRoZSBsZWFzZSB0aW1lLCBob3cgZG9lcyBhIERIQ1AgY2xpZW50
IGhhbmRsZSBpdC4KClRoZXNlIHF1ZXN0aW9ucyB3aWxsIGJlIHRha2VuIHRvIHRoZSBXRyBtYWls
aW5nIGxpc3QuCgpUaGUgV0cgbWVldGluZyBjb25zZW5zdXMgd2FzIHRvIGFjY2VwdCB0aGlzIGRy
YWZ0IGFzIHRoZSBzb2x1dGlvbgpjaG9zZW4gYnkgdGhlIFdHIHRvIG1lZXQgdGhlIHJlcXVpcmVt
ZW50cyBkZWZpbmVkIGluCmRyYWZ0LWlldGYtZGhjLXN0YXRlbGVzcy1kaGNwdjYtcmVudW1iZXJp
bmcuICBUaGUgYXV0aG9yIHdpbGwgcHVibGlzaAphIHJldmlzaW9uIGJhc2VkIG9uIGNvbW1lbnRz
IGZyb20gdGhlIG1lZXRpbmcgYW5kIHRoZSBXRyBtYWlsaW5nIGxpc3QKYmVmb3JlIGNvbnNpZGVy
YXRpb24gZm9yIFdHIGxhc3QgY2FsbC4KCkRIQ1AgT3B0aW9uIGZvciBIb21lIEFnZW50IERpc2Nv
dmVyeSBpbiBNSVB2NiA8ZHJhZnQtamFuZy1kaGMtaGFvcHQ+Ci0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpUaGlzIGRy
YWZ0IGFkZHJlc3NlcyB0aGUgTUlQdjYgYm9vdHN0cmFwcGluZyBwcm9ibGVtIC0gaG93IGRvZXMg
YQptb2JpbGUgbm9kZSBsZWFybiB0aGUgYWRkcmVzcyBvZiBpdHMgaG9tZSBhZ2VudD8KClRoZSBX
RyBzdWdnZXN0ZWQgdGhhdCB0aGUgZHJhZnQgc2hvdWxkIHNwZWNpZmljeSB1c2Ugb2YgUkZDIDEw
MzUKZW5jb2Rpbmcgd2hlbiBjYXJyeWluZyBhbiBGUUROLgoKVGhlIGNoYWlyIHdpbGwgaGF2ZSBh
IGRpc2N1c3Npb24gd2l0aCB0aGUgbWlwNiBjaGFpcnMgdG8gZGV0ZXJtaW5lCndoaWNoIFdHIHNo
b3VsZCB0YWtlIG9uIHRoaXMgZHJhZnQuICBJcyB0aGVyZSBpbnRlcmVzdCBpbiAzR1BQMiB0byB1
c2UKdGhpcyBvcHRpb24gYXMgd2VsbD8KCklzc3VlcyBpbiBESENQdjYgYXV0aGVudGljYXRpb24g
PGRyYWZ0LWppbm1laS1kaGMtZGhjcHY2LWNsYXJpZnktYXV0aD4KLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKVGhl
IGF1dGhvciBwcmVzZW50ZWQgYSBzdW1tYXJ5IG9mIHRoZSBkcmFmdCwgd2hpY2ggY2xhcmlmaWVz
IGlzc3VlcyBpbgpESENQdjYgYXV0aGVudGljYXRpb24gYmFzZWQgb24gaW1wbG1lbmV0YXRpb24g
ZXhwZXJpZW5jZS4gIAoKVGhlIFdHIG1lZXRpbmcgY29uc2Vuc3VzIHdhcyB0byB0YWtlIG9uIHRo
aXMgZHJhZnQgYXMgYSBXRyB3b3JrIGl0ZW0sCnRvIGJlIHB1Ymxpc2hlZCBhcyBQUywgdXBkYXRp
bmcgUkZDIDMzMTUuICBUaGUgY29udGVudHMgd2lsbCBiZSBtZXJnZWQKd2l0aCBSRkMgMzMxNSBm
b3IgRFMuCgpJUHY2IG11bHRpY2FzdCBhZGRyZXNzIGFzc2lnbm1lbnQgd2l0aCBESENQdjYgPGRy
YWZ0LWpkdXJhbmQtYXNzaWduLWFkZHItaXB2Ni1tdWx0aWNhc3QtZGhjcHY2PgotLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKVGhpcyBkcmFmdCBkZXNjcmliZXMgbXVsdGlj
YXN0IGFkZHJlc3MgbWFuYWdlbWVudCB1c2luZyBESENQdjYsCmJlY2F1c2UgdGhlIGF1dGhvciBj
b25zaWRlcnMgTUFEQ0FQIChSRkMgMjk3MCksIFNBUCAoUkZDIDI5NzQpLCByYW5kb20KY2hvaWNl
LCBHTE9QIGFuZCBaTUFBUCBpbmFkZXF1YXRlLgoKVGhlIGRyYWZ0IGRlc2NyaWJlcyBhIG5ldyBp
ZGVudGl0eSBhc3NvY2lhdGlvbiwgSUFfTUEsIHRoYXQgY2FycmllcwptdWx0aWNhc3QgYWRkcmVz
c2VzLiAgVGhlIHNjb3BlIG9wdGlvbiBhbGxvd3MgdGhlIHJlcXVlc3QgdG8gc3BlY2lmaWMKc2Nv
cGUgZm9yIHRoZSBhc3NpZ25lZCBhZGRyZXNzZXMuCgpTb21lIG1haWxpbmcgbGlzdCBkaXNjdXNz
aW9uIGlzc3VlczoKCjEuIFNob3VsZCBpdCBiZSBzcGxpdCBpbnRvIHR3byBkcmFmdHM/CgoyLiBS
YW5nZSBmb3IgZ3JvdXAtaWQgdXNlZnVsbG5lc3MuCgozLiBUaW1lcnMgc3BlY2lmaWVkIHdpdGgg
YSBuZXcgREhDUHY2IG9wdGlvbj8KCjQuIFNjb3BlIG9wdGlvbiBtYW5kYXRvcnk/Cgo1LiBESENQ
djYgaW4gdXNlcnNwYWNlIC0gbm90IGluIGtlcm5lbD8gIFByb2JsZW1zPwoKNi4gSVB2NCBtdWx0
aWNhc3QgYWRkcmVzcyBhc3NpZ25tZW50PyAgU2hvdWxkIHRoaXMgYmUgY29uc2lkZXJlZD8KCjcu
IFByZWZpeCBkZWxlZ2F0aW9uIGZvciBJUHY2IG11bHRpY2FzdCBhZGRyZXNzZXM/CgpEYXZlIFRo
YWxlciBzdWdnZXN0ZWQgTUFEQ0FQIHByb3ZpZGVzIG11bHRpY2FzdCBhZGRyZXNzIGFzc2lnbm1l
bnQsIGlzCnRoZXJlIGEgbmVlZCBmb3IgYSBuZXcgbWVjaGFuaXNtPyAgVGhlIGF1dGhvciByZXNw
b25kZWQgdGhhdCBNQURDQVAKZXhpc3RzLCBidXQgcGVvcGxlIGhhdmVuJ3QgYWN0dWFsbHkgZGVw
bG95ZWQgaXQuICBUaGFsZXIgYXNrZWQgaWYgdGhhdAppcyBhIHJlYXNvbiB0byB0cnkgdG8gZG8g
dGhpcyB3aXRoIERIQ1B2Niwgb3Igc2hvdWxkIE1BRENBUCBiZQpyZXF1aXJlZD8gIERhdmUgYWxz
byBhc2tlZCBpZiB3ZSBkbyB0aGlzIHdpdGggREhDUHY2LCB0aGVuIHdoYXQgZG8gd2UKYWJvdXQg
SVB2NCBtdWx0aWNhc3Q/CgoKQ2hhaXIgdG8gZGlzY3VzcyB0aGlzIGRyYWZ0IHdpdGggbWJvbmVk
IGNoYWlycyB0byBkZXRlcm1pbmUgd2hlcmUgdGhlCmRyYWZ0IHNob3VsZCBiZSByZXZpZXdlZCBh
bmQgaG93IHRvIG1vdmUgZm9yd2FyZC4KCkRIQ1B2NCBPcHRzLiBmb3IgQi1jYXN0IGFuZCBNLWNh
c3QgQ29udHJvbCBTZXJ2ZXJzIDxkcmFmdC1jaG93ZGh1cnktZGhjLWJjbWN2NC1vcHRpb24+CkRI
Q1B2NiBPcHRzLiBmb3IgQi1jYXN0IGFuZCBNLWNhc3QgQ29udHJvbCBTZXJ2ZXJzIDxkcmFmdC1j
aG93ZGh1cnktZGhjLWJjbWN2Ni1vcHRpb24+Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
CgpUaGVzZSB0d28gZHJhZnRzIHdlcmUgZGlzY3Vzc2VkIHRvZ2V0aGVyLiAgVGhlIGNoYWlyIHdp
bGwgZGlzY3Vzcwp0aGVzZSBkcmFmdHMgd2l0aCB0aGUgSW50ZXJuZXQgQURzIGFuZCB0aGUgM0dQ
UDIgbGlhaXNvbiB0byBkZXRlcm1pbmUKaG93IHRvIG1vdmUgdGhlIGRyYWZ0cyBmb3J3YXJkLgoK
SVB2NCBhbmQgSVB2NiBEdWFsLVN0YWNrIElzc3VlcyBmb3IgREhDUHY2IDxkcmFmdC1pZXRmLWRo
Yy1kdWFsLXN0YWNrPgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpUaGUgV0cgTWVldGluZyBjb25zZW5zdXMgd2Fz
IHRvIGNob29zZSBzZXBhcmF0ZSBzZXJ2ZXJzIGFzIHRoZQpzb2x1dGlvbiB0byBkdWFsLXN0YWNr
IERIQ1Agc2VydmljZS4gIERpc2N1c3Npb24gb2Ygb3RoZXIgcXVlc3Rpb25zCndpbGwgbW92ZSB0
byB0aGUgV0cgbWFpbGluZyBsaXN0LgoKPC94bXA+Cg==
--=====================_54347367==_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
--=====================_54347367==_--
From dhcwg-bounces@ietf.org Thu Sep 2 09:11:34 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01069;
Thu, 2 Sep 2004 09:11:34 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C2rFw-0008Vb-KC; Thu, 02 Sep 2004 09:04:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C2rBC-0005pd-EW
for dhcwg@megatron.ietf.org; Thu, 02 Sep 2004 08:59:06 -0400
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 IAA00134
for ; Thu, 2 Sep 2004 08:59:05 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33)
id 1C2rDa-0001CR-93
for dhcwg@ietf.org; Thu, 02 Sep 2004 09:01:35 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
by sj-iport-3.cisco.com with ESMTP; 02 Sep 2004 06:06:46 +0000
X-BrightmailFiltered: true
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
[161.44.122.62])
by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i82CwN2r006723;
Thu, 2 Sep 2004 05:58:31 -0700 (PDT)
Received: from volzw2k (che-vpn-cluster-2-79.cisco.com [10.86.242.79])
by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALG63924;
Thu, 2 Sep 2004 08:46:24 -0400 (EDT)
From: "Bernie Volz"
To: =?iso-8859-1?B?J0pJTk1FSSBUYXR1eWEgLyCQXy2+J0KNxic=?=
Subject: RE: [dhcwg] Re: one more comment about the lifetime option
Date: Thu, 2 Sep 2004 08:46:24 -0400
Organization: Cisco
Message-ID: <000701c490ea$db453770$6501a8c0@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.5709
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Importance: Normal
In-Reply-To:
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: quoted-printable
Cc: dhcwg@ietf.org, "'Ted Lemon'"
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable
> An authentication=20
> option can be used with Information-request and can have sub-options.
That's news to me and I don't see where this is possible based on RFC =
3315.
But in any case, its no big deal to specify that the option is =
restricted to
the message level.
- Bernie
> -----Original Message-----
> From: JINMEI Tatuya / =90_=96=BE=92B=8D=C6 =
[mailto:jinmei@isl.rdc.toshiba.co.jp]=20
> Sent: Thursday, September 02, 2004 5:21 AM
> To: Bernie Volz
> Cc: 'Ted Lemon'; dhcwg@ietf.org
> Subject: Re: [dhcwg] Re: one more comment about the lifetime option
>=20
>=20
> (forgot to reply to this...)
>=20
> I've changed the order of the citation below.
>=20
> >>>>> On Tue, 24 Aug 2004 20:55:14 -0400,
> >>>>> "Bernie Volz" said:
>=20
> >> > We should also restrict the position where the lifetime=20
> option can
> >> > appear: it should only be able to appear at the "top level"
> >> of option
> >> > hierarchy.
> >>=20
> >> I think this is a good idea.
>=20
> > If it is restricted to a REPLY to an INFORMATION-REQUEST,=20
> there is no=20
> > need for this explicit statement as that's all that is currently=20
> > possible - there are no IA_NA, IA_TA, or IA_PD options for these=20
> > messages.
>=20
> I don't think this is really the case. An authentication=20
> option can be used with Information-request and can have sub-options.
>=20
> JINMEI, Tatuya
> Communication Platform Lab.
> Corporate R&D Center,=20
> Toshiba Corp.
> jinmei@isl.rdc.toshiba.co.jp
>=20
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Thu Sep 2 10:31:56 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07774;
Thu, 2 Sep 2004 10:31:56 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C2sPQ-0004d4-3A; Thu, 02 Sep 2004 10:17:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C2sEP-0006vw-LM
for dhcwg@megatron.ietf.org; Thu, 02 Sep 2004 10:06:29 -0400
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 KAA04889
for ; Thu, 2 Sep 2004 10:06:28 -0400 (EDT)
Received: from marseille.netlab.nec.de ([195.37.70.15] helo=venus.office)
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2sGm-0006js-3r
for dhcwg@ietf.org; Thu, 02 Sep 2004 10:08:59 -0400
Received: from cadar.office (cadar.office [10.1.1.118])
by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id
D1ED816B168
for ; Thu, 2 Sep 2004 16:05:54 +0200 (CEST)
From: Cristian Cadar
Organization: NEC Europe Ltd.
To: dhcwg@ietf.org
Date: Thu, 2 Sep 2004 16:07:33 +0200
User-Agent: KMail/1.5.4
References: <20040825151559.GJ5677@sverresborg.uninett.no>
<000701c48b65$a23c6000$6401a8c0@amer.cisco.com>
<20040827083406.GA26829@login.ecs.soton.ac.uk>
In-Reply-To: <20040827083406.GA26829@login.ecs.soton.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200409021607.33096.Cristian.Cadar@netlab.nec.de>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: 7bit
Subject: [dhcwg] DHCPv6 Interop event - last call
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7bit
More details on event: http://www.dhcpv6.org/events.htm
Cristian
--
________________________________________________________
| Cristian Cadar cadar@netlab.nec.de
| Network Laboratories Heidelberg NEC Europe Ltd.
| Kurfuerstenanlage 36 D 69115 Heidelberg
| Tel. (+49) 6221 90511-21 Fax: (+49) 6221 90511-55
| URL: http://www.netlab.nec.de/heidelberg/index.html
| ________________________________________________________
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Thu Sep 2 17:32:47 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13520;
Thu, 2 Sep 2004 17:32:46 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C2z0d-0004gl-Ej; Thu, 02 Sep 2004 17:20:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C2yun-0002Fw-2e
for dhcwg@megatron.ietf.org; Thu, 02 Sep 2004 17:14:41 -0400
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 RAA12401
for ; Thu, 2 Sep 2004 17:14:38 -0400 (EDT)
Received: from [192.150.250.67] (helo=fuchsia.home)
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2yx3-0000ZU-1T
for dhcwg@ietf.org; Thu, 02 Sep 2004 17:17:14 -0400
Received: from delta.noi.kre.to (delta.ex0.home [192.168.192.22]) by
fuchsia.home with ESMTP
id i82LDV0v020440; Fri, 3 Sep 2004 04:13:31 +0700 (ICT)
Received: from munnari.OZ.AU (localhost [127.0.0.1])
by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i82LD7a1011954;
Fri, 3 Sep 2004 04:13:11 +0700 (ICT)
From: Robert Elz
To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on
draft-ietf-dhc-lifetime-01.txt)
In-Reply-To:
References:
<20040803033357.GA20506@sverresborg.uninett.no>
<6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com>
<20040901123029.GI15000@sverresborg.uninett.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 03 Sep 2004 04:13:07 +0700
Message-ID: <2221.1094159587@munnari.OZ.AU>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: dhcwg@ietf.org, Stig Venaas ,
Ted Lemon
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Date: Wed, 01 Sep 2004 23:52:32 +0900
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
Message-ID:
| ...but I don't want to delay this important work due to my pedantic
| ego. If others still want to leave those points to other documents,
| I'll obey that decision (but at least I want the "lifetime" document
| to mention those a bit and to say that those are beyond the scope of
| the doc).
There's no question of ego here.
The document is logically incomplete and meaningless if there's no
discussion (either in the document, or in a companion) of what happens
when a renewal attempt fails to achieve what was expected.
It is all obvious what to do when a "renewal" info request gets back the
same data as last time - even perhaps when it gives back that data, and
more. It may even be fairly obvious (if not quite as obvious) what to
do if there's no reply at all (dead dhcp server, or node moved to a location
where there is no server).
Dealing with replacement data (conceptually anyway) isn't hard to understand
(in some cases it might be hard to implement) - ut dealing with getting an
answer with some data missing is quite a different thing - it clearly isn't
the same case as not getting an answer at all.
Once again, the relevance of this to this doc is just that this doc is
incomplete without that extra detail specified somewhere. It is however
totally irrelevant what causes the new request to be made - whether it is
the expiration of one timer or another, or the detection of some kind of
"connected to a different link" signal, or even the (let's hope it is
defunct) proposal where the server sent out messages to clients telling
them to ignore previous timers and renew now.
Because of this, having the specification in a different (referenced,
and a normative ref at that) doc is an entirely reasonable thing to do.
But moving forward with this "explicitly demand refresh" doc without
any indication what should be done if it fails is simply not good enough.
kre
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From nv33134@yahoo.com Thu Sep 2 18:33:15 2004
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 SAA19023;
Thu, 2 Sep 2004 18:33:14 -0400 (EDT)
Date: Thu, 2 Sep 2004 18:33:14 -0400 (EDT)
Message-Id: <200409022233.SAA19023@ietf.org>
Received: from [218.12.34.234] (helo=ietf.org)
by ietf-mx.ietf.org with smtp (Exim 4.33)
id 1C30BI-0006ng-Mh; Thu, 02 Sep 2004 18:35:52 -0400
From: "Brasil 2004 / Informe Exclusivo"
To: MapaAtualizado2004@local.cnri.reston.va.us
Subject: Mapa atualizado da "esquerda católica"
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
MIME-Version: 1.0
Content-Type: text/html
X-Spam-Score: 30.7 (++++++++++++++++++++++++++++++)
X-Spam-Flag: YES
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Brasil 2004: reportagem desenha mapa atualizado da "esquerda católica"
* A "esquerda católica", sua influência visível na esfera sociopolítica, e seu poder subterrâneo através de redes capilares e "vasos comunicantes" no Brasil de hoje, é apresentada num livro-reportagem inédito de 56 páginas, de fácil leitura e ampla documentação.
* "Pastoral da Terra e MST incendeiam o País" é ao mesmo tempo um mapa atualizado e um instrumento informativo indispensável para quem deseja conhecer os possíveis rumos sociopolíticos do Brasil de amanhã.
* O autor, o advogado e pesquisador Gregorio Vivanco Lopes, com mais de 30 anos de especialização no tema das comunidades eclesiais de base e da teologia da libertação, mostra a real dimensão da Pastoral da Terra e do MST, duas pontas de um mesmo e gigantesco iceberg que a mídia nem sempre revela e que a opinião pública ignora.
* A força e o talão de Aquiles da "esquerda católica" descritas num informe objetivo, documentado e sereno que todo brasileiro deve ler, ainda que para discordar e debater de maneira invariavelmente respeitosa, em prol da paz social no Brasil.
* O autor do livreto "Pastoral da Terra e MST incendeiam o País" exerce o legítimo direito de informar, e favorece também o direito de cada brasileiro de ser informado, condições ambas indispensáveis para uma autêntica democracia.
* Solicite gratuitamente, por e-mail, o Índice e a Introdução contendo um resumo da reportagem e a capa da edição impressa:
* Envie seu voto eletrônico e, se possível, sua valiosa opinião a respeito do tema abordado, e receberá informação gratuita sobre próximos lançamentos:
* Caso deseje adquirir a versão impressa (R$ 10,00 correio incluído), clique no link: DesejoAdquirirLivro (receberá as instruções do distribuidor, de exclusiva responsabilidade deste).
* Caso deseje receber, por e-mail, o e-Book com o texto completo da reportagem (R$ 1,99), clique no link:
From dhcwg-bounces@ietf.org Fri Sep 3 01:32:40 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12971;
Fri, 3 Sep 2004 01:32:39 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C36bh-0006GW-1o; Fri, 03 Sep 2004 01:27:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C36Vr-0002Fc-Mr
for dhcwg@megatron.ietf.org; Fri, 03 Sep 2004 01:21:29 -0400
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 BAA12332
for ; Fri, 3 Sep 2004 01:21:26 -0400 (EDT)
Received: from mailout3.samsung.com ([203.254.224.33])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C36YN-0004yA-Fu
for dhcwg@ietf.org; Fri, 03 Sep 2004 01:24:05 -0400
Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com
(iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
id <0I3G006LP9IPX0@mailout3.samsung.com> for dhcwg@ietf.org; Fri,
03 Sep 2004 14:20:49 +0900 (KST)
Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33])
by mailout3.samsung.com
(iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
with ESMTP id <0I3G004RC9I8VH@mailout3.samsung.com> for dhcwg@ietf.org;
Fri, 03 Sep 2004 14:20:32 +0900 (KST)
Received: from SUMAN ([107.108.71.141])
by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built
Jun 23 2003)) with ESMTPA id <0I3G0085U9I5V6@mmp1.samsung.com> for
dhcwg@ietf.org; Fri, 03 Sep 2004 14:20:32 +0900 (KST)
Date: Fri, 03 Sep 2004 10:50:09 +0530
From: Suman
Subject: [dhcwg] Server Unicast Option in DCHPv6
To: dhcwg@ietf.org
Message-id: <000601c49175$b2e5eaf0$8d476c6b@sisodomain.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: multipart/mixed; boundary="===============0902264325=="
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
This is a multi-part message in MIME format.
--===============0902264325==
Content-type: multipart/alternative;
boundary="Boundary_(ID_35gpyzjZTtyySFeg0kAe+Q)"
This is a multi-part message in MIME format.
--Boundary_(ID_35gpyzjZTtyySFeg0kAe+Q)
Content-type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Hi,
I need some clarification on the Server Unicast Option, in DHCPv6,
RFC 3315.
In particular, when the client receives a Server Unicast option in an
advertise message and it has to send a request message to that server,
it unicasts the message to the server. That apart, should the client
include Server Unicast Option in the Request message that it sends?
Also, all the subsequent transaction between the client and that server
has to be unicast, if I have got it right! Does the client need to
include this option in all the subsequent message exchanges, Request
message in particular?
Any insight into this would be greatly appreciated.
Regards,
Suman.
--Boundary_(ID_35gpyzjZTtyySFeg0kAe+Q)
Content-type: text/html; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Hi,
I
need some clarification on the Server Unicast Option, in DHCPv6, RFC 3315.
In particular, when the client receives a Server
Unicast option in an advertise message and it has to send a request message to
that server, it unicasts the message to the server.
That apart, should the client include Server Unicast
Option in the Request message that it sends?
Also, all the subsequent transaction between the
client and that server has to be unicast, if I have got it right! Does the client need to include this option in all the subsequent
message exchanges, Request message in particular?
Any insight into this would be greatly appreciated.
Regards,
Suman.
--Boundary_(ID_35gpyzjZTtyySFeg0kAe+Q)--
--===============0902264325==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
--===============0902264325==--
From dhcwg-bounces@ietf.org Fri Sep 3 02:50:46 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02118;
Fri, 3 Sep 2004 02:50:46 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C37pi-0004wi-N9; Fri, 03 Sep 2004 02:46:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C37fD-0000yh-Qz
for dhcwg@megatron.ietf.org; Fri, 03 Sep 2004 02:35:12 -0400
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 CAA00904
for ; Fri, 3 Sep 2004 02:35:10 -0400 (EDT)
Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C37hl-00021s-1o
for dhcwg@ietf.org; Fri, 03 Sep 2004 02:37:50 -0400
Received: from ocean.jinmei.org (unknown [2001:200:0:8002:7036:3eab:f2f4:3846])
by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP
id 0B5C81525D; Fri, 3 Sep 2004 15:35:09 +0900 (JST)
Date: Fri, 03 Sep 2004 15:35:10 +0900
Message-ID:
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
To: "Bernie Volz"
Subject: Re: [dhcwg] Re: one more comment about the lifetime option
In-Reply-To: <000701c490ea$db453770$6501a8c0@amer.cisco.com>
References:
<000701c490ea$db453770$6501a8c0@amer.cisco.com>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0
(SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: dhcwg@ietf.org, "'Ted Lemon'"
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
>>>>> On Thu, 2 Sep 2004 08:46:24 -0400,
>>>>> "Bernie Volz" said:
>> An authentication
>> option can be used with Information-request and can have sub-options.
> That's news to me and I don't see where this is possible based on RFC 3315.
Ah, okay, I was wrong. The authentication option is a variable-length
option but does not take a sub-option according to RFC3315.
> But in any case, its no big deal to specify that the option is restricted to
> the message level.
That's correct. But at the same time, I believe we all agree that
there is no reason to allow the lifetime (or refresh timer) option
appearing as a sub-option.
We can prefer the former logic for the reason not to specify this
point in the document. We can also prefer the latter logic for the
reason to specify this point in the document. I believe this is a
matter of taste, and I myself can live with either approach. So, I'd
leave the decision to the document author.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
jinmei@isl.rdc.toshiba.co.jp
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Fri Sep 3 04:12:08 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06417;
Fri, 3 Sep 2004 04:12:08 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C397J-0001iG-7d; Fri, 03 Sep 2004 04:08:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C38wR-0005aH-Vs
for dhcwg@megatron.ietf.org; Fri, 03 Sep 2004 03:57:04 -0400
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 DAA05508
for ; Fri, 3 Sep 2004 03:57:02 -0400 (EDT)
Received: from tyholt.uninett.no ([158.38.60.10])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C38yz-0008Fi-KG
for dhcwg@ietf.org; Fri, 03 Sep 2004 03:59:43 -0400
Received: from sverresborg.uninett.no (sverresborg.uninett.no
[IPv6:2001:700:e000:0:204:75ff:fee4:423b])
by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i837uLOK025822;
Fri, 3 Sep 2004 09:56:21 +0200
Received: (from venaas@localhost)
by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i837uHO8022058;
Fri, 3 Sep 2004 09:56:17 +0200
X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to
Stig.Venaas@uninett.no using -f
Date: Fri, 3 Sep 2004 09:56:17 +0200
From: Stig Venaas
To: "JINMEI Tatuya / ?$B?@L@C#:H"
Subject: Re: [dhcwg] Re: one more comment about the lifetime option
Message-ID: <20040903075617.GA22032@sverresborg.uninett.no>
References:
<000701c490ea$db453770$6501a8c0@amer.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: dhcwg@ietf.org, Bernie Volz ,
"'Ted Lemon'"
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
On Fri, Sep 03, 2004 at 03:35:10PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> >>>>> On Thu, 2 Sep 2004 08:46:24 -0400,
> >>>>> "Bernie Volz" said:
>
> >> An authentication
> >> option can be used with Information-request and can have sub-options.
>
> > That's news to me and I don't see where this is possible based on RFC 3315.
>
> Ah, okay, I was wrong. The authentication option is a variable-length
> option but does not take a sub-option according to RFC3315.
>
> > But in any case, its no big deal to specify that the option is restricted to
> > the message level.
>
> That's correct. But at the same time, I believe we all agree that
> there is no reason to allow the lifetime (or refresh timer) option
> appearing as a sub-option.
Yes, I don't mind adding some wording to the fact. It's against the
whole idea to use it as a sub-option.
I must say though that I'm a little bit surprised this came up. I'm
not that into the world of DHCP, but I don't recall seeing specs for
other options saying this, and I had thought that they should only
be used as sub-options if specified as such. Or is the idea that in
general, any option could be used as a sub-option?
I think though that the IRT (lifetime) option might appear to make
sense as a sub-option, while many other options pretty obviously
don't make sense. So I'm happy to add the wording, just to avoid
possible misuse.
Stig
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Fri Sep 3 05:17:35 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09668;
Fri, 3 Sep 2004 05:17:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C39ro-0002ci-Bb; Fri, 03 Sep 2004 04:56:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C39XX-0004id-II
for dhcwg@megatron.ietf.org; Fri, 03 Sep 2004 04:35:23 -0400
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 EAA07491
for ; Fri, 3 Sep 2004 04:35:21 -0400 (EDT)
Received: from tyholt.uninett.no ([158.38.60.10])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C39a5-0002pg-TD
for dhcwg@ietf.org; Fri, 03 Sep 2004 04:38:02 -0400
Received: from sverresborg.uninett.no (sverresborg.uninett.no
[IPv6:2001:700:e000:0:204:75ff:fee4:423b])
by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i838YoOK005520;
Fri, 3 Sep 2004 10:34:50 +0200
Received: (from venaas@localhost)
by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i838YoQR022124;
Fri, 3 Sep 2004 10:34:50 +0200
X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to
Stig.Venaas@uninett.no using -f
Date: Fri, 3 Sep 2004 10:34:50 +0200
From: Stig Venaas
To: "JINMEI Tatuya / ?$B?@L@C#:H"
Subject: Re: [dhcwg] behavior on lifetime expiration (Re:
comments on draft-ietf-dhc-lifetime-01.txt)
Message-ID: <20040903083450.GA22060@sverresborg.uninett.no>
References:
<20040803033357.GA20506@sverresborg.uninett.no>
<6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com>
<20040901123029.GI15000@sverresborg.uninett.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: dhcwg@ietf.org, Ted Lemon
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
On Wed, Sep 01, 2004 at 11:52:32PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> >>>>> On Wed, 1 Sep 2004 14:30:29 +0200,
> >>>>> Stig Venaas said:
>
> > What you write sounds reasonable, but I'm still not sure we should go
> > into the details. The reason is that we don't know in general what
> > the behaviour should be, and it's a generic issue. It's obviously a
> > related issue though. We could as Ted suggests, specify this later
> > when we have more information. That could either be as an update to
> > the lifetime RFC, or IMO perhaps better, add some text if an update
> > to RFC 3315 is done. There seems to be other reasons to update RFC
> > 3315 too (draft-jinmei-dhc-dhcpv6-clarify-auth-00?).
>
> I would first like to note that the suggestion by Ted of leaving it to
> a later document was followed by his response to me where he agreed
> (or at least seemed to agree) with my proposal.
Yes
> Secondly, if I understand the sense in this list correctly, I believe
> my proposal reflects some level of consensus here.
Yes, my impression too. Note that I'm saying that I don't think we
should go into details, I think it's reasonable to write something.
I just think that this document isn't the right place to solve that
issue. Also, since the issue is present when not implementing this
draft, I believe it's good to specify some text in a place where it
will be read by those not implementing this option.
> Third, I personally think we can reflect the proposal without making
> the document unnecessarily long. (If you want, I'll try to contribute
> to some text.)
>
> So, I personally think it makes sense to clarify the points at this
> chance even though the points can be extended to general issues.
Yes, so I would suggest adding some text, see suggestion below, that
raises the issue and gives some general recommendation, without
being too strict (no MUSTs).
> ...but I don't want to delay this important work due to my pedantic
> ego. If others still want to leave those points to other documents,
> I'll obey that decision (but at least I want the "lifetime" document
> to mention those a bit and to say that those are beyond the scope of
> the doc).
The latter part I agree with. I really welcome your comments, I don't
always agree with them, but you have raised many interesting issues,
and helped improve the draft.
> > In general I agree with your distinction between still and moving
> > clients. What worries me though, is that it might not be possible for
> > a client to distinguish between movement and renumbering. The fact
> > that a new prefix is announced in RAs is not sufficient.
>
> As I said in my previous message, I basically think we can concentrate
> on the "still" clients in this document, and do not have to worry
> too much about miscellaneous subtle cases of moving vs
> not-actually-moving. Movement detection is itself a difficult
> challenge (we even have a dedicated wg on this!), so I think it is
> enough in the scope of dhc wg to show some preliminary considerations
> on the moving clients (e.g., as shown in Section 18.1.2 of RFC3315.).
Right.
[Deleted some text below that I agree with]
So how about something like this:
When a client receives a Reply to an Information-Request that
contains configuration information (i.e., does not contain a
Status Code option), it SHOULD install that new configuration
information after removing any previously received configuration
information. There may be reasons not to always do this. One
example might be when client has indication that it has moved to
a new link. How a client copes with movement is outside the scope
of this document.
I'm not not sure if it should be "SHOULD" or "should" there. At
least I don't see this as part of the protocol. In my opinion
the idea is just to give a general recommendation or some guidance
to implementors.
Stig
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Fri Sep 3 06:10:05 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14092;
Fri, 3 Sep 2004 06:10:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C3Atb-0002jp-SC; Fri, 03 Sep 2004 06:02:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C3AVf-0002Nx-0w
for dhcwg@megatron.ietf.org; Fri, 03 Sep 2004 05:37:31 -0400
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 FAA10904;
Fri, 3 Sep 2004 05:37:28 -0400 (EDT)
Received: from mailout3.samsung.com ([203.254.224.33])
by ietf-mx.ietf.org with esmtp (Exim 4.33)
id 1C3AYD-0007PO-5K; Fri, 03 Sep 2004 05:40:10 -0400
Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com
(iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
id <0I3G0060TLD5P3@mailout3.samsung.com>;
Fri, 03 Sep 2004 18:36:41 +0900 (KST)
Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33])
by mailout3.samsung.com
(iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
with ESMTP id <0I3G00JF7LD5M3@mailout3.samsung.com>; Fri,
03 Sep 2004 18:36:41 +0900 (KST)
Received: from LocalHost ([168.219.202.103])
by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built
Jun 23 2003)) with ESMTPA id <0I3G003GOLD428@mmp2.samsung.com>; Fri,
03 Sep 2004 18:36:41 +0900 (KST)
Date: Fri, 03 Sep 2004 18:37:53 +0900
From: "S. Daniel Park"
Subject: RE: [dhcwg] Minutes from IETF 60 dhc WG meeting
In-reply-to: <4.3.2.7.2.20040902082231.0200cbe8@flask.cisco.com>
To: Ralph Droms , proceedings@ietf.org
Message-id:
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Content-Transfer-Encoding: 7BIT
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7BIT
One typo for me..
>The chair announced that Samung has published a zero-cost licensing
>IPR claim on draft-ietf-dhc-rapid-commit-opt-05.txt. There was no
>objection in the WG to moving the draft draft forward.
s/Samung/Samsung
Thanks
- Daniel (Soohong Daniel Park)
- Mobile Platform Lab. Samsung Electronics.
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Fri Sep 3 07:48:07 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21163;
Fri, 3 Sep 2004 07:48:07 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C3CWJ-00051y-Nh; Fri, 03 Sep 2004 07:46:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C3CVB-0004gU-Gt
for dhcwg@megatron.ietf.org; Fri, 03 Sep 2004 07:45:09 -0400
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 HAA20994
for ; Fri, 3 Sep 2004 07:45:08 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3CXm-0000Di-JN
for dhcwg@ietf.org; Fri, 03 Sep 2004 07:47:50 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13)
by rtp-iport-2.cisco.com with ESMTP; 03 Sep 2004 07:44:40 -0400
X-BrightmailFiltered: true
Received: from flask.cisco.com (flask.cisco.com [161.44.122.62])
by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i83BiZ6r010633;
Fri, 3 Sep 2004 07:44:37 -0400 (EDT)
Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-212.cisco.com
[10.86.242.212]) by flask.cisco.com (MOS 3.4.6-GR)
with ESMTP id ALH42614; Fri, 3 Sep 2004 07:44:34 -0400 (EDT)
Message-Id: <4.3.2.7.2.20040903074356.01f618f8@flask.cisco.com>
X-Sender: rdroms@flask.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 03 Sep 2004 07:44:32 -0400
To: "S. Daniel Park"
From: Ralph Droms
Subject: RE: [dhcwg] Minutes from IETF 60 dhc WG meeting
In-Reply-To:
References: <4.3.2.7.2.20040902082231.0200cbe8@flask.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Good catch. Thanks...
I just sent off revised minutes with several typo corrections.
- Ralph
At 06:37 PM 9/3/2004 +0900, S. Daniel Park wrote:
>One typo for me..
>
> >The chair announced that Samung has published a zero-cost licensing
> >IPR claim on draft-ietf-dhc-rapid-commit-opt-05.txt. There was no
> >objection in the WG to moving the draft draft forward.
>
>
>s/Samung/Samsung
>
>
>Thanks
>
>
>- Daniel (Soohong Daniel Park)
>- Mobile Platform Lab. Samsung Electronics.
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Fri Sep 3 23:45:58 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05974;
Fri, 3 Sep 2004 23:45:58 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C3RJd-000824-BS; Fri, 03 Sep 2004 23:34:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C3RJ8-0007qp-S8
for dhcwg@megatron.ietf.org; Fri, 03 Sep 2004 23:33:43 -0400
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 XAA05417
for ; Fri, 3 Sep 2004 23:33:39 -0400 (EDT)
Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3RLq-0007rs-UG
for dhcwg@ietf.org; Fri, 03 Sep 2004 23:36:32 -0400
Received: from ocean.jinmei.org (unknown [2001:200:0:8002:545c:249b:d371:bb2c])
by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP
id 4CEAA15263; Sat, 4 Sep 2004 12:33:35 +0900 (JST)
Date: Sat, 04 Sep 2004 12:33:37 +0900
Message-ID:
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
To: Stig Venaas
Subject: Re: [dhcwg] behavior on lifetime expiration (Re:
comments on draft-ietf-dhc-lifetime-01.txt)
In-Reply-To: <20040903083450.GA22060@sverresborg.uninett.no>
References:
<20040803033357.GA20506@sverresborg.uninett.no>
<6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com>
<20040901123029.GI15000@sverresborg.uninett.no>
<20040903083450.GA22060@sverresborg.uninett.no>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0
(SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: dhcwg@ietf.org, Ted Lemon
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
>>>>> On Fri, 3 Sep 2004 10:34:50 +0200,
>>>>> Stig Venaas said:
> So how about something like this:
> When a client receives a Reply to an Information-Request that
> contains configuration information (i.e., does not contain a
> Status Code option), it SHOULD install that new configuration
> information after removing any previously received configuration
> information. There may be reasons not to always do this. One
> example might be when client has indication that it has moved to
> a new link. How a client copes with movement is outside the scope
> of this document.
> I'm not not sure if it should be "SHOULD" or "should" there. At
> least I don't see this as part of the protocol. In my opinion
> the idea is just to give a general recommendation or some guidance
> to implementors.
The proposed text basically looks fine. But I'd be a bit more
specific that the above description means if the new configuration
information does not have any update on a particular instance of the
old information (e.g., DNS server list) the client will simply remove
the old information.
As for "SHOULD" vs "should", I don't have a strong opinion. If you
prefer "should", please just go for it.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
jinmei@isl.rdc.toshiba.co.jp
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Sat Sep 4 02:26:03 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27832;
Sat, 4 Sep 2004 02:26:03 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C3Txu-0007O8-Pn; Sat, 04 Sep 2004 02:23:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C3TuY-0005lm-Dw
for dhcwg@megatron.ietf.org; Sat, 04 Sep 2004 02:20:30 -0400
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 CAA27354
for ; Sat, 4 Sep 2004 02:20:29 -0400 (EDT)
Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3TxI-0002S9-2j
for dhcwg@ietf.org; Sat, 04 Sep 2004 02:23:21 -0400
Received: from ocean.jinmei.org (unknown [2001:200:0:8002:545c:249b:d371:bb2c])
by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP
id 7F7291525D; Sat, 4 Sep 2004 15:20:26 +0900 (JST)
Date: Sat, 04 Sep 2004 15:20:27 +0900
Message-ID:
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
To: Stig Venaas
Subject: Re: [dhcwg] Re: one more comment about the lifetime option
In-Reply-To: <20040903075617.GA22032@sverresborg.uninett.no>
References:
<000701c490ea$db453770$6501a8c0@amer.cisco.com>
<20040903075617.GA22032@sverresborg.uninett.no>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0
(SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: dhcwg@ietf.org, Bernie Volz ,
"'Ted Lemon'"
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
>>>>> On Fri, 3 Sep 2004 09:56:17 +0200,
>>>>> Stig Venaas said:
>> Ah, okay, I was wrong. The authentication option is a variable-length
>> option but does not take a sub-option according to RFC3315.
>>
>> > But in any case, its no big deal to specify that the option is restricted to
>> > the message level.
>>
>> That's correct. But at the same time, I believe we all agree that
>> there is no reason to allow the lifetime (or refresh timer) option
>> appearing as a sub-option.
> Yes, I don't mind adding some wording to the fact. It's against the
> whole idea to use it as a sub-option.
> I must say though that I'm a little bit surprised this came up. I'm
> not that into the world of DHCP, but I don't recall seeing specs for
> other options saying this, and I had thought that they should only
> be used as sub-options if specified as such. Or is the idea that in
> general, any option could be used as a sub-option?
I think your understanding is basically correct. RFC3315 says in
Section 22 that:
Unless otherwise noted, each option may appear only in the options
area of a DHCP message and may appear only once.
The term "options area" does not seem to be officially defined in the
RFC, but it should be natural to interpret this to mean areas which
are not a sub-option of a separate option.
But at the same time, the RFC explicitly mentions the default
restriction in some places. For example, in Section 22.5 it says:
An IA_TA option may only appear in the options area of a DHCP
message.
And,
> I think though that the IRT (lifetime) option might appear to make
> sense as a sub-option, while many other options pretty obviously
> don't make sense. So I'm happy to add the wording, just to avoid
> possible misuse.
this is exactly my point.
I believe it depends on whether we want to avoid possible misuse
explicitly. And then it depends on how we asses the possibility of
the misuse. Of course, the sense on this may vary among people (so I
won't push my preference). But if we recall that we are talking
about this in the context where we are trying to add a note that a
single IRT (or lifetime) optin should be common for all possible
information resources, I personally think it's reasonable to add an
explicit note here.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
jinmei@isl.rdc.toshiba.co.jp
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Sat Sep 4 16:38:38 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06069;
Sat, 4 Sep 2004 16:38:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C3hGb-0006fx-Bs; Sat, 04 Sep 2004 16:36:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C3hCr-0006L9-2Q
for dhcwg@megatron.ietf.org; Sat, 04 Sep 2004 16:32:17 -0400
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 QAA05800
for ; Sat, 4 Sep 2004 16:32:14 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3hFj-00085W-TW
for dhcwg@ietf.org; Sat, 04 Sep 2004 16:35:16 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
by sj-iport-5.cisco.com with ESMTP; 04 Sep 2004 13:31:49 -0700
X-BrightmailFiltered: true
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
[161.44.122.62])
by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i84KVg8J000480;
Sat, 4 Sep 2004 13:31:43 -0700 (PDT)
Received: from volzw2k (che-vpn-cluster-2-171.cisco.com [10.86.242.171])
by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALI20371;
Sat, 4 Sep 2004 16:31:41 -0400 (EDT)
From: "Bernie Volz"
To: "'Suman'" ,
Subject: RE: [dhcwg] Server Unicast Option in DCHPv6
Date: Sat, 4 Sep 2004 16:31:43 -0400
Organization: Cisco
Message-ID: <000c01c492be$31311bc0$6501a8c0@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.5709
In-Reply-To: <000601c49175$b2e5eaf0$8d476c6b@sisodomain.com>
x-mimeole: Produced By Microsoft MimeOLE V5.50.4939.300
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Content-Transfer-Encoding: quoted-printable
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable
The unicast option is only server to client; not client to server. So, =
no
the client does not send the option.
There is no hard requirement for a client to use unicast. From the =
option
description in RFC 3315:
The server specifies the IPv6 address to which the client is to send
unicast messages in the server-address field. When a client receives
this option, where permissible and appropriate, the client sends
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
messages directly to the server using the IPv6 address specified in
the server-address field of the option.
When the server sends a Unicast option to the client, some messages
from the client will not be relayed by Relay Agents, and will not
include Relay Agent options from the Relay Agents. Therefore, a
server should only send a Unicast option to a client when Relay
Agents are not sending Relay Agent options. A DHCP server rejects
any messages sent inappropriately using unicast to ensure that
messages are relayed by Relay Agents when Relay Agent options are in
use.
Details about when the client may send messages to the server using
unicast are in section 18.
-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf =
Of
Suman
Sent: Friday, September 03, 2004 1:20 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Server Unicast Option in DCHPv6
Hi,
=20
I need some clarification on the Server Unicast Option, in DHCPv6, =
RFC
3315.=20
=20
In particular, when the client receives a Server Unicast option in an
advertise message and it has to send a request message to that server, =
it
unicasts the message to the server. That apart, should the client =
include
Server Unicast Option in the Request message that it sends?=20
=20
Also, all the subsequent transaction between the client and that server =
has
to be unicast, if I have got it right! Does the client need to include =
this
option in all the subsequent message exchanges, Request message in
particular?
=20
Any insight into this would be greatly appreciated.=20
=20
Regards,
Suman.
=20
=20
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Mon Sep 6 04:49:20 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14916;
Mon, 6 Sep 2004 04:49:20 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C4F9q-0001bS-DB; Mon, 06 Sep 2004 04:47:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C4F6g-0000qm-Mu
for dhcwg@megatron.ietf.org; Mon, 06 Sep 2004 04:44:11 -0400
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 EAA14665
for ; Mon, 6 Sep 2004 04:44:08 -0400 (EDT)
Received: from tyholt.uninett.no ([158.38.60.10])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4F9p-00022g-Mj
for dhcwg@ietf.org; Mon, 06 Sep 2004 04:47:29 -0400
Received: from sverresborg.uninett.no (sverresborg.uninett.no
[IPv6:2001:700:e000:0:204:75ff:fee4:423b])
by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i868hVOK025607;
Mon, 6 Sep 2004 10:43:32 +0200
Received: (from venaas@localhost)
by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i868hRVT008421;
Mon, 6 Sep 2004 10:43:27 +0200
X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to
Stig.Venaas@uninett.no using -f
Date: Mon, 6 Sep 2004 10:43:27 +0200
From: Stig Venaas
To: "JINMEI Tatuya / ?$B?@L@C#:H"
Subject: Re: [dhcwg] behavior on lifetime expiration (Re:
comments on draft-ietf-dhc-lifetime-01.txt)
Message-ID: <20040906084327.GA8343@sverresborg.uninett.no>
References: <20040803033357.GA20506@sverresborg.uninett.no>
<6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com>
<20040901123029.GI15000@sverresborg.uninett.no>
<20040903083450.GA22060@sverresborg.uninett.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: dhcwg@ietf.org, Ted Lemon
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
On Sat, Sep 04, 2004 at 12:33:37PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> >>>>> On Fri, 3 Sep 2004 10:34:50 +0200,
> >>>>> Stig Venaas said:
>
> > So how about something like this:
>
> > When a client receives a Reply to an Information-Request that
> > contains configuration information (i.e., does not contain a
> > Status Code option), it SHOULD install that new configuration
> > information after removing any previously received configuration
> > information. There may be reasons not to always do this. One
> > example might be when client has indication that it has moved to
> > a new link. How a client copes with movement is outside the scope
> > of this document.
>
> > I'm not not sure if it should be "SHOULD" or "should" there. At
> > least I don't see this as part of the protocol. In my opinion
> > the idea is just to give a general recommendation or some guidance
> > to implementors.
>
> The proposed text basically looks fine. But I'd be a bit more
> specific that the above description means if the new configuration
> information does not have any update on a particular instance of the
> old information (e.g., DNS server list) the client will simply remove
> the old information.
Note that I say "after removing any previously received configuration
information". To me at least, that says that ALL the previously
received data is removed when receiving new information. It doesn't in
any way say that this is on a per option basis. E.g. if you previously
received options A, B and C, and you in the new message receive only a
new option D, then you should still remove previous information (A, B
and C).
But, if you still think this is not clear, I will try to improve it. If
it's not clear to you, then it may not be clear to others either.
Stig
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Tue Sep 7 05:08:28 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02859;
Tue, 7 Sep 2004 05:08:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C4bvg-0003LP-PA; Tue, 07 Sep 2004 05:06:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C4brb-0002Vr-PX
for dhcwg@megatron.ietf.org; Tue, 07 Sep 2004 05:02:08 -0400
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 FAA02263
for ; Tue, 7 Sep 2004 05:02:05 -0400 (EDT)
Received: from tyholt.uninett.no ([158.38.60.10])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4bv0-00081B-UU
for dhcwg@ietf.org; Tue, 07 Sep 2004 05:05:39 -0400
Received: from sverresborg.uninett.no (sverresborg.uninett.no
[IPv6:2001:700:e000:0:204:75ff:fee4:423b])
by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i8790VOK010237;
Tue, 7 Sep 2004 11:00:31 +0200
Received: (from venaas@localhost)
by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i8790TU2018175;
Tue, 7 Sep 2004 11:00:29 +0200
X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to
Stig.Venaas@uninett.no using -f
Date: Tue, 7 Sep 2004 11:00:29 +0200
From: Stig Venaas
To: "JINMEI Tatuya / ?$B?@L@C#:H"
Subject: Re: [dhcwg] behavior on lifetime expiration (Re:
comments on draft-ietf-dhc-lifetime-01.txt)
Message-ID: <20040907090029.GB17934@sverresborg.uninett.no>
References:
<6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com>
<20040901123029.GI15000@sverresborg.uninett.no>
<20040903083450.GA22060@sverresborg.uninett.no>
<20040906084327.GA8343@sverresborg.uninett.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040906084327.GA8343@sverresborg.uninett.no>
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: dhcwg@ietf.org, Ted Lemon
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
On Mon, Sep 06, 2004 at 10:43:27AM +0200, Stig Venaas wrote:
> On Sat, Sep 04, 2004 at 12:33:37PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> > >>>>> On Fri, 3 Sep 2004 10:34:50 +0200,
> > >>>>> Stig Venaas said:
> >
> > > So how about something like this:
> >
> > > When a client receives a Reply to an Information-Request that
> > > contains configuration information (i.e., does not contain a
> > > Status Code option), it SHOULD install that new configuration
> > > information after removing any previously received configuration
> > > information. There may be reasons not to always do this. One
> > > example might be when client has indication that it has moved to
> > > a new link. How a client copes with movement is outside the scope
> > > of this document.
> >
> > > I'm not not sure if it should be "SHOULD" or "should" there. At
> > > least I don't see this as part of the protocol. In my opinion
> > > the idea is just to give a general recommendation or some guidance
> > > to implementors.
> >
> > The proposed text basically looks fine. But I'd be a bit more
> > specific that the above description means if the new configuration
> > information does not have any update on a particular instance of the
> > old information (e.g., DNS server list) the client will simply remove
> > the old information.
Since I felt the need to explain further what I meant, I should put
something in the draft too. I've now changed it to this:
When a client receives a Reply to an Information-Request that
contains configuration information (i.e., does not contain a
Status Code option), it should install that new configuration
information after removing any previously received configuration
information. Note that it should also remove information that
is missing from the new information set, e.g. an option might be
left out or contain only a subset of what it did previously.
There may be reasons not to always do this. One example might
be when client has indication that it has moved to a new link.
How a client copes with movement is outside the scope of this
document.
Stig
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Tue Sep 7 09:25:42 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20676;
Tue, 7 Sep 2004 09:25:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C4fos-0006OJ-KZ; Tue, 07 Sep 2004 09:15:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C4fhx-00055d-33
for dhcwg@megatron.ietf.org; Tue, 07 Sep 2004 09:08:25 -0400
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 JAA19414
for ; Tue, 7 Sep 2004 09:08:23 -0400 (EDT)
Received: from hoemail1.lucent.com ([192.11.226.161])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4flN-0003kM-M6
for dhcwg@ietf.org; Tue, 07 Sep 2004 09:11:58 -0400
Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10])
by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i87D82gm014119;
Tue, 7 Sep 2004 08:08:13 -0500 (CDT)
Received: from kraken.mh.lucent.com by homail.ho.lucent.com
(8.11.7+Sun/EMS-1.5 sol2)
id i87D80101458; Tue, 7 Sep 2004 09:08:00 -0400 (EDT)
From: Joe Quanaim
To: JINMEI Tatuya /
=?utf-8?q?=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89=09?=,
Stig Venaas
Subject: Re: [dhcwg] Re: one more comment about the lifetime option
Date: Tue, 7 Sep 2004 09:07:59 -0400
User-Agent: KMail/1.5.4
References:
<20040903075617.GA22032@sverresborg.uninett.no>
In-Reply-To:
MIME-Version: 1.0
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200409070907.59505.jdq@lucent.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: quoted-printable
Cc: dhcwg@ietf.org, Bernie Volz ,
"'Ted Lemon'"
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jdq@lucent.com
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable
JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote:
> > I think though that the IRT (lifetime) option might appear to make
> > sense as a sub-option, while many other options pretty obviously
> > don't make sense. So I'm happy to add the wording, just to avoid
> > possible misuse.
>
> this is exactly my point.
>
> I believe it depends on whether we want to avoid possible misuse
> explicitly. And then it depends on how we asses the possibility of
> the misuse. Of course, the sense on this may vary among people (so I
> won't push my preference). But if we recall that we are talking
> about this in the context where we are trying to add a note that a
> single IRT (or lifetime) optin should be common for all possible
> information resources, I personally think it's reasonable to add an
> explicit note here.
I also think it is worthwhile to add text limiting this option's position t=
o=20
the message options.
Joe.
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Tue Sep 7 09:29:15 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20972;
Tue, 7 Sep 2004 09:29:15 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C4fov-0006PL-FL; Tue, 07 Sep 2004 09:15:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C4flz-0005ak-Ef
for dhcwg@megatron.ietf.org; Tue, 07 Sep 2004 09:12:35 -0400
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 JAA19684
for ; Tue, 7 Sep 2004 09:12:33 -0400 (EDT)
Received: from hoemail1.lucent.com ([192.11.226.161])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4fpR-0003ml-2i
for dhcwg@ietf.org; Tue, 07 Sep 2004 09:16:09 -0400
Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10])
by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i87DCGNh021602;
Tue, 7 Sep 2004 08:12:23 -0500 (CDT)
Received: from kraken.mh.lucent.com by homail.ho.lucent.com
(8.11.7+Sun/EMS-1.5 sol2)
id i87DCD102925; Tue, 7 Sep 2004 09:12:13 -0400 (EDT)
From: Joe Quanaim
To: Stig Venaas ,
"JINMEI Tatuya / ?$B?@L@C#:H"
Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on
draft-ietf-dhc-lifetime-01.txt)
Date: Tue, 7 Sep 2004 09:12:13 -0400
User-Agent: KMail/1.5.4
References:
<20040906084327.GA8343@sverresborg.uninett.no>
<20040907090029.GB17934@sverresborg.uninett.no>
In-Reply-To: <20040907090029.GB17934@sverresborg.uninett.no>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200409070912.13081.jdq@lucent.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7bit
Cc: dhcwg@ietf.org, Ted Lemon
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jdq@lucent.com
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7bit
Stig Venaas wrote:
> When a client receives a Reply to an Information-Request that
> contains configuration information (i.e., does not contain a
> Status Code option), it should install that new configuration
> information after removing any previously received configuration
> information. Note that it should also remove information that
> is missing from the new information set, e.g. an option might be
> left out or contain only a subset of what it did previously.
> There may be reasons not to always do this. One example might
> be when client has indication that it has moved to a new link.
> How a client copes with movement is outside the scope of this
> document.
Should "does not contain a Status Code option" be replaced with "does not
contain a negative Status Code option"? A status code of 0 should be
acceptable.
Otherwise, this text looks good.
Joe.
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Tue Sep 7 16:17:15 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27758;
Tue, 7 Sep 2004 16:17:15 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C4mAN-0004a4-HA; Tue, 07 Sep 2004 16:02:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C4m4y-0001MQ-I4; Tue, 07 Sep 2004 15:56:36 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26087;
Tue, 7 Sep 2004 15:56:34 -0400 (EDT)
Message-Id: <200409071956.PAA26087@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Date: Tue, 07 Sep 2004 15:56:33 -0400
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-subscriber-id-07.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.
Title : DHCP Subscriber ID Suboption for the DHCP Relay Agent Option
Author(s) : R. Johnson, et al.
Filename : draft-ietf-dhc-subscriber-id-07.txt
Pages : 10
Date : 2004-9-7
This memo defines a new Subscriber-ID suboption for the Dynamic Host
Configuration Protocol's (DHCP) relay agent information option. The
suboption allows a DHCP relay agent to associate a stable
'Subscriber-ID' with DHCP client messages in a way that is
independent of the client and of the underlying physical network
infrastructure.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-subscriber-id-07.txt
To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dhc-subscriber-id-07.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-dhc-subscriber-id-07.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <2004-9-7152019.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-subscriber-id-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-subscriber-id-07.txt"; site="ftp.ietf.org";
access-type="anon-ftp"; directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2004-9-7152019.I-D@ietf.org>
--OtherAccess--
--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
--NextPart--
From dhcwg-bounces@ietf.org Tue Sep 7 17:40:16 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09441;
Tue, 7 Sep 2004 17:40:16 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C4nP8-0003zh-EU; Tue, 07 Sep 2004 17:21:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C4mqG-0001JF-9w
for dhcwg@megatron.ietf.org; Tue, 07 Sep 2004 16:45:28 -0400
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 QAA02987
for ; Tue, 7 Sep 2004 16:45:25 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4mtl-0006mB-GY
for dhcwg@ietf.org; Tue, 07 Sep 2004 16:49:06 -0400
Received: from sj-core-4.cisco.com (171.68.223.138)
by sj-iport-5.cisco.com with ESMTP; 07 Sep 2004 13:44:53 -0700
X-BrightmailFiltered: true
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com
[161.44.122.62])
by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i87Kib6l003692;
Tue, 7 Sep 2004 13:44:38 -0700 (PDT)
Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR)
with ESMTP id ALJ34976; Tue, 7 Sep 2004 16:44:36 -0400 (EDT)
From: "Bernie Volz"
To: , "'Ted Lemon'"
Subject: RE: [dhcwg] Re: I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt - NEED INPUT
BEFORE REVISING DRAFT!
Date: Tue, 7 Sep 2004 16:44:36 -0400
Organization: Cisco
Message-ID: <002301c4951b$7d08c980$efa0560a@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.5709
x-mimeole: Produced By Microsoft MimeOLE V5.50.4939.300
In-Reply-To: <005001c483e9$cd040d70$d0412ca1@amer.cisco.com>
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250
Content-Transfer-Encoding: quoted-printable
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable
Hi again:
Before I revise the draft, please let me know if you think it is worth
doing. The choices are:
1. Allow only the simple case for now (ie, Client FQDN option in an =
IA_NA or
IA_TA options field applies to all addresses in the IA). We can always =
add
the complex case (using a bit) in the future.
2. Allow both the simple and more complex case (latter is as currently
documented); we'd use a bit in the flags field to indicate whether the
client supports the complex method and wants to use (server can support =
it
or not). Default (bit not set) is simple-only.
3. Come up with a completely different approach the problem (ideas?).
4. Abandon this work (if there's no interest in it).
- Bernie Volz
> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20
> On Behalf Of Bernie Volz
> Sent: Monday, August 16, 2004 7:36 PM
> To: 'Ted Lemon'
> Cc: dhcwg@ietf.org
> Subject: RE: [dhcwg] Re: I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt
>=20
>=20
> Ted:
>=20
> Thanks for your feedback on this issue.
>=20
> Others, please chime in with your thoughts/opinions.
>=20
> One possibility is to allow both.
>=20
> The simple case just has the client FQDN option in the=20
> IA_*-options field for both the client and server and one=20
> name applies to all of the address.
>=20
> The complex case (if the server determines that a unique name=20
> is required for each address) it can use the alternate form -=20
> putting the client FQDN option into the IAaddr-options field=20
> (as currently specified).
>=20
> Since it requires client (and server) support for the complex=20
> case, we can use a "flag" bit to allow the client to specify=20
> whether it can support the complex case. By default (if the=20
> bit is 0), the client (and server) can only use the simple=20
> case. If the bit is set, it is up to the server to determine=20
> whether to use the simple or complex case, based on the=20
> addresses and the configuration.
>=20
> - Bernie
>=20
> > -----Original Message-----
> > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]
> > On Behalf Of Ted Lemon
> > Sent: Monday, August 16, 2004 2:39 PM
> > To: Bernie Volz
> > Cc: dhcwg@ietf.org
> > Subject: [dhcwg] Re: I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt
> >=20
> >=20
> > Bernie, the problem I have with the complex model for the=20
> DHCPv6 FQDN
> > option is that I can't imagine any of the scenarios you=20
> describe ever=20
> > having a meaning in practice. A computer is a computer. =20
> It has a=20
> > name. One name. If you give it multiple names, that=20
> doesn't have=20
> > any meaning, generally speaking. The exception is when you are=20
> > configuring a single computer to present more than one=20
> > identity on the=20
> > network. In this case, it makes sense that each identity=20
> would have=20
> > its own name.
> >=20
> > So I think it makes sense to have a one-to-one mapping=20
> between names=20
> > and identity associations. I do not think it makes sense to=20
> > break it=20
> > down below this point. Let's consider some of the=20
> scenarios you've=20
> > proposed. First, let's consider number four, which you say you=20
> > consider most likely.
> >=20
> > In this case, the client has a single identity, and gets both a=20
> > globally-scoped address and a locally-scoped address. So=20
> > what does it=20
> > make sense to do here? We have several options:
> >=20
> > 1. Publish the name with the global address.
> > 2. Publish the name with both the global and site-local
> > address. 3. Publish two names, one for the global address and=20
> > one for the local=20
> > address.
> >=20
> > So what's going to fail in case 1? Let's say some clients get=20
> > site-local addresses, and some get global _and_ site-local=20
> > addresses. =20
> > If we only publish the global address, can a client with only a
> > site-local address exchange packets with the client with the global=20
> > address? I think it can, as long as they are both at the=20
> same site=20
> > (which is the only case that matters). So I think that this=20
> > solution=20
> > works, and we don't need to do anything further.
> >=20
> > What fails in case 2? We've published a site-local address in a=20
> > global namespace. If a host outside of the site wants to=20
> > contact the
> > host using the name, how does it know that the site-local=20
> address is=20
> > not local? It doesn't. We can't control which address=20
> it tries to=20
> > connect to, and many network clients do not try to connect to every=20
> > address - they just try to connect to the first one, which DNS is=20
> > required to alternate. So what we would get, from the=20
> > perspective of=20
> > a naive user, would be intermittent failures. Not good.
> >=20
> > What about case 3? Case 3 works, but now you have to tell people=20
> > about two different names. Why would you want that, when one name=20
> > will do? So I really think that case 1 is how you want to=20
> > do things,
> > and this is easy and matches the one name per IAID model=20
> very nicely.
> >=20
> > As far as whether temporary and public addresses are part=20
> of the same
> > IA or not, why not let it be that if you want for some reason to=20
> > publish your temporary address, the way you do it is under=20
> a separate=20
> > IAID? Why add complexity when there's a way to do it that's less=20
> > complex?
> >=20
> > If a site is multihomed and wants to use different names for
> > different=20
> > addresses, I'm skeptical that it's something we need to think about=20
> > here and now. While it's true that this is a possible scenario, I=20
> > think the complexity that addressing this problem adds to=20
> the current=20
> > draft is unacceptable. I would like to see this problem actually=20
> > happen in the real world, and have that drive a new standardization=20
> > effort, rather than trying to guess how people are going to want to=20
> > solve this problem when we've never seen it happen in the=20
> real world,=20
> > and really don't have a basis for talking about what need we're=20
> > addressing.
> >=20
> >=20
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> >=20
>=20
>=20
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>=20
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Tue Sep 7 18:31:25 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14318;
Tue, 7 Sep 2004 18:31:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C4oBq-0007fX-JS; Tue, 07 Sep 2004 18:11:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C4ny2-00077Z-W2
for dhcwg@megatron.ietf.org; Tue, 07 Sep 2004 17:57:35 -0400
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 RAA11155
for ; Tue, 7 Sep 2004 17:57:31 -0400 (EDT)
Received: from toccata.fugue.com ([204.152.186.142])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4o1Y-0000wN-7D
for dhcwg@ietf.org; Tue, 07 Sep 2004 18:01:13 -0400
Received: from [10.0.2.3] (neubayern.net [66.93.162.100])
by toccata.fugue.com (Postfix) with ESMTP
id 661931B2402; Tue, 7 Sep 2004 16:54:46 -0500 (CDT)
In-Reply-To: <002301c4951b$7d08c980$efa0560a@amer.cisco.com>
References: <002301c4951b$7d08c980$efa0560a@amer.cisco.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id:
Content-Transfer-Encoding: 7bit
From: Ted Lemon
Subject: Re: [dhcwg] Re: I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt - NEED INPUT
BEFORE REVISING DRAFT!
Date: Tue, 7 Sep 2004 14:57:28 -0700
To: "Bernie Volz"
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Content-Transfer-Encoding: 7bit
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7bit
On Sep 7, 2004, at 1:44 PM, Bernie Volz wrote:
> 1. Allow only the simple case for now (ie, Client FQDN option in an
> IA_NA or
> IA_TA options field applies to all addresses in the IA). We can always
> add
> the complex case (using a bit) in the future.
This would obviously be my preference.
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Wed Sep 8 08:30:45 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06251;
Wed, 8 Sep 2004 08:30:44 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C51SN-0002SW-8t; Wed, 08 Sep 2004 08:21:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C51QS-00025R-6q
for dhcwg@megatron.ietf.org; Wed, 08 Sep 2004 08:19:48 -0400
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 IAA05420
for ; Wed, 8 Sep 2004 08:19:46 -0400 (EDT)
Received: from hoemail1.lucent.com ([192.11.226.161])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C51U5-0007aM-Bz
for dhcwg@ietf.org; Wed, 08 Sep 2004 08:23:34 -0400
Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10])
by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i88CIULq021816;
Wed, 8 Sep 2004 07:18:30 -0500 (CDT)
Received: from kraken.mh.lucent.com by homail.ho.lucent.com
(8.11.7+Sun/EMS-1.5 sol2)
id i88CITP01836; Wed, 8 Sep 2004 08:18:29 -0400 (EDT)
From: Joe Quanaim
To: "Bernie Volz" , ,
"'Ted Lemon'"
Subject: Re: [dhcwg] Re: I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt - NEED INPUT
BEFORE REVISING DRAFT!
Date: Wed, 8 Sep 2004 08:18:27 -0400
User-Agent: KMail/1.5.4
References: <002301c4951b$7d08c980$efa0560a@amer.cisco.com>
In-Reply-To: <002301c4951b$7d08c980$efa0560a@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200409080818.28071.jdq@lucent.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jdq@lucent.com
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7bit
Bernie Volz wrote:
> Before I revise the draft, please let me know if you think it is worth
> doing. The choices are:
> 1. Allow only the simple case for now (ie, Client FQDN option in an IA_NA
> or IA_TA options field applies to all addresses in the IA). We can always
> add the complex case (using a bit) in the future.
> 2. Allow both the simple and more complex case (latter is as currently
> documented); we'd use a bit in the flags field to indicate whether the
> client supports the complex method and wants to use (server can support it
> or not). Default (bit not set) is simple-only.
> 3. Come up with a completely different approach the problem (ideas?).
> 4. Abandon this work (if there's no interest in it).
I think 1 is sufficient for now, but I would also accept 2. I think 4 is not
a good choice. dns integration is a valuable differentiator between dhcp and
slac.
Joe.
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Wed Sep 8 15:56:33 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11722;
Wed, 8 Sep 2004 15:56:32 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C58Fj-0006hj-K9; Wed, 08 Sep 2004 15:37:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C58EZ-000612-RL; Wed, 08 Sep 2004 15:35:59 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09720;
Wed, 8 Sep 2004 15:35:57 -0400 (EDT)
Message-Id: <200409081935.PAA09720@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Date: Wed, 08 Sep 2004 15:35:57 -0400
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-agentopt-radius-08.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.
Title : RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option
Author(s) : R. Droms, J. Schnizlein
Filename : draft-ietf-dhc-agentopt-radius-08.txt
Pages : 9
Date : 2004-9-8
A NAS (network access server) may choose to authenticate the identity
of a device before granting that device access to the network. The
IEEE 802.1X protocol is an example of a mechanism for providing
authenticated layer 2 network access. A network element using RADIUS
as an authentication authority will receive attributes from a RADIUS
server that may be used by a DHCP server in the selection of
configuration parameters to be delivered to the device through its
DHCP client. The RADIUS Attributes sub-option enables a network
element to pass along attributes for the user of a device received
during RADIUS authentication to a DHCP server.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-08.txt
To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dhc-agentopt-radius-08.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-dhc-agentopt-radius-08.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <2004-9-8154302.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-agentopt-radius-08.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-agentopt-radius-08.txt";
site="ftp.ietf.org"; access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2004-9-8154302.I-D@ietf.org>
--OtherAccess--
--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
--NextPart--
From dhcwg-bounces@ietf.org Wed Sep 8 19:40:52 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03015;
Wed, 8 Sep 2004 19:40:52 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C5BzO-0001w4-R3; Wed, 08 Sep 2004 19:36:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C5Bsv-0000iz-RL
for dhcwg@megatron.ietf.org; Wed, 08 Sep 2004 19:29:53 -0400
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 TAA02427
for ; Wed, 8 Sep 2004 19:29:49 -0400 (EDT)
Received: from mailout1.samsung.com ([203.254.224.24])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5BwT-0005jS-ST
for dhcwg@ietf.org; Wed, 08 Sep 2004 19:33:45 -0400
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com
(iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
id <0I3Q00JFOX8KJS@mailout1.samsung.com> for dhcwg@ietf.org; Thu,
09 Sep 2004 08:29:08 +0900 (KST)
Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24])
by mailout1.samsung.com
(iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003))
with ESMTP id <0I3Q00NKTX1Q3I@mailout1.samsung.com> for dhcwg@ietf.org;
Thu, 09 Sep 2004 08:25:02 +0900 (KST)
Received: from LocalHost ([168.219.202.103])
by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built
Jun 23 2003)) with ESMTPA id <0I3Q00F7EX1POG@mmp1.samsung.com> for
dhcwg@ietf.org; Thu, 09 Sep 2004 08:25:02 +0900 (KST)
Date: Thu, 09 Sep 2004 08:26:16 +0900
From: Soohong Daniel Park
To: Dhcwg
Message-id:
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=ks_c_5601-1987
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Content-Transfer-Encoding: 7BIT
Cc: Ralph Droms
Subject: [dhcwg] Rapid commit draft is ready for IESG
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7BIT
I believe *Rapid commit* draft is now ready to be submitted to the IESG.
Above all, the WG Last Call was done by 5PM Fir, 2004-08-13.
(final decision is up to the chair of DHC WG of course...:-))
Goals and Milestones:
Sep 04 Submit 'Rapid Commit Option for DHCPv4' to IESG (draft-ietf-dhc-rapid-commit-opt)
- Daniel (Soohong Daniel Park)
- Mobile Platform Lab. Samsung Electronics.
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Thu Sep 9 01:28:40 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04583;
Thu, 9 Sep 2004 01:28:40 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C5HRi-0008VY-MH; Thu, 09 Sep 2004 01:26:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C5HQw-0008Lz-W2
for dhcwg@megatron.ietf.org; Thu, 09 Sep 2004 01:25:23 -0400
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 BAA04423
for ; Thu, 9 Sep 2004 01:25:22 -0400 (EDT)
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5HUi-0002gD-KS
for dhcwg@ietf.org; Thu, 09 Sep 2004 01:29:18 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i895PBEf011108
for ; Thu, 9 Sep 2004 14:25:11 +0900 (JST)
Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1])
by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id
i895PBDD021872
for ; Thu, 9 Sep 2004 14:25:11 +0900 (JST)
Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112])
by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id
i895PBWU021864
for ; Thu, 9 Sep 2004 14:25:11 +0900 (JST)
Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1])
by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id
i895PALJ006879
for ; Thu, 9 Sep 2004 14:25:10 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100])
by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id
i895PAO7006876
for ; Thu, 9 Sep 2004 14:25:10 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp
[129.60.5.69])
by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id
i895P90W017568
for ; Thu, 9 Sep 2004 14:25:09 +0900 (JST)
Received: from ime.m.ecl.ntt.co.jp (localhost [127.0.0.1])
by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id OAA18043
for ; Thu, 9 Sep 2004 14:25:09 +0900 (JST)
Received: from lab.ntt.co.jp
by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id OAA28710
for ; Thu, 9 Sep 2004 14:25:09 +0900 (JST)
Message-ID: <413FEA08.6030500@lab.ntt.co.jp>
Date: Thu, 09 Sep 2004 14:28:40 +0900
From: Mayumi Yanagiya
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP;
rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: ja
MIME-Version: 1.0
To: Dhcwg
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
Subject: [dhcwg] Authentication for Information-request
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
List-Post:
List-Help:
List-Subscribe: ,
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7bit
Hi,
I have a question about transmitting Information-request message.
In RFC3115, it is not specified clearly that solicit/advertise messages
are exchanged between client and server before exchanging
Information-request/reply message.
On the other hand, it is defined that the client requests
authentication in its Solicit message.
So, I think that solicit/advertise messaged are exchanged before sending
information-request when clients want to use authentication for
information-request.
Is my understanding right?
(I know that Jinmei-san submitted $B!H(BClarifications on DHCPv6
Authentication$B!I(B. But I couldn't find any discussion for above issue on
this mailing list.)
--Mayumi
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
From dhcwg-bounces@ietf.org Thu Sep 9 05:06:54 2004
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29485;
Thu, 9 Sep 2004 05:06:54 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1C5Knh-0002gI-G0; Thu, 09 Sep 2004 05:01:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1C5KlK-000276-Sm
for dhcwg@megatron.ietf.org; Thu, 09 Sep 2004 04:58:38 -0400
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 EAA29044
for ; Thu, 9 Sep 2004 04:58:36 -0400 (EDT)
Received: from ovaron.uni-muenster.de ([128.176.191.5]
helo=ovaron.join.uni-muenster.de)
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5Kp8-0005pl-Vk
for dhcwg@ietf.org; Thu, 09 Sep 2004 05:02:36 -0400
Received: from [128.176.13.5] (OTHERLAND.UNI-MUENSTER.DE [128.176.13.5])
(authenticated bits=0)
by ovaron.join.uni-muenster.de (8.13.1/8.12.9) with ESMTP id
i898wdLh006182
(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
for ; Thu, 9 Sep 2004 10:58:40 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v619)
Content-Transfer-Encoding: 7bit
Message-Id: <5DAC24BA-023E-11D9-995A-000A95ABEDDA@uni-muenster.de>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: ""
From: Tina Strauf
Date: Thu, 9 Sep 2004 10:58:06 +0200
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Subject: [dhcwg] DHCPv6 client implementation
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: