Subject: RE: [Sigtran] M2PA v10 - comments on M2PA draft version 9

From: Schwarzbauer Hanns Juergen <[email-masked]>
Date: Tue, 21 Oct 2003 10:52:23 +0200

Dear all,

Section 9.1 normative references.

All dates given for the ITU-T recommendations are wrong.
Below the correct ones:

Q.703		July 1996
Q.704		July 1996
Q.2140	February 1995
Q.2210	July 1996

Furthermore there are Implementors' guides published for these ITU-T Recommendations that should be also part of this section
Q.703 Implementors' Guide 	March 1999
Q.704 Implementors' Guide 	December 2000
Q.2140 Implementors' Guide	March 1999 
Q.2210 Implementors' Guide	March 1999 

Section 9.2 Informative references
The reference to Q.702 is wrong
the correct one is:
Q.702		11-1988 (Bluebook)

Furthermore there is an Implementors' guide published for a ITU-T Recommendations that should be also part of this section

Q.705 Implementors' Guide September 1997

I haven't checked the ANSI and TTC dates!

Greetings

HannsJuergen

> -----Original Message-----
> From: Ong, Lyndon [mailto:[email-masked]]
> Sent: Thursday, October 16, 2003 11:45 PM
> To: 'Tom George'; SIGTRAN e-mail list
> Subject: RE: [Sigtran] M2PA v10 - comments on M2PA draft version 9
> 
> 
> Tom,
> 
> Thanks very much for the hard work!  Let's all take a look
> over version 10 and see if we can agree to move this on to
> IESG review.  I know many people are impatient to get this
> to closure.
> 
> Please send email with any concerns over sending this to
> IESG by Wednesday October 22nd, after that I plan to send
> official notification to our A-Ds and the IESG secretary.
> 
> Editorial comments can be logged and addressed during IESG
> review or RFC editing :o)
> 
> Cheers,
> 
> L. Ong
> 
> -----Original Message-----
> From: Tom George [mailto:[email-masked]]
> Sent: Thursday, October 16, 2003 2:32 PM
> To: SIGTRAN e-mail list
> Subject: [Sigtran] M2PA v10 - comments on M2PA draft version 9
> 
> 
> Comments on M2PA draft version 9.
> Tom George
> 10/16/2003
> 
> Here is my list of comments on M2PA draft version 9 and how they were
> incorporated into version 10. For the most part, they are arranged by
> the thread from the SIGTRAN list. The date/name/subject identify the
> beginning of the thread.
> 
> 01. 07/11/03 Brian Bidulock "[Sigtran] M2PA Last Call Comment - T1
>      Editorial".
> 
>      LS Ready is not always sent at end of proving. Clarify this.
> 
>      A: I changed the last 2 paragraphs of 4.1.3.
> 
> 02. 07/12/03 Brian Bidulock "[Sigtran] M2PA Last Call Comment" and
>      "FW: [Sigtran] M2PA Last Call Comment".
> 
>      A: In 4.1.3, changed reference to Q.2140.
> 
>         Changed section 4 to say that both ends must follow the same
>         MTP2 standard.
> 
> 03. 07/12/03 Brian Bidulock "[Sigtran] M2PA Last Call Comment - T6".
> 
>      A: Several changes made to section 4.1.5:
> 
>         While in receive congestion, M2PA does not ack messages. It
>         buffers them.
> 
>         Clarified paragraph about T6 and T7.
> 
>         In last paragraph, changed "T6" to "between LS Busy 
> and LS Busy
>         Ended" since T6 does not always run in Busy.
> 
> 04. 07/12/03 Brian Bidulock "[Sigtran] M2PA Last Call Comment - RPO".
> 
>      Section 4.1.4. The side in LPO can continue sending messages in
>      M2PA. So the side in RPO should continue receiving and acking
>      incoming messages.
> 
>      A: Updated section 4.1.4 to allow for this.
> 
> 05. 07/14/03 Brian Bidulock "[Sigtran] M2PA Last Call Comment - FSN".
> 
>      If FSN is out of order, M2PA should discard the message as in
>      MTP2.
> 
>      A: I corrected this in section 4.2.1 Sending and receiving
>      messages.
> 
> 06. 07/14/03 Brian Bidulock "[Sigtran] M2PA Last Call Comment - TTC".
> 
>      Change JT-Q704 "Retrieval Request and FSNC request" to "Retrieval
>      Request" to match terminology in the standard.
> 
>      A: In 4.2.3, changed JT-Q704 to JT-Q703.
> 
>         Updated text to distinguish between
>            - Retrieval Request, and
>            - Retrieval Request and FSNC
> 
> 07. 07/14/03 Brian Bidulock "[Sigtran] M2PA Last Call Comment -
>      JT-Q703 nit pick".
> 
>      PRI format is in JT-Q703, not JT-Q704.
> 
>      A: In 9.1, added reference to JT-Q703.
> 
>         In 2.3.1, added sentence about PRI with reference to JT-Q703.
> 
> 08. 07/14/03 Brian Bidulock "[Sigtran] M2PA Last Call Comment - LI nit
>      pick".
> 
>      Explanation about LI octet is unnecessary. Just define PRI field.
> 
>      A: I replaced this part of 2.3.1 with Brian's suggested text.
> 
> 09. 07/16/03 Andrew Booth "[Sigtran] M2PA last call comment - ANSI
>      primitives for LPO".
> 
>      Mention ANSI terminology.
> 
>      A: I did not want to do this. Use Q.703 terminology, and let the
>      reader substitute the corresponding terms.
> 
> 10. 07/21/03 Gaiser Franz "[Sigtran] M2PA Last Call Comment - LPO" and
>      "AW: [Sigtran] M2PA Last Call Comment - LPO".
> 
>      A: In 4.1.4, I clarified that the LS PR message's BSN is set to
>      last FSN received from peer.
> 
> 11. 08/04/03 Nitin Vairagare "[Sigtran] M2PA Timers". Should there be
>      a section on M2PA timers?
> 
>      A: This information is inherited from the M2PA standards. No need
>      to repeat it in M2PA. No change to the draft is needed.
> 
> 12. 09/0/03 Tom George "M2PA alignment without proving (was: [Sigtran]
>      Sigtran Plugtest - DAY 1)". A question from the plugtest. Why is
>      there an option of alignment without proving?
> 
>      A: In case someone wants an M2PA that works like Q.2210.
> 
> 13. 09/03/03 Rohit Raghav "[Sigtran] Queries on M2PA". Several
>      questions.
> 
>      A: No changes to the draft are needed.
> 
> 14. 09/04/03 Andrew Booth "[Sigtran] Misc M2PA questions".
> 
>      A: No changes to the M2PA draft are needed. But see item 
> 17 below.
> 
> 15. 09/05/03 Ken Morneault "[Sigtran] Sigtran Plugtest - DAY
>      2-5". Questions that came up at the plugtest.
> 
>      A: No changes to the M2PA draft are needed.
> 
> 16. 09/17/03 Javier Kim "[Sigtran] M2PA MSU_ACK frequency issue".
> 
>      A: In 4.2.1, text was change to be more specific than to ack
>      "promptly".
> 
> 17. 09/25/03 Jeffrey Craig "[Sigtran] (M2PA) LSPO and LSPR sent on
>      stream 1 and LSPR used to re-synch resolves PO issue?".
> 
>      A: The procedure was revised to put LS PO, LS PR, and LSR on
>      stream 1.
> 
> =====================================================================
> 
> -- 
> * Tom George       PB7-24001 (near B-21)      
> [email-masked]  *
> * 972-519-3168   Intranet:  
http://www.ssd.usa.alcatel.com/~tgeorge/  *
*   I actively disclaim speaking for Alcatel.  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

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

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

---

From: Tom George <[email-masked]>
Date: Tue, 21 Oct 2003 10:02:29 -0500

Hanns,

Comments below...

tomG.

> All dates given for the ITU-T recommendations are wrong.

I'll correct these three.

> Q.2210	July 1996

That's what I have for Q.2210.

> 
> Furthermore there are Implementors' guides published for these ITU-T 
 > Recommendations that should be also part of this section

What is in the implementor's guides that would make them normative 
references?

> Furthermore there is an Implementors' guide published for a 
 > ITU-T Recommendations that should be also part of this section
> 
   [...]

-- 
* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
*   I actively disclaim speaking for Alcatel.  I do not purport to    *
*   advertise or represent its position, operations, or activities.   *

---

From: Tom George <[email-masked]>
Date: Tue, 21 Oct 2003 10:59:52 -0500

Hanns,

You are right about Q.702. I will change that one.

T1.111 should be 2001:

   [T1.111]
        ANSI, "American National Standard for Telecommunications -
        Signaling System Number 7 (SS7) - Message Transfer Part (MTP),"
        ANSI T1.111-2001, American National Standards Institute
        (February 2001).

 From the TTC web site
http://www.ttc.or.jp/j/summary/std020/pdf/jt-q704.pdf
it looks like there is a new version of JT-Q704:

   [JT-Q704]
        TTC, "Message Transfer Part Signalling Network Functions," TTC
        Standard JT-Q704, Telecommunication Technology Committee (TTC),
        version 4 (May 30, 2002).

The summary of JT-Q703 did not have any dates. So I am not sure about 
the date for that one yet.  8-(
http://www.ttc.or.jp/j/summary/std020/pdf/q703.pdf

tomG.

Tom George wrote:
>> Q.2140 Implementors' Guide    March 1999 Q.2210 Implementors' Guide    
>> March 1999 
> 
>

---

From: Tom George <[email-masked]>
Date: Wed, 22 Oct 2003 15:17:35 -0500

Hanns and others,

Yutaka Sakai from Japan was kind enough to verify my dates for the TTC
document JT-Q703. I was able to get JT-Q704 from the TTC web site, as I
mentioned in an earlier message.

I went to the ITU web site and searched for the IGs Hanns listed.
http://www.itu.int/search/index.html

There was a later version of Q.Imp2210 than the one in Hanns' message.

So here is my updated section 9:

=====
9.  References

9.1 Normative

    [JT-Q703]
         TTC, "Message Transfer Part Signalling Link," TTC Standard
         JT-Q703, Telecommunication Technology Committee (TTC), version
         3 (April 27, 1994).

    [JT-Q704]

    [Q.703]
         ITU, "Signalling System No. 7 - Signalling Link," ITU-T
         Recommendation Q.703, ITU-T Telecommunication Standardization
         Sector of ITU (July 1996).

    [Q.Imp703]
         ITU, "Implementors' Guide (03/99) for Recommendation Q.703
         (07/96)" ITU-T Recommendation Q.Imp703, ITU-T Telecommunication
         Standardization Sector of ITU (March 1999).

    [Q.704]
         ITU, "Message Transfer Part - Signalling Network Functions and
         Messages," ITU-T Recommendation Q.704, ITU-T Telecommunication
         Standardization Sector of ITU (July 1996).

    [Q.Imp704]
         ITU, "Implementors' Guide (12/2000) for Recommendation Q.704
         (07/96)" ITU-T Recommendation Q.Imp704, ITU-T Telecommunication
         Standardization Sector of ITU (December 2000).

    [Q.2140]
         ITU, "B-ISDN ATM Adaptation Layer - Service Specific
         Coordination Function for Signalling at the Network Node
         Interface (SSCF at NNI)," ITU-T Recommendation Q.2140, ITU-T
         Telecommunication Standardization Sector of ITU (February
         1995).

    [Q.Imp2140]
         ITU, "Implementors' Guide (03/99) for Recommendation Q.2140
         (02/95)" ITU-T Recommendation Q.Imp2140, ITU-T
         Telecommunication Standardization Sector of ITU (March 1999).

    [Q.2210]
         ITU, "Message Transfer Part Level 3 Functions and Messages
         Using the Services of ITU-T Recommendation Q.2140," ITU-T
         Recommendation Q.2210, ITU-T Telecommunication Standardization
         Sector of ITU (July 1996).

    [Q.Imp2210]
         ITU, "Implementors' Guide (12/99) for Recommendation Q.2210
         (07/96)" ITU-T Recommendation Q.Imp2210, ITU-T
         Telecommunication Standardization Sector of ITU (December
         1999).

    [RFC791]
         Information Sciences Institute, "Internet Protocol - DARPA
         Internet Program - Protocol Specification," RFC 791, The
         Internet Society (September 1981).

    [RFC2119]
         S. Bradner, "Key words for use in RFCs to Indicate Requirement
         Levels," BCP 14, RFC 2119, Internet Engineering Task Force
         (March 1997).

    [RFC2196]
         B. Y. Frazer, "Site Security Handbook," RFC 2196, Internet
         Engineering Task Force (September 1997).

    [RFC2401]
         S. Kent, R. Atkinson, "Security Architecture for the Internet
         Protocol," RFC 2401, Internet Engineering Task Force (November
         1998).

    [RFC2434]
         T. Narten, H. T. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs," BCP 26, RFC 2434, The Internet
         Society (October, 1998).

    [RFC2960]
         R. Stewart, et. al., "Stream Control Transmission Protocol
         (SCTP)," RFC 2960, The Internet Society (February 2000).

    [RFC3309]
         J. Stone, R. Stewart, and D. Otis, "Stream Control Transmission
         Protocol (SCTP) Checksum Change," RFC 3309, The Internet
         Society (September 2002).

    [Security]
         J. Loughney, M. Tuexen, and J. Pastor-Balbas, "Security
         Considerations for SIGTRAN Protocols,"
         draft-ietf-sigtran-security-02.txt (January 2003).

    [T1.111]

9.2 Informative

    [M2UA]
         K. Morneault, et. al., "Signaling System 7 (SS7) Message
         Transfer Part 2 (MTP2) - User Adaptation Layer," RFC 3331,
         Internet Engineering Task Force - Signalling Transport Working
         Group (September, 2002).

    [Q.700]
         ITU, "Introduction to CCITT Signalling System No. 7," ITU-T
         Recommendation Q.700, ITU-T Telecommunication Standardization
         Sector of ITU (March 1993).

    [Q.701]
         ITU, "Functional Description of the Message Transfer Part (MTP)
         of Signalling System No. 7," ITU-T Recommendation Q.701, ITU-T
         Telecommunication Standardization Sector of ITU (March 1993).

    [Q.702]
         ITU, "Signalling Data Link," ITU-T Recommendation Q.702, ITU-T
         Telecommunication Standardization Sector of ITU (November
         1988).

    [Q.705]
         ITU, "Signalling System No. 7 - Signalling Network Structure,"
         ITU-T Recommendation Q.705, ITU-T Telecommunication
         Standardization Sector of ITU (March 1993).

    [Q.Imp705]
         ITU, "Implementors' guide (version 09/97) for Q.705 (03/93)"
         ITU-T Recommendation Q.Imp705, ITU-T Telecommunication
         Standardization Sector of ITU (September 1997).

    [RFC2719]
         L. Ong, et. al., "Framework Architecture for Signaling
         Transport," RFC 2719, The Internet Society (October 1999).

=====

Schwarzbauer Hanns Juergen wrote:
 > Furthermore there are Implementors' guides published for these
    [...]

---

From: Andrew Booth <[email-masked]>
Date: Wed, 22 Oct 2003 16:41:22 -0400

Hi Tom,

Is it usual to refer to an IETF draft in the Normative references, as 
M2PA does with [Security]?

Andrew

-- 
Andrew Booth, Software Developer
Signaling Systems Group, Performance Technologies
613-237-4344

Visit www.pt.com/mailing.html to subscribe to our Packets & Signals eLetter.

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 22 Oct 2003 22:57:56 +0200

Andrew,
you can not reference an ID as a Normative Reference, but that ID has
been approved as an PS. So there is no problem here.
Best regards
Michael