RE: [Sigtran] M3UA IG Last Call Comment

["J.Javier Pastor (ML/EEM)" <[e-mail]>]

Dear Michael, 

Pls, see my comments below...

> -----Original Message-----
> From: Michael Tuexen [mailto:[e-mail]]
> Sent: martes, 17 de febrero de 2004 16:00
> To: J.Javier Pastor (ML/EEM)
> Cc: [e-mail]
> Subject: Re: [Sigtran] M3UA IG Last Call Comment
> 
> 
> 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.
> 
Yes I understand, and my personal opinion is that it was due to the lack of explanation of this parameter in other sections. Now it is explained in general (all the messages). And a specific section inside the Asp-Up procedures is kept due to detection of invalid versions in ASP-Up is the regular procedure to detect different M3UA versions implemented. This is a typical case that may happen when operators updated their nodes. But receiving a packet in the middle of the data exchange with the wrong version is an error as it may be receiving and invalid ASP identifier. Nothing different there. General explanation is enough.

> 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.


Take into account that there are not specific sections for saying that Message Class/Type and other errors are checked in every message either and this point is perfectly understood.  I think the main problem with this concrete error during the Plugtests is that the only place where it was treated was inside the ASP-Up procedures (of course it was a typo). Now it is treated as the other ones and it should be understood as the other ones. 

My personal opinion, as I said, is that the current change is enough, but if there are more support to your proposal, I have no problem in changing it. 


Thanks // Javier.


> 
> 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.
> >
> >
> >> -----Original Message-----
> >> From: [e-mail]
> >> [mailto:[e-mail]]On Behalf Of
> >> Michael Tuexen
> >> Sent: lunes, 16 de febrero de 2004 22:06
> >> To: [e-mail]
> >> 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, [e-mail] 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:
> >>> 	[e-mail].
> >>> 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:	<[e-mail]>
> >>
> >>
> >> _______________________________________________
> >> Sigtran mailing list
> >> [e-mail]
> >> 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.
> >
> >
> 

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/sigtran