RE: [Sigtran] I-D ACTION:draft-ietf-sigtran-sua-15.txt

[[e-mail]]

Brian,

These looked reasonable, I am in the process of adding them.

thanks,
John

> -----Original Message-----
> From: ext Brian F. G. Bidulock [mailto:[e-mail]]
> Sent: 05 September, 2003 17:27
> To: Loughney John (NRC/Helsinki); [e-mail]
> Subject: Re: [Sigtran] I-D ACTION:draft-ietf-sigtran-sua-15.txt
> 
> 
> John,
> 
> Did you ever get a chance to look at any of these?
> 
> --brian
> 
> Brian F. G. Bidulock wrote:                                   
>                         (Sat, 26 Jul 2003 08:02:15)
> > John,
> > 
> > Actually, there are a lot of problems with the changes made from
> > sua-14 to sua-15 as follows:
> > 
> > +   SCTP - Stream Control Transport Protocol. 
> > 
> > That would be Stream Control TRANSMISSION Protocol.  There 
> are quite a
> > few places in the document where this error is made.  Even in the
> > references:
> > 
> > +   Signalling Connection Control Part-User signalling over 
> IP using the 
> > +   Stream Control Transport Protocol. The protocol is 
> designed to be 
> > +   modular and symmetric, to allow it to work in diverse 
> architectures, 
> > +   such as a Signalling Gateway to IP Signalling Endpoint 
> architecture 
> > +   as well as a peer-to-peer IP Signalling Endpoint 
> architecture.   
> > 
> > -   [2960]         RFC 2960 "Stream Control Transport Protocol" R. 
> > +   [2960]         RFC 2960 "Stream Control Transport Protocol", R. 
> >                    Stewart, et al, November 2000. 
> > 
> > Please use "Siganlling" instead of "Signaling".
> > 
> > +   PC - Signaling System no. 7 Point Code. 
> > 
> > Network Appearance:
> > 
> > +   Network Appearance - The Network Appearance is an SUA local 
> > +   reference (typically an integer) shared by SG and AS 
> that together 
> > +   with a Signalling Point Code or global title uniquely 
> identifies an 
> > +   SS7 node by indicating the specific SS7 network it belongs to. 
> > 
> > Network appearance has no meaning in relationship to a Global Title.
> > Global Titles are independent of signalling point code and are only
> > meaningful to the node performing global title translation.  Strike
> > global title from the definition.
> > 
> > +   code (PC) and sub-system number (SSN).  The subsystem 
> identified by 
> > 
> > That should be "subsystem number," no hyphen.
> > 
> >  1.4.1 Support for the transport of SCCP-User Messages 
> >  
> >     The SUA supports the transfer of SCCP-user messages. 
> The SUA layer 
> > -   at the SG and at the ASP support the seamless transport 
> the user 
> > -   messages between the SG and the ASP. 
> > +   at the signaling gateway and at the ASP support the seamless 
> > +   transport the user messages between the signaling 
> gateway and the 
> > +   ASP. 
> > 
> > Above should be "transport of user messages" instead of 
> "transport the
> > user messages".
> > 
> >  1.4.2 SCCP Protocol Class Support 
> >  
> > -   Depending upon the SCCP-users supported, the SUA shall 
> support the 4 
> > +   Depending upon the SCCP-users supported, the SUA supports the 4 
> >     possible SCCP protocol classes transparently.  The SCCP 
> protocol 
> >     classes are defined as follows: 
> > 
> > Why the removal of SHALL?
> > 
> >  1.5.2 Address Mapping at the ASP 
> > 
> > -   An ASP routes responses to the SGP that it received 
> messages from; 
> > -   within the routing context which it is currently active and 
> > -   receiving traffic.  The routing context itself is used 
> by the ASP to 
> > -   select the SGP. 
> > +   An ASP routes all responses to the SGP that it received 
> messages 
> > +   from; within the routing context which it is currently 
> active and 
> > +   receiving traffic.  The ASP uses the routing context to 
> select the 
> > +   SGP. 
> > 
> > The second sentence is clearer, but the first sure is not.
> > 
> >  1.5.4 SCTP Stream Mapping 
> >  
> > -   The SUA supports SCTP streams. The SG/AS needs to 
> maintain a list of 
> > -   SCTP and SUA-users for mapping purposes.  SCCP-users requiring 
> > -   sequenced message transfer need to be sent over a 
> stream supporting 
> > -   sequenced delivery. 
> > +   The SUA supports SCTP streams. Signaling Gateway SG and 
> Application 
> > +   Servers need to maintain a list of SCTP and SUA-users 
> for mapping 
> > +   purposes.  SCCP-users requiring sequenced message 
> transfer need to 
> > +   be sent over a stream supporting sequenced delivery. 
> > 
> > Above use "Signalling" instead of "Signaling".  Also, ALL 
> SCTP streams
> > support sequenced delivery.  Please say "stream with 
> sequenced delivery"
> > instead of "stream supporting sequenced delivery".
> > 
> > +   The Reserved field is set to 0 in messages sent, is not 
> be examined 
> > +   on reception. 
> > +
> > 
> > Please make the above a proper sentence.  Something like: 
> "The Reserved
> > field is set to 0 in messages sent and is not to be 
> examined in messages
> > received."
> > 
> >     Implementation note: This message covers the following SCCP 
> >     messages: unitdata (UDT), extended unitdata (XUDT), 
> long unitdata 
> > -   (LUDT). 
> > +   (LUDT). Sequence Control is set to 0 for class 0 messages. 
> > 
> > This change is incorrect.  Please remove this addition.  We 
> discussed this
> > long ago and Sequence Control is required in class 0 
> messages for some
> > network configurations and for proper MTP relay accross a 
> relay point.
> > It might not be provided by the SCCP/SUA-User for class 0, 
> but then the
> > SUA layer (at ASP, IPSP or SGP) must ultimately select a 
> loadsharing value.
> > That is why we made the parameter MANDATORY for all 
> protocol classes.
> > 
> >     Note 1:    When the SSN is included, the DUNA message 
> corresponds to 
> > -              the SCCP N-STATE primitive. When SSN is not, 
> the DUNA 
> > -              message corresponds to the SCCP N-PCSTATE 
> primitive.   
> > +              the SCCP N-STATE primitive, and contains 
> just one point 
> > +              code in the Affected Point Code parameter. 
> When SSN is 
> > +              not, the DUNA message corresponds to the 
> SCCP N-PCSTATE 
> > +              primitive.   
> > 
> > The DUNA can contain multiple affected point codes even if 
> the SSN is
> > included.  This is particularly the case when the SG or 
> IPSP supports
> > the same subsystem on multiple point codes.  Please put it back the
> > way it was.
> > 
> > -   Note 1:    When the SSN is included, the SCON message 
> corresponds to 
> > -              the SCCP N-STATE primitive. When SSN is not 
> included, the 
> > -              SCON message corresponds to the SCCP 
> N-PCSTATE primitive. 
> > +   Note 1:    When the SSN is included it must be equal to 
> 1. If the 
> > +              SSN is included the SCON corresponds to the 
> N-PCSTATE 
> > +              primitive used to convey the Restricted 
> Importance Level 
> > +              (RIL) to the SCCP user. When the SSN is not 
> included, the 
> > +              SCON message corresponds to the SCCP 
> N-PCSTATE primitive 
> > +              reporting signalling point or network 
> congestion status. 
> > 
> > No, the SSN doesn't have to be 1.  Where did you get that idea?
> > 
> > -   Note 1:    The DUPU corresponds to the SCCP N-PCSTATE 
> primitive.  
> > +   Note 1:    The DUPU corresponds to the SCCP N-PCSTATE 
> primitive, and 
> > +               contains in the Affected Point Code 
> parameter just one 
> > +              point code.  
> > 
> > Particularly as User/Cause is always the SCCP SI number, 
> multiple affected
> > point codes can occur.  Please put it back the way it was.
> > 
> >  3.4.6 Destination Restricted (DRST) 
> >  
> >     The DRST message is optionally sent from the SG to all 
> concerned 
> >     ASPs to indicate that the SG has determined that one or more 
> >     destinations are now restricted from the point of view 
> of the SG, or 
> >     in response to a DAUD message if appropriate. The SUA 
> layer at the 
> >     ASP is expected to send traffic to the affected 
> destination via an 
> >     alternate SG of equal priority, but only if such an 
> alternate route 
> > -   exists and is available. If the affected destination is 
> currently 
> > -   considered unavailable by the ASP, the peer should be 
> informed that 
> > -   traffic to the affected destination can be resumed.  In 
> this case, 
> > -   the SUA layer should route the traffic through the SG 
> initiating the 
> > -   DRST message. 
> > +   exists and is available. If the ASP currently considers 
> the affected 
> > +   destination unavailable, the peer should be informed 
> that traffic to 
> > +   the affected destination could be resumed.  In this 
> case, the SUA 
> > +   layer should route the traffic through the SG 
> initiating the DRST 
> > +   message. 
> > 
> > This is only true if the DRST corresponds to TFR.  Note 
> also that the
> > DRST cannot correspond to N-PCSTATE because there is no 
> N-PCSTATE primitive
> > for PC restriction (it is an MTP concept only).  This 
> message corresponds to
> > N-COORD that has little to do with the description above, 
> no matter how is is
> > worded exactly.
> > 
> > -            0x17      Routing Key Change Refused 
> > +            0x17      Not Used in SUA 
> > 
> > Good, but you forgot to remove the statement later:
> > 
> >    The "Routing Key Change Refused" error is sent when the 
> SG refuses a 
> >    change in the Routing Key parameters.   
> > 
> > 
> > -   User/Cause                           0x010C 
> > +   Cause / User                         0x010C 
> > 
> > Everwhere else in the document it is referred to as 
> User/Cause, execpt here:
> > 
> >  3.10.12 Cause / User 
> > 
> > Change both of these to "User/Cause".
> > 
> >      0010     This is most commonly used in North American 
> networks. 
> >                The Translation Type implicitly determines Nature of 
> >                Address and Numbering Plan. This data can be 
> configured 
> >                in the SG. The number of digits is always even and 
> >                determined by the SCCP address length.  
> > -    0011                     Numbering Plan and 
> Translation Type are tak
> > +    0011                     Numbering Plan and 
> Translation Type are taken over. It 
> >                is implicitly assumed that the Nature of Address = 
> >                Unknown.  
> > -    0100                     This format is used in 
> international networ
> > +    0100                     This format is used in 
> international networks and most 
> >                commonly in networks outside North America. All 
> >                information to populate the source address 
> is present in 
> >                the SCCP Address. 
> > 
> > Above is text extending past 72 columns that was truncated 
> in sua-14.  Please
> > shift the text over.
> > 
> >       0              Unknown 
> >       1 - 63         International services 
> >       64 - 127       Spare 
> > -     128 > 254      National network specific 
> > +     128 û 254      National network specific 
> >       255            Reserved 
> > 
> > Non ASCII character, again.
> > 
> >            Value     Description  
> >             0x0      No special options 
> >             0x1      Return message on error 
> >  
> > -                    Bits 3-7 are spare and SHOULD be coded 
> zero, and MUS
> > +                    Bits 3-7 are spare and SHOULD be coded 
> zero, and MUST be 
> >           ignored by the receiver. 
> > 
> > Again text extending beyond 72 columns.
> > 
> >  4.3 AS and ASP State Maintenance 
> >  
> > -   The SUA layer on the SGP maintains the state of each 
> remote ASP, in 
> > -   each Application Server that the ASP is configured to receive 
> > +   The SUA layer on on the SGP maintains the state of each 
> remote ASP, 
> > +   in each Application Server that the ASP is configured 
> to receive 
> >     traffic, as input to the SUA message distribution function.  
> > 
> > All this change did was introduce a typo: "on on".
> > 
> > +      1 IPSP Single Exchange (SE) model. Only a single exchange of 
> > +        ASPTM or ASPSM messages is needed to change the 
> IPSP state. 
> > +        This means that a set of request from one end and 
> acknowledge 
> > +        from the other will be enough. This configuration requires 
> > +        static RK configuration.  
> > +
> > +      2 IPSP Double Exchange (DE) model. Both IPSPs have to send 
> > +        request messages and both IPSPs have to 
> acknowledge the request 
> > +        messages from the other end. This results in a 
> double exchange 
> > +        of ASPTM and ASPSM message, one from each end. This 
> > +        configuration supports dynamic routing key 
> configuration by 
> > +        using RKM messages in the same way as ASP-SGP scenario.  
> > 
> > Remove mention of RK configuration.  This has not been agreed.
> > 
> > +   In order to ensure interoperability, an M3UA implementation 
> > +   supporting IPSP communication MUST support IPSP SE 
> model and MAY 
> > +   implement IPSP DE model.  
> > 
> > Change M3UA to SUA above.
> > 
> > +   * Reception of messages from the peer M3UA layer at the 
> ASP/IPSP;  
> > +   * Reception of some messages from the peer M3UA layer at other 
> > +   ASPs/IPSPs in the AS (e.g., ASP Active message indicating 
> > 
> > Change M3UA to SUA above.
> > 
> > +   ASP-DOWN: The remote M3UA peer at the ASP/IPSP is 
> unavailable and/or 
> > +   the related SCTP association is down.  Initially all 
> ASPs/IPSPs will 
> > +   be in this state. An ASP/IPSP in this state SHOULD NOT 
> be sent any 
> > +   SUA messages, with the exception of Heartbeat, ASP Down 
> Ack and Error 
> > 
> > Change M3UA to SUA above.
> > 
> > +   ASP-INACTIVE: The remote M3UA peer at the ASP/IPSP is 
> available (and 
> > +   the related SCTP association is up) but application traffic is 
> > +   stopped. In this state the ASP/IPSP SHOULD NOT be sent 
> any DATA or 
> > +   SSNM messages for the AS for which the ASP/IPSP is inactive.  
> > +
> > +   ASP-ACTIVE: The remote M3UA peer at the ASP/IPSP is 
> available and 
> > +   application traffic is active (for a particular Routing 
> Context or 
> > +   set of Routing Contexts).  
> > 
> > Change M3UA to SUA above.
> > 
> > +   SCTP CDI: The SCTP CDI denotes the local SCTP layer's 
> Communication 
> > +   Down Indication to the Upper Layer Protocol (M3UA) on 
> an SGP.  The 
> > +   local SCTP layer will send this indication when it 
> detects the loss 
> > +   of connectivity to the ASP's peer SCTP layer.  SCTP CDI 
> is understood 
> > +   as either a SHUTDOWN_COMPLETE notification or 
> COMMUNICATION_LOST 
> > +   notification from the SCTP layer.  
> > +
> > +   SCTP RI: The local SCTP layer's Restart indication to 
> the upper layer 
> > +   protocol (M3UA) on an SG.  The local SCTP will send 
> this indication 
> > +   when it detects a restart from the ASP's/IPSP's peer 
> SCTP layer.  
> > 
> > You now have two SCTP CDI and SCTP RI paragraphs.  Those 
> above and these
> > below:  Delete the ones above because they have M3UA instead of SUA.
> > 
> >    SCTP CDI: The SCTP CDI denotes the local SCTP layer's 
> Communication 
> >    Down Indication to the Upper Layer Protocol (SUA) on an SGP. The 
> >    local SCTP layer will send this indication when it 
> detects the loss 
> >    of connectivity to the ASP's peer SCTP layer.  SCTP CDI 
> is understood 
> >    as either a SHUTDOWN_COMPLETE notification or COMMUNICATION_LOST 
> >    notification from the SCTP layer. 
> > 
> >    SCTP RI: The local SCTP layer's Restart indication to 
> the upper layer 
> >    protocol (SUA) on an SG.  The local SCTP will send this 
> indication 
> >    when it detects a restart from the ASP's peer SCTP layer. 
> > 
> > The diagram now says "Other IPSP in AS Overrides".  Please say
> > "Other ASP/IPSP in AS Overrides".
> > 
> >                 |      Other   +-------|              | 
> > -               |   ASP in AS  |       +--------------+ 
> > +               |   IPSP in AS |       +--------------+  
> >                 |   Overrides  |           ^     | 
> > 
> >  4.3.4.2 ASP Down Procedures 
> >  
> >     The ASP will send an ASP Down message to an SGP when 
> the ASP wishes 
> >     to be removed from service in all Application Servers 
> that it is a 
> > -   member and no longer receive any DATA, SSNM or ASPTM 
> messages.  This 
> > -   action MAY be initiated at the ASP by an M-ASP_DOWN 
> request primitive
> > -   from Layer Management or MAY be initiated automatically 
> by an SUA 
> > -   management function.    
> > +   member and no longer receive any Connectionless or Connection - 
> > +   Oriented, SNM or ASPTM messages.  This action MAY be 
> initiated at the 
> > +   ASP by an M-ASP_DOWN request primitive from Layer 
> Management or MAY 
> > +   be initiated automatically by an SUA management function. 
> > 
> > Above change SNM to SSNM.
> > 
> >     When an ASP wishes to withdraw from receiving traffic 
> within an AS, 
> > -   the ASP sends an ASP Inactive message to the SGP or IPSP.  This 
> > -   action MAY be initiated at the ASP by an M-ASP_INACTIVE request 
> > -   primitive from Layer Management or MAY be initiated 
> automatically by 
> > -   an SUA management function.  In the case where an ASP 
> is processing 
> > -   the traffic for more than one Application Server across 
> a common SCTP
> > -   association, the ASP Inactive message contains one or 
> more Routing 
> > -   Contexts to indicate for which Application Servers the 
> ASP Inactive 
> > -   message applies.  In the case where an ASP Inactive 
> message does not 
> > -   contain a Routing Context parameter, the receiver must 
> know, via 
> > -   configuration data, which Application Servers the ASP 
> is a member and
> > -   move the ASP to the ASP-INACTIVE state in each all Application 
> > -   Servers.  In the case of an Override mode AS, where 
> another ASP has 
> > -   already taken over the traffic within the AS with an ASP Active 
> > -   ("Override") message, the ASP that sends the ASP 
> Inactive message is 
> > -   already considered by the SGP to be in state 
> ASP-INACTIVE.  An ASP 
> > -   Inactive Ack message is sent to the ASP, after ensuring 
> that all 
> > -   traffic is stopped to the ASP.  
> > +   or the ASP wants to initiate the process of activation, 
> the ASP sends 
> > +   an ASP Inactive message to the SGP or IPSP.  
> > 
> > Change above to "initiate the process of deactivation" 
> instead of "initiate
> > the process of activation".
> > 
> > Also, above you have delted the description of the ASP 
> Inactive procedure for
> > Override mode.  Please put back:
> > 
> > -                     In the case where an ASP Inactive 
> message does not 
> > -   contain a Routing Context parameter, the receiver must 
> know, via 
> > -   configuration data, which Application Servers the ASP 
> is a member and
> > -   move the ASP to the ASP-INACTIVE state in each all Application 
> > -   Servers.
> > 
> > and
> > 
> > -             In the case of an Override mode AS, where 
> another ASP has 
> > -   already taken over the traffic within the AS with an ASP Active 
> > -   ("Override") message, the ASP that sends the ASP 
> Inactive message is 
> > -   already considered by the SGP to be in state 
> ASP-INACTIVE.  An ASP 
> > -   Inactive Ack message is sent to the ASP, after ensuring 
> that all 
> > -   traffic is stopped to the ASP.  
> > 
> > The following addition:
> > 
> > +4.8 NIF Not Available on SGP  
> > +
> > +   If the SG (all the SGPs) is isolated from the NIF, then 
> all the users 
> > +   are isolated from the SS7 network.  A DUNA(*) message 
> MUST be sent 
> > +   from the SGPs to all the ASPs.   
> > +
> > +   If only one SGP in the SG is isolated entirely from the 
> NIF, the SGP 
> > +   SHOULD abort its associations. An alternative would be 
> for the SGP to 
> > +   send ASP Down Ack. 
> > +
> > +   If one or more SGP suffer a partial failure (where aborting the 
> > +   association(s) would cause all active AS(es) to fail), 
> then the SGP 
> > +   MUST send DUNA messages for the affected SPC(es).  This 
> is the case 
> > +   where an SGP can continue to service one or more active 
> AS(es), but 
> > +   due to a partial failure it is unable to service 
> other(s) active 
> > +   AS(es). 
> > 
> > Please remove the entire addition.  The M3UA IG has removed 
> this.  That is
> > the problem with adding stuff from the M3UA IG.  The M3UA 
> IG has not gone
> > through Last Call.
> > 
> > +   [SIGSEC]       J. Loughney, M. Tuexen, J. 
> Pastor-Balbas, "Security 
> > +                  Considerations for SIGTRAN Protocols", Work in 
> >                    Progress.  
> > 
> > There is a Work In Progress as a normative reference.  This 
> draft will be
> > held until this reference becomes an RFC.
> > 
> > --brian
> > 
> > 
> > John Loughney wrote:                                (Thu, 
> 03 Jul 2003 19:29:23)
> > > Hi all,
> > > 
> > > I have updated SUA, I have tried to incorporate some of 
> the major issues
> > > from the M3UA Implementation Guide.  All interested 
> parties, please
> > > give the document a quick read, because I would like to 
> send this to the
> > > IESG for final approval.
> > > 
> > > thanks,
> > > John
> > > 
> > > > -----Original Message-----
> > > > From: ext [e-mail] 
> [mailto:[e-mail]]
> > > > Sent: 03 July, 2003 18:33
> > > > Cc: [e-mail]
> > > > Subject: [Sigtran] I-D ACTION:draft-ietf-sigtran-sua-15.txt
> > > > 
> > > > 
> > > > 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		: Signalling Connection Control Part 
> > > > User Adaptation 
> > > >                           Layer (SUA)
> > > > 	Author(s)	: J. Loughney, G. Sidebottom
> > > > 	Filename	: draft-ietf-sigtran-sua-15.txt
> > > > 	Pages		: 118
> > > > 	Date		: 2003-7-3
> > > > 	
> > > > This Internet Draft defines a protocol for the transport of 
> > > > any         Signalling Connection Control Part-User 
> > > > signalling over IP using the   Stream Control Transport 
> > > > Protocol. The protocol is designed to be 
> > > > modular and symmetric, to allow it to work in diverse 
> architectures, 
> > > > such as a Signalling Gateway to IP Signalling Endpoint 
> architecture 
> > > > as well as a peer-to-peer IP Signalling Endpoint architecture.
> > > > 
> > > > A URL for this Internet-Draft is:
> > > > 
> http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sua-15.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-sua-15.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-sua-15.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.
> > > > 
> > > 
> > > _______________________________________________
> > > Sigtran mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > 
> > -- 
> > Brian F. G. Bidulock
> > [e-mail]
> > http://www.openss7.org/
> > 
> > _______________________________________________
> > Sigtran mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> -- 
> Brian F. G. Bidulock
> [e-mail]
> http://www.openss7.org/
> 

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