Subject: [midcom] Deleting requirements

From: Melinda Shore <[email-masked]>
Date: Wed, 15 Aug 2001 14:42:58 -0400

I've received a clear "small is beautiful" message from our ADs,
and with that in mind I'd like to propose deleting the following
requirements as redundant, obvious, or unnecessary (note that some
of these have already been identified as things to be handled by
design teams, but which I think we can kill to no ill effect):

R16 (needs to be deleted or reworded)
R78
R19
R25
R27
R29
R30
R42
R48
R50 (redundant with R40)
R51 (see earlier note from Scott Bradner)
R52 (redundant with R50 and R40)
R53 (ditto - just need to state somewhere that the protocol must support
     both v4 and v6)
R54 
R55
R56
R57
R71
R74

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

---

From: Scott Brim <[email-masked]>
Date: Wed, 15 Aug 2001 15:55:18 -0400

> R16 (needs to be deleted or reworded)

(Security should be low-impact.)  I'd delete it.  I disagree with it.

> R78

(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.

> R19

(Optional ICMP reporting after closure.)  Agreed, delete.

> R25

(Robust in face of packet loss.)  Again, why?  Because it's obvious?

> R27

(Low latency.)  Why?

> R29

(Don't assume 0 delay.)  Agreed.  Obvious.

> R30

(Agent must be able to report status to middlebox.)  I think you can
delete this as a subset of R23, already accepted.

> R42

(independence from any app.)  Agreed.  Obvious.

> R48

Agreed.  Unclear, probably a subset of a different one.

> 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.

> R51 (see earlier note from Scott Bradner)

Yes.

> R52 (redundant with R50 and R40)

Yes, my mistake.

> R53 (ditto - just need to state somewhere that the protocol must support

And where would that be?  That's what this requirement was supposed to
be for :-)

> R54 

Agreed, redundant.

> R55

Agreed, redundant.

> R56

Well, ICMP type is not part of the usual tuple and could easily be
overlooked.  I think this one could use some consensus.  

> R57

Well, IGMP type is not part of the usual tuple and could easily be
overlooked.  I think this one could use some consensus.  

> R71

OK

> R74

(Ask what resources are available.)  We should put this off until Version
2, but I think it should be discussed eventually.  The point was that
after discovery (or perhaps as part of it) you want to be able to do
selection.  This was a mechanism for the agent to gather information in
order to make a selection.

I won't do anything with any of these until the Chair declares consensus
on them (individually).  At that point I'll put out a new version of the
bullets.

..Scott

---

From: Melinda Shore <[email-masked]>
Date: Wed, 15 Aug 2001 16:21:03 -0400

I got a "thanks and good luck" from Scott Bradner in response
to this.  Hah.

I'm thinking of getting another husky.  Clearly, one dog doing
this: 
http://www.employees.org/~shore/mov00051.mpg

is not enough (note the completely shredded bedding).

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Wed, 15 Aug 2001 17:02:24 -0400

>shouldn't be a requirement, or that it's obvious?  Personally I'm in

I think it's obvious.

>(Robust in face of packet loss.)  Again, why?  Because it's obvious?

I think so.  Consider the alternative.

>(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.

>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

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.

>overlooked.  I think this one could use some consensus.  

See my comments on R50.

>on them (individually).  

That's why I've put out a proposal to delete these.  I'm trying to 
get yes/no answers.

Melinda

---

From: Mark Duffy <[email-masked]>
Date: Wed, 15 Aug 2001 23:56:49 -0400

Melinda, I agree with all the deletions you propose, except a few as noted
below.

R52: I don't think we should delete it.  R52 is mostly redundant with R40
and R50 but adds the additional requirement that masks be supported.
Perhaps we can reduce R52 to R40b: "all items in the tuple are maskable"
and then debate that when we come to it.

>overlooked.  I think this one could use some consensus.  

Besides the ones you identified for deletion, I think R11 is a duplicate of
R40 so can be deleted.

-Mark

---

From: "Scott Brim" <[email-masked]>
Date: Thu, 16 Aug 2001 07:48:49 -0400

> R16 (needs to be deleted or reworded)

	Delete

> R78

	Keep.  I don't think it's obvious. 

> R19

	Delete

> R25

	Delete

> R27 (low latency)

	Delete -- I can't imagine anyone wanting this protocol not to be 
	low latency.

> R29

	Delete

> R30

	Delete, subset of R23 (already accepted)

> R42

	Delete

> R48

	Delete

> R50 (redundant with R40)

	Keep.  R40 has "flow direction".  R50 has "DSCP".  I believe you should
	remove the obvious fields from both, but leave both, because they are
	contentious.  I don't think a requirement which lists all the fields 
	different people want is as useful as multiple requirements, one for
	each.  Keep both these, with just the one contentious field.

> R51 (see earlier note from Scott Bradner)

	Delete

> R52 (redundant with R50 and R40)

	Delete

> R53 (ditto - just need to state somewhere that the protocol must support

	Keep ... until someone submits such text, this can be a placeholder.

> R54 

	Delete

> R55

	Delete

> R56 (icmp)
> R57 (igmp)

	Keep both.  In both these cases, someone wants to be able to request 
	a particular matching rule.  You said see comment above on R50.  I
	say the same thing :-).  Actually, the best would be for the author
	who proposed them in the requirements draft to say he doesn't think
	they're worth keeping.

> R71

	Delete

> R74

	Delete

...Scott

---

From: Melinda Shore <[email-masked]>
Date: Thu, 16 Aug 2001 09:14:22 -0400

>and then debate that when we come to it.

I'd like to see the filtering elements required in one place, so that
suggestion sounds good to me.  The big caveat, of course, is that
we've already received an admonition from one of the ADs, and that time
taken to go into great detail about filtering elements is not time well-
spent.  My personal preference would be to specify no filtering elements
at all - this is not a protocol specification document.

Melinda

---

From: "Scott Brim" <[email-masked]>
Date: Thu, 16 Aug 2001 09:19:34 -0400

> at all - this is not a protocol specification document.

I thought we had general agreement that there was a minimum set of
filtering elements which were absolutely necessary, like destination
address, and that we could/would require those.

---

From: Mark Duffy <[email-masked]>
Date: Thu, 16 Aug 2001 10:07:44 -0400

>at all - this is not a protocol specification document.

Melinda, I have 2 procedural approaches to 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.

2. (Building here on Scott Brim's last message.)  Replace all the existing
requirements items about tuple composition with the following:
 
 Ri: The Midcom protocol must permit the following to be specified as
criteria for each session-descriptor [replace "session-descriptor with
chosen term].  It must also be possible to specify "don't care" for any
packet field, either using the mask available or by other means.

  Ri.01  Source IP address 
  Ri.02  Source IP address mask
  Ri.03  Destination IP address
  Ri.04  Destination IP address mask
  Ri.05  IP protocol/ next header field
  Ri.06  Transport layer source port
  Ri.07  Transport layer source port mask
  Ri.08  Transport layer destination port
  Ri.09  Transport layer destination port mask
  Ri.10  DiffServ Code Point
  Ri.11  TCP SYN set or not
  Ri.12  interface/realm
  Ri.13  Direction relative to interface/realm
  Ri.14  ICMP type field
  Ri.15  ICMP code field
  Ri.16  IGMP type field

The above list is a compilation of all the proposed requirements we have
circulating.  I'm sure we would need to approve or reject each at some point.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 16 Aug 2001 11:00:09 -0400

>  Ri.13  Direction relative to interface/realm

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.

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
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
it's going to remain insufficient.

Third, see item the first.

Melinda

---

From: Mark Duffy <[email-masked]>
Date: Thu, 16 Aug 2001 12:00:06 -0400

>the ADs.  Small is beautiful, trim the fat, the 5-tuple is

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

>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.

>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).

---

From: Melinda Shore <[email-masked]>
Date: Thu, 16 Aug 2001 12:21:22 -0400

At 12:00 PM 8/16/01 -0400, Mark Duffy wrote:
>line for that -- not everyone has the same objectives as the ADs.  

Fair enough.  But I do think that we need to keep in mind that
the document will have to go through IESG review and IETF last
call, so anybody who advocates heading off in a different
direction from what's been recommended by both the ADs and the
chair should be prepared to make a very strong case.  What I'm
trying to avoid is getting through WG last call with a document 
containing stuff that I know for a fact won't survive IESG review.

>I
>requirements, if you and the ADs feel it is.  

I'm about that -><- close to doing something similar (the topic *isn't*
out of scope, but we're making a mess of it by trying to do too much).  
However, I don't like unilateralism and I'm hoping that we can find some 
sort of compromise that works.  Sticking with just a 5-tuple may be that 
compromise, but there may be something else, as well.  

Melinda

---

From: "Scott Brim" <[email-masked]>
Date: Thu, 16 Aug 2001 12:23:38 -0400

The bullets aren't meant to be an actual requirements draft.  Once we
agree (using the bullets) on what *should* be in a requirements draft,
the authors say they'll go off and fix one up.  So I wouldn't spend a
lot of time on how the content of the bullets should be organized.