Requirements for Marking SIP Messages to be Logged
draft-ietf-insipid-logme-reqs-12

[Ballot discuss]
Okay, there's 5 obstains, and at this rate may be more by the telechat. I can take a hint :-)

This is a discuss-discuss; I want to talk about the recent guidance we've given people for this sort of thing, and how we should address work items that were approved well before that guidance was given. Otherwise, I want to regroup with the authors and working group before progressing this further.

[Ballot comment]
I agree with Mirja that useful content would be better placed in the solution document.
I don't think that there are communication issues between WGs where requirements need
to be nailed down - and obviously no delay in working on a solution.

[Ballot comment]
I fail to see the value in publishing this document as an RFC in its own right. However I shall not stand in the way of publication should that be the ballot outcome.

[Ballot comment]
In addition to Stephen's questions, I would like to see a little more text in the following sentence of the Security Considerations section:
OLD:
  If a prior agreement to log
  sessions exists with the next hop network then the "log me" marker
  SHOULD NOT be removed.
NEW: (or something similar that ties this back to requirement 7)
  If a prior agreement to log
  sessions, at a debugging or regression testing level for data, exists with the next hop network then the "log me" marker
  SHOULD NOT be removed.

That requirement only shows up in one place (as far as I could see and I think it would be helpful in the security considerations section as it shows the limited scope of use besides the "trust domain" (name may be changed?).

Note that I am balloting No Objection as this is part of the WG's charter (also pointed out in the SecDir review).

[Ballot comment]
I do see the value in the content of this document, but I do not see the value of publishing it as a separate RFC at this point of time. I think it should be merged into the solution document.

[Ballot comment]

Note that I'm balloting no-objection here. If some of
these things weren't fixed, I'd be a DISCUSS ballot when
the protocol spec turned up, should I still be on the
IESG at that point (which I guess is unlikely:-)

- 3.2: I think "trust domain" isn't a great term, and
doesn't really match the definition offered well. You're
including the entire "source" operator plus the bits of
any other operator that have agreed to help the
source-operator with logging. I don't think that set of
things is really a domain. Nor are the things in that set
"trusted" except to do this logging stuff properly. It's
also not clear to me if the relevant set is meant to
differ per-call, or to be the same for all calls that a
source-operator might originate.

- 5.1: REQ1 seems to me to ignore privacy in one bad
respect - isn't the right thing to log the entire message
*except* bits that are considered sensitive by the
logging entity concerned?  E.g. any secrets or PII in the
SIP message may be best not logged. Forcing everyone to
log the entire thing would seem brittle to me - it may
cause operators to not co-operate with one another esp if
data privacy laws differ between them. (Or maybe more
likely, the logs will not have the sensitive bits, or
will eventually have them XXXX'd out.)

- REQ9: Not quite sure, but I wonder are there additional
requirements for intermediaries inserting this that
aren't covered. For example, that that not be (ab)used
for other than diagnostics and hence ought not be on by
default and maybe more. I think the thing to do is to get
someone to do a privacy analysis of this situation before
the protocol spec is done - some minor changes might make
a biggish difference there.

- 6.1: See above wrt 3.2. I'm not convinced that there is
such a thing as a "trust domain boundary" as you use the
term. I think (not sure) that may mean that logme stuff
is either dropped on ingress or else never dropped
which'd seem like a bad outcome.

[Ballot comment]
I agree with Mirja in that I to don't see any archival value in this document as is, especially given that the WG has been working on the solution draft (draft-ietf-insipid-logme-marking) for over two years.

I am however not standing in the way of publication and am ABSTAINing instead.

[Ballot comment]
I don't see a value in publishing this draft as a stand-alone document. If needed content can be merged into draft-ietf-insipid-logme-marking (maybe in the appendix); especially the security considerations belong in the spec itself.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-insipid-logme-reqs-11.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ben@nostrum.com, insipid@ietf.org, insipid-chairs@ietf.org, draft-ietf-insipid-logme-reqs@ietf.org, gsalguei@cisco.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Requirements for Marking SIP Messages to be Logged) to Informational RFC


The IESG has received a request from the INtermediary-safe SIP session ID
WG (insipid) to consider the following document:
- 'Requirements for Marking SIP Messages to be Logged'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-01-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  SIP networks use signaling monitoring tools to debug customer
  reported problems and for regression testing if network or client
  software is upgraded.  As networks grow and become interconnected,
  including connection via transit networks, it becomes impractical to
  predict the path that SIP signaling will take between clients, and
  therefore impractical to monitor SIP signaling end-to-end.

  This draft describes requirements for adding an indicator to the SIP
  protocol data unit (PDU, or a SIP message) that marks the PDU as a
  candidate for logging.  Such marking will typically be applied as
  part of network testing controlled by the network operator and not
  used in regular client signaling.  However, such marking can be
  carried end-to-end including the SIP terminals, even if a session
  originates and terminates in different networks.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-insipid-logme-reqs/ballot/


No IPR declarations have been submitted directly on this I-D.

This is my initial AD evaluation of draft-ietf-insipid-logme-reqs-10.

I have some significant concerns about this document, as noted below. I'd like to discuss the major concerns before progressing the document.

Major Concerns:

- 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.

- The purpose of the draft is not clear to me. I understand it to be requirements for the creation of a protocol mechanism; that is, that it would describe the features of the mechanism, but not the details of how the mechanism works. But many of the requirements seem like requirements on the behavior of network elements (that is, mechanism details). If this draft is to be published as an RFC, I think quite a number of them will need to be rethought. Details in the minor concerns section.

Minor Concerns:

-2: The usage in this draft does not exactly match RFC2119.  That RFC is about interoperability, not compliance or requirements on a mechanism. (That could be more clear in the definitions of the terms in 2119, but it's pretty clear in section 6.). That doesn't mean this draft cannot use 2119 terms, but please edit the boilerplate to describe how you really intend to use them. (I note that this draft does use some 2119 language as described in 2119, but that's what triggered my other comments about describing mechanism rather than requirements.

- 3.1, 2nd paragraph: Is this still part of the definition of network boundary?

- 3.2: I assume the "trust domain" is specific to trust for logging purposes. I suggest "Logging trust domain" or "logging domain".

- 4.3, third bullet: Is "dialog" the correct term here? Is this really limited to a dialog, or do you expect it to apply to the concept of a "session" as described in the session-ID doc?

- 5.1, REQ1: This seems more like mechanism than a requirement against the mechanism, in that it states a requirement for specific network element behavior. Isn't the real requirement something along the lines of "The mechanism must allow the endpoint to indicate that it wishes the entire message to be logged"?

Also the MUST seems misplaced as stated; do elements have the option not to log? That seems to be in conflict with typical privacy requirements that suggest log minimization.

- 5.1, third paragraph: Making policies about log retrieval out of scope seems unfortunate. This draft should have something to say about such policies in the form of privacy requirements on the mechanism. That doesn't mean this draft has to state the policies, but it can require the mechanism to discuss them. (Or can something be referenced from the CLF work?)

- 5.3: Req6 is confusing as worded. It starts off saying things work best if the marker goes end to end, then says not to send it end to end. Please explain why the "responsible" behavior goes against the first sentence. (I think we can all infer the reasoning, but it's better to be explicit.)

-- Req7: This seems like mechanism, not requirements for a mechanism. It stated normative requirements on the behavior of a network element. It seems like that belongs in the mechanism document.

-- Req8: Same as last comment.

-- Req9 seems to have privacy implications that need discussion somewhere. How would a user know logging was requested? Can a user override that?

-- Req10: Again, this seems like mechanism. I would expect a requirement to say something like "The mechanism must allow for stateless operation."

-- Req11: Mechanism again. I would expect a requirement to be of the form of " a log me indication applies for the duration of a dialog (or a session?).

- 6.2.1: Would it make sense to say the marker must not contain information can be used to identify the uer or endpoint device, and that it must not be possible to correlate markers across multiple sessions? If not, why not?

-- Does the requirement that the marker must not be modified in transit imply that it must not be possible for it to be modified, or just that participating endpoints must not modify it?

-- The requirement that logs not be readable by an unauthorized party seems to contradict the earlier statement that how and when logs are read is out of scope.

- 6.2.2: The previous section stated this more strongly, so this section seems entirely redundant.

Editorial Comments:

- Abstact: "... if network or client software is upgraded.":
s/if/when

- abstract, paragraph 2:
I assume this document intends to create requirements on the capabilities of a logme indication mechanism, not define how the indicator works. (The latter would be solution, not requirements)

- introduction: " if SIP client software/hardware"

I suggest "... when SIP client software or hardware"

-3.1, 2nd paragraph : "prevent the
  sending network passing on sensitive information"
s/network passing/network from passing/

- figure 1: there are lines that don't seem to line up. (e.g. diagonal line from top of country Y and from the side of country X, Operator A, SIP phones.

- 5.3, Req 9: Should the "dialog" be "session"?

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

It is intended that the document be published as informational. It is not intended that this document should be applicable directly to an implementation, but rather identifies a set of requirements on which a future IETF solution will be built; the latter document will be standards track. In the cases where these requirements are a standalone document, they have traditionally been published as an informational RFC.
The document status is indicated in the document title page.  This logme work parallels the Session-ID approach of requirements document followed by solution document.  In that case RFC 7206, which was the requirements document for the later Session-ID solution draft (RFC 7989).

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

This document specifies the requirements for requirements for adding an indicator to the SIP protocol data unit (PDU, or a SIP message) that marks the PDU as a candidate for logging. This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks.  This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

The document has achieved working group consensus and has received sufficient discussion.  There were no particularly contentious issues to work through in this document (unlike its INSIPID predecessor).

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There is no working implementation, per se, of this draft since it is a requirements document.  That said, its corresponding solution draft (draft-ietf-insipid-logme-marking) does indeed  have working implementations.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Gonzalo Salgueiro is the document shepherd and Ben Campbell is the responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The document is ready for publication.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

This document does not need reviews from a particular or a from a broader perspective. The solution document might need such wider reviews, but this is not appropriate for a requirements document.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

The document shepherd has no concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Each author has confirmed that all appropriate IPR disclosures have been made.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There is no IPR disclosures against this document and neither author knows of any  undeclared IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The contents of this document have been extensively discussed amongst several individuals in this working group.  A reasonable number of individuals have indicated they had read the document during working group last call and had no further comments.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No such view has been expressed.  This document was progressed without any major contentious issues.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No idnits have been found and the document passes the boilerplate checks.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as
either normative or informative?

Yes, all references have been properly classified as normative or informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are published RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

There are no downward references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This document does not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The document has no IANA considerations, as it makes no changes to any IANA registry.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

The document has no IANA considerations, as it makes no changes to any IANA registry.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

The document contains no material of a formal nature requiring such review.