Re: [dhcwg] dhcpv6-w4: optional parts of spec

Ted Lemon <Ted.Lemon@nominum.com> Wed, 15 May 2002 17:38 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 NAA15137 for <dhcwg-archive@odin.ietf.org>; Wed, 15 May 2002 13:38:11 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15905 for dhcwg-archive@odin.ietf.org; Wed, 15 May 2002 13:38:24 -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 NAA15724; Wed, 15 May 2002 13:36:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15701 for <dhcwg@ns.ietf.org>; Wed, 15 May 2002 13:36:52 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15062 for <dhcwg@ietf.org>; Wed, 15 May 2002 13:36:36 -0400 (EDT)
Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g4FHZWS07314; Wed, 15 May 2002 10:35:32 -0700 (PDT)
Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g4FHald01927; Wed, 15 May 2002 12:36:47 -0500 (CDT)
Date: Wed, 15 May 2002 12:36:46 -0500
Subject: Re: [dhcwg] dhcpv6-w4: optional parts of spec
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Mime-Version: 1.0 (Apple Message framework v481)
Cc: dhcwg@ietf.org
To: Thomas Narten <narten@us.ibm.com>
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <200205151647.g4FGlar01969@cichlid.adsl.duke.edu>
Message-Id: <5460A7FA-682A-11D6-B998-00039367340A@nominum.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.481)
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit

> 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