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

Brian,

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

Done.

> > Please use "Siganlling" instead of "Signaling".
> > 
> > +   PC - Signaling System no. 7 Point Code. 

Done.

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

Done

> > +   code (PC) and sub-system number (SSN).  The subsystem identified by 
> > 
> > That should be "subsystem number," no hyphen.

Done

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

done.

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

Editorial clean-up.  IESG complained about 'shall' - in my opinion, it
doesn't affect the meaning.

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

I put the first version of the first sentence back in.

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

Done

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

Done

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

Done.

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

Done

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

Do you suggest returning to the original text?

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

Done

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

What do you suggest as text?

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

Text removed.

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

Fixed.

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

Fixed.

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

Fixed.

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

Fixed

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

Fixed

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

Done.

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

Done

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

Done.

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

Done

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

Done

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

Done.

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

Done

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

Done

> >     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" nstead of "initiate
> > the process of activation".

Done

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

Done

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

Done.
´
> > +   [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.

Yes, I understand.  This was the IESGs point.  They wanted the SIGTRAN security
document to be an RFC before SUA would pass the IESG, this is why SUA has been
held up.

John

_______________________________________________
Sigtran mailing list
Sigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/sigtran