Middlebox Communications (MIDCOM) Protocol Semantics
draft-ietf-midcom-semantics-08

[Ballot discuss]
In Prague we talked about some easy changes to clear my discuss and I thought we agreed to do theses but I don't see them here. Do you disagree with my Discuss ? If so I don't think I have any email form anyone on that. If not, do you think this document resolves it and I am just missing it?

To repeat, my discuss is: The example has a SIP proxy modifying bodies is explicitly forbidden by RFC 3261 and a really bad idea.

[Ballot discuss]
This RFC is not on its own qualified for the Standards Track.  It would be better for the documents that reference RFC3989, that need to be on the Standards Track, to import the few things needed rather than promote this to the Standards Track.

My reasons for considering this RFC more appropriate where it is, at Informational:
- no MUST language, thus the requirements that would be imported by referring documents is quite unclear
- implementation/deployment plans are not there
- I don't think the security and transport MTI meets our policy requirements
- I don't understand how midcom-mib can work for all possible protocols that implement the semantics outlined in RFC3989, whether there are any already standardized, etc.

Since this is a disconsolate discuss, I'm turning this into an abstain.

[Ballot discuss]
This RFC is not on its own qualified for the Standards Track.  It would be better for the documents that reference RFC3989, that need to be on the Standards Track, to import the few things needed rather than promote this to the Standards Track.

My reasons for considering this RFC more appropriate where it is, at Informational:
- no MUST language, thus the requirements that would be imported by referring documents is quite unclear
- implementation/deployment plans are not there
- I don't think the security and transport MTI meets our policy requirements
- I don't understand how midcom-mib can work for all possible protocols that implement the semantics outlined in RFC3989, whether there are any already standardized, etc.

[Ballot discuss]
I'd like to discuss before entering a real vote
- the implementation and deployment status of this area of work
- how this is supposed to be evaluated in terms of interoperability on the Standards Track

[Ballot comment]
Following advice from Sam and Brian, I cleared the DISCUSS and change this part of the DISCUSS to a COMMENT.

If this document becomes standards track it seems to me that requirements like those in Section 3.1 need to follow the rules of key-words capitalization as per RFC 2119. This could be solved in RFC Editor notes.

[Ballot discuss]
1. It is not clear to me to what extent this procedure is consistent to RFC 2026. A document can be approved as Informational without an IETF Last-Call. I do not know if this was the case with RFC 3989, but I do not understand how this procedure does not become a precedent for documents being approved first as Informational, and then re-classified by the IESG as Standards Track, without meeting the requiremnt for community review described in Section 6.1.2 of RFC 2026. It was mentioned during the discussion that this procedure was used in the past, so the issue may have been discussed in the past and there are good arguments, so I am open to clear this part of the DISCUSS if I get convinced that the process is consistent

2. If this document becomes standards track it seems to me that requirements like those in Section 3.1 need to follow the rules of key-words capitalization as per RFC 2119. This could be solved in RFC Editor notes.

[Ballot discuss]
This can't be done without issuing a new RFC with the standards track boilerplate. Otherwise, we would have a document on the standards
track that has these words on its first page:

  This memo provides information for the Internet community.  It does
  not specify an Internet standard of any kind.

What I believe we have to do is to approve the reclassification
AND instruct the RFC Editor to perform this by issuing a new RFC
that obsoletes 3989, and differs from it only by carrying the
current boilerplate for a standards track document and the current
date.

[Ballot discuss]
The example has a SIP proxy modifying bodies with is explicitly forbidden by RFC 3261 and a really bad idea. I really don't look forward to a PS that has that. I imagine this could be fixed with an RFC Editor comment. I'd like to talk about options on the call.

The good news is, I think this makes it clear how to solve Brian's discuss.

[Ballot comment]
I don't understand Brian's approach here.  The RFC Editor cannot change the date and boilerplate on a document and retain the RFC's series' presumption that a document, once issued, is permanent in that form.  Is this a suggestion to re-issue with a new number and those changes?

I also believe that we have re-classified documents in the past (certainly we move them to historic regularly), so I do not believe that the issues he raises are necessarily show stoppers.  Can't we allow the external pointers to change without the text changing (if necessary, adding something to the errata to clarify the issue)?

[Ballot discuss]
This can't be done without issuing a new RFC with the standards track boilerplate. I'd be satisfied with an instruction to the RFC Editor to do so, with no other changes except the date and current boilerplate.

[Ballot comment]
The DISCUSS comment from -07 has been addressed - the "type of middlebox" field is now gone, replaced with a set of capabilities.
This clears my DISCUSS.

[Ballot comment]
>                              abstraction that enables communcation

Run through spell

>    sending a reply message on the actual state transition, in latter
>    case the middlebox sends an unsolicited asynchronous notification

s/in latter/in the latter/

>    Request and reply messages contain an agent unique request identifier

s/agent unique/agent-unique/

>    middlebox.  If an optional transactions is implemented in the
s/transactions/transaction/

>    the last one is a asynchronous transaction initiated by the
s/a/an/

[Ballot comment]
Bottom of page 9 abbreviation/acronym conflict?:
  For notification messages, there exist three message types: the
  Session Termination Notification (STN) message type, the Policy Rule
  Event Notification (REN) message type and the Group Event
                      ^^^^^
  ... snip ..

  PEN  The Policy Rule Event Notification message contains the
  ^^^^^
        notification identifier, a policy rule identifier and the

later on in the text it seems that REN is used a few more times.

Need to use xxx.examle.com for exampls instead of mb.com and B@b.de.
  pn page 52 and following pages

Incorrect citation on page 63:
  Therefore, the UNSAF considerations of [RFC2424] do not apply
Should be RFC3424!
In fact, the text would read better as:
  Therefore, this document addresses the UNSAF considerations in
  [RFC3424] by proposing a longterm alternative solution.

---

Additional comments from MIB Doctor review

1. Section 7, page 64

OLD

  Therefore, the UNSAF considerations of [RFC2424] do not apply.

NEW

  Therefore, the UNSAF considerations of [RFC3424] do not apply.

2. Section 4.2 refers specifically to SIP traversal, and the
example makes usage of SIP messages. I think that an
Informative reference to RFC 3261 could help.

[Ballot comment]
Bottom of page 9 abbreviation/acronym conflict?:
  For notification messages, there exist three message types: the
  Session Termination Notification (STN) message type, the Policy Rule
  Event Notification (REN) message type and the Group Event
                      ^^^^^
  ... snip ..

  PEN  The Policy Rule Event Notification message contains the
  ^^^^^
        notification identifier, a policy rule identifier and the

later on in the text it seems that REN is used a few more times.

Need to use xxx.examle.com for exampls instead of mb.com and B@b.de.
  pn page 52 and following pages

Incorrect citation on page 63:
  Therefore, the UNSAF considerations of [RFC2424] do not apply
  Should be RFC3424!

---

Additional comments from MIB Doctor review

1. Section 7, page 64

OLD

  Therefore, the UNSAF considerations of [RFC2424] do not apply.

NEW

  Therefore, the UNSAF considerations of [RFC3424] do not apply.

2. Section 4.2 refers specifically to SIP traversal, and the
example makes usage of SIP messages. I think that an
Informative reference to RFC 3261 could help.

[Ballot comment]
Bottom of page 9 abbreviation/acronym conflict?:
  For notification messages, there exist three message types: the
  Session Termination Notification (STN) message type, the Policy Rule
  Event Notification (REN) message type and the Group Event
                      ^^^^^
  ... snip ..

  PEN  The Policy Rule Event Notification message contains the
  ^^^^^
        notification identifier, a policy rule identifier and the

later on in the text it seems that REN is used a few more times.

Need to use xxx.examle.com for exampls instead of mb.com and B@b.de.
  pn page 52 and following pages

Incorrect citation on page 63:
  Therefore, the UNSAF considerations of [RFC2424] do not apply
  Should be RFC3424!

[Ballot comment]
Should SCTP support be mandated?  Put another way, is SCTP a first-class transport protocol that should be supported in all appropriate ways in IETF protcols?

The description of a group says that membership is the only attribute.  Surely lifetime is another attribute, since it's manipulable?

[Ballot comment]
Please change 'IPSEC' to 'IPsec' throughput the document.

  Section 5.3.3 states the need for authentication, but this is not sufficient.
  Integrity is needed in addition to authentication.  This is just as just a
  request for better documentation, as both TLS and IPsec provide integrity.

  Section 5.3.4: s/TLS or IPSEC encryption/TLS or IPsec protection/

[Ballot comment]
Please change 'IPSEC' to 'IPsec' throughput the document.

  Section 5.3.3 states the need for authentication, but this is not sufficient.
  Integrity is needed in addition to authentication.  This is just as just a
  request for better documentation, as both TLS and IPsec provide integrity.

  Section 5.3.4: s/TLS or IPSEC encryption/TLS or IPsec protection/

[Ballot comment]
Please change 'IPSEC' to 'IPsec' throughput the document.

  Section 5.3.3 states the need for authentication, but this is not sufficient.
  Integrity is needed in addition to authentication.  This is just as just a
  request for better documentation, as both TLS and IPsec provide integrity.

  Section 5.3.4: s/TLS or IPSEC encryption/TLS or IPsec protection/

[Ballot discuss]
The last paragraph of the security considerations (section 6) says that
  the secure configuration is too restrictive for use with real protocols
  like SIP.  So, what settings provide an acceptable balance between
  security and working communications?

[Ballot comment]
Further comments from Spencer Dawkins, Gen-ART reviewer:

There's a minor editing pass waiting ("This memo suggests a
semantics for the MIDCOM protocol" in the second paragraph, so I quit reading
for typos), but I ignored this in my review below.

Basics - "This draft is on the right track but has open issues,
described in the review".

The real challenge for the authors was trying to abstract principles
from the middleboxes that are deployed today, and they did this
pretty well.

Minor comments:

Mystery - 2.2.1 - Shows a "MIDCOM protocol version" parameter - is
this in addition to any version number on the specific protocol used
to provide MIDCOM communication?

Robustness - 2.2.4 - Is the intention here to minimize state on the
middlebox? Tearing down sessions when a connection is interrupted
seems to beg for keep-alives. If I understand correctly, the MIDCOM
connection is experiencing the problem, but the "end-to-end"
connection supported by MIDCOM may be idle - why tear it down, if
you could put things back together before the end-to-end connection
becomes active?

Nit - 2.3.5 - The TCP "first packet" has SYN set, and ACK not set.
Meta-sigh - why are port numbers part of the transport header? I
understand that MIDCOM needs to talk about port numbers, but
awareness of transport protocols seems to make deploying SCTP, DCCP, etc. more
difficult...

[Ballot discuss]
The semantics of the "type of middlebox" seem somewhat weakly described.
From Spencer Dawkins, Gen-ART reviewer:

Architecture, Interoperability - 2.1.6 Middlebox Capabilities - I'd
like to see more thought given to "type of the middlebox". In
particular, what matters is capabilities, not device categories.
What I see deployed today is a seemingly-endless variety of transparent
middleboxes. If faced with a list of "things that the box does", a
client could base actions on the items on the list that it
recognizes.
If faced with a type-of-middlebox = Flatula, the client has no idea
what to do next, even if a Flatula middlebox provides many
capabilities that the client does know about because they are also
provided by other types of middleboxes. I'm not saying showstopper,
but I expect this would lessen deployability down the road (new type
of middlebox, but widely deployed clients don't support it for a
year). This complexity ripples (see 2.3.2, where the type of
middlebox affects the IP addresses that are reserved).

This is (in my, Harald's opinion) design decisions that may be justified, but the justification is not easy to see from the document.

[Ballot comment]
Further comments from Spencer Dawkins, Gen-ART reviewer:

There's a minor editing pass waiting ("This memo suggests a
semantics for the MIDCOM protocol" in the second paragraph, so I quit reading
for typos), but I ignored this in my review below.

Basics - "This draft is on the right track but has open issues,
described in the review".

The real challenge for the authors was trying to abstract principles
from the middleboxes that are deployed today, and they did this
pretty well.

Minor comments:

Mystery - 2.2.1 - Shows a "MIDCOM protocol version" parameter - is
this in addition to any version number on the specific protocol used
to provide MIDCOM communication?

Nit - 2.3.5 - The TCP "first packet" has SYN set, and ACK not set.
Meta-sigh - why are port numbers part of the transport header? I
understand that MIDCOM needs to talk about port numbers, but
awareness of transport protocols seems to make deploying SCTP, DCCP, etc. more
difficult...

[Ballot comment]
Further comments from Spencer Dawkins, Gen-ART reviewer:

Mystery - 2.2.1 - Shows a "MIDCOM protocol version" parameter - is
this in addition to any version number on the specific protocol used
to provide MIDCOM communication?

Nit - 2.3.5 - The TCP "first packet" has SYN set, and ACK not set.
Meta-sigh - why are port numbers part of the transport header? I
understand that MIDCOM needs to talk about port numbers, but
awareness of transport protocols seems to make deploying SCTP, DCCP, etc. more
difficult...

[Ballot discuss]
The semantics of the "type of middlebox" seem somewhat weakly described.
From Spencer Dawkins, Gen-ART reviewer:

Architecture, Interoperability - 2.1.6 Middlebox Capabilities - I'd
like to see more thought given to "type of the middlebox". In
particular, what matters is capabilities, not device categories.
What I see deployed today is a seemingly-endless variety of transparent
middleboxes. If faced with a list of "things that the box does", a
client could base actions on the items on the list that it
recognizes.
If faced with a type-of-middlebox = Flatula, the client has no idea
what to do next, even if a Flatula middlebox provides many
capabilities that the client does know about because they are also
provided by other types of middleboxes. I'm not saying showstopper,
but I expect this would lessen deployability down the road (new type
of middlebox, but widely deployed clients don't support it for a
year). This complexity ripples (see 2.3.2, where the type of
middlebox
affects the IP addresses that are reserved).

Also from Spencer Dawkins:

Robustness - 2.2.4 - Is the intention here to minimize state on the
middlebox? Tearing down sessions when a connection is interrupted
seems to beg for keep-alives. If I understand correctly, the MIDCOM
connection is experiencing the problem, but the "end-to-end"
connection supported by MIDCOM may be idle - why tear it down, if
you could put things back together before the end-to-end connection
becomes active?

Both of these are (in my, Harald's opinion) design decisions that may be justified, but the justification is not easy to see from the document.