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
- [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)