Subject: [midcom] Requirements summary: all requirements

From: Scott Brim <[email-masked]>
Date: Fri, 3 Aug 2001 13:15:56 -0400

I went through the requirements draft, the framework draft, and some
(but not all) mail that's been exchanged recently and produced the
enclosed.  

Yes, I really think we should work on very focused requirements in order
to make progress.  This is supposed to be a tool to help.  I propose
that someone (me by default, although I hope to find a volunteer) keep
this up and produce a new version every week.  If I'm doing it I will
not be sending it out to the list after this, but making it FTPable
instead.

Does a weekly update of a "living document" sound good?

I did not ask the Requirements authors before putting their names on
this, but they wrote 95% of the material.

By the way, this is a product of emacs and xml2rfc
<http://xml.resource.org>.

..Scott

---

From: "Melinda Shore" <[email-masked]>
Date: Sun, 5 Aug 2001 15:40:48 -0400

> Does a weekly update of a "living document" sound good?

I think this is an outstanding idea.  Let's borrow a page from 
AAA and use numbered "issues" along with brief text describing 
where we currently stand, if it's not too onerous (just a suggestion, 
not a mandate).  It's most important for the purpose of making
progress to track the unresolved issues.

Thanks!

Melinda

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

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 09 Aug 2001 13:49:54 +0200

Scott,

I very much appreciate your effort to nail-down the requriement issues.
Let me send my comments on some of them. Mainly, they are motivated by
my desire to limit both framework and requirement documents to a needed
minimum.

-Jiri

   R1: The MIDCOM protocol MUST enable a MIDCOM Agent requiring the
       services of a Middlebox to establish an association between
       itself and the Middlebox for the purposes of requesting pin-hole
       services from the Middlebox and obtaining statistics and other
       reporting information.

*** I am not sure what association means here. I suspect it is not necessarily 
    midcom protocol's task to establish a relationsship (i.e.,
    IP addresses and security credentials) between
    agents and middleboxes (if this is what you mean by association).
    This can be also done by an admin. 
    - proposal: drop R1.

   R3: The Middlebox MUST support multiple simultaneous MIDCOM Agents.

       A specific Middlebox MUST NOT assume any relationship between
       MIDCOM Agents.

*** I do not understand what the second sentence says. I think that
    a middlebox simply does not care whether two agents have some
    relationship or not. 
    - proposal: drop R2

   R4: Agents MUST be known to end system applications.

          This comes from the following text in the framework draft,
          version -03: "In-Path MIDCOM agents are entities that have a
          native role in the path of the application traversal (with
          prior knowledge to one of the application end-hosts),
          independent of their MIDCOM function."

*** I think usage scenarios are out of requirements scope; besides that it is
    not always the case that end-devices know the agent explicitly
    (for example, there might be more SIPproxies in the chain; an
     end-devices sees then only the nearest one which may or may not
     be a midcom agent)
    - proposal: drop R4, fix framework

   R5: a middlebox MUST couple middlebox resources with midcom agents.

          This is from the framework draft, version -03: 

*** I see two issues here: 1) resource ownership and 2) registration/deregistration.
    I think ownership is needed and registration/deregistration not. Both
    these issues need more discussion.

   R6: A middlebox must be able to associate a timer with session
       elements.

*** - proposal: I would like to add a protocol requirement which
      would allow (subject to middlebox policy, of course) agents
      to determine the timer; it is the application that knows best
      what timer values are adequate.

   R7: An agent MUST accept responsibility for application-specific
       processing under direction of a middlebox which is performing a
       related service for that agent.

          This comes from the following text in the framework draft
          version -03: "The MIDCOM protocol between a MIDCOM agent and a
          middlebox allows the MIDCOM agent to gain access to middlebox
          resources and allows the middlebox to delegate application
          specific processing to MIDCOM agent.  The protocol will allow
          MIDCOM agents to signal the middleboxes to let complex
          applications using dynamic port based sessions through them
          (i.e., middleboxes) seamlessly."

          "Delegate" assumes a particular control relationship between
          middlebox and agent.

*** I think R7 says something else than the framework does. The framework
    describes midcom decomposition here. I do not think that an agent
    does anything under direction of a middlebox. I also do not think that
    we can want to dictate agent's responsibility. It is certainly useful
    to describe what an agent may be good for but I do no see the need
    for a requirement here.
    - my proposal: drop R7

   R8: There MUST be some activity between agent and middlebox which
        maintains a "connected" state.

*** Why? Unless this is well documented I would prefer dropping notion
    of connected state (including registration and deregistration) from 
    both framework and requirements. The same for R9.
    - proposal: drop conection,registration,deregistration entirely
      from framework and requriements

   R10: A middlebox MUST be able to notify a midcom agent of the
        following events: Session creation, Session termination, MIDCOM
        protocol failure, Middlebox function failure or any other
        significant event.  Independently, ICMP error codes can also be
        useful to notify transport layer failures to the agents.

           From the framework draft, version -03.

*** I personaly do not expect such notifications to be communicated using
    midcom protocol. As such, I do not see the need for listing it in
    the requirement document. 
    - proposal: drop R10

   R13: Agent hosting entity (whatever that is) MUST be identified in
        the midcom protocol.

           This is from the framework document, version -03.

*** I think this the notion of agent identity is useful and it can be
    used for policy decisions and resource ownership. I do not think
    this must be necessarily feature of the midcom protocol -- this may
    also come from a lower-layer.
    - my proposal: clarify this better in framework, change requriement
      to "Support for communicating agent identity must be present
      either in midcom protocol itself or an accompanying security
      protocol"

   R18: The Middlebox MUST NOT alter packet information unless it
        appears in the packet header.

           There is disagreement over whether this requirement is needed
           or even useful, since it's essentially none of midcom's
           business what a particular middlebox does.

*** I agree with the disagreement,
    - proposal: drop R18

   R21: Where the communication relationship between a Middlebox and a
        MIDCOM Agent becomes invalid, all existing Pin-Holes owned by
        the MIDCOM Agent concerned MUST be closed.

*** The same as for R9. I think that pinhole validity is related to its
    time-to-live rather than to agent's time-to-live.
    proposal: drop it along with connection.disconnecction/registrration/etc.
    (the same later for R34, R35, R36, R37)

   R43: The Midcom Protocol SHOULD allow the aggregation of commands,
        requests and responses.

*** I do not know what command/request/response aggregation is. Could you
    explain please?

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

---

From: Scott Brim <[email-masked]>
Date: Mon, 13 Aug 2001 07:35:15 -0400

On Thu, Aug 09, 2001 at 01:49:54PM +0200, Jiri Kuthan apparently wrote:
> my desire to limit both framework and requirement documents to a
> needed minimum.
> 
> -Jiri

I hope(!) much of this was taken care of in our meetings.  As I said
before I believe the chair should select no more than three requirements
at a time, and make sure discussion focuses only on those.

It's my turn to catch up on mail ...

>    services of a Middlebox to establish an association between itself
>    and the Middlebox for the purposes of requesting pin-hole services
>    from the Middlebox and obtaining statistics and other reporting
>    information.
> 
> 
> *** I am not sure what association means here. I suspect it is not
> necessarily midcom protocol's task to establish a relationsship (i.e.,
> IP addresses and security credentials) between agents and middleboxes
> (if this is what you mean by association).  This can be also done by
> an admin.  - proposal: drop R1.

We truncated from "for the purposes" onward, but we still don't have
agreement -- I think that's simply because we haven't got around to it
(Scott nudges Melinda).

I'll make a note of your interesting suggestion under this bullet item.

> *** I do not understand what the second sentence says. I think that a
> middlebox simply does not care whether two agents have some
> relationship or not.  - proposal: drop R2

This has been split into two -- that comment is gone, although I believe
I meant the same thing you do:

   R3a: The Midcom protocol MUST support communication between multiple
        MIDCOM Agents and multiple middleboxes.

   R3b: The Midcom protocol MUST support multiple agents manipulating
        the same middlebox resource.

> *** I think usage scenarios are out of requirements scope; besides
> that it is not always the case that end-devices know the agent
> explicitly (for example, there might be more SIPproxies in the chain;
> an end-devices sees then only the nearest one which may or may not be
> a midcom agent) - proposal: drop R4, fix framework

R4 is dropped because the "interim" framework draft removed the problem
text.

> *** I see two issues here: 1) resource ownership and 2)
> registration/deregistration.  I think ownership is needed and
> registration/deregistration not. Both these issues need more
> discussion.

Right.  I had already noted that you believe in ownership and I look
forward to that discussion -- the purpose of "ownership" and so on.

> *** - proposal: I would like to add a protocol requirement which would
> allow (subject to middlebox policy, of course) agents to determine the
> timer; it is the application that knows best what timer values are
> adequate.

We already have:

   R6: A middlebox must be able to associate a timer with a ruleset.
       When a timer expires, resources are freed.

Is that enough?

>           version -03: "The MIDCOM protocol between a MIDCOM agent and
>           a middlebox allows the MIDCOM agent to gain access to
>           middlebox resources and allows the middlebox to delegate
>           application specific processing to MIDCOM agent.  The
>           protocol will allow MIDCOM agents to signal the middleboxes
>           to let complex applications using dynamic port based
>           sessions through them (i.e., middleboxes) seamlessly."
> 
> *** I think R7 says something else than the framework does. The
> framework describes midcom decomposition here. I do not think that an
> agent does anything under direction of a middlebox. I also do not
> think that we can want to dictate agent's responsibility. It is
> certainly useful to describe what an agent may be good for but I do no
> see the need for a requirement here.  - my proposal: drop R7

I put this in the requirements bullets because of the word "delegate".
This one was tentatively tossed out on Monday night because people
didn't care what "delegate" might mean or imply.  (I'll be sending out a
draft of the changes to the requirements bullets I believe we've agreed
to very soon.)

> both framework and requirements. The same for R9.  - proposal: drop
> conection,registration,deregistration entirely from framework and
> requriements

Yes, the Monday night crowd agreed :-).  For different reasons, though.
You're saying we should remove capabilities from the midcom protocol
which we can already do by some other means.  They just thought it was
wrong.  

Your suggestion that we do what we can outside of the midcom protocol
leads us back to the idea of not creating a new protocol, but rather
just adding a slight extension to an existing protocol, like COPS or
Diameter or something on BEEP.  I have a suspicion that we will satisfy
you by selecting a protocol which already does these things.

> *** I personaly do not expect such notifications to be communicated
> using midcom protocol. As such, I do not see the need for listing it
> in the requirement document.  - proposal: drop R10

Noted.  Still not discussed by the group.

> used for policy decisions and resource ownership. I do not think this
> must be necessarily feature of the midcom protocol -- this may also
> come from a lower-layer.  - my proposal: clarify this better in
> framework, change requriement to "Support for communicating agent
> identity must be present either in midcom protocol itself or an
> accompanying security protocol"

Noted in the bullets.

>            There is disagreement over whether this requirement is
>            needed or even useful, since it's essentially none of
>            midcom's business what a particular middlebox does.
> 
> *** I agree with the disagreement, - proposal: drop R18

Done, on Friday.

>    MIDCOM Agent becomes invalid, all existing Pin-Holes owned by the
>    MIDCOM Agent concerned MUST be closed.
> 
> *** The same as for R9. I think that pinhole validity is related to
> its time-to-live rather than to agent's time-to-live.  proposal: drop
> it along with connection.disconnecction/registrration/etc.  (the same
> later for R34, R35, R36, R37)

Noted, for those not already rejected as duplicates or subsets.

> *** I do not know what command/request/response aggregation is. Could
> you explain please?

This means that a single packet could contain multiple requests or
responses.  

Requirements bullets soon.

..Scott

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 14 Aug 2001 11:00:22 +0200

>       When a timer expires, resources are freed.

I would actually like to require that the midcom protocol must allow
agents to set (or ask for) timer. (The point is that your
R6 requirement for middlebox products still does not imply agents 
be able to manipulate the timer.)

-Jiri