Re: [Insipid] AD Evaluation of draft-ietf-insipid-logme-reqs-10

["Ben Campbell" <[e-mail]>]

I'm not sure I follow you, but I assume you either mean either that you 
like version 10 the way it is, or you like some component of it better 
than my suggestion.

Please note that my proposals on requirements language, which I think 
are the most material suggestions, are contingent on the answers to some 
of my earlier questions about how the behavior definition is divided 
between this and the solution draft.

Ben.

On 23 Nov 2016, at 19:08, DOLLY, MARTIN C wrote:

> Ben
>
> The initial proposal was easier
>
> UGH
>
> Martin C. Dolly
> Lead Member of Technical Staff
> Core & Government/Regulatory Standards
> AT&T
> Cell: +1.609.903.3360<tel:[phone]>
> Email: [e-mail]<mailto:[e-mail]>
>
>
> On Nov 23, 2016, at 7:34 PM, Ben Campbell 
> <[e-mail]<mailto:[e-mail]>> wrote:
>
> Hi, thanks for the response. Comments inline.
>
> Ben.
>
> On 23 Nov 2016, at 8:59, Dawes, Peter, Vodafone Group wrote:
>
> Hello Ben,
> Thanks very much for your initial AD evaluation of 
> draft-ietf-insipid-logme-reqs-10, below is our response. The review 
> was long so we used some XML-style tags to structure the response 
> according to your major and minor concerns.
>
> Regards,
> Peter and Arun (co-authors)
>
> <major-issue-1>
> - What is the archival value for this draft after the mechanism is 
> complete? Is there really a reason to publish it as an RFC? Could the 
> info here be stored in the working group wiki, included in the 
> solution draft, or even allowed to expire once the mechanism is 
> complete? I contrast this to the session-id requirements document, 
> since that explored the details of some tricky concepts (such as 
> "session".) It's not clear to me that this draft does the same. I also 
> note that logme-marking already seems to replicate a good deal of this 
> draft, and seems to dive even deeper into use cases, and in some areas 
> seems to have moved beyond the requirements in this draft.
> I ask because the question is likely to come up in IESG review, and 
> also because the publication process creates a lot of effort for the 
> working group, RFC editor, reviewers, etc.
> </major-issue-1>
>
> <reply-1>
> The primary objective of a requirements draft is to provide clarity on 
> the complete list of requirements that a proposed solution needs to 
> satisfy for a given problem. In our logging and troubleshooting 
> scenarios, the requirements list has been identified through 
> discussions and consensus among INSIPID working group members.
>
> That's my understanding of what a requirements draft typically does. 
> But this draft seems to also put requirements on behavior, which seem 
> like protocol requirements to me. So as written, it seems like 
> protocol/behavior requirements are either spread or repeated between 
> the requirements and solution draft. This seems to make life harder 
> than necessary for the implementer.
>
> There are other reasonable work divisions, for example you might have 
> an requirements + architecture draft and a separate solution draft, or 
> you might have a SIP element behavior draft and a data format draft, 
> etc.
>
>
>
> In this draft, we have clearly documented the requirements from the 
> perspective of:
> -    When the logging is started and stopped
> -    Passing the log-me marker across SIP entities
> -    Privacy considerations
>
> These are all reasonable categories. My concern is how things are 
> divided between this and the solution draft within those categories. 
> For example, a requirement of the form of "The logging indication must 
> be able to be sent across B2BUAs" vs "A B2BUA must copy the <foo> 
> parameter".
>
>
>
> The solution document will provide insights into the "how" details. 
> These two documents help a network developer, administrator and 
> support engineer to understand the guiding requirements upon which the 
> solution will be built