Subject: [dhcwg] help

From: "Dawn Copeland" <[email-masked]>
Date: Tue, 14 May 2002 13:54:35 -0400

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

[email-masked]

Thanks,
Dawn

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]]
Sent:	Tuesday, May 14, 2002 12:01 PM
To:	[email-masked]
Subject:	dhcwg digest, Vol 1 #260 - 5 msgs

Send dhcwg mailing list submissions to
	[email-masked]

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
	[email-masked]
You can reach the person managing the list at
	[email-masked]

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 <[email-masked]>
cc: "Bound, Jim" <[email-masked]>,
"Bernie Volz (EUD)" <[email-masked]>,
Ole Troan <[email-masked]>, [email-masked]
Subject: Re: [dhcwg] dhcpv6-24: use of anycast
Date: Mon, 13 May 2002 21:32:33 -0400
From: Thomas Narten <[email-masked]>

> 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=?=
<[email-masked]>
To: Ralph Droms <[email-masked]>
Cc: [email-masked]
Subject: Re: [dhcwg] some comments and questions on dhcpv6-24
<[email-masked]>
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.

>>>>> On Mon, 13 May 2002 10:37:09 -0400,
>>>>> Ralph Droms <[email-masked]> 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.
					[email-masked]

--__--__--

Message: 3
From: Katia Linker <[email-masked]>
To: DHCP IETF mailing list <[email-masked]>
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=?=
<[email-masked]>
From: Ralph Droms <[email-masked]>
Subject: Re: [dhcwg] some comments and questions on dhcpv6-24
Cc: [email-masked]
<[email-masked]>
<[email-masked]>

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 <[email-masked]> 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.
>                                         [email-masked]

--__--__--

Message: 5
From: "Kostur, Andre" <[email-masked]>
To: "'Katia Linker'" <[email-masked]>,
DHCP IETF mailing list
<[email-masked]>
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:[email-masked]]
> 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>

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

<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>

<P><FONT SIZE=3D2>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).</FONT></P>

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

--__--__--

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

End of dhcwg Digest

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg