Skip to main content

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

Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke

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

Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
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
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