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

Thanks for the feedback Paul !

Please see inline.

On Sep 14, 2016, at 12:46 PM, Paul Giralt (pgiralt) <pgiralt@cisco.com<mailto:pgiralt@cisco.com>> wrote:

Sorry for the delay in commenting. Here’s some feedback:

Abstract: It states "that marks the PDU as a candidate for logging”. Does this really just mark the particular message for logging or does it mark the entire session for logging? Section 4 says "Subsequent responses and requests in the same dialog are logged” which means to me that the indicator affects the logging of more than just the PDU, but then Section 5, REQ7 makes it possible for stateless intermediaries to only log based on the presence of the marker. Then REQ9 makes it seem like the marker must be present in all messages in the dialog.

The marking applies to an individual message but the originating UA / proxy adds the logme marker for all messages in a session.

Section 1 Introduction: Why are we singling out service providers? Wouldn’t this be useful in large enterprise environments as well?

I think the Service provider was the initial use case. Yes, its applicable within large enterprise networks as well. We can broaden the use case.

Section 4: This was already mentioned, but requiring that messages be logged in their long form doesn’t seem like a good idea to me. This could be computationally intensive and what is the reason for the failure is that a device is not handling headers in their compact form correctly? Seems like we should try to preserve as much of the original, raw message as possible.

Good point.

Section 5, REQ 5: What about new requests within the same dialog / session (e.g. ACK or re-INVITE)? I think those should also include the log me marker as well.

I think REQ 9 address this scenario - "If applied, "log me" marking MUST begin with the dialog-creating request and SHOULD continue to the dialog end.”

REQ8: Should update to latest session-id draft. Also, I have some concerns about using Session-ID as the test case identifier. The Session-ID can change (in fact will change for every session because the initial INVITE will have a null remote UUID).

How about using the local UUID of the Session-ID generated by the originating UA / proxy as a test identifier (if the admin wants the system to auto-generate a test ID)?

6.2.1 - “MUST not” should be “MUST NOT”

Also, there is a non-normative use of “must” and “must not” in this section. Is that intentional? Does the debugging configuration have to be supplied by a server? Can the debug configuration not be done locally on the terminal?

Same thing with the logs. Do they have to be sent to a server? Can they just be retained locally on the terminal?

Agree. The key is to have the action that enables “logme” to be authorized. There are different ways the action could be taken - through local terminal, api etc..

Regarding logs, looks like we didn't update 6.2.1 when we added the following text.

      When and how signalling logs are retrieved is out of scope of this
      document.  Logs might be retrieved by logging on to the SIP entity
      that contains the logs, by sending logs to a central server that
      is co-ordinating debugging, by storing them on removable media for
      later manual collection, or by some other method.

We will update this section.

I only see mention of Proxies, but not other intermediaries such as B2BUA’s. I think there should be some call out to be encompassing of all intermediaries.

We plan to include B2BUA / intermediaries, gateways in the next version based on input from Alberto Llamas.

Thanks!
Arun

-Paul

On Aug 20, 2016, at 1:18 AM, Gonzalo Salgueiro (gsalguei) <gsalguei@cisco.com<mailto:gsalguei@cisco.com>> 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 insipid@ietf.org<mailto:insipid@ietf.org> 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
insipid@ietf.org<mailto:insipid@ietf.org>
https://www.ietf.org/mailman/listinfo/insipid