Subject: Re: [Sigtran] I-D ACTION:draft-ietf-sigtran-m3ua-implementors-guide-02.txt

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 18 Dec 2002 03:43:23 -0700

Some comments on this version of the IG:

Section 3.2

  This section is unnecessary.  It was always intended that the M3UA entity
  sending the ERR message include the offending message in the Diagnostic.
  This appears in RFC 3332 section 3.8.1:

   Diagnostic Information: variable length

      When included, the optional Diagnostic information can be any
      information germane to the error condition, to assist in
      identification of the error condition. The Diagnostic information
      SHOULD contain the offending message.

  I don't see any reason to say MUST for REG REQ.  The SHOULD is sufficient
  to cover all cases.  It was clear from discussions that if the Diagnostic
  information does not contain the offending message, that correlation of
  Error messages with the messages that cause them will be impossible in
  many circumstances.

Section 3.3

  There is no need to include Q.700 in the reference.  The Routing Label
  coding is described in Q.704.  Also, this reference does not include
  other routing label variants (e.g. ANSI, TTC, etc.).  So, it should
  actually refer to [7][8][29] instead of just [7].

Section 3.4

  This section is against the concensus in the RFC.  The concensus was
  that if an SGP suffers a partial failure, it should send ASP Inactive
  Ack for the affected AS, and that if it should suffer a complete
  failure, it should send ASP Down Ack.

  DUNA(*) is completely incorrect, particularly because the ASP is
  permitted to interpret DUNA(*) from one SGP to mean DUNA(*) from
  all SGPs in an SG.  SNMM are not per-SGP messages and were kept
  as indicating routing at SG scope.  Section 3.4 is in conflict with
  this.

  Pertinent passages in 4.3.4.2 permitting the unsolicited ASP Down
  Ack procedure are:

    "If the ASP receives an ASP Down Ack without having sent an ASP Down
     message, the ASP should now consider itself as in the ASP-DOWN state.
     If the ASP was previously in the ASP-ACTIVE or ASP-INACTIVE state,
     the ASP should then initiate procedures to return itself to its
     previous state."

  Pertinent passages in 4.3.4.4 permitting the unsolicited ASP Inactive
  Ack procedure are:

    "...                If the ASP receives an ASP Inactive Ack without
     having sent an ASP Inactive message, the ASP should now consider
     itself as in the ASP-INACTIVE state.  If the ASP was previously in
     the ASP-ACTIVE state, the ASP should then initiate procedures to
     return itself to its previous state."

  Sending DUNA(*) for a partial failure at one SGP will result in
  MTP-PAUSE being issued to all MTP Users per section 4.5.2.1:

    "At an ASP, upon receiving an SS7 Signalling Network Management (SSNM)
     message from the remote M3UA Peer, the M3UA layer invokes the
     appropriate primitive indications to the resident M3UA-Users.  Local
     management is informed."

  making the IG Section 3.4. sending of DUNA(*) in an incorrect action.
  Partial failure of one SGP will wipe out traffic to all SGPs.

  Sending DUNA(*) is also in conflict with section 4.5.2.1 which says:

    "In the case where a local event has caused the unavailability or
     congestion status of SS7 destinations, the M3UA layer at the ASP
     SHOULD pass up appropriate indications in the primitives to the M3UA
     User, as though equivalent SSNM messages were received.  For example,
     the loss of an SCTP association to an SGP may cause the
     unavailability of a set of SS7 destinations.  MTP-PAUSE indication
     primitives to the M3UA User are appropriate."

  Reword to use ASP Down Ack and ASP Inactive Ack for full or partial
  failures of an SGP, as this was always the intended use of unsolicited
  ASP Down Ack and ASP Inactive Ack.  Remove the MUST from both DUNA(*)
  and DUNA so as to not conflict with the unsolicited procedures and the
  requirements of Sections 4.5.2.

Section 3.6

  "Conditional" would be more descriptive than "Semi-Optional" (and more
  in fitting with standards parlance)

Section 3.7

  This section should be changed to permit updating a Routing Key as
  adopted by SUA and missed by M3UA in editing.  See discussion on
  sigtran list.

Section 3.8

  It makes no sense to change the "Origination Point Code List" to
  "Destination Point Code List" without also changing the "Destination Point
  Code" in the Routing Key to "Origination Point Code".  Change "Destination"
  back to "Origination", because the REG REQ is formatted from the perspective
  of the AS (the entity generating it) and not the SG.

Section 3.9

  SCON(0) was always intended to be optional.  Strike the requirement
  to send SCON(0) (i.e. strike Section 3.9).  Again this was discussed
  at length on the list we arrived again at SCON(0) being optional.
  Strike section 3.9.

Section 3.10

  This section is unnecesary.  The RFC clearly states in Section 4.3.4.4:

    "The SGP MUST send an ASP Inactive Ack message in response to a
     received ASP Inactive message from the ASP and the ASP is already
     marked as ASP-INACTIVE at the SGP."

  Deregistration does not change the state of the ASP in the AS.  In
  particular it does not move it to the ASP-DOWN state.  The only actions
  moving an ASP to the ASP-DOWN state are the successfuly completion of
  the ASP Down Procedure or the loss of the SCTP association.  Therefore,
  in the example, according to section 4.3.4.4 the SGP MUST send ASPIA Ack
  regardless of the fact that the ASP has deregistered for the routing key.

  Then new text for Section 4.5.3 is in conflict with the MUST in
  section 4.3.4.4, becuase it requires an Error instead of an ASP Inactive
  Ack in the same situation (ASP in the ASP-INACTIVE state).

  Strike section 3.10.

Section 3.12

  Strike this section.  It precludes DE which is allowed as an alternative
  in the the RFC.  SE and DE were never intended to interoperate with each
  other.  IPSPs that communicate with each other must operate in either SE
  mode or DE mode, but not a mixture.  As there is no interoperability
  concern, there is no reason to preclude DE.

Section 3.13

  There are situations in which a MGMT message (Notify) must be sent
  on a stream other than "0".  This is where a Notify is required to
  be synchronized with ASPTM and DATA messages.  For example, when an
  SG sends Notify("Alternate ASP Active") it serves to move the active
  ASP to the ASP-INACTIVE state (just as an ASP Inactive Ack would do)
  and the ASP should not process DATA received after the Notify.  To
  avoid the race condition between a Notify("Alternate ASP Active")
  on stream "0" with data not on stream "0" would require sending the
  Notify on the same stream as the data.

  There are other situations when an ASPTM and Notify message must be
  ordered with respect to each other.

  Therefore, Section 3.13 should say:

  2. ASPSM, MGMT, RKM should be sent on stream 0 (Other than BEAT and
     BEAT ACK and Notify).
              ^^^^^^^^^^

Section 3.14

  Remove "For AS-SG communication this parameter MUST NOT be used."

  ASP Id in the ASP Up Ack would serve to identify the SGP in cases
  where Middle boxes and NAT make it impossible for the ASP to determine
  to which of several SGP it has connected.

Section 3.15

  The change from MAY to SHOULD NOT is against consensus on the n+k
  model as described in the RFC.  Unless the "n" value is required to
  be provisioned by the SG and somehow coordinated between ASP and SG
  the SG cannot know when to do this an SHOULD NOT is not appropriate.
  "MAY chose not" was deemed appropriate in the last long discussion
  on this topic.

  Please review post-LC threads on n+k and change SHOULD NOT back to
  "MAY chose not".

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Ken Morneault <[email-masked]>
Date: Thu, 19 Dec 2002 15:14:57 -0500

Brian,

Pls see comments below.

Ken / Javier

>  Error messages with the messages that cause them will be impossible in

This ambiguity is exactly what folks wanted to avoid in the case of REG REQ.  Having
"MUST instead of "SHOULD" does provide a benefit in this case.

>  actually refer to [7][8][29] instead of just [7].

This section was added due to thread about the Routing Label.  It seems useful
to refer to [7][8][29] so I will make the change.

>  failure, it should send ASP Down Ack.

Most of this text came from some of your proposed text in a long thread 
(titled "NIF not available") after the M3UA draft was frozen.  I think the only 
conflict with your proposal is sending DUNA(s) in the case of the partial
failure case.  

>  as indicating routing at SG scope.  Section 3.4 is in conflict with

DUNA(*) is only proposed in the case in which the SG (all SGPs) have
lost contact with the NIF (or SS7 network).

>  in fitting with standards parlance)

Ok

>  adopted by SUA and missed by M3UA in editing.  See discussion on

Ok

>  of the AS (the entity generating it) and not the SG.

Ok

>  at length on the list we arrived again at SCON(0) being optional.

I think you are referring to the thread "Another Congestion/SCON Question".
This outcome of this thread has not been worked into the IG yet.

>  Ack in the same situation (ASP in the ASP-INACTIVE state).

I don't see how it conflicts with Section 4.3.4.4.  In the case of a static
Routing Key, a SG would not return ASP Inactive Ack if the Routing
Context was invalid.  Instead, it would return an error.  The new text
clarifies the same for the dynamically configured Routing Key.

>  concern, there is no reason to preclude DE.

We should make one option mandatory as it is right now (SE, as it is simpler) and have the DE as optional, since there are implementations that use it. The best way forward to ensure a minimum interoperability... 

>  Notify on the same stream as the data.

Are you recommending that Notify be sent on all non-zero streams 
in this case?  Otherwise, how do you select which stream to use?

>  2. ASPSM, MGMT, RKM should be sent on stream 0 (Other than BEAT and

Not necessarily against the idea of allowing Notify on stream other than zero,
but unsure of the benefits.

>  to which of several SGP it has connected.

Can you explain how the ASP would determine which SGP is had connected
to based on ASP ID in the case of a NAT.  

>  Please review post-LC threads on n+k and change SHOULD NOT back to

Wasn't there a discussion (thread "m3ua: IG : n+k redundancy - AS state machine") in 
which it was concluded that n is *required*. The SHOULD NOT is in line with that 
discussion. If "n" is required, it means that SG will have to know that value. It is a clear 
consequence.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 19 Dec 2002 14:51:09 -0700

Ken,

Please see additional comments below...

Ken Morneault wrote:                              (Thu, 19 Dec 2002 15:14:57)
> "MUST instead of "SHOULD" does provide a benefit in this case.

And what is that benefit?  A requirement to support a Error procedure at
the SG for an optional feature of the protocol?  I don't see a
interoperability need for an SG to support this procedure if the SG knows
that it will never connect to an ASP which dynamic registers.  Dynamic
registration is, after all, OPTIONAL.

Change "MUST" to "SHOULD".

> conflict with your proposal is sending DUNA(s) in the case of the partial

It was discussed long before that.  That is why there is the wording
in the RFC concerning the response to ASP Down Ack and ASP Inactive Ack
in the case that no ASP Down or ASP Inactive has been sent: it is because
we discussed partial and complete failure in the WG perviously (at the
same time as we changed SNMM back from being per-SGP to being per-SG,
shortly after the s/SG/SGP/g fiassco) which was back at about Draft7 or 8.

At that time we agreed that SSNM was per-SG (e.g. DRST cannot be used to
redirect traffic between SGP in the same SG) and that ASPSM/ASPTM was
per-SGP.  We also agreed at that time that DUNA was inappropriate in
response to SGP failures (because they are per-SG, and intended to
reflect SS7 network management and not ASP management) and the ASP
Inactive Ack and ASP Down Ack were the appropriate response to partial
and complete failures of the SGP (because they are per-SGP and intended
to reflect ASP management, not SS7 network management).

I can dig up the threads if you'd like, but the matter was settled
a long time ago.  It just resurfaced after the draft was frozen.

Now, the IG attempts to again use SSNM where ASPSM/ASPTM is proscribed.

> >  as indicating routing at SG scope.  Section 3.4 is in conflict with

I should have said DUNA not DUNA(*) above, but,

> lost contact with the NIF (or SS7 network).

DUNA(*) is inappropriate because the SG has not lost accessibility to these
destinations.  When the NIF recovers. there is no procedure to inform
the AS that these destinations are indeed available.  ASP Down Ack is
appropriate because it informs all AS at all ASPs that they have lost
connectivity to the NIF from a given SGP.  When the NIF recovers and
the ASP performs its normal startup DAUD procedure (if required).
With DUNA(*) the ASP is given no indication when the NIF recovers and
does not know to perform DAUD.

MTP/MTP-User interfaces use means other than MTP-PAUSE to indicate
whether the MTP-User is "connected" to MTP or not (bind, attach),
and when that connection fails (error return, exception).  MTP-PAUSE is
reserved for MTP to inform its user that a remote destination is
inaccessible to MTP, not when the local MTP is inaccessible to the
MTP-User.

DUNA (without the *) is inappropriate for the reasons cited.  It falsely
indicates to the AS that the destination is inaccessible to the SG rather
than the fact that a single SGP is suffering a partial failure.  In the
world of MTP/MTP-User interfaces there is no "partial failure", it is
an all or nothing deal: either the MTP can provide service or it cannot.
When an SGP suffers a partial failure, it should send ASP Inactive Ack
so that the ASP knows to route traffic to alternate SGPs.

So, again, please change DUNA(*) to ASP Down Ack and DUNA to ASP Inactive
Ack in this passage.  There should be no mention of SSNM being sent in
regard to SGP failures.

> This outcome of this thread has not been worked into the IG yet.

You can work it into the IG by striking section 3.9.

> clarifies the same for the dynamically configured Routing Key.

The Routing Context is valid in the example case that the solution
is claiming to address.

Also, just because the RK is not registered does not mean that the
Routing Context is invalid.  The Routing Context being an index
into the routing table, means that it can be valid as long as there
is a Routing Key in the table.  It is at the SG's discretion upon the
last ASP deregistering for a key whether to leave it in the routing
table or to strike it.  Therefore, where the IG says:

       -  If the RK is not registered, or the RC information is not valid,
          the peer must respond with an ERROR message with Error Code =
          "Invalid Routing Context".

is incorect, because the RK being not registered does not necessarily
mean that the Routing Context is invalid.  See RFC section 4.4.2 which
states:

     The deregistration procedure does not necessarily imply the deletion
     of Routing Key and Application Server configuration data at the SG.
     Other ASPs may continue to be associated with the Application Server,
     in which case the Routing Key data SHOULD NOT be deleted.  If a
     Deregistration results in no more ASPs in an Application Server, an
     SG MAY delete the Routing Key data.

The remainder of the IG section is either wrong, already stated in
the RFC or contradictatory:

For annother example of wrong:

  the IG says

    ---------
    New text: (Section 4.5.3)
    ---------

  The section is 4.3.4.4.

For example of contradictory:

  the IG says:

       - If the corresponding RK is registered (statically or
         dynamically), the peer should respond with an ASP Inactive Ack
         message.

  the RFC (later in section 4.3.4.4) says:

     The SGP MUST send an ASP Inactive Ack message in response to a
     received ASP Inactive message from the ASP and the ASP is already
     marked as ASP-INACTIVE at the SGP.

For an example of duplication:

  the IG says:

       -  If the RK is not registered, or the RC information is not valid,
          the peer must respond with an ERROR message with Error Code =
          "Invalid Routing Context".

  the RFC (later in section 4.3.4.4) says:

                    ... The SGP or IPSP sends an Error message ("Invalid
     Routing Context") message for each invalid or unconfigured Routing
     Context value in a received ASP Inactive message.

And that covers all the proposed changes for the section, so please
strike the section.

> We should make one option mandatory as it is right now (SE, as it is
> simpler) and have the DE as optional, since there are implementations that
> use it. The best way forward to ensure a minimum interoperability... 

I disagree.  The best way forward is to write a proper extension draft
for peer-to-peer operation as was agreed when we let the RFC pass WG LC.
SE does not required any special IPSP description in the draft (because
it is exactly the way that an ASP talks to an SGP), and is already
supported by any node that supports ASP or SG operation.  IPSP is optional.
The only special treatment required for IPSP operation is DE, therefore
I take it that DE is clearly optional.

So there is really no need to go to all that extent, all you are saying
is that SE is already there and DE is optional which is what was agreed
at WG LC and already reflected in the RFC.  I can give you pointers to
message threads if you would like to look back.

Please strike the section.

> in this case?  Otherwise, how do you select which stream to use?

See draft-bidulock-sigtran-corid-00.txt for synchronization of data
flows across multiple streams.  Without those procedures, sending
DATA for one AS on multiple streams will result in a high probability
of mis-sequencing under failover conditions which an MTP-User is not
prepared to accept.

If you use CORID, the Notify would only have to be sent on one of the
synchronized streams.

If you don't, you will get mis-sequencing of DATA if you send on
multiple streams regardless of which stream you choose for Notify.

The RFC/IG should not tell the SG which stream it must send Notify on
otherwise, it will preclude the SG from synchronizing Notify with DATA.

> but unsure of the benefits.

Benefits are allowing an SG implementor to synchronize notification of
events concerning traffic to ASP in sychronization with the traffic to
which it pertains.  In the case of Notify("Alternate ASP Active") the
SG can ensure that the last DATA message sent is received by the retiring
ASP before it receives the Notify and starts discarding all subsequent
DATA.  This reduces message loss: which is a significant benefit.

> to based on ASP ID in the case of a NAT.  

The ASP would determine which SGP it had connected to by examining the
ASP Id (really the SGP Id) returned in the ASP Up Ack.  This Id would
uniquely identify the SGP to the ASP.

> Wasn't there a discussion (thread "m3ua: IG : n+k redundancy - AS state
> machine") in which it was concluded that n is *required*. The SHOULD NOT is
> in line with that discussion. If "n" is required, it means that SG will have
> to know that value. It is a clear consequence.

No, it was determined that "n" would be required to perform these
procedures.  Rather than require "n" (because many implementations
have no use for it), we made the procedure OPTIONAL with the MAY
that you just removed!  Please put it back the way it was before.

--brian

---

From: Ken Morneault <[email-masked]>
Date: Fri, 20 Dec 2002 13:22:50 -0500

Brian,

Pls see my feedback below.   I removed the items that already
had consensus or were minor edits.  For the rest, we need more
feedback on the list before progressing.

Regards,

Ken

>Change "MUST" to "SHOULD".

Although the feature is optional, the SG must return an error.  The
change to the text just makes it mandatory for the ASP and SG
to always include the Diagnostic information for Msg Class/Type
errors so that the other side can correlate.  

>a long time ago.  It just resurfaced after the draft was frozen.

I know it was discussed before that.  However, that thread was the final
discussion and the one from which the test changes were pulled.  

>Ack in this passage.  There should be no mention of SSNM being sent in

While I'm not necessarily opposed to making some mods to this text, I
still think we need more feedback before we start making changes.

>You can work it into the IG by striking section 3.9.

I believe there is value in Section 3.9 as there had been comments about what
the SG should send when audited.  Section 3.9 provides a clear description
which was lacking in the RFC.

>mean that the Routing Context is invalid.  

While I agree that RK may exist in the database, the ASP has deregistered.
Therefore, the RK would no longer be associated with that ASP (of course,
it may be associated with other ASPs).

>See RFC section 4.4.2 which
>states:
>

Right, but it is no longer registered so this statement doesn't apply.

>     marked as ASP-INACTIVE at the SGP.

Granted, but the SGP would first validate the ASP Inactive message before
replying.  If it found the RC in the message did not match any RKs the
ASP was registered to, it would return an Error.

>And that covers all the proposed changes for the section, so please

One could argue that this text in the RFC is sufficient, but there was
enough confusion for people to request some clarifying text.

>Please strike the section.

Hopefully, there will be more comments on IPSP.  In regards to the SG-SG I-D,
Tolga recently pitched that it move forward as a WG doc and I certainly support
that.

>If you use CORID, the Notify would only have to be sent on one of the

CORID no longer exists and cannot be considered normative.

>otherwise, it will preclude the SG from synchronizing Notify with DATA.

I don't have a major problem with removing this restriction... again, hopefully
we'll get more feedback.

>uniquely identify the SGP to the ASP.

Since the ASP is acting as the client, it will have to have an external address/port
configured for the SGP in order to establish the association.  As SGP acts as
a server behind the NAT, this external address/port would be statically provisioned
to an internal address/port.  Allowing the SGP to return a SGP ID does not seem
to provide much.

>that you just removed!  Please put it back the way it was before.

I'll review the thread.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 20 Dec 2002 12:35:10 -0700

Ken,

Ken Morneault wrote:                                                                   (Fri, 20 Dec 2002 13:22:50)
> errors so that the other side can correlate.  

So why should correlation be mandatory for this case and not all others?
There are many other cases where correlation causes problems.  I think it
is time to revisit the SHOULD or the MUST.  As I recall you were the one
advocating SHOULD in the first place for offending messages in Diagnostic
and those that reported correlation problems were asking for MUST.  Can
you continue to defend SHOULD for other cases?  If you are making a unilateral
decision to say MUST for the one error, also remove "germane" and change
"SHOULD" to "MUST" under "Diagnostic Information" above.

> discussion and the one from which the test changes were pulled.  

Sending DUNA for partial failure does not appear in that discussion:
what that your own invention?  Strike it.  It was never discussed.

On the other hand, ASP Down Ack was discussed in that thread.

Also, DUNA(*) was mentioned as appropriate, but so was ASP Inactive Ack
and ASP Down Ack.  I don't know how you could possible state DUNA(*)
as a MUST when there are other options for the SG designer to respond
to what is clearly an event which is outside the scope of the document:
an event of the "implementation-depdendent NIF."

Strike the "MUSTs" and put "MAY," or "MAY, for example," because it is an
implemetation issue and not a protocol issue.  The results from sending
any of these messages is clearly stated in the protocol.  When to send
them is an implementation matter.

> still think we need more feedback before we start making changes.

Here's feedback: its broken; fix it.

> which was lacking in the RFC.

The description is not clear, because as it stands it is incorrect.

> it may be associated with other ASPs).

Are you saying that the ASP is moved to the ASP-DOWN state?  This is
incorrect (and the RFC does not agree with you).  ASP Down is required to move
the ASP to the ASP-DOWN state.  Therefore, the ASP is in the ASP-INACTIVE
state for the AS and the text is clear in the RFC that the SGP "MUST" send
ASP Inactive Ack.

If you don't want that to be the case, you need to change the state diagrams,
and the registration procedures, and a lot of things in a lot of places.
Where do you get the mandate to make all these changes to the registration
procedure?

You should get more feedback before placing such things in the IG.

Strike section 3.10.

> Right, but it is no longer registered so this statement doesn't apply.
             ^^

"It," being the RK in the statement above, can continue to be registered.

> ASP was registered to, it would return an Error.

Nowhere does it say in the RFC that the SGP screens messages for RC values
that are only registered to ASPs.

There is also nothing in the RFC requiring that the SGP "forget" its static
configuration information just because an ASP deregisters.  Otherwise, the
static and dynamic approaches could not co-exist.  You must leave room for
the case where an SGP supports both static and dynamic configuration to ASPs
because it is permitted.  So the SGP in fact is permitted not to remove
Routing Keys and is also permitted to treat and ASP as though it is statically
registered after it deregisters.  This is why the section is contradictory,
it presupposes to tell the SG how to treat the ASP when the option is no
longer in effect.

> enough confusion for people to request some clarifying text.

Repeating the same statements with errors, contradictions, and repetitions
in the same section does not qualify as "clarifying text".

Strike the section.   Or, rewrite it to remove the errors, contradictions
and repetitions.

> Tolga recently pitched that it move forward as a WG doc and I certainly support

Then let's strike this section and move these issues to the extension draft
as was agreed at LC.

If the WG, and particularly the WG chair and editors of these documents
don't start honoring some of the "promises" that were made at LC that
persuaded us into letting the drafts pass WG LC with outstanding issues,
I for one will certainly never let another RFC pass WG LC again with
outstanding issues.  That includes the IG.

This document (the IG) appears filled with implementation concerns rather
than interoperabiltiy issues.  That would be fine if the implementations
concerns were not being permitted to make "MUST" and "SHOULD" requirements.

If any implementor cannot see how to implement DE, the recomendation to
them is to not implement it.  The last thing that should be done is to
say that DE is "forbidden" because some implementors are short-signted.
Yet, this seems to be the case.

Strike the section.  Some implementors wish to implement the DE OPTION
as described in the RFC.  It is not the IGs place to remove this option
at this point.  Strike the section.

> CORID no longer exists and cannot be considered normative.

You asked

>> how do you select which stream to use?

I was answering your question, not making a normative reference.

Besides, what has "normative" got to do with the discussion?--The IG
is in draft and cannot be considered normative.

> I don't have a major problem with removing this restriction... again, hopefully

Anybody disagree?  No?  Good.  Please remove the restriction.

This is a draft for heaven's sake, not a final draft of an RFC hanging on
being advanced.  Make the edits.  If someone disagrees they can bring it
up now, on the next version of the draft, or at LC, or not at all.

> Since the ASP is acting as the client
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Incorrect assumption.  The ASP is not required to act as a client from the
SCTP perspective.  The SG may also connect to the ASP.  In which case, it is
still the responsibiliy of the ASP to send ASP Up, but it does not necessarily
know which SGP has connected to it if dynamic port assignment and address
translation is being performed on the SGP side.

> >that you just removed!  Please put it back the way it was before.

Thank you for considering my lowly comments as worthy, master, for you
to perform a review, and for possibly considering making a change to
what must be an almost perfect document: because at revision number 1
it must have already been so thoroughly reviewed as to represent world
concensus. ;)

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 21 Dec 2002 15:44:00 -0800 (PST)

Brian, Ken,
> as a MUST when there are other options for the SG
[TOLGA] On that thread, also my intial opinion was
that ASPIA-ACK is the most appropriate action from
SGP, when NIF is not available. But after some time I
noticed the scenario, where SGP routes between two
ASPs and also to/from TDM domain SS7 nodes. In such a
case, one could argue that unavailability of NIF might
not hinder any message transfer activity on SGP
between two ASPs. So, I thought, DUNA for the relevant
destinations (destinations in TDM domain) might be a
better alternative, so that SGP can continue to route
between ASPs. But now, what I think is, all of this is
too implementation dependent (what would one expect,
if NIF is involved?). Depending on implementation, one
could have NIF involved also for message routing
between ASPs, or not. So, after all of this, I again
return to my very initial proposal : There is no need
to say anything about unavailability of NIF. There are
too many implementation dependednt things (whether it
migth be unavailable from a single SGP but available
from the others or is on/off for the whole SG, whether
it playa a role in routing between ASPs etc...) And if
the consensus is that there is a need to describe the
behaviour in such a case, then I would think, it is
not a very good idea to use "MUST" for any described
activity. Depending on implementation/configuration
both DUNA and ASPIA-ACK might be fine and even I
wouldn't choose it I still think even dropping
association won't be wrong.

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Tolga Asveren <[email-masked]>
Date: Sat, 21 Dec 2002 16:19:55 -0800 (PST)

>otherwise, it will preclude the SG from synchronizing
Notify with 
DATA.

I don't have a major problem with removing this
restriction... again, 
hopefully
we'll get more feedback.
[TOLGA] Although such a procedure is not mandated in
RFC/IG, I believe it is usefull to prevent
missequencing (in fact there might be other ways of
doing this, for example aqfter stopping DATA, sending
HBEAT on each stream and waiting for HBEAT-ACK for all
of them (this method is also desribed in corid draft I
as far as I remember) before sending NTFY) sending
NTFY on each stream seems more elegant. Personally I
also don't think, there will be a problem by removing
the restriction for sending NTFY on stream 0, and it
might serve some usefull purposes sending it on any
stream (like for Brian's example)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 21 Dec 2002 18:38:02 -0700

Tolga,

Tolga Asveren wrote:                 (Sat, 21 Dec 2002 15:44:00)
> association won't be wrong.

I agree, how a SGP chooses to report this situation is
implementation depedent.  The SG implementation has all
three procedures at its disposal, the results of which
are well defined.  It is up to the SG designer to choose
the approach most appropriate for her implementation.

I would have no problem if the section discussed the
implications of each procedure, without recommending
(or requiring) one or the other.

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Sun, 22 Dec 2002 07:35:11 -0800 (PST)

Brian, Ken,
> 
> >> 
> >> 
> >> >Section 3.15
> >> >
> >> >  The change from MAY to SHOULD NOT is against
consensus on the 
n+k
> >> >  model as described in the RFC.  Unless the "n"
value is 
required to
> >> >  be provisioned by the SG and somehow
coordinated between ASP 
and SG
> >> >  the SG cannot know when to do this an SHOULD
NOT is not 
appropriate.
> >> >  "MAY chose not" was deemed appropriate in the
last long 
discussion
> >> >  on this topic.
> >> >
> >> >  Please review post-LC threads on n+k and
change SHOULD NOT back 
to
> >> >  "MAY chose not".
> >> 
> >> Wasn't there a discussion (thread "m3ua: IG : n+k
redundancy - AS 
state
> >> machine") in which it was concluded that n is
*required*. The 
SHOULD NOT is
> >> in line with that discussion. If "n" is required,
it means that SG 
will have
> >that you just removed!  Please put it back the way
it was before.
[TOLGA] In fact there are two different situations,
where n is required and where it is preferred. To
bring a clarification to that was the main reason for
the n+k redundancy thread.
When it is required, it must be coordinated between
ASP and SGP. Currently, configuration is the only way
for this, a new optional parameter migth be added to
ASPAC though. Required corresponds to the case, where
there is a strict need to have n ASPs active, for
example is one does not want to start traffic before 2
ASPs are active (for redundancy purposes), one can use
n=2. For the required case, if number of active ASPs
is below n, this triggers an AS state change and so I
would think SHOUL NOT is appropriate.
IMO, preferred is the case, where most probably
because of changing traffic volume SGP decides to have
more active ASPs. There is no AS state change. In such
a scenario MAY seems as a beter alternative. Also one
question, how does ASP know in such a scenario, when
SGP decides to stop traffic? I still believe this
migth cause some problems (SGP stops traffic and ASP
continues to send messages)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 31 Dec 2002 18:21:43 -0700

Ken,

Section 3.2.

What does it matter if the SGP sends "Unsupported Message Type" or
"Unsupported Message Class"?  Acutally, if we ever add a message to the class,
"Unsupport Message Class" might no longer be correct, whereas "Unsupported
Message Type" survives the addition of new message types to the class.

Also, as the only necessary piece of information given in the Error message
is the Message Class and Type, why force an implementation to include the
first 40 bytes of the message?  That's ridiculous.  All that needs to be
included a couple bytes of the message header.

Also, there is no more need to correlate this error than others.  The
ASP is obviously misconfigured (it figures it can register with an SGP
that does not even supoprt registration), so it really doesn't matter
what happens to it: there are many ways to misconfigure an ASP so that
it will not be caught by the protocol.

Please strike section 3.2.

Also note that M2UA and SUA also use the same text.  It makes no sense to
have M3UA act differently in this regard than M2UA and SUA.

--brian