MSGTRK IETF45 design session meeting notes

Meeting Notes
Message Tracking (msgtrk) Working Group
Model Design Session
IETF 45, July 13, 1999
Steve Hole (chair)
ietf-msgtrk[-request]@imc.org

Please send corrections and additions to the list.

(+ lines show original text from slides)
(Robert Miles, from Lotus, shared his notes with me. His contributions
are gratefully accepted.)

+ Administrivia
+	History:
	The original leaders have moved off, so we're doing a full
	reset on the schedule.

+	Current state of the union:
	Steve Hole has taken over as WG chair

+	Why a design meeting?
	Today's meeting is a design meeting; no milestones will be
	addressed at this meeting, but will be addressed on the list.

+	Notifications of patents
	Lotus has a patent pending on "message tracking", but we think
	it's restricted to message tracking using via "SNMP".
	Issue:  We need to know the boundaries of the Lotus patent
	application and the WG needs to make sure that it's designs
	are in a different space.

+ Scope for this Meeting
+	intended to get the WG moving - accept controversy
+	open discussion within the framework of objectives
+	Steve will represent the existing work
+	Steve reserves the right to call a rathole on any issue

+Not in Scope for the meeting
+	charter milestone reassessment
	this obviously must be done, but will be done on the list.

+ Objectives for the Meeting
+	1) define an owner author for the doc
	the model design document
+	2) gain direction for the document authors
+	3) initiate other design (breakout) sessions
	e.g., bar BOFs
+	4) sanity check on whether to continue at all
+	5) <time permitting> blue-sky solution protocols based on model

+ Model Document Design
+	Ken Lin (Lotus), Tony Hansen (AT&T)
	Tony will be primary ping accepter.
+	What has been defined so far (all of which needs to be reviewed):
+	- requirements
+	- definitions and terminology
+	- anatomy of a tracking request

   Need to mine stuff from Gordon Jone's original document.
   Comment:  Probably should include an example scenario.

+ Model Documnt Outline
+	blah blah blah ...
+    	Problem Statement
+	Definitions
+	Entities
	    participants within the architecture
+	Interaction
	    between the participants
+	Security Considerations

+ Model Design - Entities (roles)
+	originating UA
	User Agent
	creates the message

+	intermediate MTA
	Mail Transfer Agent

+	final delivery MTA
	Mail Transfer Agent
	the final place that a message is accepted
	changed to say "final MTA"
	the final MTA is what sends any DSN,s

+	tracking client (requestor/initiator)
	wants to find information on a message

+	tracking server (repository/provider)
	provides tracking information to client

+	responsibilities / contract

in addition to the above, there would be:
    -	originating MSA Mail Submission Agent
	accepts a message from a UA, munges headers as necessary, and
	passes it to the first MTA
	(The UA and MSA are often combined into a single program.)

    -	local DA (delivery agent)
	delivers the message to the local message store

    LMTP was mentioned a variety of times as a source of ideas.

    The concept of a proxy MTA transferrer was discussed, but rejected
    from the definitions list. Such a beast lives on the edge of a
    firewall and accepts SMTP, but passes it on to an MTA within the
    firewall. Because such beasts are hopefully invisible, there is
    hopefully no need to consider it further.

+ Interaction model
    We want something that will be easy to implement and easy to
    deploy, otherwise, message tracking will never be deployed
    Note: Performance is a concern.  Don't want to slow down servers
    too much.
+	- expressed as a relationship between entities
+	- query request
	Another term would be "post-hoc model"
+	- passive request
	Another term would be "pre-hoc model"
	you're asking for "telemetry" -
	possibly through intermediate DSNs
+	- query + passive (hybrid)

Notes from discussion on pre-hoc model vs. post-hoc model:

    In post-hoc model, the question to ask when tracking:
	- has the message arrived?
	- if yes, is message xx here?
	- if not, where did it go?

    Another way to ask the question: what do you know about message XX?
    The answer is one of:
	A1: nothing
	A2: arrived
	A3: moved on to recipient R1,R2,R3,...,Rn and is in state
	    - S1 -> queued
	    - S2 -> relayed to hostx
	    - S3 -> delivered locally

A2 is the same as A3-S1.
There should also be
	    - S0 -> taken, but no further comment
	    - S2n -> relayed, but no further comment

Issue: Does tracking follow through alias expansion?
Issue: Does tracking follow through list expansion?

Who owns the message while it's in transit: the originator, the
transport system, or the recipient? Is this a rathole?

Consensus: Once the message is in the transport system, it is owned by
the transport system, and ownership passes hop to hop.

     Who owns the message in transit?  The transport system.
     Who owns the delivery information?  The transport system.

This means, among other things, that the transport system can refuse to
track.


Issue: Should we add?
       A0: no comment
Issue:  Do we need different gradations of the "No comment" response?
What are the semantics of the response?

#1 request of people buying enterprise message systems is: can I track
the messages?

It's conceivable that service providers could offer to track messages in
exchange for money.  I.e. you'll get "No comment" unless you pay.

Lots of places will want to turn on tracking within a firewall, but
block it at the firewall from outside. Firewalls may want to answer
queries from their Intranet, but respond with "No comment" to the
Internet.

Back to interaction model:

    pre-hoc - put something in beforehand that indicates that
	      telemetry needs to be kept 
        DSN is a form of pre-hoc for the last delivery step.
	pre-hoc kind of means you want a success DSN from every hop.
	Note, the proposed "deliver by" SMTP extension's trace mode
	could be used to do this!
	This will be considered a non-starter by the WG, other than
	recognizing what forms of pre-hoc information are already
	available.

    post-hoc - ask later for the telemetry.
	real-time queries of messaging servers to ask where the
	message is at.

    hybrid model - 
	DSN is part of tracking information that's actually available.
	Message tracking extends DSN (end-to-end tracking) to include
	dynamic intermediate tracking.
	Consider a client that sends a message, keeping state info
	about the message that is updated as information is received.
	If a DSN is requested and received, it knows that much about
	the message. If "deliver by" tracing is used and intermediate
	results are requested, those states can be incorporated as
	received. When the user requests the current status of a
	message, the information possibly already gathered can be
	combined with real-time queries to display the final answers
	to the user.

hum consensus: the WG will NOT extend the notary work (DSN) model to
provide pre-hoc.

+ Protocol Options - query mechanisms
+	passive - clearly should be DSN's
+	active - SNMP | new "lightweight" protocol

Consensus: SNMP is a non-starter.

There was no time to get into design.

================

Chair wants:
    - Two revisions of the model document by the next (Washington D.C.)
IETF.
    - Model document out ASAP.  Time estimate for this by the end of
next week.

ACTION ITEMS and ISSUES FOR THE LIST:

Issue:  We need to know the boundaries of the Lotus patent application
and the WG needs to make sure that it's designs are in a different
space.
Issue: Does tracking follow through alias expansion?
Issue: Does tracking follow through list expansion?
Issue: Should we add a "no comment" response, possibly with different
gradations.