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

From: "Cedric Aoun" <[email-masked]>
Date: Thu, 3 Jul 2003 18:09:23 +0200

More comments:

Page 32,"The agent can use this transaction type to request
an extension the lifetime of an already established policy rule".
I would suggest rewording to:
the agent can use this transaction type to request the extension
of an already established policy rule's lifetime.

Page 33, "After a the remaining policy rule lifetime was successfully",
typo error need to remote "a"

page 41, "After a the remaining policy rule group lifetime was 
successfully" same as the previous typo error

page 43, "A compliant implementation" sentence is not complete

page 43, 3.2, "notification transaction if it is able to 
to generate the", typo error need to take out one "to"

page 44, 3.2, "A compliant middlebox implementation of a MIDCOM
protocol must inform the agent about the list of supported 
transactions within the SE". 
From where does the "MUST" come from, this is supposed to be a semantics
document ...
The capability information could be sent but it is based on local policies 
to determine if the supported capabilities are sent.

Cheers
Cedric

-----Original Message-----
From: Aoun, Cedric [GOLF:MA01:EXCH] 
Sent: 03 July 2003 16:15
To: [email-masked]
Subject: RE: Melinda Shore: [midcom] WG LAST CALL - semantics document

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... 
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. 
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. 
Page 6: By saying the source and the destination the direction is already
implied 
page 6, "semantics of the MIDCOM protocol is specified"; 
should be are specified 
page 7, "all negative  replies do just have two parameters"; 
suggest rewording to all negative  replies have only tow parameters 
page 7, "the list is not exclusive", I expect you meant exhaustive 
page 7, "State transitions are either initiated ...middlebox", 
this does not apply to what u refer as monitoring transactions 
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. 
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 
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 
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. 
Page 11, "maximum remaining lifetime of a policy rule or policy rule" 
u probably forgot the policy rule group ... 
page 12 "maximum number of simultaneous MIDCOM sessions group" 
here is were the group went to. 
Page 18: "traditional NAT", Suggest adding reference to RFC 3022 
page 18: "the enable action is interpreted as as bind", typo error remove an
"as" 
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. 
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. 
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) 
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) 
-----Original Message----- 
From: Melinda Shore [mailto:[email-masked]] 
Sent: 02 July 2003 15:28 
To: [email-masked] 
Subject: Melinda Shore: [midcom] WG LAST CALL - semantics document 

WG last call on this document closes tomorrow.  Please try 
to take a look and get comments to the mailing list by the 
end of the day tomorrow. 
Thanks, 
Melinda 

------- Forwarded Message 
Date:    Wed, 18 Jun 2003 11:11:16 -0400 
From:    Melinda Shore <[email-masked]> 
To:      [email-masked] 
Subject: [midcom] WG LAST CALL - semantics document 
The midcom semantics document is now in WG last call. 
*Please* give it a careful reading and bring any issues 
you identify to the mailing list. 
WG last call closes on Thursday, July 3. 
Thanks, 
Melinda 
- ------- Forwarded Message 
Date:    Wed, 18 Jun 2003 07:53:51 -0400 
From:    [email-masked] 
To:      IETF-Announce: ; 
cc:      [email-masked] 
Subject: [midcom] I-D ACTION:draft-ietf-midcom-semantics-03.txt 
- - --NextPart 
A New Internet-Draft is available from the on-line Internet-Drafts
directories. 
This draft is a work item of the Middlebox Communication Working Group of
the I 
ETF. 
        Title           : MIDCOM Protocol Semantics 
        Author(s)       : M. Stiemerling 
        Filename        : draft-ietf-midcom-semantics-03.txt 
        Pages           : 61 
        Date            : 2003-6-17 
        
This memo specifies semantics for a Middlebox Communication (MIDCOM) 
protocol to be used by MIDCOM agents for interacting with 
middleboxes, such as firewalls and NATs.  The semantics discussion 
does not include any specification of a concrete syntax or a 
transport protocol.  However, a concrete protocol is expected to 
implement the specified semantics or - more probably - a superset of 
it.  The MIDCOM protocol semantics is derived from the MIDCOM 
requirements, from the MIDCOM framework, and from working group 
decisions. 
A URL for this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-ietf-midcom-semantics-03.txt 
To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message. 
Internet-Drafts are also available by anonymous FTP. Login with the username

"anonymous" and a password of your e-mail address. After logging in, 
type "cd internet-drafts" and then 
        "get draft-ietf-midcom-semantics-03.txt". 
A list of Internet-Drafts directories can be found in 
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt 

Internet-Drafts can also be obtained by e-mail. 
Send a message to: 
        [email-masked]. 
In the body type: 
        "FILE /internet-drafts/draft-ietf-midcom-semantics-03.txt". 
        
NOTE:   The mail server at ietf.org can return the document in 
        MIME-encoded form by using the "mpack" utility.  To use this 
        feature, insert the command "ENCODING mime" before the "FILE" 
        command.  To decode the response(s), you will need "munpack" or 
        a MIME-compliant mail reader.  Different MIME-compliant mail readers

        exhibit different behavior, especially when dealing with 
        "multipart" MIME messages (i.e. documents which have been split 
        up into multiple messages), so check your local documentation on 
        how to manipulate these messages. 

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version of the 
Internet-Draft. 
- - --NextPart 
Content-Type: Multipart/Alternative; Boundary="OtherAccess" 
- - --OtherAccess 
Content-Type: Message/External-body; 
        access-type="mail-server"; 
        server="[email-masked]" 
Content-Type: text/plain 
Content-ID:     <[email-masked]> 
ENCODING mime 
FILE /internet-drafts/draft-ietf-midcom-semantics-03.txt 
- - --OtherAccess 
Content-Type: Message/External-body; 
        name="draft-ietf-midcom-semantics-03.txt"; 
        site="ftp.ietf.org"; 
        access-type="anon-ftp"; 
        directory="internet-drafts" 
Content-Type: text/plain 
Content-ID:     <[email-masked]> 
- - --OtherAccess-- 
- - --NextPart-- 

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

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

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

---

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

| Page 32,"The agent can use this transaction type to request
| an extension the lifetime of an already established policy rule".
| I would suggest rewording to:
| the agent can use this transaction type to request the extension
| of an already established policy rule's lifetime.

Done.

|
| Page 33, "After a the remaining policy rule lifetime was successfully",
| typo error need to remote "a"

Done.

|
| page 41, "After a the remaining policy rule group lifetime was
| successfully" same as the previous typo error

Done. (Looks like a typical 'a' error, jumping around in the document and
making fun ;-)

|
| page 43, "A compliant implementation" sentence is not complete

Actually a lot is missing, again nroff. Done.

|
| page 43, 3.2, "notification transaction if it is able to
| to generate the", typo error need to take out one "to"

Done.

|
| page 44, 3.2, "A compliant middlebox implementation of a MIDCOM
| protocol must inform the agent about the list of supported
| transactions within the SE".
| From where does the "MUST" come from, this is supposed to be a semantics
| document ...  The capability information could be sent but it is based on
| local policies  to determine if the supported capabilities are sent.

The middlebox must tell the agent which set of optional transaction are
supported. It is up to the middlebox to decided whether there are ten, one,
or zero optional capabilities listed. So it is indeed up to local policies.
See 2.1.8 "Support limitation may be different for different authenticated
agents".

Thanks Cedric for reading carefully the semantics document. I hope to
have even more reviews (and I see just now there are some on the way).

Cheers
Martin