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

From: Melinda Shore <[email-masked]>
Date: Mon, 28 Jul 2003 10:50:01 -0400

Another SIRS review.

Melinda

------- Forwarded Message

Date:    Thu, 24 Jul 2003 08:57:25 +0200
From:    Juergen Schoenwaelder <[email-masked]>
To:      Melinda Shore <[email-masked]>
cc:      [email-masked]
Subject: Re: [ietf-sirs] Review request

On Mon, Jul 21, 2003 at 06:11:30AM -0400, Melinda Shore wrote:

> I'd like to request a review of
> http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-03.txt.
> The document has gone through wg last call with only one set
> of comments returned, and we need a more thorough review
> with an eye towards the question of whether or not the
> document is sufficiently mature to send to the IESG.

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.

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.

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

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

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

(e) Section 2.1.6 says:

          - maximum number of simultaneous MIDCOM sessions
            group

    Perhaps "group" is just an editorial mistake?

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

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

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

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

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

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

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

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

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

(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

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

(q) Duplicate "to" in section 3.2.

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

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

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

Hope this helps.

/js

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

------- End of Forwarded Message

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