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 NAA15419 for ; Wed, 15 May 2002 13:46:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA16401 for dhcwg-archive@odin.ietf.org; Wed, 15 May 2002 13:46:31 -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 NAA16302; Wed, 15 May 2002 13:44:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16282 for ; Wed, 15 May 2002 13:44:15 -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 NAA15333 for ; Wed, 15 May 2002 13:44:01 -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 g4FHiDl01330 for ; Wed, 15 May 2002 12:44:13 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g4FHiD818545 for ; Wed, 15 May 2002 12:44:13 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed May 15 12:43:39 2002 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 12:43:39 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D41F@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ted Lemon'" , Thomas Narten Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-w4: optional parts of spec Date: Wed, 15 May 2002 12:43:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC38.09F14720" 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_01C1FC38.09F14720 Content-Type: text/plain; charset="iso-8859-1" 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_01C1FC38.09F14720 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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]<= /FONT>
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_01C1FC38.09F14720-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg