RE: [dhcwg] Questions about Invalid Option : I'd like clarification

[<[e-mail]>]

Hello Berine,
 
> I'm thinking that we might just want to drop the first 
> paragraph of Section 15. And, perhaps the second paragraph's 
> requirements be moved into the corresponding subsections for 
> the messages. This makes it easier to find all the hard rules 
> for each message.

I agree with your opinion.

Thanks,
> -----Original Message-----
> From: Bernie Volz (volz) [mailto:[e-mail]] 
> Sent: Tuesday, March 06, 2007 10:44 AM
> To: Enokihara, Hideshi ([e-mail]); 
> [e-mail]
> Subject: RE: [dhcwg] Questions about Invalid Option : I'd 
> like clarification 
> 
> Hideshi:
> 
> On the surface, your rewording does seem a bit better ...
> 
> >   Clients and servers MUST discard any messages that 
> contain options 
> >which appearance (or lack of appearance) is a clear violation of the
> >DHCPv6 protocol.
>  
> But, I feel that it too may be misinterpreted. Is sending a 
> "information-type" option (i.e., DNS Servers) that an RFC 
> says MUST NOT be sent in a specific message a "clear 
> violation of the DHCPv6 protocol"?
> 
> I'm thinking that we might just want to drop the first 
> paragraph of Section 15. And, perhaps the second paragraph's 
> requirements be moved into the corresponding subsections for 
> the messages. This makes it easier to find all the hard rules 
> for each message.
> 
> - Bernie
> 
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Monday, March 05, 2007 8:32 PM
> To: Bernie Volz (volz); [e-mail]
> Subject: RE: [dhcwg] Questions about Invalid Option : I'd 
> like clarification 
> 
> Thank you so much for your response. 
> 
> I was confused about meaning of following Section 15.
> 
> RFC3315 section 15,
>  ------------
>     Clients and servers SHOULD discard any messages that 
> contain options that are not allowed to appear in the 
> received message.  
>     For example, an IA option is not allowed to appear in an 
> Information-request message. 
>  ------------
> I was believing that this "SHOULD" rule covered all of RFCs 
> related to DHCPv6.
> Is this text focusing on only section 15.1 to 15.14?
> 
> If not, I think that this text should be,
>  ------------
>     Clients and servers MUST discard any messages that 
> contain options which appearance (or lack of appearance) is a 
> clear violation of the
> DHCPv6 protocol.
>  ------------
> 
> What do you think?
> 
> Best regards,
> ...Hideshi
> > -----Original Message-----
> > From: Bernie Volz (volz) [mailto:[e-mail]]
> > Sent: Monday, March 05, 2007 11:47 PM
> > To: Enokihara, Hideshi ([e-mail]);
> > [e-mail]
> > Subject: RE: [dhcwg] Questions about Invalid Option : I'd like 
> > clarification
> > 
> > The text in RFC 3646 (and likely other options RFCs) does 
> not indicate 
> > what an entity should do if these options appear in 
> messages that they 
> > shouldn't. I view this text as guidance for implementers of these 
> > options not to send them in these messages.
> > 
> > It is my opinion that an entity should *IGNORE* options that don't 
> > make any sense in a particular message *EXCEPT* if the 
> appearance (or 
> > lack of
> > appearance) is a clear violation of the DHCPv6 protocol. 
> These are the 
> > conditions outlined in RFC 3315, Section 15.1 through 15.14.
> > 
> > One major reason for ignoring "unexpected" options is that 
> > implementations need to be able to handle new options that they may 
> > not yet implement. And, therefore it is impossible to 
> expect existing 
> > implementations to act in certain ways for things that they 
> have not 
> > yet implemented. And, being too strict will cause interoperability 
> > issues for no real benefit.
> > 
> > The old Internet policy that implementations should be flexible in 
> > what they receive but conservative in what they send applies.
> > 
> > Thus, section 15.1 - 15.14 in RFC 3315 are all that should 
> be used in 
> > any Conformance check.
> > 
> > If you add checks to make sure that not allowed options are 
> ignored, 
> > you MUST support two possible outcomes as some 
> implementations MAY act 
> > on the text in Section 15 and discard these messages whereas others 
> > will just ignore the options but otherwise respond.
> > 
> > - Bernie
> > 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]]
> > Sent: Monday, March 05, 2007 3:32 AM
> > To: [e-mail]
> > Subject: [dhcwg] Questions about Invalid Option : I'd like 
> > clarification
> > 
> > 
> > Hello all,
> > 
> > I have some questions about Invalid Options that are not allowed to 
> > appear in the message.
> > I'd like to clarify following things, because I have to 
> finish writing 
> > the Conformance test specification for IPv6 Ready Logo Program for 
> > DHCPv6.
> > Could you give me your thoughts, please?
> > 
> > 
> > RFC3315 section 15 says,
> > ------------
> >    Clients and servers SHOULD discard any messages that contain 
> > options
> >    that are not allowed to appear in the received message.  
> > For example,
> >    an IA option is not allowed to appear in an Information-request
> >    message. 
> > ------------
> > 
> > And "A. Appearance of Options in Message Types" shows table that 
> > indicates with a "*" the options are allowed in each DHCP message 
> > type.
> > 
> > This mean that without a "*" the options are not allowed in each 
> > message type, right?
> > 
> > I believe that this table information is too old( not correct ). 
> > I think that we need to clarify which option(message with invalid
> > option) should be discarded or should be ignored.
> > 
> > Following things are my thoughts. Are these things correct?
> > ------------------
> > For Server
> > 	Receiving Solict message:
> > 		A Server must discard the Solicit message 
> including Server 
> > Identifier option.
> > 		A Server must ignore all options that are not 
> allowed to appear in 
> > the message except for Server Identifier option.
> > 
> > 	Receiving Confirm message:
> > 		A Server must discard the Confirm message 
> including Server 
> > Identifier option.
> > 		A Server must ignore all options that are not 
> allowed to appear in 
> > the message except for Server Identifier option.
> > 		
> > 	Receiving Rebind message:
> > 		A Server must discard the Confirm message 
> including Server 
> > Identifier option.
> > 		A Server must ignore all options that are not 
> allowed to appear in 
> > the message except for Server Identifier option.
> > 
> > 	Receiving Information-request message:
> > 		A Server must discard the Confirm message 
> including Server 
> > Identifier option and/or IA_NA option.
> > 		A Server must ignore all options that are not 
> allowed to appear in 
> > the message except for Server Identifier option and IA_NA option.
> > 
> > 	Other messages(Request/Renew/Release/Decline/Relay-forward):
> > 		A Server must ignore all options that are not 
> allowed to appear in 
> > the message.
> > 
> > 	*I'd like to confirm following things.
> > 	RFC3646 section5 says,
> > 	--------------------------
> > 	   The DNS Recursive Name Server option MUST NOT appear 
> in any other
> > 	   than the following messages: Solicit, Advertise, 
> Request, Renew,
> > 	   Rebind, Information-Request, and Reply.
> > 
> > 	   The Domain Search List option MUST NOT appear in any 
> other than 
> > the
> > 	   following messages: Solicit, Advertise, Request, 
> Renew, Rebind,
> > 	   Information-Request, and Reply.
> > 	--------------------------
> > 	This means that servers should discard  the 
> > Confirm/Release/Decline/Relay-forward message
> > 	that including  DNS Recursive Name Server option and/or 
> Domain Search 
> > List option, right?
> > 	Or just ignore the option?
> > 	
> > For Client
> > 	All messages(Advertise/Reply/Reconfigure).
> > 		A Client must ignore all options that are not 
> allowe to appear in 
> > the message.
> > 
> > For Relay Agent
> > 	All messages
> > 		A Relay Agent just relay the message.
> > 		
> > ---------------------
> > 
> > What do you think?
> > 
> > Best regards,
> > ...Hideshi Enokihara
> > 	
> > 
> > _______________________________________________
> > dhcwg mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> > 
> 

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg