Middlebox Communications (MIDCOM) Protocol Semantics
draft-ietf-midcom-semantics-08
Discuss
Yes
(Magnus Westerlund)
No Objection
(Bill Fenner)
(David Kessens)
(Jari Arkko)
(Jon Peterson)
(Mark Townsley)
(Ross Callon)
(Sam Hartman)
Abstain
(Lisa Dusseault)
No Record
Andy Newton
Charles Eckel
Christopher Inacio
Deb Cooley
Éric Vyncke
Gorry Fairhurst
Gunter Van de Velde
Jim Guichard
Ketan Talaulikar
Mahesh Jethanandani
Mike Bishop
Mohamed Boucadair
Roman Danyliw
Tommy Jensen
Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Andy Newton
No Record
Charles Eckel
No Record
Christopher Inacio
No Record
Deb Cooley
No Record
Éric Vyncke
No Record
Gorry Fairhurst
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
Ketan Talaulikar
No Record
Mahesh Jethanandani
No Record
Mike Bishop
No Record
Mohamed Boucadair
No Record
Roman Danyliw
No Record
Tommy Jensen
No Record
Cullen Jennings Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2007-05-30)
Unknown
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 Former IESG member
Yes
Yes
()
Unknown
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
Brian Carpenter Former IESG member
(was Discuss)
No Objection
No Objection
(2007-01-17)
Unknown
See Gen-ART review at http://www1.ietf.org/mail-archive/web/gen-art/current/msg01629.html
Dan Romascanu Former IESG member
(was Discuss)
No Objection
No Objection
(2007-01-11)
Unknown
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.
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
(2007-01-11)
Unknown
I have no problem with reclassifying this to PS, but I think we need to talk about the procedure to be used.
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2004-02-04)
Unknown
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/
Sam Hartman Former IESG member
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
No Objection
No Objection
(2007-01-10)
Unknown
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)?
Lisa Dusseault Former IESG member
(was Discuss)
Abstain
Abstain
()
Unknown