Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms
RFC 6216

Note: This ballot was opened for revision 09 and is now closed.

(Gonzalo Camarillo) Yes

(Alexey Melnikov) (was Discuss) Yes

Comment (2011-01-19 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
6.  Additional Test Scenarios

      *  assure that the most specific CommonName in the Subject field
         matches if there are no dNSName entries in the subjectAltName
         at all (which is not the same as there being no matching
         dNSName entries).  This match can be either exact, or against
         an entry that uses the wildcard matching character '*'

Anywhere in the domain pattern or only in the leftmost position?

Nits: The usual (many acronyms are not spelled out on first use, etc.)

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Russ Housley) No Objection

(Dan Romascanu) No Objection

Comment (2011-01-18 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The 'Observed Interoperability Issues' section includes a number of example of implementation problems detected during the SIPit events. I can guess that this information canges in time, as interoperability problems due to implementation bugs or lack of clarity in documents are in the majority of the cases being fixed in the coming releases of the implementations. For this purpose it would be useful I think to mention what is the time reference (may be the indication of the SIPit event) when the problems were detected. 

(Peter Saint-Andre) No Objection

Comment (2011-01-18 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
This is a fine document. My only nits are:

1. Some of the acronyms are not expanded on first use.

2. There are some trifling typos (e.g., "particulary").

3. Some of the terms are used inconsistently or casually (e.g., "subjAltName" when "subjectAltName" is meant; it might be even better to re-use the terminology from draft-saintandre-tls-server-id-check).

4. No rules are provided regarding the process of matching IP addresses (e.g., matching of IPv4 addresses vs. IPv6 addresses); however, because use of IP addresses is deemed inadvisable, the lack of rules probably does not have implications for interoperability.

(Sean Turner) (was Discuss) No Objection

Comment (2011-01-20)
No email
send info
Appendix A: Add an informative reference to PKCS#8 [RFC5958].

ASN.1 dumps: The "hority" wraps around the line oddly.

Section 5: Is it worth noting that the SHA2 algs also say don't include the parameters according to [RFC5754].

(Robert Sparks) Recuse