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

John,

John Loughney wrote:                                                                  (Thu, 02 Oct 2003 12:56:36)

-[snip]-
> > > 
> > >  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.

Ok.

-[snip]-
> > > -   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?

No, just remove the "When the SSN is included it must be equal to 1."

-[snip]-
> > >  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?

Remove section 3.4.6.  It only applies to M3UA, not SUA.

-[snip]-
> > > +   [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.

Why not just remove the reference?

--brian

-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/

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