Subject: Re: [Sigtran] M2PA draft comments and questions.

From: [email-masked]
Date: Tue, 11 Feb 2003 13:24:26 -0500

Hello John,

Since no one else is responding, I'll answer.

My responses are embedded below.

Regards,

Jeff

On 02/11/2003 10:09:47 AM sigtran-admin wrote:

>All,
>I sent the following comments and questions to the group a while ago, and
have
>not got responses yet. here goes again.
>thanks.
>John
>
>
>1.   In section 1.5: the following statement is somewhat confusing.
>"The SG is an IPSP equipped with both traditional SS7 and IP
>network connections. In effect, the Signaling Gateway acts as a
>Signal Transfer Point (STP)"
>
>Perhaps we can say "The SG interconnects SS7 and IP networks by
>converting signaling traffic" or just refer to the definition in
>section 1.2

I am not sure what defect this removes, and so I have no comment on this.

>
>
>2.   Section 2.1.5 Message length
>Should we specify the valid value range of the length?
>

No. Min/Max message length is dependent on message type,
and in the case of user data is governed by MTP3.

>3.   Section 2.3.1 User Data
>
>statement "M2PA does not add padding to the MTP3 message.".
>I think we should make it a requirement: "M2PA should not add padding
>to the MTP3 message."
>

Sounds good to me.

>
>4.   In section 4.1.3 Link alignment
>
>perhaps we can specify the recommended practice for choosing
>emergency proving vs. normal proving during alignment procedure.
>

This is governed by MTP3 procedures and is outside the scope
of the M2PA draft.

>
>5.   Section 4.1.8:
>"If a Link Status Alignment message with an unsupported
>received by the newer version, the receiving end's M2PA
>SHALL NOT complete the alignment procedure."
>
>can we clearly define the behavior of not completing the alignment
>procedure?

I believe that you are suggesting that the text be reworded to state
the following:

"If a Link Status Alignment message with an unsupported version
is received by the newer version, the receiving end's M2PA
SHOULD fail the link."

I think this was already understood, but the change improves clarity.

>
>6.   section 4.2.1 sending and receiving messages
>When M2PA receives a User Data message with Backward Sequence Number
>equal to 'n', it may remove all messages with Forward Sequence Number
><= n from its queue.
>
>This is incorrect. Consider at the time SN is cycled to 0 from 127
>(assume 128 buffers), there are 127, 126, etc are waiting for
>acknowledgement. We should replace it with "The message n and all
>outstanding (not yet acknowledged) messages sent before the message n
>may be removed from its queue.

I agree with the change.

>
>7.   section 4.2.1
>If M2PA receives an empty User Data message, it SHALL NOT send an
>acknowledgement of that message.
>
>What is empty User Data message? FISUs?
>

It is a M2PA user data message containing only the common header.
An 'empty'  User Data message is an M2PA receipt acknowledgement.
The statement in the draft is saying don't ACK an ACK.

>--
>__________________________________________________________
>Sign-up for your own FREE Personalized E-mail at Mail.com
>http://www.mail.com/?sr=signup
>
>_______________________________________________
>Sigtran mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/sigtran

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Feb 2003 19:25:09 -0700

jeffrey.craig,

[email-masked] wrote:                                             (Tue, 11 Feb 2003 13:24:26)
> and in the case of user data is governed by MTP3.

Agree.  No link restriction on message length.

> >I think we should make it a requirement: "M2PA should not add padding

M2PA MUST not add padding to the MTP3 message.  (The receiver cannot
detect it, so it needs to be a MUST).

> This is governed by MTP3 procedures and is outside the scope

Agree.  MTP3 decides this.

> I think this was already understood, but the change improves clarity.

The link has not align so it cannot be "failed."  I agree with the current
wording: "SHALL NOT complete the alignment procedure", because the link
is already in the OOS state.

> >may be removed from its queue.

I think it is understood that the <= is modulo arithmetic.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/