Subject: RE: Melinda Shore: [midcom] WG LAST CALL - semantics document (fwd)

From: Martin Stiemerling <[email-masked]>
Date: Thu, 24 Jul 2003 15:03:22 +0200

Hi Cedric,

after long time here is finally a reply.

--On Donnerstag, 3. Juli 2003 16:15 +0200 Cedric Aoun
<[email-masked]> wrote:

|
| Hi,
| Here are my first comments, apologies if this is on several pages:
|
| -I mentioned several times on the list that the relation
| (what the framework defines as a Midcom session) between a
| Middlebox agent and a Middlebox is not necessarily built
| within the MIDCOM protocol.Since the document is a semantics
| document it should not impose the type of mechanisms used to
| build the relation but provide the type of information required
| to build the relation. It is not supposed to look at the
| detailed protocol design aspects and the messaging format...

As far as I can tell, does the session between the middlebox
and agent belong to the MIDCOM protocol. Therefore, the session
belongs in the semantics as well. See MIDCOM framework section 2.12.
and protocol requirements 2.1.9., both talk about MIDCOM protocol
and session. Furthermore says a statement in the framework
section 4 "MIDCOM Protocol":
"The MIDCOM protocol will consist of a session setup phase, run-time
session phase, and a session termination phase."
So the session is part of the protocol/semantics.

|
| Most of my other comments are minor issues:
|
| Page 6: the set of actions ...action enable".
|
| This may not seem very clear for readers not familiar to the topic.
| The condition is expressed by the filters;
| hence the actions applied on the packets matching the filters are
| not reserve; maybe command would fit better than action as people
| that will use this could get confused with the real actions
| being enforced on the packets.

I don't see the point. If someone is not familiar with the policy rule
wording, he or she should check the the reference RFC 3198. The paragraph
about the policy rule just clarifies what are conditions and what are
actions. If you know a better phrasing, let me know.

|
| Page 6: "the policy condition ...always true".
| What do we mean that the policy condition always true, it is
| obvious the creation of the NAT bind and the pinhole apply
| to the specific filter defined within the policy rule. Suggest taking
| this out.

This sentence is there to make a link to the policy rule definition. So
the reader can see that the condition mentioned in the policy rule
definition is always met in a policy reserve rule. Perhaps some more text
would be good. It is actually not quite obvious that a NAT binding is
create during the policy reserve rule, since this may depend on the NAT
implementation, i.e. some NATs may just block some ports for further use.

|
| Page 6: By saying the source and the destination the direction is already
| implied

That's true, but mentioning the address tuples (A0 to A3) at this point
is not be helpful for a reader. It will confuse more that it will help.
The directional part is needed in the policy rules.

|
| page 6, "semantics of the MIDCOM protocol is specified";
| should be are specified

The word 'semantics' is treated as singular as per definition of Oxford's
dictionary.

|
| page 7, "all negative  replies do just have two parameters";
| suggest rewording to all negative  replies have only tow parameters

done.

|
| page 7, "the list is not exclusive", I expect you meant exhaustive

Yes, should have been 'exhaustive'. Done.

|
| page 7, "State transitions are either initiated ...middlebox",
| this does not apply to what u refer as monitoring transactions

Right, should be note that this is not the case for monitoring
transactions. Done.

|
| Page 7, "establishment and termination of MIDCOM sessions".
| I have raised several times on the list and off the list, that
| the association of a MIDCOM agent and the Middlebox is not
| necessarily part of the protocol,  the document should clearly state that
| or align to that.

As written at the top of this email. We see that the session is part
of the semantics and protocol.

|
| Page 9, "there exist three message types: ... message type".
| Again this is optional, there is no reason to have this as part
| of the protocol

I do not see the point you are raising here. Would you mind to
explain in more detail?

|
| Page 10, "Their states are independent of each other ...can be
| separated".  One of the usefulness of having a state for a relationship
| between   an MA and MB is to delete all states installed by one MA when
| the  relation is no longer valid.
| Hence the states are a little bit dependent, which contradicts the
| current text

Of course there are some dependencies between all the state machines,
but this text is intended to show that changes in policy rule or
session state machine do not have any impact on the other state machine.
For instance, a session can be closed by an agent and the configured
policy rules are still in the middlebox (until they timeout). A change
in the policy rule state machine does not have any impact on the session.

|
| Page 11, as this document is supposed to be standard,
| I suggest that u reword this to be less familiar
| "Anyway, the configuration ...MIDCOM protocol semantics" to
| the configuration of authorization is out of scope of
| this document or something along these lines.

Sounds good and added. Done.

|
| Page 11, "maximum remaining lifetime of a policy rule or policy rule"
| u probably forgot the policy rule group ...

Looks like an error in the nroff source.
|
| page 12 "maximum number of simultaneous MIDCOM sessions group"
| here is were the group went to.

Same here, a line or two is gone. Will check the nroff source.

|
| Page 18: "traditional NAT", Suggest adding reference to RFC 3022

Thanks. Done.

|
| page 18: "the enable action is interpreted as as bind", typo error remove
| an "as"

Done.

|
| page 19: "the new group identifier is chosen by the middlebox",
| IMO it would be simpler to let the MA assign that as it could
| use the same identifier as the application session identifier
| that links all the media streams that require the operations
| by the MB. This will take out the need of doing a translation
| of identifiers at the MA. Although the current text  would make
| sense if there are several application sessions that are part
| of the group.

Only one owner can own a group. The identifier should be chosen
by the middlebox, since the middlebox has to keep track of all
groups and so the box can choose a convenient one.

|
| Page 22, "ANY" transport protocol parameter, I would suggest adding
| some clarification. u need to have both  a wildcard (i.e. all
| packets flowing between a set of addresses) and the ability
| to have a integer value that could be used to configure specific
| protocol types.u should also consider adding SCTP and DCCP as part of the
| defined  parameter values.

The use of SCTP and DCCP in NAT traversal was a controversial point
on the MIDCOM list sometime ago, without any clear consensus about
allowing SCTP and DCCP in MIDCOM or not. Pyda (NAT MIB) wrote that
there is no document for SCTP NAT traversal. The NAT MIB for example
does care about IP/ICMP/UDP/TCP.
The 'ANY' parameter value needs some explanation. My suggestion is to
change it to 'IP'; this would result in a firewall rule/NAT binding
of 'allow ip from x to y' and don't care about any other next header.

|
| page 31, "if an existing policy rule group is specified that is not
| owned by the requesting agent". You may want to mention that authorized
| Midcom agents could request the PER even if they weren't the
| creators of the PRR state (case of failover as u mentioned in a previous
| section)

In the failover case the agent must use the same identity/user as the
crashed agent. In section 2.1.5. it is stated that a rule (independent of
reserve or enable) is owned by only one agent.

|
| page 32, "However, in case of non-conflicting ...are accepted".
| Should state who owns the policy rule, in case one agent
| request its deletion but the other needs it, what happens? This doesn't
| fit in the  conflicting policy rules, as it was already accepted the
| conflict is on its  removal.Need to define what is the default behavior,
| last requestor rules (or other based on local policy)

Actually it may be that rules overlap, but this does not imply that there
is only one rule loaded in the middlebox. If two agents request overlapping
rules, and they are non-conflicting, two rules are loaded. If one agent
requests the deletion of its rule, its rule will be deleted. The other rule
remains as is.

Cheers
Martin

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