HI Ted, Cheers, Ian
> On 9 Jun 2016, at 14:34, Ted Lemon <[email protected]> wrote: > > Actually, this is a classic example of what we try to avoid: special server > behavior for options. Options are just payload, not protocol, unless they > are intended to affect the flow of the protocol. It should not be necessary > for the server to have special code to support a different payload, any more > than the TCP stack should have to be modified in order to support new > extensions to HTTP. > > So you could make an operational note about how servers ought to be > configured, but you should not require that the server check to make sure it > is configured that way. You should not require that the server understand > the semantics of the option--what it means for there to be two of them, or > what order they should occur in, or what meaning that ordering has. [if - So, for the original reason that the point was raised, do you suggest that enforcing this only in the client (i.e. if it receives an invalid option combination/content then drop all instances) in addition to the operation guidance for server config?] > > If you have two different uses for an option, with different semantics, you > should define two different options, each of which has only one semantics. > > On Thu, Jun 9, 2016 at 3:44 AM, Ian Farrer <[email protected] > <mailto:[email protected]>> wrote: > Hi Med, > > To be clear, both of the suggestions include the modification to the Section > 5 client text? I think this is necessary. But is the error condition that all > of the enclosed options are the same scope, or that two or more are? > > Between the two, I would prefer (1) - a MUST NOT with an exception is a > SHOULD NOT. An alternative wording that tries to get the best of both: > > A server MUST NOT send more than on one instance of OPTION_V6_PREFIX64 per > scope. Servers MAY send one instance of OPTION_V6_PREFIX64 for each distinct > IPv6 multicast prefix with a distinct scope. > > Thanks, > Ian > >> On 9 Jun 2016, at 08:49, [email protected] >> <mailto:[email protected]> wrote: >> >> Hi Ian, >> >> There are two options: >> >> (1) >> >> Maintain the current text in the draft but add the following text to Section >> 4: >> >> Servers SHOULD NOT send more than one instance of OPTION_V6_PREFIX64, >> except if distinct IPv6 multicast prefixes with distinct scopes are >> configured. >> >> This is the behavior defined in >> https://tools.ietf.org/html/rfc6334#section-5/ >> <https://tools.ietf.org/html/rfc6334#section-5/>. >> >> (2) >> >> Add this text in Section 4: >> >> Servers MUST NOT send more than one instance of OPTION_V6_PREFIX64, >> except if distinct IPv6 multicast prefixes with distinct scopes are >> configured. >> >> And modify the text in Section 5 to indicate that the client must discard >> the options if all enclosed addresses are of the same scope. >> >> I agree with you that (2) will help to identify a server error, but with a >> risk to induce service disruptions. >> >> Which one do you prefer to be implemented in the draft? >> >> Thank you. >> >> Cheers, >> Med >> >> De : Ian Farrer [mailto:[email protected] <mailto:[email protected]>] >> Envoyé : mercredi 8 juin 2016 19:10 >> À : BOUCADAIR Mohamed IMT/OLN; Softwires WG >> Cc : [email protected] <mailto:[email protected]> >> Objet : Fwd: Problem in draft-ietf-softwire-multicast-prefix-option >> >> Hi Med, >> >> Forwarding this to the list (the left group mailing addresses were not >> working earlier). >> >> Please see inline below. >> >> Thanks, >> Ian >> >> >> Begin forwarded message: >> >> From: <[email protected] <mailto:[email protected]>> >> Subject: RE: Problem in draft-ietf-softwire-multicast-prefix-option >> Date: 8 June 2016 16:50:51 CEST >> To: ian Farrer <[email protected] <mailto:[email protected]>>, >> "[email protected] <mailto:[email protected]>" <[email protected] >> <mailto:[email protected]>>, Jacni Qin <[email protected] >> <mailto:[email protected]>>, "[email protected] <mailto:[email protected]>" >> <[email protected] <mailto:[email protected]>> >> Cc: "[email protected] <mailto:[email protected]>" >> <[email protected] <mailto:[email protected]>> >> >> Hi Ian, >> >> Please see inline. >> >> Cheers, >> Med >> >> De : ian Farrer [mailto:[email protected] <mailto:[email protected]>] >> Envoyé : mercredi 8 juin 2016 16:11 >> À : [email protected] <mailto:[email protected]>; BOUCADAIR Mohamed >> IMT/OLN; Jacni Qin; [email protected] <mailto:[email protected]> >> Cc : [email protected] <mailto:[email protected]> >> Objet : Problem in draft-ietf-softwire-multicast-prefix-option >> >> Hi, >> >> On reviewing this draft I would like to raise a problem with section 5 of >> the draft. The text is: >> >> "If all the enclosed IPv4-embedded IPv6 multicast prefixes have the same >> scope, the first instance of the option MUST be used." >> >> The problem is that this contravenes section 17 of RFC7227: >> Option order, either the order among many DHCPv6 options or the order >> of multiple instances of the same option, SHOULD NOT be significant. >> New documents MUST NOT assume any specific option processing order. >> >> [Med] That sentence does not assume any (preference) order. It does only >> provide one way to select one instance among that list. As a reminder, the >> server is supposed to return one instance (per scope). >> >> [if - If the client is taking the first occurrence within the option and >> attempting to configure it, then it is preferring this option over other >> instances based on the order in which it occurs in the message. >> >> The current text which describes the server behaviour (section 4) does not >> mention scope at all and does not specify any limitations on the number of >> instances or criteria for which they may be included - see RFC7227 sec 16. >> >> If the server is meant to only return a single instance of the option per >> scope, but it is sending more than one, then this is a server configuration >> error. A quasi-random mechanism for the client to try and work around this >> just means that the configuration error may get masked. >> >> As a suggestion, wouldn’t it be better to specify what the valid cases for >> the server including multiple option instances are and are not (with >> normative language). The client’s behaviour can then be defined to discard >> the options if they do not meet this criteria?] >> >> >> >> >> I raised this with the DHC WG chairs, and they have a couple of suggestions: >> >> 1. Define an encapsulating option - as the data inside an option can be >> order dependent. >> 2. Add a “preference” (octet?) and then a client can sort them based on this >> preference. >> >> Thanks, >> Ian > > > _______________________________________________ > Softwires mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/softwires > <https://www.ietf.org/mailman/listinfo/softwires> > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
