Subject: Re: [midcom] Deleting requirements

From: "Philip Mart" <[email-masked]>
Date: Fri, 17 Aug 2001 13:41:58 +0100

My vote on the deletion candidates.

>R16 (needs to be deleted or reworded)

OK delete.

>R78

I agree with Scott Brim, it is not obvious.

Retain

>R19

Given the tight specification desired by the AD this should be deleted.
However it should be noted in order to help specify extensibility requirements
in outline rather than by enumeration.

>R25
>R27
>R29

Taken together these three requirements permit the use of UDP with timers which
take topology into account. This permits the entities to be separated by
considerable distances. I can only agree to their deletion if consensus is
reached
that the interpretation of other requirements meets these goals. Therefore,
until
that position is reached -

Retain

>R30

Delete

>R42

Delete. On the basis that the protocol is to allow minimal description of the
pinhole this becomes obvious.

>R48

Delete. I agree to this reluctantly following our A-D's advice to use a minimal
pinhole description.

>R50 (redundant with R40)

Delete. I agree to this subject to an ability to include packet-handling
information, in addition to packet selection criteria, in the extensible
part of the protocol.

>R51 (see earlier note from Scott Bradner)

Delete. Notwithstanding the note from Scott Bradner I agree to this subject
to an ability to include packet-handling information, in addition to packet
selection criteria, in the extensible part of the protocol.

>R52 (redundant with R50 and R40)

Delete. But...
This is a requirement that allows multiple pinholes to be opened with one
operation where the range of applicable addresses is determined by reference
to an address mask and was intended as an aid to protocol efficiency.

I don't recall that being ruled out of scope.

>R53 (ditto - just need to state somewhere that the protocol must support
>     both v4 and v6)

Delete, subject to IPv4 and v6 statement.

>R54

This is a requirement that allows multiple pinholes to be opened with one
operation. It can be seen that the use of this feature, for RTP/RTCP at least,
may aid protocol efficiency.

I do not agree to the deletion of this requirement but would accept rewording.
I prefer to await other reaction rather than offer words at the moment.

>R55

Delete.

>R56

Delete, subject to Richard's agreement.

>R57

Delete, subject to Richard's agreement.

>R71

Delete.
Actually people do need this but it will have to be an extension given our
present minimalism.

>R74

I am not happy to delete this because it is needed for recovery of state
after failure and subsequent recovery of an agent or its replacement by an
authorized substitute.

Retain.

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

---

From: Paul Sijben <[email-masked]>
Date: Mon, 20 Aug 2001 10:57:15 +0200

The results from the Dutch jury:

R16 sure, kill

R78 this seems very sensible, yet, is it a security requirement or a
functional requirement?

R19 this is one of the functions I'd like to see in the protocol. How to
align this with the ADs directive?

R25,27,29 I agree with phil. These requirements per se may not be very
clear. But together they clearly convey an intention. I would only agree
with removing them if there is a clearer replacement.

R30 this requirement is obviously a genric requirement for all such
protocols. If we take the stance that such requirements have to go, this
indeed has to be removed.

R42, ought to be obvious as well. yet, after dropping it I surely hope
that we will not see MIDCOM versions for SIP, MIDCOM versions for H.323
and MIDCOM versions for whatever.

R48, IF we agree to delete this, where do we put the requirement that we
want to specify a pinhole description and actions on the flow (such as
header rewriting or possibly body rewriting)?

R50 agreed, remove. Yet I agree with Phil, we do need the extensibility to
add other stuff later.

R51, my intentions with the MIDCOM protocol are clear, as long as I still
can do that. I can agree to removing this one.

R52, hmm, removing this requirement may impact protocol efficiency. Why
would this need to be removed?

R53, indeed if we state that we need to support v4 & v6, I am cool with
removing it.

R54 same comment as R52.

R55, if small is beautiful this one has to go

R56, R57 Hmm, this looks like a security requirement. hearing from people
with more operational experience than I have, this one is _really_ needed!

R71  my intentions with the MIDCOM protocol are clear, as long as I still
can do that. I can agree to removing this one.

R74 I'd say this is a rather useful thing to have for auto-configuration
of the network and recovery situations. Retain

Paul
-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Fax:+31 356875954
Forward Looking Work     
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)