Subject: RE: [midcom] Deleting requirements -tuple items

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 16 Aug 2001 09:20:44 -0700

Hello Melinda,

I second Mark on this. Just because the AD (I think in this case Scott
Bardner) wants that, doen't mean we all have to comply blindly. Of course I
respect Scott's direction on this, but my opinion is different. Otherwise
the IETF stop being a "rough consensus and running code" to a "you do what I
told you to".

We can as Mark propose,

1.  Remove all requirements or parts of requirements that state what the
components of the n-tuple are.  Leave this to be determined later.

And also base my opinion due to the fact that I agree with you when you say
that "It appears to be intended to
be comprehensive, but the fact is that network operators are filtering on
all sorts of stuff, not just what's listed here."

regards,

Reinaldo

> -----Original Message-----
> From: Mark Duffy [mailto:[email-masked]]
> Sent: Thursday, August 16, 2001 9:00 AM
> To: Melinda Shore; Mark Duffy; Mark Duffy; [email-masked]
> Subject: Re: [midcom] Deleting requirements -tuple items
> 
> 
> At 11:00 AM 8/16/01 -0400, Melinda Shore wrote:
> >First, I've got to say that I'm pretty disappointed that people
> >aren't listening to the *very* clear message coming down from 
> >the ADs.  Small is beautiful, trim the fat, the 5-tuple is
> >sufficient for now, etc.
> 
> Melinda, I don't think it is realistic to expect everyone to 
> just get in
> line for that -- not everyone has the same objectives as the ADs.  I
> suggest that you as chair should declare this out of scope for the
> requirements, if you and the ADs feel it is.  Otherwise it 
> should be up to
> the wg concensus whether this belongs in the requirements or not.
> 
> BTW I did present this option in my email, along with the 
> proposed list of
> tuple requirements, perhaps you missed it:
> 
> >1.  Remove all requirements or parts of requirements that 
> state what the
> >components of the n-tuple are.  Leave this to be determined later.
> 
> 
> 
> >Second, this is actually a very good representation of the 
> problem with 
> >enumerating the filtering elements.  It appears to be intended to
> >be comprehensive, but the fact is that network operators are 
> filtering
> 
> Actually, it was not intended to be comprhensive of the 
> possibilities, only
> comprehensive of what was already in the requirements doc.
> 
> >on all sorts of stuff, not just what's listed here.  Another problem
> >is how this is going to scale.  When you talk about using a 
> "don't care"
> >flag for elements as needed, you're saying that the whole 
> filter needs
> >to be sent down every time.  It's either going to become 
> very large or
> 
> No, I didn't say that.  I just proposed requirements for an 
> initial list of
> elements to support.  It is a protocol design issue whether 
> they all need
> to be sent every time (and as you point out, that might well be a poor
> design).
> 
> >it's going to remain insufficient.
> >
> >Third, see item the first.
> >
> >Melinda
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/midcom
>