Subject: [midcom] Comments On The Semantics Draft

From: Tom Taylor <[email-masked]>
Date: Wed, 26 Mar 2003 22:25:00 -0500

It may look odd for me as co-author to be commenting on this draft, but Martin and 
Juergen didn't have time to wave the latest version past me before submitting it.

I've submitted a bunch of purely editorial markup directly to them.

Section 2.1.2 Atomicity:
-------------------------
The last sentence of the first paragraph reads:
   "However, asynchronous notification transactions may interrupt and terminate
    processing of a request at any time."

This is not quite accurate -- it seems to imply that the middlebox receives 
asynchronous notification transactions rather than generating them.  I suggest the 
following instead: "However, events other than the receipt of requests may interrupt 
processing of a request, influence the outcome of that request, and cause the 
middlebox to generate an asynchronous notification before responding to the request."

It is clear from text in 2.2.3 that some requests are never answered (e.g. those 
queued for processing when a session is terminated).  I suppose it is unnecessary to 
go into the detail of whether a request on which processing has begun may not 
terminate in a response.

Section 2.2.1 Session Establishment
-----------------------------------
If the agent needs to know the middlebox's functions, they are probably best 
expressed as a set drawn from {firewall, NAT, PT}.  Per Bob Cunningham's point, we 
probably also have to indicate twice-NAT capability.

Section 2.2.4 Session Termination By Interruption Of Connection
---------------------------------------------------------------
I don't think MIDCOM should be tied to transport at the level of semantics: this is 
a protocol issue.  I think this section should be deleted.

Section 2.3.5  Address Parameter Constraints
--------------------------------------------
We have now determined that the third paragraph of this section, stating: "The 
specified IP address cannot be wildcarded.", should be changed.

Further down, this section assigns a meaning to port value zero.  Since this is a 
description of semantics rather than an actual protocol, an abstract value such as 
'ANY' should be used.

The same paragraph ends: "Depending on the value of the transport protocol 
parameter, this parameter may truly refer to ports, or may refer to an equivalent 
concept."  This is inconsistent with the preceding paragraph, where it is stated 
that port is irrelevant for the transport protocol value ANY.  I would suggest 
keeping this latter statement, as the path of least resistance.  We can always 
provide details for particular protocols later.

Section 2.3.6 Policy Reserve Rule (PRR)
---------------------------------------
Specific address values are given to represent unassigned addresses.  For a semantic 
description, an abstract value such as 'UNASSIGNED' should be used.

Section 2.3.7 Policy Enable Rule (PER)
--------------------------------------
I note that the group number is assigned independently of the group number of any 
predecessor reserve rule, rather than being inherited from the reserve rule.  Does 
this make sense to people?

Section 2.3.9 Policy Rule Status (PRS)
--------------------------------------
There should be text added for the direction reply parameter, indicating that it 
appears only for enable rules.

Section 2.3.11 Policy Rule State Machine
----------------------------------------
Given the separation of the reserve rule from its successor enable rule in the 
preceding text, we actually need to portray two different state machines, possibly 
interlinked.  Alternatively, since the diagram actually shows the states of a PRID 
rather than a rule, the "may" stated for reuse of PRID in going from reserve to 
enable rule could be made a MUST.  Then only one state machine would be required.

Section 2.4.2 Group Lifetime Change (GLC)
-----------------------------------------
We might want to add text noting that setting a group lifetime to zero will cause 
the middlebox to send Asynchronous Policy Rule Deletion (ARD) notifications for all 
of the rules concerned, to all agents allowed access to those rules.  This is 
obviously something that can be optimized in a concrete protocol realization.

Tom Taylor

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