Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs

["Paul Giralt (pgiralt)" <[e-mail]>]

Some feedback on this document

Section 5.1: I didn’t quite understand the point of this section. Shouldn’t configuration be totally out of scope of the document? I didn’t feel like this section added any value to the document.

Section 5.2: Perhaps mention that another criteria a proxy or UA can use is a calling / called party number. This actually seems like the most likely scenario for troubleshooting.

Section 5.7: Should this be a normative statement? (e.g. An intermediary forking a request MUST copy log-me markings to all forked requests).

Section 5.8.3.1: I’m confused about this section. What does “controlled by explicit configuration of the originating side” mean? I would think signaling-only B2BUAs should still copy log-me markings from originating to terminating by default. I’m thinking the situation of a soft-switch in an SP network acting as a signaling-only B2BUA as opposed to a proxy or proxy-B2BUA (7092 is not very clear as to which one a soft switch falls into). In such a scenario, the desired behavior would be to always copy log-me from originator to terminator.

But then in Section 5.8.4, the reader is referred back to 5.8.2/3 for how to behave even if they are media terminating. This type of B2BUA would more likely be an SBC where a network operator might want to filter out log-me messages because they act as a trust boundary in which case the forwarding from originating to terminating should be configurable.

Section 5.9.1 and 5.9.2: The references to 7206 should be replaced with the RFC number assigned to [draft-ietf-insipid-session-id-27]/ 7206 doesn’t actually define the Session-ID header.

Section 5.9.2: A Session-ID may change within the same dialog due to protocol interworking somewhere further downstream. Is the intention really for this to generate a separate log file? How does this affect the requirement that a new logging session cannot start mid-dialog? From the perspective of the device doing the logging, the dialog may not have changed, but the Session-ID changed.

Section 6.2.1: What determines whether a marker has been “incorrectly inserted”?

Section 6.2.2: What do you mean by “it MUST NOT be readable by an unauthorized third party”? I’m not clear what “it” refers to. Seems like it refers to “activating a debug” but I’m not sure what “activating a debug MUST not be readable” means.

Section 6.3: Suggesting that logs SHOULD be encrypted seems like a stretch to me. Of course that doesn’t have to be followed, but most platforms today don’t encrypt their log files. I’d rather this say something like

   A SIP entity that has logged information MUST protect the logs, such that
   the logs can only be read by a person authorized to do so.

If others feel we should impose encryption, I’m okay with it staying a SHOULD but realistically seems unlikely most will implement it.

As far as I can tell, a device implementing log-me MUST implement [draft-ietf-insipid-session-id-27], correct? Seems like this should be called out at the beginning of the document (and of course added as a normative reference once the RFC number is assigned).

Does I-D.ietf-insipid-logme-reqs really have to be a normative reference? Seems like it should be Informative.


Nits:

s/signalling/signaling/g

I’d prefer is the references were not duplicated in the text (e.g. RFC 7206 [RFC7206] or defined in draft-ietf-insipid-logme-reqs [I-D.ietf-insipid-logme-reqs])

-Paul



> On Aug 20, 2016, at 1:18 AM, Gonzalo Salgueiro (gsalguei) <[e-mail]> wrote:
> 
> Dear INSIPID Participants,
> 
> We have finally completed the Session-ID draft and it is now in the RFC Editor’s queue. It is now time to move forward with the completion of the pending bottlenecked milestones. The first one of these is draft-ietf-insipid-logme-reqs, which has previously received sufficient review and currently has no pending unaddressed issues.
> 
> This message begins a Working Group Last Call on draft-ietf-insipid-logme-reqs-07 (https://tools.ietf.org/html/draft-ietf-insipid-logme-reqs-07 <https://tools.ietf.org/html/draft-ietf-insipid-logme-reqs>), to end on Friday September 9th, 2016. Please post comments and feedback to the [e-mail] <mailto:[e-mail]> list, including just a simple "looks good” if you have read the draft and have no material comments.
> 
> I kindly request the authors to please address any WGLC comments in a timely fashion.
> 
> It is my hope we can muster the energy for a final push to finish up the two remaining milestones and then close out this WG.
> 
> Regards,
> 
> Gonzalo (as chair)
> _______________________________________________
> insipid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/insipid