Re: (M2PA) Initial version of M2PA IG is Now Available

Hi Brian,

I appreciate that minimal corrections leave less room for errors, but I
think your recommendation on its own may be a bit too subtle.

What I do like about Jeff's description is that the issue under
discussion is very clearly laid out, that page of text is informative
only and hence has a minimal risk of introducing errors.
I don't see any errors introduced in Jeff's proposed text, but if
minimal changes are desirable perhaps the following (it may be possible
to shorten things up even more):

2.5.3.        Text Changes

   Original Text (4.1.3. Link Alignment)
   ---------------------------------------------------------------------
   The Link Status Ready message replaces the FISU of MTP2 that is sent
   at the end of the proving period.  The Link Status Ready message is
   used to verify that both ends have completed proving.  When M2PA
   starts timer T1, it SHALL send a Link Status Ready message to its
   peer in the case where MTP2 would send a FISU after proving is
   complete. If the Link Status Ready message is sent, then M2PA MAY
   send additional Link Status Ready messages while timer T1 is
   running. These Link Status Ready messages are sent on the Link
   Status stream.

   In the case that MTP2 sends an MSU or SIPO message at the end of
   proving, M2PA SHALL send (respectively) a User Data or Link Status
   Processor Outage message.

   New Text
   ---------------------------------------------------------------------

   (Paste in old text here).

   While timer T4 is running, M2PA SHOULD mark reception of either a
   Link Status Ready message or a Link Status Processor Outage message.
   Upon expiration of timer T4, M2PA SHOULD check whether a Link Status
   Ready message or a Link Status Processor Outage message was
   received, and if either message was received, M2PA SHOULD NOT start
   timer T1 and instead SHOULD operate as if the message had been
   received after timer T1 had been started. If neither message was
   received during proving, then M2PA SHOULD start timer T1 and proceed
   according to the applicable MTP2 standard.

Brian, Jeff, any thoughts on this?
Andrew

Brian F. G. Bidulock wrote:

>Andrew,
>
>Andrew Booth wrote:                          (Mon, 29 May 2006 16:03:59)
>  
>
>>I think the RFC does (implicitly) say to ignore LS Ready during proving.
>>If I recall correctly, MTP2 (q.703/T1.111.3) ignores FISU during
>>proving. Hence in the absence of specific text, M2PA should ignore LS
>>Ready during proving.
>>    
>>
>
>Well, no, but it explicitly says:
>
>   The Link Status Ready message replaces the FISU of MTP2 that is sent
>   at the end of the proving period.  The Link Status Ready message is
>   used to verify that both ends have completed proving.  When M2PA
>   starts timer T1, it SHALL send a Link Status Ready message to its
>   peer in the case where MTP2 would send a FISU after proving is
>   complete.  If the Link Status Ready message is sent, then M2PA MAY
>   send additional Link Status Ready messages while timer T1 is running.
>   These Link Status Ready messages are sent on the Link Status stream.
>
>   In the case that MTP2 sends an MSU or SIPO message at the end of
>   proving, M2PA SHALL send (respectively) a User Data or Link Status
>   Processor Outage message.
>
>How about changing the one line
>
>   peer in the case where MTP2 would send a FISU after proving is
>
>to
>
>   peer in the case where MTP2 would send FISU(s) after proving is
>
>Is that satisfactory?  I don't think that it merits changing a page
>of text, possibly breaking other things.  Particularly when a M2PA
>link that ignores LSR will not even align with itself.
>
>(I'll reply separately on the second part.)
>
>--brian
>
>  
>