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

["DOLLY, MARTIN C" <[e-mail]>]

Longer than most of my short answers
Initially meant in controlled deployments

Maybe SIP or now the world version of SiP being done in 3GPP.

Not IETF. In would have been interoperable

Sorry
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 9:02 PM, Ben Campbell <[e-mail]<mailto:[e-mail]>> wrote:

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]><mailto:[e-mail]>


On Nov 23, 2016, at 7:34 PM, Ben Campbell <[e-mail]<mailto:[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