I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-sipcore-content-id-06 Reviewer: Elwyn Davies Review Date: 2017-06-22 IETF LC End Date: 2017-06-27 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits. There are a couple of minor issues related to the procedures after inappropriate usage of the new header. Major issues: None Minor issues: s3.4.1, last para: In line with the last sentence of Section 3.2, the Content-ID URL only needs to be unique within the SIP message where it occurs.  I assume it does not make sense to have a Content-ID header combined with a mutipart message-body (this isn't stated - maybe it should be); I am not sufficiently knowledgeable in this area of SIP to know if there could be content-id URLs in other headers if there is a Content-ID header in the message.  Thus either the statement about global uniqueness is irrelevant (as there is only one) and can be removed or it should be made consistent with s3.2 so that the Content URLs are unique within the message. Global uniqueness is neither possible or required.  s3.4.1, para 1: Following on from the previous comment: Is a UA allowed to add a Content-ID header to a message with a multipart message-body?  s3.4.1: What should a UA do if it receives a message with a Content-ID header when the message is not allowed to contain one?  Is there some generic error procedure that should be referenced?  s6.1: I started looking for specification that told me that items added to the SIP header fields registry effectively extend the definition of the message-header production in Section 25.1of RFC 3261.  Bit obvious perhaps, but it would be nice if it had been said somewhere!  Time for an Erratum perhaps?  Nits/editorial comments: Abstract:  I would suggest adding a sentence that clarifies what the update of RFC 5621 is modifying: OLD: The document also updates RFC 5621, to enable a Content-ID URL to reference a complete message-body and metadata provided by some additional SIP header fields. NEW: The document also updates RFC 5621, which only allows a Content-ID URL to reference a body-part that is part of a multipart message-body.  This update enables a Content-ID URL to reference a complete message-body and metadata provided by some additional SIP header fields. END s1.2, first bullet: s/for providing location/for providing location information/ s1.4.1: Need to expand UAC (User Agent Client) on first usage. s1.4.1, para 1: s/can be e.g. of/can be, for example, of/   s3.4.1: Need to expand UA (User Agent) on first usage (in section title). s4, NEW text: s/allow creating/allow the creation of/