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

On 9/7/16 10:39 AM, Dawes, Peter, Vodafone Group wrote:
> Hello Paul,
> Thanks very much for your review comments and suggestions, the authors will discuss and try to resolve them in the next version. I have outlined my thoughts on resolving the comments in-line below.

Sounds good. I'll keep an eye out for the next version.

	Thanks,
	Paul

> Regards,
> Peter
>
>> -----Original Message-----
>> From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Paul Kyzivat
>> Sent: 01 September 2016 19:47
>> To: insipid@ietf.org
>> Subject: Re: [Insipid] WG Last Call: draft-ietf-insipid-logme-reqs
>>
>> Here are some comments on the document:
>>
>> * Section 4:
>>
>> I'm not clear of the intent of this section. It doesn't seem to include
>> requirements, yet it has normative statements. It reads more like a
>> mechanism.
>>
>> I think this section should be rewritten. Perhaps as a set of
>> assumptions/prerequisites for the environment where you are seeking a
>> solution.
>>
> [PD] Section 4 is currently a mixture of describing the motivating scenario, some pre-requisites (such as logging ends when a dialog ends) and requirements that do not apply to the logme marker itself. We can try to better group these aspects.
>
>> * Section 5:
>>
>> I think the requirements in this section are a bit mixed up. Some are
>> requirements that are to be met by a log-me *mechanism*. Others seem to
>> be requirements that should be levied by a log-me mechanism on those who
>> are implementing the mechanism. These are both useful things, but they are
>> different. Perhaps they should be in two separate lists.
> [PD] We can try to group the requirements by who or what they impact.
>
>>
>> * REQ2
>>
>> This talks about "network boundaries". I think more definition is needed to
>> clarify exactly what constitutes a network boundary and what the
>> impediments are for something to cross it. (Perhaps by referencing
>> RFC7092.)
> [PD] We can revise REQ2 to make the scenarios clear, perhaps by a combination of referring to some of the figures in RFC5853, which has many examples of network boundaries  even though it does not use the term "network boundary", and giving the RFC7092 categories of B2BUA that could manipulate the logme marker in SIP.
>>
>> * REQ3 (and section 6.1)
>>
>> Do you have a particular definition of "trust domain" in mind? Again, I think
>> some sort of definition is needed.
>>
> [PD] We can define trust domain as it applies to these requirements. A trust domain contains all SIP entities under configuration control of the network operator that is performing (e.g.) regression testing plus all SIP entities that are under configuration control of peer network operators who have agreed to participate in that (e.g.) regression testing. The purpose of trust domain requirements is to prevent network operators inadvertantly triggering logging in networks that are not part of any testing or troubleshooting.
>
>> Also, more discussion of motivation for removing at trust domains is needed.
>> IMO there is often little motivation for removing the marking on
>> *exit* from a trust domain, and in fact good reason for not doing so.
>> OTOH, there may indeed be good reason for removing from a request that is
>> *entering* a trust domain. (And some might want to remove the indicator
>> on exit in order to ensure that neighbors *aren't* aware they are
>> debugging.)
> [PD] We can clarify the role of trust domains.
>>
>> * REQ6/7
>>
>> Do you really mean *proxy*? I suspect you really mean *intermediary*,
>> including both proxies and B2BUAs?
> [PD] "proxies" was used to make it clear that SIP entities that are currently stateless are able to implement logme and still stay stateless. We can consider the B2BUA types in RFC7092 to see whether this wording needs to cover some subtleties of intermediary types.
>>
>> 	Thanks,
>> 	Paul
>>
>> _______________________________________________
>> insipid mailing list
>> insipid@ietf.org
>> https://www.ietf.org/mailman/listinfo/insipid
>