Re: (M2PA) M2PA Implementor's Guide Kickoff

Hi Lyndon,

Thanks for clarifying the path forward.

So far I've heard comments downplaying the need for an Implementor's 
Guide.  For what it's worth, I think an M2PA Implementor's Guide is a 
worthwhile effort.

I think the current RFC is good, but there are areas that are hard to 
understand.  This is especially true of the processor outage section.  I 
think some clarifications could make the protocol easier to implement, 
which should mean fewer incorrect implementations, which would help 
interoperability.   Additional examples or deployment considerations 
could also help.

It may also be appropriate to add requirements to M2PA implementations, 
I'm thinking in particular in explicitly specifying how long an 
implementation should wait for LS READY at the end of processor outage.  
It looks like this is already contained in Jeff's list, so I expect it 
will be discussed in due course and either accepted or not.

As a closing note, I know that internally our interpretation of the M2PA 
spec was not painless.  There were a number of cases where we spent 
hours looking through Q.703, through the RFC, and considering and 
generating test cases (we didn't find the latest draft of the test spec 
at the time).  In the end there were a number of decisions that we took 
that involved a reasonable amount of deduction.  Sometimes ambiguity is 
good, in that it doesn't constrain implementations, other times it just 
makes it hard to know if you're doing the right thing.  I think an I-G 
could help ease the pain of future generations of M2PA developers.

Regards,
Andrew

Ong, Lyndon wrote:

>Hi Folks,
>
>Let's cool things down, please!  Jeff's initial draft should in fact
>be draft-craig-sigtran-m2pa-ig since it will not yet have been agreed to
>be a WG draft.  Our intention should be to identify any areas of M2PA
>that may lead to problems with interoperable implementations, based
>on our experience.  This is different from saying the M2PA RFC is 
>"wrong" - Brian is perfectly correct that the RFC is the standing
>agreement.
>
>Cheers,
>
>Lyndon
>
>-----Original Message-----
>From: [email protected] [mailto:[email protected]] On
>Behalf Of Brian F. G. Bidulock
>Sent: Thursday, January 12, 2006 10:57 AM
>To: Craig, Jeffrey
>Cc: [email protected]
>Subject: Re: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff
>
>Craig,
>
>I hope your descriptions are less vague than they are in this note.  I
>look forward to commenting on your draft.  Perhaps you should call it
>draft-craig-m2pa-ig because it is already far from consensus.  The RFC
>_is_ the current consensus.
>
>--brian
>
>Craig, Jeffrey wrote:
>(Thu, 12 Jan 2006 12:41:49)
>  
>
>>Hello Brian,
>>
>>Both Figures 15 and 16 are defective in that they fail to accurately 
>>depict the L3L2 and L2L3 primitives that are essential to the 
>>procedures being described.
>>
>>The processor outage section is defective in that it fails to 
>>adequately address the aligned not ready state.
>>It also fails to adequately address the ambiguity in treatment of 
>>received LSR based upon stream.
>>
>>I am working on detailed problem descriptions and proposed new text 
>>and new figures that addresses my concerns. Stay tuned.
>>
>>As far as you not seeing any defects in the document, I am not 
>>surprised, since you were an author. I think the RFC can better serve 
>>its audience by being clear to everyone, not just the authors.
>>
>>Regards,
>>
>>Jeff
>>
>>    
>>
>
>  
>

-- 
Andrew Booth
Signaling Systems Group
Performance Technologies
www.pt.com
+1-613-237-4344
fax: +1-613-237-5277

Visit www.pt.com/mailing.html to subscribe to our Packets & Signals eLetter.