Re: [Insipid] Alissa Cooper's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)

["Dawes, Peter, Vodafone Group" <[e-mail]>]

Hello Alissa,

Thanks for your review comments for the draft, in-line below are our proposed resolutions. Some of the section numbers are different from version -12 because the -13 we have prepared (not yet submitted) has some restructuring.


Best regards,

Peter and Arun



>S 3.7:

>   "As described

>   in [RFC7989] section 6, related dialogs can occur when an endpoint

>   receives a 3xx message, a REFER that directs the endpoint to a

>   different peer, or an INVITE request with Replaces that also

>   potentially results in communicating with a new peer."

>

>To avoid help discourage overbroad logging, this would be better if

>it normatively limited the set of what may be considered "related

>dialogs" to what is listed here, rather than saying "can occur."

>



We have described related dialogs more fully as below and state that they are limited to call control features, but we don’t think it’s possible to normatively limit the definition to a specific list of cases as many call control features are possible.



3.7.  Marking Related Dialogs



   "Log me" marking is done per-dialog and typically begins at dialog

   creation and ends when the dialog ends.  However, dialogs related to

   a "log me" marked dialog MAY also be "log me" marked for call control

   features such as call forward, transfer, park, and join.  As

   described in [RFC7989] section 6, related dialogs can occur when an

   endpoint receives a 3xx message, a REFER that directs the endpoint to

   a different peer, or an INVITE request with Replaces that also

   potentially results in communicating with a new peer, or an INVITE

   with a Join header field as described in [RFC3911].  An example is

   call transfer described in section 6.1 of [RFC5589] and the logged

   signaling for related dialogs can be correlated using Session-ID

   values as described in section 10.9 of [RFC7989].



>S 4.3:

>If intermediaries are going to be authorized to insert "log me" on

>behalf of UAs, was any consideration given to providing support for

>UAs to be able to insert "do not log me"? I realize this is a

>different use case -- not where the UA isn't adding new functionality

>specified in this document, but rather where it is -- but it seems

>like it might be warranted if having intermediaries insert "log me"

>is going to be a sanctioned practice.

>

>Note that there could be multiple plausible semantics of "do not log

>me" worth supporting: telling intermediaries not to turn on "log me"

>or telling the terminating user agent not to log.

>



Network administrator authorization is needed to enable “log me”, and the default is “do not log me” even if a UA supports “log me”. We have re-worded the second paragraph of 5.2.2. to make this clear as follows:



   Another use case is a network in which some but not all endpoints

   support "log me" marking that wants to avoid treating endpoints

   differently by always managing "log me" marking at a SIP

   intermediary.  In this case, the endpoint that supports "log me" is

   not configured to mark a dialog, instead the SIP intermediary is

   configured to perform "log me" marking on behalf of that endpoint.

   This case still requires authorization as described in Section 7.1.

   This SIP intermediary MAY optionally mark a request or response

   towards the endpoint, such as the 100 response F3 in Figure 3.  The

   endpoint will receive a "log me" marker mid-dialog and this is not

   considered an error.





>S 4.6:

>"Any previously logged messages SHOULD be

>   retained and not deleted."

>

>I think this needs to say "in accordance with the limitations set out

>in Section 8.4.5."



We modified the second paragraph in 5.3 as follows:



   If a missing marker error is detected by a UA, SIP intermediary, or

   B2BUA, it SHOULD consider this as an error condition in the "log me"

   functionality.  It MUST NOT mark subsequent requests and responses

   and MUST stop logging messages in the same dialog.  Any previously

   logged messages SHOULD be retained, for the time period defined in

   Section 8.5, and not deleted.





________________________________
From: Alissa Cooper <[e-mail]>
Sent: 16 August 2018 02:12
To: The IESG
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Alissa Cooper's No Objection on draft-ietf-insipid-logme-marking-12: (with COMMENT)

Alissa Cooper has entered the following ballot position for
draft-ietf-insipid-logme-marking-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-marking/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

S 3.7:
"As described
   in [RFC7989] section 6, related dialogs can occur when an endpoint
   receives a 3xx message, a REFER that directs the endpoint to a
   different peer, or an INVITE request with Replaces that also
   potentially results in communicating with a new peer."

To avoid help discourage overbroad logging, this would be better if it
normatively limited the set of what may be considered "related dialogs" to what
is listed here, rather than saying "can occur."

S 4.3:
If intermediaries are going to be authorized to insert "log me" on behalf of
UAs, was any consideration given to providing support for UAs to be able to
insert "do not log me"? I realize this is a different use case -- not where the
UA isn't adding new functionality specified in this document, but rather where
it is -- but it seems like it might be warranted if having intermediaries
insert "log me" is going to be a sanctioned practice.

Note that there could be multiple plausible semantics of "do not log me" worth
supporting: telling intermediaries not to turn on "log me" or telling the
terminating user agent not to log.

S 4.6:
"Any previously logged messages SHOULD be
   retained and not deleted."

I think this needs to say "in accordance with the limitations set out in
Section 8.4.5."