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 