5 Feb 2004 13:01
Re: M3UA version control
Michael Tuexen <Michael.Tuexen <at> lurchi.franken.de>
2004-02-05 12:01:18 GMT
2004-02-05 12:01:18 GMT
Brian, you disagree with the change? This means you want to have an error ONLY returned for ASP-Up messages as the RFC states? I'm suggesting a change that it is returned for all messages. Best regards Michael On Feb 5, 2004, at 12:33 PM, Brian F. G. Bidulock wrote: > Michael, > > I missed that. And, therefore, disagree with the change. An error > must be returned for any message with an unsupported version, not > just ASP Up, as the RFC already states. The example case was in > my last mail. > > --brian > > Michael Tuexen wrote: > (Thu, 05 Feb 2004 12:24:07) >> Brian, >> >> part of my suggestion is to replace: >> >> If an ASP Up message with an unsupported version is received, the >> >> with >> >> If a message with an unsupported version is received, the >> >> At least for me, this does change the requested behaviour. >> >> Best regards >> Michael >> >> On Feb 5, 2004, at 11:30 AM, Brian F. G. Bidulock wrote: >> >>> Michael, >>> >>> I don't think that your proposed text takes us any farther towards >>> that goal. You have changed "assumed that" to "likely that the >>> message having an unsupported version is an ASP Up message and >>> therefore [likely] that". >>> >>> This is just description. The requirement is (unchanged): >>> >>>> If a message with an unsupported version is received, the >>>> receiving end responds with an Error message, indicating the version >>>> the receiving node supports and notifies Layer Management. >>> >>> This is obviously any message. >>> >>> As there is no change to the requirement, the new text is >>> superfluous. >>> >>> Regardless of likelihoods or assumptions, the Error message is >>> returned to any message received with an unsupported version and >>> Layer >>> Management is notified. Suggesting that it is likely that an ASP Up >>> is the cause, actually distracts from the requirement to return the >>> error to any message. >>> >>> A node might actually send message Foo with Version=100 to test a >>> remote node's support for message Foo (only available in Version=100) >>> while performing the ASP Up and ASP Active procedures using >>> Version=1. >>> This requirement provides that message Foo will be retured with an >>> "usupported version" if version 100 is not supported (and obviously >>> the message Foo is not supported). >>> >>> It would be better to strike the line starting with "Because", >>> because >>> it was superfluous to begin with. Changing assumptions to >>> likelihoods >>> does not increase its pertinence. >>> >>> --brian >>> >>> >>> Michael Tuexen wrote: >>> (Thu, 05 Feb 2004 10:17:40) >>>> Brian, >>>> >>>> I agree with you that there are a lot of places which are not >>>> very precisely (this is the same with other RFCs) but this >>>> question came up multiple times. Others not. That is why I'm >>>> asking to clarify this. >>>> >>>> I know about customers and testers who test exactly this and >>>> always ask: what is the correct behaviour. So what is the >>>> problem in making this clear? Think about having different >>>> customers requesting different implementations? >>>> >>>> Best regards >>>> Michael >>>> >>>> On Feb 4, 2004, at 11:46 PM, Brian F. G. Bidulock wrote: >>>> >>>>> Michael, >>>>> >>>>> I think you need to read the RFC from the viewpoint of a >>>>> specification >>>>> instead of the viewpoint of an implementation. When it says >>>>> "assumed" >>>>> it means "assumed [by the authors in the specification of the >>>>> protocol]" >>>>> and not "assumed [by the implementation]". >>>>> >>>>> There are many place in the RFC where this is the case, because of >>>>> the >>>>> editors' preference for words like "assumed". If we are to correct >>>>> the lazy >>>>> English in the document, it would require an extensive rewrite. >>>>> >>>>> --brian >>>>> >>>>> Michael Tuexen wrote: >>>>> (Wed, 04 Feb 2004 21:56:43) >>>>>> Dear all, >>>>>> >>>>>> the RFC describes that an M3UA endpoint should check the version >>>>>> field >>>>>> for ASP Up messages and leaves it unspecified how other messages >>>>>> should >>>>>> be handled. >>>>>> >>>>>> In real scenarios the first message having an unsupported message >>>>>> is >>>>>> most likely an ASP-Up message, but my experience is, that people >>>>>> testing >>>>>> implementations always ask how these other messages should be >>>>>> handled. >>>>>> >>>>>> Therefore I would like to suggest a clarification in the IG >>>>>> clearly >>>>>> stating how these other messages with an unsupported version >>>>>> should >>>>>> be handled. >>>>>> >>>>>> We can specify that it is checked for all messages or only for >>>>>> ASP-Up >>>>>> messages, ignoring the version field for non ASP-Up messages. >>>>>> >>>>>> The easiest solution seems to be (for me) to check the field for >>>>>> all messages. So you could write >>>>>> >>>>>> if (message->version != 1) >>>>>> send(error) >>>>>> >>>>>> instead of >>>>>> >>>>>> if ((message->class == 3) && (message->type == 1) && >>>>>> (message->(message->version != 1)) >>>>>> send(error) >>>>>> >>>>>> Therefore I suggest to include the following text in the IG. >>>>>> >>>>>> Best regards >>>>>> Michael >>>>>> >>>>>> >>>>>> <---- SNIP >>>>>> 3.28 Version Control >>>>>> >>>>>> 3.28.1 Description of the problem >>>>>> >>>>>> The RFC describes how ASP Up messages with an unsupported version >>>>>> are handled but leaves it unspecified how other messages should be >>>>>> handled if the version number is not supported. >>>>>> >>>>>> 3.28.2 Text changes to the document >>>>>> --------- >>>>>> Old text: (Section 4.3.4.1.1) >>>>>> --------- >>>>>> >>>>>> 4.3.4.1.1 M3UA Version Control >>>>>> >>>>>> If an ASP Up message with an unsupported version is received, >>>>>> the >>>>>> receiving end responds with an Error message, indicating the >>>>>> version >>>>>> the receiving node supports and notifies Layer Management. >>>>>> >>>>>> This is useful when protocol version upgrades are being >>>>>> performed >>>>>> in >>>>>> a network. A node upgraded to a newer version should support >>>>>> the >>>>>> older versions used on other nodes it is communicating with. >>>>>> Because >>>>>> ASPs initiate the ASP Up procedure it is assumed that the >>>>>> Error >>>>>> message would normally come from the SGP. >>>>>> >>>>>> --------- >>>>>> New text: (Section 4.3.4.1.1) >>>>>> --------- >>>>>> >>>>>> 4.3.4.1.1 M3UA Version Control >>>>>> >>>>>> If a message with an unsupported version is received, the >>>>>> receiving end responds with an Error message, indicating the >>>>>> version >>>>>> the receiving node supports and notifies Layer Management. >>>>>> >>>>>> This is useful when protocol version upgrades are being >>>>>> performed >>>>>> in >>>>>> a network. A node upgraded to a newer version should support >>>>>> the >>>>>> older versions used on other nodes it is communicating with. >>>>>> Because >>>>>> ASPs initiate the ASP Up procedure it is likely that the >>>>>> message >>>>>> having >>>>>> an unsupported version is an ASP Up message and therefore that >>>>>> the >>>>>> Error >>>>>> message would normally come from the SGP. >>>>>> >>>>>> >>>>>> 3.28.3 Solution description >>>>>> >>>>>> The new text clearly describes that the version should be checked >>>>>> for >>>>>> all >>>>>> messages. >>>>>> <---- SNIP >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Sigtran mailing list >>>>>> Sigtran <at> ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/sigtran >>>>> >>>>> -- >>>>> Brian F. G. Bidulock >>>>> bidulock <at> openss7.org >>>>> http://www.openss7.org/ >>>>> >>> >>> -- >>> Brian F. G. Bidulock >>> bidulock <at> openss7.org >>> http://www.openss7.org/ >>> > > -- > Brian F. G. Bidulock > bidulock <at> openss7.org > http://www.openss7.org/ >
RSS Feed