Subject: [midcom] Requirements draft

From: Melinda Shore <[email-masked]>
Date: Wed, 14 Nov 2001 09:36:07 -0500

There have not yet been any comments on the revised requirements
draft.  I'd like to get it into last call ASAP, but both the
contents and the format have been points of fairly raucous 
contention in the past and I'd be hard-pressed to believe that
everybody thinks the current document doesn't need editing.
Please have a look at it and post comments to the mailing list.

Thanks,

Melinda

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

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 15 Nov 2001 08:10:19 -0500

Hi,

I have some comments on the requirements draft, mostly nits.

2.1.2: 1st para: s/middleboxe/middlebox/

2.1.3: I agree with Mark that the reasoning should mention multiple midcom
agents.

2.1.4: 2nd para: s/The states/This states/

2.1.5: 2nd para: s/provide identifying clear identification/provide clear
identification/

2.1.7: There may also be events that the agent would be interested in that
may not necessarily result in the closing of pinholes or freeing of
resources. For example, an agent might be interested in knowing when packets
for a given ruleset start or stop flowing.

2.1.11: 1st para: s/types of middlebox/types of middleboxes/

2.1.11: 2nd para: s/support other/support for other/

2.1.11: This may also include capability discovery/negotiation so that peers
can determine the set of operations and attributes that both support.

2.1.12: I agree with Mark that the protocol should define ruleset precedence
so that behavior of such overlaps is deterministic.

2.2.1: 1st para s/dopted/adopted/

2.2.1: There may also be new attributes or options (as implied by 2.2.5)
added to message types. For example,  additional filtering elements.

2.2.2: The last sentence of the 2nd paragraph is a bit confusing. I suggest:

    A midcom agent ought to be able to have a single midcom *session* with
    a middlebox and use that single session to access different middlebox
    functions on the same middlebox interface.

2.2.5: 2nd para: s/accomodate/accommodate/

2.2.6: s/behaviour/behavior/

2.2.7: The reason for this requirement is related to 2.1.5. Where there is
redundancy in the application, a redundant or backup midcom agent will need
to maintain and/or remove a ruleset created by a failed midcom agent.

cheers,
(-:bob

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