Re: (M2PA) M2PA Implementor's Guide Kickoff

Hi Brian,

In summary, I think having reference test cases recorded somewhere as an 
informational resource would be appreciated by many.  I don't know what 
the best format is.  The test spec does seem to overlap somewhat with 
additional examples in the I-G.  I do still think the I-G is a 
worthwhile exercise.  The rest of this email contains further details.

BTW, The IETF web site references draft-bidulock-sigtran-m2pa-test-06, 
but it does not seem to provide the document when requested.  Hence I 
cannot comment on whether I agree with the contents of that particular 
draft.

In the past however I have found the draft M2PA test specifications to 
be useful both for constructing test cases and as a source of 
(non-authoritative) examples.  A number of people here have used the 
M2PA test documents as references when constructing conformance test 
suites and have found them quite useful and clear.

So, I think there is a lot of value in having the work you've done in 
some IETF document.  An informational RFC is one choice, though I've 
heard objections on the list that conformance tests are out of scope.  
I'll admit to ignorance here on IETF policies at that level.

As an idea, what do you and Jeff think of moving the "test spec" to an 
appendix of an I-G?  Some advantages

- As an appendix the information could still be informational rather 
than normative

- the "test cases" could serve as examples that could help clarify 
existing text and procedures.

- with only one M2PA document to worry about, the working group focus 
will probably be better.
  It will certainly be easier to keep examples and changes (if any) in 
synch if it's one document.

- examples formulated as tests makes it easy for implementors to pull 
out test cases.

- it may be more palatable to IETF procedures to consider an appendix 
full of examples
  rather that an informational test spec.

- it may help eliminate a lot of duplication between a "test spec" 
document and extra exampes in an I-G

This is just an idea, hopefully no one will shoot me over it.  In 
particular, the test document is reasonably long as I recall and I'm not 
sure if Jeff would be  interested in taking on that much extra text, 
especially so early on in the I-G process.  Including the test spec in 
the I-G would certainly increase the work load involved in an I-G.

Does that answer your question?

Andrew

Brian F. G. Bidulock wrote:

>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. 
>>    
>>
>
>  
>

-- 
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.