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