Subject: RE: [Sigtran] (M2PA) M2PA Implementor's Guide Kickoff

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 12 Jan 2006 18:30:36 -0500

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-masked] [mailto:[email-masked]] On
Behalf Of Brian F. G. Bidulock
Sent: Thursday, January 12, 2006 10:57 AM
To: Craig, Jeffrey
Cc: [email-masked]
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
> 

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

_______________________________________________
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: Andrew Booth <[email-masked]>
Date: Fri, 13 Jan 2006 13:18:17 -0500

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 13 Jan 2006 11:45:30 -0700

Andrew,

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

--brian

Andrew Booth wrote:                                                 (Fri, 13 Jan 2006 13:18:17)

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

---

From: Andrew Booth <[email-masked]>
Date: Fri, 13 Jan 2006 18:05:00 -0500

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 13 Jan 2006 16:33:23 -0700

Andrew,

Andrew Booth wrote:                       (Fri, 13 Jan 2006 18:05:00)
> cannot comment on whether I agree with the contents of that particular 

They messed up: (I think they only published the .pdf format)  You can
view all formats here:

  http://www.openss7.org/docs/draft-bidulock-sigtran-m2pa-test-06.txt
  http://www.openss7.org/docs/draft-bidulock-sigtran-m2pa-test-06.ps
  http://www.openss7.org/docs/draft-bidulock-sigtran-m2pa-test-06.pdf

> I'll admit to ignorance here on IETF policies at that level.

If it sits on the IETF servers for 6 months, and there are no violent
objections from the WG, I can request personally that it be published 
as an Information RFC and it likely would.  However, I wanted to vette
it by the WG and give an opportunity to have it formally revied reviewed
by the WG before publication.

> the I-G would certainly increase the work load involved in an I-G.

Its a possibility.  Typically we use IGs in this WG as a delta document
for a replacement RFC.  Would the material then go as a non-normative
appendix in a 'bis' RFC?  It would be a strange document in the end:
RFC 4165 is 53 pages and the test spec is 140 pages.  It just strikes me
that structurally it is probably better as a separate document.

Also, don't let the title "Implementer's Guide" fool you: it is really only
such in the ITU-T sense.  In the ITU-T sense, IG means "Specification_Errata
that_was_not_caught_before_the_document_was_formally_approved_and_that_we_are
now_just_pretending_is_a_different_interpretation."

> Does that answer your question?

Yes, thank you.

--brian

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