IETF conflict review for draft-hartmann-default-port-for-irc-via-tls-ssl
Note: This ballot was opened for revision 00 and is now closed.
Ballot question: "Is this the correct conflict review response?"
(Robert Sparks) Discuss
This document currently claims to Update RFCs 2812 and 2813, which are IETF stream documents that went through a Last Call. It's not clear it actually does, and that these are meant as "see also". If that's right, I suggest we ask these be removed. If that's not right, and these actually do update those RFCs, we should discuss whether this document is in the correct stream.
Barry Leiba Yes
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
I agree with Robert's Discuss. I also have concerns about giving this document any status with the port number included until it has been through port number review by the designated experts since this may precipitate a collision in the wild.
(Gonzalo Camarillo) No Objection
(Benoît Claise) No Objection
(Ralph Droms) No Objection
(Wesley Eddy) No Objection
(Adrian Farrel) No Objection
(Stephen Farrell) (was Discuss, Yes) No Objection
The authors changed the UPDATEs stuff so the 5742 review is now ok.
(Brian Haberman) No Objection
(Russ Housley) No Objection
(Pete Resnick) No Objection
(Martin Stiemerling) No Objection
In support of Robert's DISCUSS.
(Sean Turner) No Objection
Note that if this document had come through the IETF stream I probably would have asked for a bit more information about the certificates: s2.3.1/2: why only common name what about putting the FQDN/nick in the subject alt extension? s2.3.1/2: when you say should verify that the certificate validates back to an installed Trust Anchor as in [RFC5280]? s2.3.2: Should the server also verify the client's cert? WRT to naming matching should RFC 6125 be followed?