Re: (M2PA) M2PA Implementor's Guide Kickoff

Andrew,

Would you like to see the test spec become and informational RFC?

--brian

Andrew Booth wrote:                                                 (Fri, 13 Jan 2006 13:18:17)
> 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. 

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