Re: [Sigtran] SCON in response to DAUD

["Brian F. G. Bidulock" <[e-mail]>]

Soni,

I requested at last call that this section be corrected and was told by
the Editor: "Alternative text based on consensus provided."

I pointed out that the "[a]lternate text is in error.  This has been
discussed and no objections remain to the proposed text.  Please apply."

But, it fell on deaf ears; even though all discussions have come back to
the text that you cite at the bottom of your note.

Perhaps the Editor can point to the discussion that shows the consensus
upon which he based his deviation from that text.  (Although I doubt it
because it was consensus, after much discussion, that agreed on the
change in the first place.)

Unfortunately, it is not the only such occurrence in the draft.

What is clear of the matter is that the SCON MUST be sent before a DAVA
or a DRST (but rfc3332bis-04 does not require this) otherwise during
restart M3UA at the ASP cannot possibly know how long to wait for a
possibly trailing SCON before starting traffic.

Also, it is clear that unless the SGP maintains congestion state (in
accordance with whatever prevailing SS7 standards are applicable) it is
incapable of sending SCON, and can only therefore be required to send it
when it maintains it (but rfc3332bis-04 merely make a vague reference to
some sort of national network).

So, I would say it is a clear error in rfc3332bis-04, but, then, I
already said that at Last Call and was overruled by the Editor, and so
the document stands in error.

I would suggest following the text the you cite from IG-07 instead, for
the sake of interoperability and a functioning protocol.

See topic "M3UAbis - consensus on comment resolution" on the mail
archive for a longer list of problems with rfc3332bis-04.

--brian


Soni Goel wrote:                                                                       (Tue, 06 Sep 2005 00:11:03)
> Hi,
> 
> This is regarding Section 4.5.3 ASP Auditing in draft RFC3332bis. As I
> understand, this draft replaces the Implementor's Guide, Version 7.
> 
> The Implmentor's Guide, Version 7 proposed following change in the above
> Section specifying that in response to DAUD message where the SGP
> maintains the congestion status of the SS7 destination, the SGP MUST
> additionally respond with an SCON message before the DAVA or DRST
> message . 
> 
> This change is not present in the latest draft RFC3332bis. Can somebody
> let me know if there is a specific reason for this? 
> 
> As per draft-ietf-sigtran-m3ua-implementors-guide-07.txt -
> --------------------------------------------------------
> 
> 3.8 Auditing procedure and congestion state
> 3.8.1 Description of the problem
> 
>    The current description of the AUDIT procedure in regards to
>    congestion state is not clear enough. When to send SCON is not
>    completely specified.
> 
> 3.8.2 Text changes to the document
> ....
> New text: (Section 3.3.1)
> ---------
>  
>    [...]. Where the SGP maintains the congestion status of the SS7
>    destination, the SGP MUST additionally respond with an SCON message
>    before the DAVA or DRST message.  If the SS7 destination is
>    available, the SGP MUST respond with an SCON message (indicating the
>    appropriate congestion level) and then a DAVA message.  If the SS7
>    destination is restricted, the SGP MUST respond with an SCON message
>    (with the appropriate congestion level) immediately followed by a
>    DRST message.  If the SGP has no information on the availability
>    status of the SS7 destination, the SGP responds with a DUNA message,
>    as it has no routing information to allow it to route traffic to this
>    destination.
>  
>    Where the SGP does not maintain the congestion status of the SS7
>    destination, the response to a DAUD message should always be only a
>    DAVA, DRST or DUNA message as appropriate.
> --------------------------
> 
> Thanks,
> Soni
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005
>  
> 
> 
> _______________________________________________
> 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