Subject: [midcom] Status update

From: Melinda Shore <[email-masked]>
Date: Tue, 10 Jul 2001 09:31:19 -0400

Just so everybody knows where we are ...

The working group has two deliverables - a framework document and a
requirements document.  We are NOT responsible for delivering a protocol
document.  Both of the deliverables are supposed to be through working
group last call and delivered to the IESG in August.  I think we're
on track for the framework document and somewhat behind schedule on the
requirements document.  The URLs for the documents are:

http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-midcom-requirements-01.txt

Please note that a revision of the framework document has been submitted
to ietf-drafts and will be posted once it clears her queue.  Please read
it carefully once it's announced - if there is general agreement and no
SUBSTANTIVE objections, it's the version that will go to last call.  I
expect several more iterations of the requirements document.

We are tentatively scheduled to meet from 9am-11:30am on Thursday
during the London IETF meeting.  

Melinda

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: "Scott Brim" <[email-masked]>
Date: Tue, 10 Jul 2001 11:39:19 -0400

I don't think we'll be able to get the Requirements draft ready for last
call by the London meeting.  It needs a major overhaul.  I say this with
regret.

I want to be able to easily verify whether a particular protocol design
meets the requirements.  This document would help me if

* I don't have to sift throug philosophy and context -- that's why we
  have a separate framework document.  If we want context with our
  requirements we can combine the two drafts when we go to draft
  standard.  Apart from actual requirements, the requirements document
  should just have scope and terminology (and these should be excerpted
  from the framework).

* It lists all of the requirements succinctly, up front, e.g. in a
  table.  It should also have justifications and notes, but in a
  separate major section.  Right now the requirements are often
  interspersed with discussion text, and sometimes I can't tell what is
  supposed to be a requirement and what is not.

* It is very clear about MUST, SHOULD, MAY etc.

* The requirements should be distilled down to real operational
  requirements -- some of them are still somewhat abstract and what they
  refer to is not clearly defined.  This is something we could have done
  on the mailing list but we've been busy.  This would be much easier if
  the requirements were separated out from discussion text.

Finally, I estimate that about 30% of the requirements listed would be
contentious if we actually took the time to talk about them.

What do I suggest?  Sigh.  I suggest we edit the current document with
an axe.  Take the existing text but totally reorganize it and remove the
fat.  Have: a (very!) brief introduction, scope, and terminology; then a
succinct list of clear requirements that are not contentious at all;
then a list of requirements which for which consensus has not been
demonstrated; then finally, a completely separate section with
discussion text for the different requirements (but only the text that
is necessary for understanding the requirements).  Optionally, for
institutional memory, a major section of requirements that have been
proposed but rejected, and why.

...Scott