Subject: RE: [Sigtran] M3UA version control

From: "J.Javier Pastor (ML/EEM)" <[email-masked]>
Date: Thu, 5 Feb 2004 14:49:30 +0100

Hi Michael et al., 

Take into account that you are referring to a section that talks about the ASPUP procedures. ASPUP message is what is really discussed and we should not include there the behavior as a response to any other messages. 

What should be included in the IG is paragraph within the section 3.8.1 explaining the "Invalid Version" code. I've just seen that we have a typo there and include the "Invalid Stream Identifier" twice while there is no mention of the "Invalid Version". We'll update the IG with some text explaining the general behavior.

Anyway, a good implementation that is following the state machines and so on from the M3UA document will not have this problems...

Cheers // Javier.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Samuel Dur D. Jeyaseelan
> Sent: jueves, 05 de febrero de 2004 13:16
> To: Michael Tuexen
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sigtran] M3UA version control
> 
> 
> 
> Brian,
>  Is there any reason why you disagree with the change?
> 
>  Is it is because ASP Up is the first message comes from ASP and
>  version control is checked at very first time with the assumption
>  all remaining messges will have the same version?
> 
> --Samuel
> 
> On Thu, 5 Feb 2004, Michael Tuexen wrote:
> 
> > 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
> > >>>>>> [email-masked]
> > >>>>>> https://www1.ietf.org/mailman/listinfo/sigtran
> > >>>>>
> > >>>>> -- 
> > >>>>> Brian F. G. Bidulock
> > >>>>> [email-masked]
> > >>>>> http://www.openss7.org/
> > >>>>>
> > >>>
> > >>> -- 
> > >>> Brian F. G. Bidulock
> > >>> [email-masked]
> > >>> http://www.openss7.org/
> > >>>
> > >
> > > -- 
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > >
> > 
> > 
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> > 
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran