[dhcwg] help

Help...I would like to unsubscribe from the list.

drcopeland@lucent.com

Thanks,
Dawn

-----Original Message-----
From:	dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]
Sent:	Tuesday, May 14, 2002 12:01 PM
To:	dhcwg@ietf.org
Subject:	dhcwg digest, Vol 1 #260 - 5 msgs

Send dhcwg mailing list submissions to
	dhcwg@ietf.org

To subscribe or unsubscribe via the web, visit
	https://www1.ietf.org/mailman/listinfo/dhcwg
or, via email, send a message with subject or body 'help' to
	dhcwg-request@ietf.org
You can reach the person managing the list at
	dhcwg-admin@ietf.org

When replying, please edit your Subject line so it is more specific than
"Re: Contents of dhcwg digest..."

Today's Topics:

  1. Re: dhcpv6-24: use of anycast (Thomas Narten)
  2. Re: some comments and questions on dhcpv6-24 (JINMEI Tatuya /
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=)
  3. "Options" field (Katia Linker)
  4. Re: some comments and questions on dhcpv6-24 (Ralph Droms)
  5. RE: "Options" field (Kostur, Andre)

--__--__--

Message: 1
To: Ralph Droms <rdroms@cisco.com>
cc: "Bound, Jim" <Jim.Bound@hp.com>,
"Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>,
Ole Troan <ot@cisco.com>, dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: use of anycast
Date: Mon, 13 May 2002 21:32:33 -0400
From: Thomas Narten <narten@us.ibm.com>

> Is there a precedent for the reservation of a link-scoped, well-known
> unicast address?

Not that I know of.

Another reason why I'd like to include this only if we *really* need
it.

Thomas

--__--__--

Message: 2
Date: Tue, 14 May 2002 10:18:45 +0900
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
<jinmei@isl.rdc.toshiba.co.jp>
To: Ralph Droms <rdroms@cisco.com>
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] some comments and questions on dhcpv6-24
<4.3.2.7.2.20020511064013.0311acc0@funnel.cisco.com>
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.

>>>>> On Mon, 13 May 2002 10:37:09 -0400,
>>>>> Ralph Droms <rdroms@cisco.com> said:

>> 17.2.2. Creation and transmission of Advertise messages
>>
>> ... The Advertise message MUST
>> be unicast through the interface on which the Solicit message was
>> received.
>>
>> It seems to me the requirement is too strong.  Is this really
>> necessary?

> It's necessary if the server received the Solicit directly from the
client;
> i.e., if the server and the client are on the same link and the server is
> sending the Advertise to the client's link-local address.

I understand that, but as I said in the succeeding message, I think
the "link" (not "interface") is more accurate.  Requiring to send a
particular "interface" is overspecification from a strict
scope-architecture point of view.  Also, using the word "link" is
consistent with the wording in Section 16.

>> 18.2.5. Receipt of Information-request messages
>>
>> The server contructs a Reply message by setting the "msg-type" field
>> ^^^^^^^^^this should be "constructs".  There are many
>> other "contructs" in the draft.

> This problem was fixed between preliminary publication of the -24
> rev and the final version published at the IETF.

>> to REPLY, copying the transaction ID from the Rebind message into the
>> ^^^^^^
>> transaction-ID field.
>>
>> Should the "Rebind" message be "Information-request"?  This sentence
>> seems to be just copied from the previous section...

> This problem was fixed between preliminary publication of the -24
> rev and the final version published at the IETF.

Okay, but where can I get the "final version"?  The -24 draft at
ftp://ftp.ietf.org/internet-drafts has the same problems.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

--__--__--

Message: 3
From: Katia Linker <KatiaL@radlan.com>
To: DHCP IETF mailing list <dhcwg@ietf.org>
Date: Mon, 13 May 2002 15:27:30 +0200
charset="windows-1255"
Subject: [dhcwg] "Options" field

Hi !
My question to all of you is regarding the "options" field of DHCP header.
*	Is it possible for DHCP server to receive some message with the
length
of options field = X, and send another message as a reply to client with
the length of options field = Y ?
*	According to RFC 2131, the minimal length of the options field is
312,
what is the maximal length of this field ?
     Thanks in advance
Katya Linker
Radlan Computer Communications Ltd.
Atidim Technological Park Bldg #4
Tel Aviv 61131, Israel
Tel: +972-3-7657900
Fax: +972-3-6487368
Visit us on http://www.radlan.com

--__--__--

Message: 4
Date: Tue, 14 May 2002 05:46:46 -0400
To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
<jinmei@isl.rdc.toshiba.co.jp>
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: [dhcwg] some comments and questions on dhcpv6-24
Cc: dhcwg@ietf.org
<y7vadrqq348.wl@ocean.jinmei.org>
<4.3.2.7.2.20020511064013.0311acc0@funnel.cisco.com>

At 10:18 AM 5/14/2002 +0900, JINMEI Tatuya /
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
> >>>>> On Mon, 13 May 2002 10:37:09 -0400,
> >>>>> Ralph Droms <rdroms@cisco.com> said:
>
> >> 17.2.2. Creation and transmission of Advertise messages
> >>
> >> ... The Advertise message MUST
> >> be unicast through the interface on which the Solicit message was
> >> received.
> >>
> >> It seems to me the requirement is too strong.  Is this really
> >> necessary?
>
> > It's necessary if the server received the Solicit directly from the
> client;
> > i.e., if the server and the client are on the same link and the server
is
> > sending the Advertise to the client's link-local address.
>
>I understand that, but as I said in the succeeding message, I think
>the "link" (not "interface") is more accurate.  Requiring to send a
>particular "interface" is overspecification from a strict
>scope-architecture point of view.  Also, using the word "link" is
>consistent with the wording in Section 16.

You're correct - we can reuse the wording of section 16 here.

> >> 18.2.5. Receipt of Information-request messages
> >>
> >> The server contructs a Reply message by setting the "msg-type" field
> >> ^^^^^^^^^this should be "constructs".  There are many
> >> other "contructs" in the draft.
>
> > This problem was fixed between preliminary publication of the -24
> > rev and the final version published at the IETF.
>
> >> to REPLY, copying the transaction ID from the Rebind message into the
> >> ^^^^^^
> >> transaction-ID field.
> >>
> >> Should the "Rebind" message be "Information-request"?  This sentence
> >> seems to be just copied from the previous section...
>
> > This problem was fixed between preliminary publication of the -24
> > rev and the final version published at the IETF.
>
>Okay, but where can I get the "final version"?  The -24 draft at
>ftp://ftp.ietf.org/internet-drafts has the same problems.

Sorry - the version at ftp.ietf.org is the "final version".  I missed that
the "Rebind"->"Information-request" goof was not fixed...

>                                         JINMEI, Tatuya
>                                         Communication Platform Lab.
>                                         Corporate R&D Center, Toshiba
Corp.
>                                         jinmei@isl.rdc.toshiba.co.jp

--__--__--

Message: 5
From: "Kostur, Andre" <Andre@incognito.com>
To: "'Katia Linker'" <KatiaL@radlan.com>,
DHCP IETF mailing list
<dhcwg@ietf.org>
Subject: RE: [dhcwg] "Options" field
Date: Tue, 14 May 2002 08:38:06 -0700
boundary="----_=_NextPart_001_01C1FB5D.57863CB0"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1FB5D.57863CB0
Content-Type: text/plain;
	charset="windows-1255"

Comments inline....

> -----Original Message-----
> From: Katia Linker [mailto:KatiaL@radlan.com]
> Sent: Monday, May 13, 2002 6:28 AM
> To: DHCP IETF mailing list
> Subject: [dhcwg] "Options" field
>
>
>
> Hi !
> My question to all of you is regarding the "options" field of
> DHCP header.
> *	Is it possible for DHCP server to receive some message with the
> length
> of options field = X, and send another message as a reply to
> client with
> the length of options field = Y ?

Sure.  Just means that the server has more to say than the client.

> *	According to RFC 2131, the minimal length of the
> options field is
> 312,
> what is the maximal length of this field ?

Probably the size of a UDP packet (minus the size of the header... 200 or so
bytes).  However, clients can tell the server that they can only accept
messages up to size X (there's an option for it).

------_=_NextPart_001_01C1FB5D.57863CB0
Content-Type: text/html;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [dhcwg] &quot;Options&quot; field</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Comments inline....</FONT>
</P>

&gt; -----Original Message-----
 &gt; From: Katia Linker [<A =
HREF=3D"mailto:KatiaL@radlan.com">mailto:KatiaL@radlan.com</A>]
 &gt; Sent: Monday, May 13, 2002 6:28 AM
 &gt; To: DHCP IETF mailing list
 &gt; Subject: [dhcwg] &quot;Options&quot; =
field
 &gt; 
 &gt; 
 &gt; 
 &gt; Hi !
 &gt; My question to all of you is regarding the =
&quot;options&quot; field of 
 &gt; DHCP header.
 &gt; *&nbsp;&nbsp;&nbsp;&nbsp; Is it possible for =
DHCP server to receive some message with the
 &gt; length
 &gt; of options field =3D X, and send another =
message as a reply to 
 &gt; client with
 &gt; the length of options field =3D Y ?

<P><FONT SIZE=3D2>Sure.&nbsp; Just means that the server has more to =
say than the client.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; *&nbsp;&nbsp;&nbsp;&nbsp; According to RFC 2131, =
the minimal length of the </FONT>
<BR><FONT SIZE=3D2>&gt; options field is</FONT>
<BR><FONT SIZE=3D2>&gt; 312,</FONT>
<BR><FONT SIZE=3D2>&gt; what is the maximal length of this field =
?</FONT>
</P>

Probably the size of a UDP packet (minus the size of =
the header... 200 or so bytes).&nbsp; However, clients can tell the =
server that they can only accept messages up to size X (there's an =
option for it).

</BODY>
</HTML>
------_=_NextPart_001_01C1FB5D.57863CB0--

--__--__--

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

End of dhcwg Digest

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg