Authenticated Identity Management in the Session Initiation Protocol (SIP)
RFC 8224

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

(Ben Campbell) Yes

Comment (2016-11-02 for -15)
No email
send info
Thanks for this work. I'm balloting  yes, but have a few minor comments and questions:

Substantive:

- 6.2, step 4:  This says that if the full form of passport is included, and the Date header and iat do not match, use iat if it is fresh. I'm curious why not just use iat in the first place? What should one do if Date is fresh, but iat is not?

-6.2.2: This section recommends specific result code reason phrases for a couple of circumstances. I assume the idea is that one should use a "helpful" reason phrase, and these are examples of phrases helpful for the circumstances. But it reads as if you mean to standardize those specific reason phrases.  If the intent is really to offer examples, please clarify. I'd hate to see us back in the days of commonly seeing SIP code break due to unexpected reason phrases.

- 7.2: The first sentence says verifiers must have a way to acquire and _retain_ certificates. Why must they have a way to retain them? The last paragraph in the section says they might wish to have a way to retain certs, but doesn't seem to require it.

-- Is there any concern that the requirement to be able to dereference effectively arbitrary URLs in "info" parameters could become a DOS attack vector? E.g. info parameters that point to HTTP URIs that never respond, respond very slowly, or return huge and/or corrupt certs?

-13.1 and 13.2: Is there a reason not to retarget the references in the IANA entries for the Identity header field and for the error codes from 4474 to [RFCThis]?

Editorial:

- 4.1.1, example: I assume the backslashes indicate line folding for documentation purposes only. It might be worth mentioning that.

- 6.1, step 4, last paragraph: Is the reference to section 9 mean that section of _this_ document, or that section of stir-passport?

- 7.1, 2nd paragraph: It seems odd to use 2119 MUSTs in examples of policies that authenticator services might have.

-8.1, third paragraph: s/exampple/example

Alissa Cooper Yes

(Jari Arkko) No Objection

Comment (2016-11-03 for -15)
No email
send info
Upcoming (minor) comments from Vijay's Gen-ART review may be interesting to look at by the authors. The comments are about to arrive.

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) (was Discuss) No Objection

Suresh Krishnan No Objection

Mirja K├╝hlewind No Objection

Comment (2016-11-01 for -15)
No email
send info
One minor comment:
Not sure how the solution with "ppt" field came up for extensibility. Wouldn't it make sense to have a version field instead that always has to be presented (or if not present is assumed to be 0); just to reduce implementation complexity. Or am I missing something? Just wondering... btw. what does 'ppt' stand for?

(Added later)

Now I have read draft-ietf-stir-passport. So it clear why this method is used. Didn't realize that the following sentence means 'please check PASSporT for further questions...': "this specification specifies an optional "ppt" parameter of the Identity header field, which mirrors the "ppt" header in PASSporT." Maybe just give a more specific reference including the section refernce.

(Terry Manderson) No Objection

Alexey Melnikov No Objection

Comment (2016-11-02 for -15)
No email
send info
This is a well written document (despite giving too many deployment choices in some areas). I have a short list of small issues/nits:

In Section 4: ABNF for the signed-identity-digest allows empty string? Is this intentional? If not, maybe use "1*" in front?

In Section 5.1: are you missing an empty line between the header and the SDP payload?

In Section 6.2.2: is it customary in SIP to use the human readable portion of error responses?

In Section 7.4: HTTP URIs need a reference.

In Section 8.4: URI-ID from RFC 6125 can be used for the subdomain case as well?

(Kathleen Moriarty) No Objection

Comment (2016-11-02 for -15)
No email
send info
Thanks for a well written document.  Just one comment, I would have liked to have seen section 10 much sooner in the document, maybe in the introduction as changes are usually up front.

Alvaro Retana No Objection