Subject: [midcom] new requirements bullets

From: Scott Brim <[email-masked]>
Date: Tue, 21 Aug 2001 15:10:25 -0400

A new version of the requirements bullets is now at
<http://www.employees.org/~swb/midcom.html>.

What's new?

- R82 introduced to define scope of rules carried by protocol.

- R11, R50-R57 replaced by R82.

- R16, R19, R27, R29, R30, R42, R48, R78 rejected as part of general
  cleanup of "motherhood" requirements.

- R71 rejected -- punted to next WG.

- R81 added for timer issues.

- Extra notes to reflect discussion.  There were not many of these,
  since the conclusions we reached were better reflected in actual
  bullet status changes.

- I took out the explicit per-bullet security considerations reminders,
  since we're not getting there and I suspect we're only going to do
  security considerations for the newly refrobnicated requirements draft
  as a whole.

We now have:

  12 accepted.
  14 "under discussion".
  18 "not yet discussed".
  42 rejected (a good number).

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

---

From: "Bob Penfield" <[email-masked]>
Date: Mon, 27 Aug 2001 16:55:33 -0400

Hi all,

I have a few more items I think we ought to consider removing or combining.

R23: Isn't this marketing? or just plain motherhood & apple pie?

R75: I'm not sure exactly what this means, but it sounds like a requirement
on the middlebox and the midcom agents to figure out that the routing has
changed and make necessary changes to existing pin-hole rules. How does this
affect the protocol? I propose we remove this requirement.

R45: Does anybody know what this means? It should be clarified or deleted.

R39+R63: These 2 need to be combined since they are basically talking about
response codes. The initial phrase in R63 "To enable management systems to
interact with the Midcom environment" is not needed. The real reason for
useful failure codes is to allow the midcom agent to do something reasonable
in response to the failure.

R68: Do we have new text for this yet?

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: Scott Brim <[email-masked]>
Date: Tue, 28 Aug 2001 15:16:12 -0400

> R23: Isn't this marketing? or just plain motherhood & apple pie?

Disagree.  This was to make sure the state stayed synchronized, partly
as a generalization of the idea that when an agent is de-authorized all
pinholes created by it should be closed.  I like this one.  It answers
the protocol design question of just how state synchronization you need
-- not much.

> R75: I'm not sure exactly what this means, but it sounds like a
> requirement on the middlebox and the midcom agents to figure out that
> the routing has changed and make necessary changes to existing
> pin-hole rules. How does this affect the protocol? I propose we remove
> this requirement.

Agreed, kill.  It's an important question about state and multiple
middleboxes, but I don't how the answer will affect the protocol itself.

> R45: Does anybody know what this means? It should be clarified or

Agreed, kill. 

> R39+R63: These 2 need to be combined since they are basically talking
> about response codes. The initial phrase in R63 "To enable management
> systems to interact with the Midcom environment" is not needed. The
> real reason for useful failure codes is to allow the midcom agent to
> do something reasonable in response to the failure.

Agreed: kill R39, keep R63, take out first bit of text.

> R68: Do we have new text for this yet?

I suggest we kill it and let Richard or anyone submit new if they wish.

My 2 cents ... Scott