Subject: [midcom] Re: Juergen Schoenwaelder: Re: [ietf-sirs] Review request

From: Martin Stiemerling <[email-masked]>
Date: Tue, 05 Aug 2003 17:30:00 +0200

Hi,

thanks to Juergen for reviewing the MIDCOM semantics.

|
| I have read <draft-ietf-midcom-semantics-03.txt> today and below are
| my comments. Note that I did not follow the midcom work nor do I
| consider myself an expert of middleboxes. So excuse if some of the
| comments are "beating a dead horse" or just show my ignorance.

All comments are welcome :-)

|
| In general, I found the document rather clear (except as noted below)
| and I wish folks good luck that they finally also find a protocol for
| the written down semantics. ;-)
|
| (a) It would be nice to say in the introduction what an agent is in
|     the context of midcom. It becomes clear when reading the document
|     but it won't hurt to avoid confusion by saying upfront what the
|     players in the game are.

We tried to avoid this and point to the MIDCOM framework and requirements.
The framework should describe it in-depth.

|
| (b) I got confused by the terms "asynchronous transaction" and
|     "notification transactions". Are these terms interchangeable?  If
|     yes, I suggest to pick just one (and in the case that every
|     asynchronous transactions leads to a notification message, I would
|     prefer the term notification transactions. But more important, the
|     relationship of these terms should be clarified.

The terminology in terms of "asynchronous transactions" and "notification
transactions" needs some shaping. We will fix this.

|
| (c) I also found the phrase "state transaction" in section 2.1.1 and
|     I guess you mean "state transition".

That's right.

|
| (d) I fail to parse the following sentence from section 2.1.3:
|
|        Policy rule groups can be used to indicate relationships
|        between policy rules and to simplify transactions on a set of
|        policy rules by using a single one per group instead of one per
|        policy rule.
|
|     What does "one" refer to?

It should refer to 'transaction'. Fixed.

|
| (e) Section 2.1.6 says:
|
|           - maximum number of simultaneous MIDCOM sessions
|             group
|
|     Perhaps "group" is just an editorial mistake?

Thanks, that's an error in the nroff source.

|
| (f) Section 2.1.8 says:
|
|        Support limitation may be different for different authenticated
|        agents.
|
|     Not sure I understand this right, but perhaps a wording such as the
|     following is clearer:
|
|        The set of announced supported transactions may be different
|        for different authenticated agents.

Sounds good!

|
| (g) The text in section 2.3 refers in three places to PLC but I think
|     it actually means RLC.

Yes, it is RLC. Fixed.

|
| (h) The text specifically talks about TCP and UDP. There are of course
|     more transports to consider. In fact, you may want to filter based
|     on the contained protocol number or something equivalent.

We tried to focus on TCP, UDP, and IP only, since most of the
NATs/Firewalls support only those. See the answer to Alain as well.

|
| (i) The last paragraph on page 26 refers to ARE notifications, which
|     are not defined in the document. Perhaps this should be ART (but I
|     am not totally sure).

This should be REN (Policy Rule Event Notification). Fixed.

|
| (j) Last paragraph in section 2.3.9: Change "After a the ..." to
|     "After the ..."

Fixed.

|
| (k) In several places, there is text like this:
|
|        After sending a success reply with a lifetime of zero, the
|        middlebox will consider the policy rule to be non-existent.  It
|        will not process any further transaction on this policy rule.
|
|     Lets assume I send to messages, one to change the lifetime to zero
|     followed by a request to retrieve the status. In this case, I
|     still expect to get a failure response to the second request and
|     so the request has to be processed - just the rule is gone. Or is
|     it really the intention that such requests are dropped and I have
|     to wait for some sort of a timeout?

You are right in the sense that the second request should result in
a negative response like "pr not available". The last sentence out of the
next above needs to be changed. Proposal: "Any further transaction
on this policy rule will result in a negative reply, indicating
that this policy rule does not exist anymore".

|
| (l) I think the decision to make the PRL/PRS and the GL/GS transaction
|     optional is not useful if you want a robust system. Further, for
|     debugging purposes, it is essential to be able to read the current
|     configuration. Just relying that the shared state between the
|     middlebox and the agent never gets out of sync won't work well in
|     the world I am familiar with.

Any other opinion? I'm fine with leaving them optional.

|
| (m) Does the PRS reply indeed cover all information? What about the
|     parity thing or the mode?

That's missing. Fixed.

|
| (n) Section 2.4.1 says:
|
|        Group transactions are declared as 'optional' by their
|        respective compliance entry in Section 3.  However, they
|        provide some functionality, that is not available if only
|        mandatory transactions are available.
|
|     I am wondering what this functionality is. My guess is that it all
|     boils down to atomicity of lifetime changes. If this is the case,
|     please say so. If not, explain what this extra functionality is.
|     (Or just remove the whole paragraph since the later text explains
|     the GLC in a bit more detail.)

We should mention what functionality. Atomicity is a point, another
is convenience for the agent in sending only one request.

|
| (o) The following text in section 2.4.2 seems to be a bit garbled:
|
|       failure reason:
|
|         - request identifier: an identifier matching the identifier of the
|           request.
|
|         - failure reason:
| 	- transaction not supported
|
|     I guess you wanted to say:
|
|       failure reason:
|
| 	- transaction not supported

That's a formatting error. Fixed.

|
| (p) My language parser failed on this text in secton 3.1:
|
|       met.  Also there still must exist a composed transaction consisting
|       of a sequence of transactions fine-grained transactions, which is
|       equivalent to a single transaction defined in this document, and for
|       which the atomicity requirement stated in Section 2.1.3 is met.
|
|       A compliant implementation
|
|     Note the phrase "sequence of transactions fine-grained transactions"
|     and the incomplete sentence.

Oh, this needs some hard rephrasing. Have to think about that.

|
| (q) Duplicate "to" in section 3.2.

Fixed.

|
| (r) Missing dot after the second sentence in section 5.3.1.

Fixed.

|
| (s) Capitalize "framework" in reference [MDC-FRM] if you choose to
|     capitalize things.

Fixed.

|
| (t) Would it make sense to say upfront that request identifier are
|     exchanged in request-response transactions so that they do not
|     have to be listed everywhere?

Should be written in the beginning. Fixed.

|
| Hope this helps.

Thanks a lot for reading and giving the feedback!

Martin

|
| /js
|
| - --
| Juergen Schoenwaelder		    International University Bremen
| <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen,
| Germany
|
| ------- End of Forwarded Message
|

Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  [email-masked]
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de

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