Subject: RE: [midcom] Thought you'd want to know

From: "Christian Huitema" <[email-masked]>
Date: Thu, 11 Oct 2001 17:32:53 -0700

> >   R35: Once the need for the relationship between a Midcom Agent and
> a
> >        Middlebox established during the registration process has
> >        lapsed, a deregistration process will be required.  This will
> >        break the trust relationship between the specific Middlebox
> and
> >        Midcom Agent.  Once this has been done, a Middlebox MUST NOT
> >        service any further requests from a given Midcom Agent
> without
> >        the Midcom Agent first re-establishing the appropriate trust
> >        relationship with the Middlebox.
> >
> >           Wording problems.  "Registration" needs better definition
> (in
> >           framework?).  "Lapsed" is not understood the same by
> >           everyone.
> >
> >This is obvious.  Discard.
> 
> Yes, discard.

Yes, discard.
> 
> >   R38: The Midcom Protocol MUST enable the Middlebox and/or Midcom
> >        Agent to determine when a registration session is no longer
> >        valid.  This is to address cases such as when either a
> Middlebox
> >        or MIDCOM Agent restarts.
> >
> >"Registration", as used by Suresh and in this case, is a policy
> issue.
> >It's what happens when a middlebox (or agent) hears from some policy
> >entity that an agent (or a middlebox) is allowed to communicate at
> all.
> >This doesn't have anything to do with the midcom protocol, but rather
> >with policy interactions.  So far we've done close to nothing wrt
> >policy.  I say discard this one, since it will be included in
> whatever
> >we finally do with policy.
> 
> Yes, discard.

Yes, discard.

> 
> >   R43: The Midcom Protocol SHOULD allow the aggregation of commands,
> >        requests and responses.
> >
> >           We don't know what this one really means, but we're
> putting
> >           off judgment until we know more about our other
> >           requirements.
> >
> >Already covered by already accepted ones.  Discard.
> 
> I'm not sure what accepted reqts cover this one.  But I vote for
> discard
> anyway.

Ditto. Discard.

> >   R47: When accepting a request for a pin-hole, the Middlebox MUST
> be
> >        able to provide the MIDCOM Agent with information that may be
> >        used to identify the resource in subsequent operations.
> >
> >           Temporarily changed "flow" to "resource".  Need better
> word
> >           than "resource".
> >
> >I think we should discard this too.  We don't know how midcom will be
> >used, especially when multiple agents and middleboxes get involved.
> >There are two possible approaches.  First, accept this requirement,
> and
> >require a field in the protocol packets with a note that it *might*
> be
> >used for an identifier, but keep it reserved and do our best not to
> use
> >it.  After a while we'll know if we need it.  If we don't we can use
> it
> >for future expansion.  The other option is to abandon this
> requirement,
> >and if in the future someone decides they really need an identifier,
> >they can add it using the protocol's extensibility features.  The
> only
> >reason to stick the field in now is if there are performance issues.

Discard. At best, this is a protocol design issue, not a protocol
functionality issue.

> >   R75: The Midcom Protocol must produce robust operation even when
> >        routing changes such that traffic from a particular end
> system
> >        passes through a different middlebox.  (Huitema)
> >
> >           Eliot Lear says "this takes too much state".
> >
> >I don't think supporting this kind of robustness is the job of the
> >midcom protocol.  I think the model underlying this one is poorly
> >formed.  Discard.
> 
> Isn't this really part of the topology question?  What is the result
> of the
> breakfast ^h^h^h^h^h^h^h^h^h contest of champions and how does that
> result
> feed back into the requirements??

OK. What I have really in mind is the support of an explicit media
relay: internal client sends to specific port on media relay, the
traffic is then relayed to final destination, and vice versa. Since the
traffic is pinned to the media relay, the configuration is immune to
routing vagaries. Several SIP implementations use such relays to cross
firewalls.

-- Christian Huitema

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