Subject: [midcom] Items currently under consideration

From: Melinda Shore <[email-masked]>
Date: Wed, 29 Aug 2001 11:40:15 -0400

These are the requirements we're currently trying to close:

From http://www.employees.org/~swb/midreqs/midcom-reqs-bullets-010821.txt

R23: Delete?
        The Midcom Protocol MUST enable the Middlebox and any associated
        Midcom Agents to establish known and stable state.  This must
        include the case of power failure, or other failure, where the
        protocol must ensure that any resources used by a failed element
        can be released.

R75: Delete?
        The Midcom Protocol must produce robust operation even when
        routing changes such that traffic from a particular end system
        passes through a different middlebox.  

R45: Clarify or delete?
        It MUST be possible for the attributes associated with a
        Pinhole-Descriptor to be specific to a given Middlebox or MIDCOM
        Agent.

R39, R63: Combine?
        (R39) A Midcom Agent MUST be able to determine whether a request was
        successful or not.
        (R63) To enable management systems to interact with the Midcom
        environment, the protocol MUST include failure reasons that
        allow the Midcom Agent behaviour to be modified as a result of
        the information contained in the reason.  Failure reasons need
        to be chosen such that they do not make an attack on security
        easier.

R79,80: Both need more discussion, someone will need to propose new text
        (R79) If a particular ruleset is created multiple times, it must be
        deleted the same number of times.
        (R80) If two rulesets overlap, and one is deleted, the overlapping
        area must not be deleted until the other is deleted.

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

---

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 29 Aug 2001 11:08:41 -0700

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: Wednesday, August 29, 2001 8:40 AM
> To: [email-masked]
> Subject: [midcom] Items currently under consideration
> 
> 
> From 
> http://www.employees.org/~swb/midreqs/midcom-reqs-bullets-010821.txt
> 
> R23: Delete?

Hello,

You do not need a routing change for the traffic to pass through different
MBs. How about ECMP? Or assymetric routing with BGP? Or MPLS? We already
have very common topologies in use today that makes traffic take different
paths.

IMO this should be rephrased to:

The MIDCOM protocol must produce robust operation even when ingress traffic
and/or egress traffic from a particular end system passes through different
MBs. 

regards,

-RP

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 29 Aug 2001 11:37:06 -0700

Keep R23 -- hey, it is accepted already! It supercedes a number of silly
requirements that would pop up otherwise.

I have mixed feelings on R75. A possibility to satisfy it is to have the
option in Midcom to carry "full mappings". Suppose I want a stable
pinhole between 10.0.0.2:3456 and 64.5.6.7:8901. A possibility is for
the midcom box (10.0.0.1, 128.9.10.11) to allocate two mappings, ask
10.0.0.1 to send packets to the address "10.0.0.1:2345", and ask
64.5.6.7 to send packets to "128.9.10.11:1213". This guarantees that the
midcom box will be in the way of the communication even if the routing
changes. (It also guarantees fate sharing between the communication and
the midcom box, but that is another issue.)

Delete R45. It is way too vague, and probably wrong anyhow. Assuming
that the Midcom protocol operates on a set of rules, then the rules are
in all cases specific to the Midcom server on which they are creates.
Assuming that rules are actually identified by an intrinsic spec such as
a five tuple, then there cannot be two rules applying to the same tuple,
which means that there can only be one attribute set for any given rule.

Accept both 39 and 63. 39 is already agreed; 63 is just sound design.

Delete 79 and 80 (see separate e-mail.)

-- Christian Huitema

---

From: "Sanjoy Sen" <[email-masked]>
Date: Wed, 29 Aug 2001 16:34:07 -0500

> Sent: Wednesday, August 29, 2001 10:40 AM
> To: [email-masked]

   I think the first part (sentence) is important & should remain. This
emphasises the need for
state synchronization/update between the MB & the MA. If there're any state
changes in the MB, this should be promptly reported to the MA & vice-versa.
However, we may try to merge R31 & R23.
 
>         passes through a different middlebox.

Delete
  
>         Pinhole-Descriptor to be specific to a given 

Please clarify. Is this talking about vendor-specific extensions?

>         to be chosen such that they do not make an attack on security

Keep separate. I think R63 is extending R39 and saying "tell me something
more". R63 is also saying that the MA should be able to change its behavior
based on certain responses - this implies that we will need to have rules on
client & server to generate reason codes & react based on the reason codes.