Re: M3UA version control

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/