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 PAA19777 for ; Wed, 15 May 2002 15:39:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25467 for dhcwg-archive@odin.ietf.org; Wed, 15 May 2002 15:40:04 -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 PAA25286; Wed, 15 May 2002 15:38:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25200 for ; Wed, 15 May 2002 15:38:11 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19691 for ; Wed, 15 May 2002 15:37:56 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g4FJc9l10272 for ; Wed, 15 May 2002 14:38:09 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g4FJc9826176 for ; Wed, 15 May 2002 14:38:09 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed May 15 14:38:08 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 14:38:08 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D429@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Bound, Jim'" , Ted Lemon , Thomas Narten Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-w4: optional parts of spec Date: Wed, 15 May 2002 14:38:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC48.08722DF0" 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 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_01C1FC48.08722DF0 Content-Type: text/plain; charset="iso-8859-1" Jim ... based on the further discussion and thought, I agree with you. -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com] Sent: Wednesday, May 15, 2002 3:35 PM To: Bernie Volz (EUD); Ted Lemon; Thomas Narten Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-w4: optional parts of spec I don't agree. This spec is for a fully compliant dhcpv6 server. that last call comment can be addressed in another spec. /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: Solicit, Advertise, Request, Renew, Rebind, Confirm, Decline, Release, Reply, Reconfigure, Information-Request A "Other Config" must support: Information-Request, Reply (I'm less sure Reconfigure is REQUIRED in this case.) Rapid Commit is an optional feature for clients and servers (IMHO). That is also why an option is used to communicate it. - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Wednesday, May 15, 2002 1:37 PM To: Thomas Narten Cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-w4: optional parts of spec > If the WG wants to define several levels of implementations (like a > non-address supporting mode) that is one thing. But then the document > should make it clear what parts MUST be implemented in order to be > support a particular mode. But life would just be simpler if the spec > just said servers need to implement everything. I don't feel very strongly about this, but we did have a last-call objection to the protocol because someone wanted to have a simpler protocol for just getting information, and didn't want to have to implement the 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 ignore it and get through last call? What about clients? Do we say that a client that only implements the information request/reply sequence isn't compliant? Is a client that doesn't implement fast commit non-compliant? What about a client that doesn't implement certain options? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1FC48.08722DF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-w4: optional parts of spec

Jim ... based on the further discussion and thought, = I agree with you.

-----Original Message-----
From: Bound, Jim [mailto:Jim.Bound@hp.com]
Sent: Wednesday, May 15, 2002 3:35 PM
To: Bernie Volz (EUD); Ted Lemon; Thomas = Narten
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-w4: optional parts of = spec


I don't agree.  This spec is for a fully = compliant dhcpv6 server.  that last call comment can be addressed = in another spec.

/jim
-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.erics= son.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:
        Solicit, = Advertise, Request, Renew, Rebind, Confirm, Decline, Release, Reply, = Reconfigure,
        = Information-Request
A "Other Config" must support:
        = Information-Request, Reply
        (I'm less = sure Reconfigure is REQUIRED in this case.)
Rapid Commit is an optional feature for clients and = servers (IMHO). That is also why an option is used to communicate = it.

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


> If the WG wants to define several levels of = implementations (like a
> non-address supporting mode) that is one thing. = But then the document
> should make it clear what parts MUST be = implemented in order to be
> support a particular mode. But life would just = be simpler if the spec
> just said servers need to implement everything. =
I don't feel very strongly about this, but we did = have a last-call
objection to the protocol because someone wanted to = have a simpler protocol
for just getting information, and didn't want to = have to implement the
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
ignore it and get through last call?
What about clients?   Do we say that a = client that only implements the
information request/reply sequence isn't = compliant?   Is a client that
doesn't implement fast commit = non-compliant?   What about a client that
doesn't implement certain options?


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

------_=_NextPart_001_01C1FC48.08722DF0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg