Subject: RE: [midcom] Deleting requirements

From: "Sanjoy Sen" <[email-masked]>
Date: Thu, 16 Aug 2001 18:29:39 -0500

I would support deletion of all proposed by Melinda except R74. The reason
is, the MA should be able to know the capabilities/resources (e.g., # of
available NAT ports) of MB after establishing the "communications
relationship" with the MB. This would be useful, for example, to allow a SIP
call Server (associated with the MA) to make a decision on whether to
admit/reject a new call.

Sanjoy

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2001 4:02 PM
> To: Scott Brim; [email-masked]
> Subject: Re: [midcom] Deleting requirements
> 
> 
> At 03:55 PM 8/15/01 -0400, Scott Brim wrote:
> >(Must be able to request specific addr/port.)  Are you saying that
> >shouldn't be a requirement, or that it's obvious?  Personally I'm in
> >favor.  It's easy.
> 
> I think it's obvious.
> 
> >(Robust in face of packet loss.)  Again, why?  Because it's obvious?
> 
> I think so.  Consider the alternative.
> 
> >> R27
> >
> >(Low latency.)  Why?
> 
> I could go either way on it.  I'm not convinced that it's a
> necessary requirement, but I could be.  At any rate, I'm just
> putting it out there.
> 
> >> R50 (redundant with R40)
> >
> >No.  R50 says you should be able to specify DSCP for 
> matching on (note,
> >this is NOT saying you can say what QoS treatment to GIVE 
> the packets).
> >R40 only covers the basic tuple.
> 
> Right, but if we decide to define the filter elements at all (and 
> I tend to think that we should not), it should be in one place.
> 
> >And where would that be?  That's what this requirement was 
> supposed to
> >be for :-)
> 
> We need one requirement saying that the protocol must support both
> v4 and v6 addresses.  Come to think of it, we need a 
> requirement saying
> that the protocol should run over both v4 and v6 networks.
> 
> >> R56
> >
> >Well, ICMP type is not part of the usual tuple and could easily be
> >overlooked.  I think this one could use some consensus.  
> 
> See my comments on R50.
> 
> >I won't do anything with any of these until the Chair 
> declares consensus
> >on them (individually).  
> 
> That's why I've put out a proposal to delete these.  I'm trying to 
> get yes/no answers.
> 
> Melinda
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/midcom
>

---

From: Scott Brim <[email-masked]>
Date: Fri, 17 Aug 2001 10:43:21 -0400

> call Server (associated with the MA) to make a decision on whether to

It would be useful.  Personally I'd like to keep it but I'm willing to
let it get deleted and trust the son-of-midcom group.