Subject: [Sigtran] M2PA v8

From: "McCandless, Kevin" <[email-masked]>
Date: Tue, 27 May 2003 13:54:17 -0700

Any status on M2PA v8 on whether it has completed last call?  There were a lot of comments on the list about this version.
 
Thanks,

Kevin

---

From: Tom George <[email-masked]>
Date: Wed, 28 May 2003 10:16:45 -0500

> "McCandless, Kevin" wrote:
> 
> Any status on M2PA v8 on whether it has completed last call?  There
> were a lot of comments on the list about this version.

Here is my list of comments. There is one comment from Jeff Craig that I
am still thinking about. 

List of comments on M2PA draft version 8. 
Tom George
05/28/2003

Here is my list of comments on M2PA draft version 8 and how they were
incorporated into version 9. For the most part, they are arranged by
the thread from the SIGTRAN list. The date/name/subject identify the
beginning of the thread.

The items that are still open are marked with "??".

01. 04/24/03 Tolga Asveren "[Sigtran] M2PA: T7 and dropping SCTP
    association after link failure".

    (This was a comment about version 7 that came in after I released
    version 8.)

    Should T7 be required to be per-message? Should M2PA terminate the
    association if the link fails?

    A: These issues have been discussed before. No change is needed.

    Changed wording to not explicitly require many timers.

02. 04/24/03 Jeff Craig "[Sigtran] (M2PA) Comments on M2PA v8".

    Several comments.

    A: Here are the comments for which I made changes.

       T7 and PO: Because LS PO is sent on a different stream, it can
       arrive ahead of a message sent before the LS PO. The sender
       would keep T7 running, but the receiver would buffer and not
       ack the message. This would cause the link to fail due to T7
       expiry. 

          To fix this, Delete (c) from 4.1.4 and follow MTP2's
	  behavior. In other words, stop T7 during LPO. 

       Typo: In 4.1.5, the typo is corrected - LS PO is changed to LS
       Busy.

       FSN, BSN, PO: ??

03. 04/28/03 Rohan "[Sigtran] Proving Message".

    Why is there a proving state and proving messages?

    A: For the same reason as in Q.703 and Q.2140: To verify that the
    link is usable before putting real traffic on it. See 4.1, 1st
    paragraph. No change needed.

04. 04/28/03 Pardeep "[Sigtran] Link States during Intial Alignment in
    M2PA".

    Are all of the MTP2 states during alignment needed in M2PA?

    A: Yes.

05. 04/28/03 Pardeep "[Sigtran] m2pa version control (sec 4.1.9)".

    Does "unsupported version" mean "incompatible old version"?

    A: Yes.

06. 04/28/03 Pardeep "[Sigtran] Need for One More message Type in
    M2PA?".

    Is there a need for an "error" message for incompatible M2PA
    versions?

    A: No. Severe errors like these require manual intervention.

07. 05/02/03 Pardeep "[Sigtran] FSN value".

    A: M2PA should not ignore the FSN in an empty user data message. 

       The first FSN should be set to 0, and the first BSN to -1, as
       in Q.703.

       No change to the document is necessary.

08. 05/06/03 HannsJuergen Schwarzbauer "[Sigtran] (M2PA) Comments on
    M2PA v8 - Last Call".

    Several comments.

    A: Here is what I did for the comments.

       Definition of SG: OK as is. 

          Changed definition of STP to refer to MTP. Added SP. Added
	  reference for SEP definition.

       RFC 2719: Reference to RFC 2719 is OK.

       XCO/XCA: There is sufficient warning about this. 

       FSNC or FSNT: It's FSNC as in Q.703.

       Empty User Data message: OK as is.

       Message Data: Added text to 2.3 to clarify what is in this
       field.

       Filler: OK as is.

       Registered port number: OK as is. 

       SLC in 4.1.2: Changed sentence in 4.1.2 to read: "Therefore, it
       is possible that the ***SLC*** values a and b MAY be equal."

09. 05/06/03 Andrew Booth "[Sigtran] M2PA v8".

    Should we include a comment on how to handle T7 after a LS Busy or
    LS Busy Ended is received?

    A: Do what MTP2 does. No change is needed to the draft.

10. 05/07/03 HannsJuergen Schwarzbauer "[Sigtran] (M2PA) Comments on
    M2PA v8 - Last Call".

    Proving_Interval has no value assigned to it.

    A: Proving may be omitted if allowed by the MTP2
    standard. Recommend that Proving_Interval be set to imitate
    expected rate of traffic.

11. 05/07/03 HannsJuergen Schwarzbauer "[Sigtran] (M2PA) Comments on
    M2PA v8 - Last Call".

    Spare bits in the LI field.

    A: Only the 2 priority bits are placed in this field. So there is
    no issue about the number of spare bits.

12. 05/07/03 HannsJuergen Schwarzbauer "[Sigtran] (M2PA) Comments on
    M2PA v8 - Last Call".

    LS messages do not go in retransmission buffer. So why say that
    they are not retrieved?

    A: Because untransmitted messages are sometimes retrieved. 

       Clarified in 4.2.1 that LS messages are not placed in
       retransmission buffer. Clarified in 4.2.3 that empty User Data
       messages are not retrieved.

=====================================================================

-- 
* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel;  3400 West Plano Pkwy,  MS PB7-SWPRO;  Plano, Texas 75075  *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran