[Insipid] Fwd: Re: draft-ietf-insipid-logme-marking-08

[Paul Kyzivat <[e-mail]>]

I had sent these comments to the authors. Peter asked me to forward them 
to the list. Here they are.

	Thanks,
	Paul

-------- Forwarded Message --------
Subject: Re: draft-ietf-insipid-logme-marking-08
Date: Thu, 26 Oct 2017 17:32:41 -0400
From: Paul Kyzivat <[e-mail]>
To: Dawes, Peter, Vodafone Group <[e-mail]>
CC: Arun Arunachalam (carunach) ([e-mail]) <[e-mail]>

Peter,

On 10/26/17 5:38 AM, Dawes, Peter, Vodafone Group wrote:
> Hello Paul,
> 
> Just a kind reminder to ask if you are able to review the latest 
> logme-marking draft and post to the insipid list? We authors would very 
> much like to conclude logme J

Oh, sorry. I see -08 has addressed a number of my comments on -07.

Reviewing the recent changes:

In section 3.7:

    In the example shown in Figure 2 below, Alice has reported problems
    making call transfers and her terminal is configured to log
    signalling for a call transfer.  ...

IIUC it isn't really feasible to configure to log just call transfers. 
The logging has to commence at the start of a dialog, before it is known 
whether there  will be a transfer. The signaling is consistent with 
this, but the description above ought to reflect reality.

Also in 3.7:

Some of the message contents aren't right. I didn't check everything, 
but here are a few problems I noted:

- F1 is supposed to be from transferor to transferee, but the From and 
To URIs are backwards from this.

- in F4, IIUC the To URI ought to be the Contact URI from F3, but 
instead has the From-URI from F3.

These all need to be rechecked.

ADAM: can you check the that the REFER stuff is correct according to the 
most recent definitions?

In section 4.2:

The terms "originating SIP intermediary" and "terminating SIP 
intermediary" are used in this section without definition. Since these 
are used in a normative way they ought to be defined. But I have a 
feeling this will not be easy. (I *think* you mean 'first' and 'last' 
here, rather than the IMS notion of simply being on the originating or 
terminating side.) While a device will know if it is acting as an 
intermediary, I don't think it in general has any way to know if it is 
first or last intermediary. Nor do I think it is necessary for it to 
know to make your mechanism work. Rather it simply has to recognize 
whether the request matches its internal state for the dialog. But 
describing it this will will require some rewording.

In section 4.2.2.2.4:

I have a question on this. IIUC Proxy 2 is logme-aware but by policy is 
removing logme marking coming from outside network B. If that is the 
intent, wouldn't it be better for it to maintain state and insert the 
logme marking on messages headed back to network A?

Or are you assuming the Proxy 2 isn't logme-aware and actively removes 
stuff it doesn't understand? (If so it is really a B2BUA rather than a 
proxy.)

Section 5.1:

I think the text here is not very precise on which cases are error 
cases, and how to distinguish them from cases where a neighbor doesn't 
support logme marking. ISTM the condition described here must be 
evaluated separately for each neighbor. It is an error if the neighbor 
has previously sent logme in the dialog and then stops, regardless of 
what has been happening on the other "side". The examples are pretty 
clear about this, but the text here is not so clear.

Otherwise it looks fine to me and my comments on -07 have been addressed.

	Thanks,
	Paul


> Best regards,
> 
> Peter
> 
> *From:*Dawes, Peter, Vodafone Group
> *Sent:* 19 September 2017 10:18
> *To:* '[e-mail]' <[e-mail]>
> *Subject:* draft-ietf-insipid-logme-marking-08
> 
> Hello Paul,
> 
> Thanks very much for being one of the people who reviewed the logme 
> solution draft in detail, it took us a while but we co-authors uploaded 
> an update and posted a summary of changes to the insipid exploder 
> https://mailarchive.ietf.org/arch/msg/insipid/6iAK8HspcC7nXNBsQEARYNoC3TA
> 
> It would be very helpful if you could check the changes listed and post 
> any comments to the list (the summary of changes lists the ones that are 
> specific to each review). We are hoping to resolve any remaining 
> comments and then we can request a security review of the draft.
> 
> Best regards,
> 
> Peter
>