Subject: RE: [Sigtran] SUA comments

From: [email-masked]
Date: Thu, 7 Mar 2002 18:01:05 +0200

Hi Brian,

I agree with your comments.  However, if anyone feels up to
starting an implementors guide, please volunteer!

Thanks,
John

> -----Original Message-----
> From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 07 March, 2002 07:03
> To: Tomar, Nitin
> Cc: [email-masked]'; Loughney John (NRC/Helsinki); [email-masked]'
> Subject: Re: [Sigtran] SUA comments
> 
> 
> Nitin,
> 
> Tomar, Nitin wrote:                                        
> (Wed, 06 Mar 2002 19:10:47)
> > Hi John,
> >  Following are few comments on SUA draft 12.
> > - Nitin.
> > 
> > 1. Description of DRST message shall include following :
> >     When SSN is not included it shall not be passed to 
> SUA-User at ASP,
> > instead it shall be used by SUA for
> >     routing towards SGPs (similar to M3UA routing to a 
> restricted route).  
> 
> SUA is hardly in the position to require this.  An implementation may
> choose to pass this to the SUA user if it wishes.
> 
> > 
> > 2. To send DRST message (and DUNA/DAVA) by SG, MTP3 at SG 
> needs interworking
> > with SUA, hence a section for
> >     MTP3 - SUA interworking at the SG is required in the draft.
> 
> This is incorrect (particularly for DUNA and DAVA which are already
> represented in SCCP as the N-PCSTATE primitive).  No MTP3-SUA 
> interworking
> is required.  MTP3 at the SG passes these indications as MTP-STATUS,
> MTP-PAUSE and MTP-RESUME primitives to SCCP which passes the 
> equivalent
> N-PCSTATE primitives to the SCCP user.
> >    
> > 3. Section 3.8.2 Registration Response (REG RSP)
> >     - The first para has incomplete sentence.
> >     - Note 1, shall include following statement similar to M3UA:
> >      "The number of results in a single REG RSP message 
> MUST be anywhere
> > from one to the total number of
> >        Routing Key parameters found in the corresponding 
> REG REQ message"
> 
> This can be caught in the implementor's guide.
> 
> > 
> > 4. Section 3.8.4 Deregistration Response (DEREG RSP)
> >      - Note 1, shall include following statement
> >        "The number of results in a single DEREG RSP message 
> MUST be anywhere
> > from one to the total number of 
> >          number of Routing Context parameters found in the 
> corresponding
> > DEREG REQ message"
> 
> This, too, can be caught in the implementor's guide.
> 
> > 
> > 5. Broadcast mode has too many implementation dependent 
> issues and to fully
> > understand and implement 
> >    it one has to refer to a NON IETF approved RFC, I 
> suggest it shall be
> > removed from the SUA draft.
> 
> Unlikely.
> 
> > 
> > 6. In section 4.4.1 Registration,
> > 
> > I suggest adding following paragraph:
> > If an SGP determines that a received Routing Key is already 
> registered by
> > the ASP, the SGP shall return already allocated RC for the 
> corresponding AS
> > to the ASP, and if AS is in ACTIVE state then SGP shall 
> mark its state to
> > INACTIVE.
> 
> This is unnecessary.  If the ASP loses its registration state 
> it should
> start again with ASPUP.
> 
> --brian
> 
> > 
> > 
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 

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