Subject: RE: [Sigtran] M3UA IG Last Call Comment

From: "J.Javier Pastor (ML/EEM)" <[email-masked]>
Date: Tue, 17 Feb 2004 15:26:03 +0100

Michael, 

The RFC does not say that the version number is only checked for ASP-UP message, but it states how to deal with different M3UA versions, normally detected during the ASPUP exchange.

All the error procedures are defined when the ERROR message is explained, as it is also now the "invalid version". That should be sufficient to understand how to respond to a wrong version message.

The text you sent was trying to include the general error parameter procedure inside the ASPUP section, what was not correct. By including the general description of this Error Parameter and their use, it should solve the problem since it applies to all messages, as you prefer... 

Cheers // Javier.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Michael Tuexen
> Sent: lunes, 16 de febrero de 2004 22:06
> To: [email-masked]
> Subject: Re: [Sigtran] I-D
> ACTION:draft-ietf-sigtran-m3ua-implementors-guide-07.txt
> 
> 
> Dear all,
> 
> is it possible that we specify clearly if the version number 
> is checked
> either
> for all messages
> or
> only for ASPU-UP messages.
> 
> As explained in my earlier mail I would prefer the first solution.
> I also think that there was consensus on this on the list.
> 
> The new ID describes only the Error parameter but leaves it open, how
> it is used. Please reconsider the text I sent.
> 
> Best regards
> Michael
> 
> 
> On 16. Feb 2004, at 21:41 Uhr, [email-masked] wrote:
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts  
> > directories.
> > This draft is a work item of the Signaling Transport 
> Working Group of  
> > the IETF.
> >
> > 	Title		: M3UA ImplementorÆs Guide
> > 	Author(s)	: J. Pastor, K. Morneault
> > 	Filename	: 
> draft-ietf-sigtran-m3ua-implementors-guide-07.txt
> > 	Pages		: 70
> > 	Date		: 2004-2-16
> > 	
> > This document contains a compilation of all defects found up until
> > the publication date for M3UA [RFC3332]. These defects may be of an
> > editorial or technical nature. This document may be thought of as a
> > companion document to be used in the implementation of M3UA to
> > clarify errors in the original M3UA document. This document updates
> > RFC3332 and text within this document supersedes the text found in
> > RFC3332.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-sigtran-m3ua- 
> > implementors-guide-07.txt
> >
> > To remove yourself from the IETF Announcement list, send a 
> message to
> > ietf-announce-request with the word unsubscribe in the body of the  
> > message.
> >
> > Internet-Drafts are also available by anonymous FTP. Login 
> with the  
> > username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > 	"get draft-ietf-sigtran-m3ua-implementors-guide-07.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > 	[email-masked].
> > In the body type:
> > 	"FILE  
> > /internet-drafts/draft-ietf-sigtran-m3ua-implementors-guide-07.txt".
> > 	
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> > 		
> > 		
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> > Content-Type: text/plain
> > Content-ID:	<[email-masked]>
> 
> 
> _______________________________________________
> 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

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 17 Feb 2004 16:00:13 +0100

Javier,

I do see that the 'new text' reads

    The "Invalid Version" error is sent 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.

But looking at the RFC there is an explicit section M3UA Version Control
under the section ASP Up Procedures which led several people to the
conclusion that they do not have to check it for other messages.

Therefore I'm suggesting to put the text I sent earlier as a new 
section 4.7
and delete section 4.3.4.1.1.

I understood you argument regarding 4.3.3.1.1 but I think version 
control
is a general thing and should be stated explicitly in a place for 
general
things and not only in a subsection regarding ASPUP procedures.

Best regards
Michael

On 17. Feb 2004, at 15:26 Uhr, J.Javier Pastor (ML/EEM) wrote:

>
> Michael,
>
> The RFC does not say that the version number is only checked for 
> ASP-UP message, but it states how to deal with different M3UA 
> versions, normally detected during the ASPUP exchange.
>
> All the error procedures are defined when the ERROR message is 
> explained, as it is also now the "invalid version". That should be 
> sufficient to understand how to respond to a wrong version message.
>
> The text you sent was trying to include the general error parameter 
> procedure inside the ASPUP section, what was not correct. By including 
> the general description of this Error Parameter and their use, it 
> should solve the problem since it applies to all messages, as you 
> prefer...
>
> Cheers // Javier.
>
>
> 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.
>
>