RE: [dhcwg] dhcpv6-w4: optional parts of spec
"Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> Wed, 15 May 2002 19:39 UTC
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 <dhcwg-archive@odin.ietf.org>; 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 <dhcwg@ns.ietf.org>; 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 <dhcwg@ietf.org>; 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 <dhcwg@ietf.org>; 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 <dhcwg@ietf.org>; 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 <KRTWNL2Y>; Wed, 15 May 2002 14:38:08 -0500
Message-ID: <66F66129A77AD411B76200508B65AC69B4D429@EAMBUNT705>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: "'Bound, Jim'" <Jim.Bound@hp.com>, Ted Lemon <Ted.Lemon@nominum.com>, Thomas Narten <narten@us.ibm.com>
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: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
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
- [dhcwg] dhcpv6-w4: optional parts of spec Thomas Narten
- Re: [dhcwg] dhcpv6-w4: optional parts of spec Ted Lemon
- RE: [dhcwg] dhcpv6-w4: optional parts of spec Bernie Volz (EUD)
- RE: [dhcwg] dhcpv6-w4: optional parts of spec Bound, Jim
- RE: [dhcwg] dhcpv6-w4: optional parts of spec Bernie Volz (EUD)