Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19560 for ; Wed, 15 May 2002 15:36:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA24972 for dhcwg-archive@odin.ietf.org; Wed, 15 May 2002 15:36:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24833; Wed, 15 May 2002 15:35:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24764 for ; Wed, 15 May 2002 15:35:05 -0400 (EDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19476 for ; Wed, 15 May 2002 15:34:50 -0400 (EDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 456059356; Wed, 15 May 2002 15:35:04 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 15 May 2002 15:35:04 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC47.9C20AB98" Subject: RE: [dhcwg] dhcpv6-w4: optional parts of spec Date: Wed, 15 May 2002 15:35:03 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8695@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-w4: optional parts of spec Thread-Index: AcH8OGPVcUOtuKaFQNyJrd7Ao5xLgwADyPnw From: "Bound, Jim" To: "Bernie Volz (EUD)" , "Ted Lemon" , "Thomas Narten" Cc: X-OriginalArrivalTime: 15 May 2002 19:35:04.0056 (UTC) FILETIME=[9C702F80:01C1FC47] Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1FC47.9C20AB98 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't agree. This spec is for a fully compliant dhcpv6 server. that = last call comment can be addressed in another spec. =20 /jim -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Wednesday, May 15, 2002 1:44 PM To: 'Ted Lemon'; Thomas Narten Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-w4: optional parts of spec We should have two levels - Fully managed (to support Stateful Address = Configuration) and something else for "Other Config" only. (Though it = will get more complex as there is also the Prefix Delegation stuff that = Ralph has been working on and that may be another subset.) A fully managed client/server must support:=20 Solicit, Advertise, Request, Renew, Rebind, Confirm, Decline, = Release, Reply, Reconfigure,=20 Information-Request=20 A "Other Config" must support:=20 Information-Request, Reply=20 (I'm less sure Reconfigure is REQUIRED in this case.)=20 Rapid Commit is an optional feature for clients and servers (IMHO). That = is also why an option is used to communicate it. - Bernie=20 -----Original Message-----=20 From: Ted Lemon [ mailto:Ted.Lemon@nominum.com]=20 Sent: Wednesday, May 15, 2002 1:37 PM=20 To: Thomas Narten=20 Cc: dhcwg@ietf.org=20 Subject: Re: [dhcwg] dhcpv6-w4: optional parts of spec=20 > If the WG wants to define several levels of implementations (like a=20 > non-address supporting mode) that is one thing. But then the document=20 > should make it clear what parts MUST be implemented in order to be=20 > support a particular mode. But life would just be simpler if the spec=20 > just said servers need to implement everything.=20 I don't feel very strongly about this, but we did have a last-call=20 objection to the protocol because someone wanted to have a simpler = protocol=20 for just getting information, and didn't want to have to implement the=20 whole thing (indeed, argued that the whole thing wasn't useful, but that = the partial implementation was). Do we just ignore that comment? Can = we=20 ignore it and get through last call?=20 What about clients? Do we say that a client that only implements the=20 information request/reply sequence isn't compliant? Is a client that=20 doesn't implement fast commit non-compliant? What about a client that=20 doesn't implement certain options?=20 _______________________________________________=20 dhcwg mailing list=20 dhcwg@ietf.org=20 https://www1.ietf.org/mailman/listinfo/dhcwg=20 ------_=_NextPart_001_01C1FC47.9C20AB98 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-w4: optional parts of spec
I=20 don't agree.  This spec is for a fully compliant dhcpv6 = server.  that=20 last call comment can be addressed in another spec.
 
/jim
-----Original Message-----
From: Bernie Volz (EUD)=20 [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Wednesday, May = 15, 2002=20 1:44 PM
To: 'Ted Lemon'; Thomas Narten
Cc:=20 dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-w4: optional = parts of=20 spec

We should have two levels - Fully managed (to = support Stateful=20 Address Configuration) and something else for "Other Config" only. = (Though it=20 will get more complex as there is also the Prefix Delegation stuff = that Ralph=20 has been working on and that may be another subset.)

A fully managed client/server must support:=20
        Solicit, = Advertise, Request, Renew, Rebind, Confirm, Decline, Release, Reply,=20 Reconfigure,
        = Information-Request

A "Other Config" must support:=20
        Information-Request, Reply=20
        (I'm = less sure=20 Reconfigure is REQUIRED in this case.)

Rapid Commit is an optional feature for clients and = servers=20 (IMHO). That is also why an option is used to communicate = it.

- Bernie

-----Original Message-----
From: Ted=20 Lemon [mailto:Ted.Lemon@nominum.com]=20
Sent: Wednesday, May 15, 2002 1:37 PM =
To: Thomas Narten
Cc: = dhcwg@ietf.org=20
Subject: Re: [dhcwg] dhcpv6-w4: optional parts of = spec=20


> If the WG wants to define several levels of=20 implementations (like a
> non-address = supporting=20 mode) that is one thing. But then the document
>=20 should make it clear what parts MUST be implemented in order to = be=20
> support a particular mode. But life would just = be=20 simpler if the spec
> just said servers = need to=20 implement everything.

I don't feel very strongly about this, but we did = have a=20 last-call
objection to the protocol because = someone=20 wanted to have a simpler protocol
for just = getting=20 information, and didn't want to have to implement the
whole thing (indeed, argued that the whole thing wasn't = useful, but=20 that
the partial implementation = was).   Do=20 we just ignore that comment?   Can we
ignore=20 it and get through last call?

What about clients?   Do we say that a = client that=20 only implements the
information = request/reply sequence=20 isn't compliant?   Is a client that
doesn't=20 implement fast commit non-compliant?   What about a client = that=20
doesn't implement certain options? =


_______________________________________________=20
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/dhcwg=20

------_=_NextPart_001_01C1FC47.9C20AB98-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg