Subject: [midcom] additional midcom reqts

From: Scott Bradner <[email-masked]>
Date: Tue, 16 Oct 2001 17:06:24 -0400 (EDT)

sigh - I'd sure like to get this phase wrapped up - the aim is not to figure
out all possible requirements for something like midcom - it should be to 
figure out the basic set of functions needed to get the job done. 
This is surely a case of 'done when the last non-basic thing is removed'
not 'done when the document gets too big to print'

Scott

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

---

From: Mark Duffy <[email-masked]>
Date: Tue, 16 Oct 2001 17:27:27 -0400

Hi Scott,

My apologies for asking this but perhaps your message is too subtle for me :-)

I'd love to get the phase wrapped up too.
The tone of your message suggests that you believe the additional
requirements I proposed are perhaps beyond what we should be working on.

From my perspective, identifying a reasonable, common set of actions that
an agent may use midcom to ask a middlebox to do should be part of our
work.  But stating every possible action is not something we should do.  I
do not believe the current list of requirements says anything about what an
agent may ask a mb to do, with the exception of 2 very specific
requirements related to a somewhat specialized request to be made of a NAT
middlebox.

Do you feel we should not identify any actions the midcom protocol may be
used request?
Or that we already have a sufficient identification of such actions?
Or we need something in that area but my proposal goes too far?
Or I have misunderstood you entirely?

Thanks, Mark

---

From: Melinda Shore <[email-masked]>
Date: Tue, 16 Oct 2001 18:25:28 -0400

I'm not Scott (did you notice?), but I'm going to take a crack at 
this from the chair's perspective:

At 05:27 PM 10/16/01 -0400, Mark Duffy wrote:
>I

I think that should be considered a good thing.  The charter
and the framework documents convey the gist of what it is 
we're trying to do, and from those it should be self-evident
what sorts of requests are going to be sent to the middlebox.
Loading up with detail essentially translates to protocol
design and that's not our job right now.  In the meantime we've
lost a *lot* of time to going into unnecessary detail in the
first place and then whittling down the list in the second.
Scott is, I think, alluding to a quote by Saint-Exupery, who says 
"Perfection is achieved, not when there is nothing left to
add, but when there is nothing left to remove."  By that yardstick
we've fallen well short of perfection.

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Wed, 17 Oct 2001 11:31:29 -0400

At 11:26 AM 10/17/01 -0400, Mark Duffy wrote:

>    Rxxx:  The Midcom protocol MUST allow a Midcom agent to request a
>           firewall opening from a middlebox that provides a firewall
>           function.
>
>    Ryyy:  The Midcom protocol MUST allow a Midcom agent to request
>           creation of an address binding or an address+port binding
>           from a middlebox that provides a NAT function.
>
>    Rzzz:  The Midcom protocol MUST allow a Midcom agent to learn the
>           address and port values assigned when a middlebox providing
>           a NAT function creates a binding at the behest of the
>           midcom agent.
>
>Those to me are a minimalist embodiment of our charter that Midcom must
>address NAT and firewall middleboxes.

Do you think that if we leave these out, the next iteration of
the working group would fail to include these functions in the
protocol?

Melinda

---

From: Mark Duffy <[email-masked]>
Date: Wed, 17 Oct 2001 11:26:21 -0400

At 06:25 PM 10/16/01 -0400, Melinda Shore wrote:
>design and that's not our job right now.

Melinda, I disagree somewhat.  

What we have loaded up on (in the requirements) is mostly generic
signalling protocol requirements (security, reliability, support for
redundancy, determinism, etc.)

If we are just trying to capture "the gist" of midcom, fine.  Let's finish
the framework and go home.  If we are to write requirements, then let's
make them complete.  As you and Scott have stressed, and I agree, complete
does not in this case mean finely detailed.  But I think it does mean
covering the entire scope.

I cannot see that we have covered the scope with the requirements if they
do not address what an agent may ask a middlebox to do.  That is after all
the heart and soul of what midcom is about -- all that stuff about
signalling is subsidiary!

I concede that the suggestions in my message yesterday on this topic were
too detailed/arcane for the current circumstances.  I propose that the
following requirements will address the matter:

Thanks.
--Mark

---

From: Mark Duffy <[email-masked]>
Date: Wed, 17 Oct 2001 11:38:33 -0400

>the working group would fail to include these functions in the

No.
Do you think that is reason enough to omit them from the requirements?
I am unfamiliar with the way of writing requirements that leaves out
fundamental requirements just because they should be obvious.

---

From: [email-masked]
Date: Wed, 17 Oct 2001 12:03:29 -0400

> redundancy, determinism, etc.)

I'm with Melinda et al.  What we've loaded it up with is *supposed* to
be information to make life easier for the protocol designers.  In
theory we've thought about the protocol a lot, reached difficult
conclusions, and recorded those conclusions.  The requirements don't
need to set context -- that's what the framework draft is for.  The
requirements also don't need to record what should be obvious to
anyone.  We've slipped over that line into a vast space of possible
obvious requirements, but we aren't lost yet.  We can step away.

> covering the entire scope.

I don't think it's worth noting that the protocol must be able to run at
speeds less than the speed of light.  Where do you draw the line?  I
draw the line at work which is useful to our successors.

> I cannot see that we have covered the scope with the requirements if
> they do not address what an agent may ask a middlebox to do.  That is
> after all the heart and soul of what midcom is about -- all that stuff
> about signalling is subsidiary!

We have, in fact, spent a lot of time on what an agent may ask a
middlebox to do.  For example, remember the weeks which concluded with
the requirement for the well-defined 5-tuple and room for future
extensions?  We intentionally ignored the obvious and worked on the gray
areas, the boundary cases.

>            a NAT function creates a binding at the behest of the

This one might actually be worth discussing ... but not the others.

Here's a test: suppose this WG is finished, and the next one, the
protocol design one, is starting out.  Would you stand up in front of
the group and say "I just want to be sure everyone realizes this
protocol has to be able to request a pinhole in a firewall."?  Wouldn't
you be embarrassed at the silence while everyone tries to figure out the
catch?

...Scott