Subject: [midcom] Terminology discussion - status

From: Melinda Shore <[email-masked]>
Date: Mon, 10 Sep 2001 11:11:53 -0400

We made some progress last week, but not enough to close the
discussion and edit the documents.

Rules: Can we resolve the "rules" issue by adding text distinguishing
between action rules and matching rules?  Suresh is correct in pointing
out that we don't want to be so restrictive in our terminology that
the documents aren't applicable to other types of middleboxes, but at
the same time we *are* focusing specifically on NATs and firewalls and
we don't want to be so general that the language is meaningless.  I
think that if we describe what action rules are and matching rules are
*without going into the details of their contents* we'll be well ahead
of where we are now.

Ruleset:  Scott proposed a definition which hasn't yet received any
discussion: "A set of rules which are installed and removed as a unit.  
A combination of a filtering (matching) specification and one or more 
action specifications.  How complex these can be is not defined."  
Objections?  Alternatives?

Pinhole: There seems to be some sentiment that if the term is to be
used at all, it's as an instantiation of a rule or ruleset.  It is
not an abstraction.

Pinhole-descriptor: Likewise - it's just a ruleset.

Connection: Them that's spoken have indicated a preference for "midcom
session."

Resource: We still need a definition here if we're to keep it.

Melinda

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

---

From: Scott Brim <[email-masked]>
Date: Mon, 10 Sep 2001 11:46:24 -0400

> discussion and edit the documents.

Mark, Suresh and I have been discussing offline.  I think we're waiting
for something from Mark right now, after which we can summarize to the
group.

> Objections?  Alternatives?

Just a small tweak which has come out: I would like to allow *one or
more* filtering (matching) specifications.  s/a/one or more/

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Sep 2001 11:52:11 -0400

> Suresh is correct in pointing
> the documents aren't applicable to other types of middleboxes,

I don't think this is correct at all.  The term 'middlebox' conflates
so many different kinds of devices that it is essentially useless.
The best thing this group could do is to discontinue use of the term entirely.

Keith

---

From: Mark Duffy <[email-masked]>
Date: Mon, 10 Sep 2001 11:52:54 -0400

Scott and I and Suresh had some side discussion on the terminology but
didn't get to agreement.  So, not claiming their endorsement, but
acknowledging their input, I'll toss out the following terms to distinguish
the components of rulesets:

Filter Spec
    Packet classifier (matching) information that identifies a set of
packets to be treated a certain way by a middlebox.
 
Action Spec
    Description of the middlebox treatment/service to be applied to a set of
packets.  

Ruleset
    The combination of one or more filter specs and one or more action
specs.  Packets matching the filter spec(s) are to be treated as specified
by the  associated action spec(s).  The ruleset may also contain auxilliary
information such as timeout values, owning agent, etc.  
  [Scott/Melinda point out that the ruleset gets
installed/removed/administered as a unit and I don't disagree but that
seems to me to go beyond defining the terminology, and belongs elsewhere.]

Pinhole -- eliminate this term if possible.  Else:
    A behavior of a firewall-type middlebox to allow a specified set of
packets to traverse the middlebox.  Pinholes instigated via the midcom
protocol are described by Rulesets.

Pinhole-descriptor  -- replace this term by Ruleset

Flow -- eliminate use of this term.  replace with the appropriate terms above.
Resource -- ditto

---

From: Scott Brim <[email-masked]>
Date: Mon, 10 Sep 2001 12:37:39 -0400

> the components of rulesets:

Heartily endorsed with one suggestion and two comments.

> seems to me to go beyond defining the terminology, and belongs elsewhere.]

[Well, I was just justifying saying that auxiliary information was
attached to rulesets, not their components.]

> protocol are described by Rulesets.

I would change "behavior" to "ruleset".  I suggest that a ruleset *is*
what gets installed, and the protocol carries descriptions of rulesets
(which just might look exactly like the rulesets, but that's for
son-of-midcom to decide).

> Flow -- eliminate use of this term.  replace with the appropriate terms above.

Clarification: We want to keep resource as a general term, but use the
more specific terms whenever possible -- and so far it seems that we can
use the more specific terms in every case except in the definition of
"resource" which will be in the Framework.

---

From: Mark Duffy <[email-masked]>
Date: Mon, 10 Sep 2001 13:57:16 -0400

At 12:37 PM 9/10/01 -0400, Scott Brim wrote:
...
>son-of-midcom to decide).

Scott, I believe you are viewing "pinhole" as a particular type of ruleset,
while I was viewing "pinhole" as the reification (great word I learned from
you this week!) of such a ruleset.  I.e. I was thinking of it being the
state installed into the middlebox as a result of the ruleset being
transmitted to it.

Of course either one can be correct since it is a matter of definition!  Or
we can have a term for each definition (FW-pinhole, pinhole-ruleset?).  Or
hopefully, we can just get rid of it entirely  ;-)

--Mark

---

From: "Bob Penfield" <[email-masked]>
Date: Mon, 10 Sep 2001 14:13:53 -0400

----- Original Message -----
From: "Mark Duffy" <[email-masked]>
To: "Melinda Shore" <[email-masked]>; <[email-masked]>
Sent: Monday, September 10, 2001 11:52 AM
Subject: Re: [midcom] Terminology discussion - status

> Flow -- eliminate use of this term.  replace with the appropriate terms
above.

Both flow & resource are generic terms and we should not use them for
protocol elements, but that does not mean we eliminate every occurance of
the words in the docs. By generic I mean we can say "The midcom protocol
enables application flows to traverse a middlebox by installing rulesets
....".

---

From: Scott Brim <[email-masked]>
Date: Mon, 10 Sep 2001 14:38:08 -0400

> state installed into the middlebox as a result of the ruleset being

Either way is fine with me.  Depending on whether "ruleset" refers to a
protocol element, some state in a middlebox, or an abstraction, terms
for the others will fall out.  

I have no problem with "ruleset" being what gets carried in the
protocol.  However, in that case what's the general term for what gets
installed in a middlebox as a result of its receiving a ruleset?

> hopefully, we can just get rid of it entirely  ;-)

Some human groups can name every tree in their area but don't have a
word for "tree".

..Scott

---

From: Scott Brim <[email-masked]>
Date: Mon, 10 Sep 2001 14:38:55 -0400

> enables application flows to traverse a middlebox by installing rulesets

Agreed.