Middlebox Communications (MIDCOM) Protocol Semantics

Summary: Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass.

(Cullen Jennings) Discuss

Discuss (2007-05-30)
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.

(Magnus Westerlund) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

(Brian Carpenter) (was Discuss) No Objection

Comment (2007-01-17)
No email
send info

Lars Eggert No Objection

Comment (2007-01-11)
No email
send info
I have no problem with reclassifying this to PS, but I think we need to talk about the procedure to be used.

(Bill Fenner) No Objection

(Ted Hardie) No Objection

Comment (2007-01-10)
No email
send info
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)?

(Sam Hartman) No Objection

(Russ Housley) No Objection

Comment (2004-02-04)
No email
send info
  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/

(David Kessens) No Objection

(Jon Peterson) No Objection

(Dan Romascanu) (was Discuss) No Objection

Comment (2007-01-11)
No email
send info
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.

(Mark Townsley) No Objection

(Lisa Dusseault) (was Discuss) Abstain

Roman Danyliw No Record

Martin Duke No Record

Benjamin Kaduk No Record

Erik Kline No Record

Murray Kucherawy No Record

Warren Kumari No Record

Francesca Palombini No Record

Alvaro Retana No Record

Zaheduzzaman Sarker No Record

John Scudder No Record

Martin Vigoureux No Record

Éric Vyncke No Record

Robert Wilton No Record