Skip to main content

Redaction of Potentially Sensitive Data from Mail Abuse Reports
RFC 6590

Revision differences

Document history

Date Rev. By Action
2015-10-14
08 (System) Notify list changed from marf-chairs@ietf.org, draft-ietf-marf-redaction@ietf.org to (None)
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Stephen Farrell
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2012-04-07
08 (System) RFC published
2012-02-22
08 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent.
2012-02-22
08 (System) IANA Action state changed to No IC
2012-02-21
08 Amy Vezza IESG state changed to Approved-announcement sent
2012-02-21
08 Amy Vezza IESG has approved the document
2012-02-21
08 Amy Vezza Closed "Approve" ballot
2012-02-21
08 Amy Vezza Approval announcement text regenerated
2012-02-17
08 Pete Resnick State changed to Approved-announcement to be sent from Waiting for AD Go-Ahead.
2012-02-15
08 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Julien Laganier.
2012-02-13
08 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2012-02-04
08 David Black Request for Last Call review by GENART Completed. Reviewer: David Black.
2012-02-02
08 Jean Mahoney Request for Last Call review by GENART is assigned to David Black
2012-02-02
08 Jean Mahoney Request for Last Call review by GENART is assigned to David Black
2012-01-30
08 Amy Vezza Last call sent
2012-01-30
08 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <marf@ietf.org>
Reply-To: ietf@ietf.org
Subject: Additional Last Call: <draft-ietf-marf-redaction-08.txt> (Redaction of Potentially Sensitive Data from Mail Abuse Reports) to Proposed Standard


The IESG has received a request from the Messaging Abuse Reporting Format
WG (marf) to consider the following document:
- 'Redaction of Potentially Sensitive Data from Mail Abuse Reports'
  <draft-ietf-marf-redaction-08.txt> as a Proposed Standard

During Last Call and IESG Evaluation, a significant change was made to
the document to address the comments of reviewers, removing a
recommended transformation mechanism and instead detailing how to select
any of the acceptable transformation mechanisms. This additional last
call is to solicit any comments on this change.

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 2012-02-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


  Email messages often contain information that might be considered
  private or sensitive, per either regulation or social norms.  When
  such a message becomes the subject of a report intended to be shared
  with other entities, the report generator may wish to redact or elide
  the sensitive portions of the message.  This memo suggests one method
  for doing so effectively.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/


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


2012-01-30
08 Amy Vezza Last Call text changed
2012-01-28
08 Pete Resnick Last Call was requested
2012-01-28
08 Pete Resnick State changed to Last Call Requested from IESG Evaluation::AD Followup.
2012-01-28
08 Pete Resnick Last Call text changed
2012-01-27
08 (System) New version available: draft-ietf-marf-redaction-08.txt
2012-01-24
07 (System) New version available: draft-ietf-marf-redaction-07.txt
2012-01-24
08 Stephen Farrell
[Ballot comment]
I'm still not fond of the example in the appendix (a hmac one would be
less likely to encourage bad practice) but thanks …
[Ballot comment]
I'm still not fond of the example in the appendix (a hmac one would be
less likely to encourage bad practice) but thanks for taking my issue
into account.
2012-01-24
08 Stephen Farrell
[Ballot discuss]
(Updated-discuss - thought about it a bit more;-)

(1) The construct here is output=H(redaction-key|sensitve-value).
I don't think that's ok. I think you want …
[Ballot discuss]
(Updated-discuss - thought about it a bit more;-)

(1) The construct here is output=H(redaction-key|sensitve-value).
I don't think that's ok. I think you want HMAC() and not H().

If I could supply a redactor with a zero length "private" string,
e.g. message with a header field like "To: @example.org" then the
redactor will send H(redaction-key) which can then allow (via
hash-continuation) checking if any value matches a value from an
output here.

If the alphabet for sensitive values has N characters
then I can also send "To: "+char[i]+"@example.org" for
each i and then play the continuation game on that.
Same for two character prefixes etc.

(2) I can also use this to validate guesses of the redaction
key value. I need to think about how one might avoid that
or if its possible to avoid that.
2012-01-24
08 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2012-01-23
08 (System) Sub state has been changed to AD Follow up from New Id Needed
2012-01-23
06 (System) New version available: draft-ietf-marf-redaction-06.txt
2012-01-20
08 David Black Request for Last Call review by GENART Completed. Reviewer: David Black.
2012-01-19
08 Cindy Morgan Removed from agenda for telechat
2012-01-19
08 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation.
2012-01-19
08 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2012-01-18
08 Pete Resnick State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2012-01-18
08 Russ Housley [Ballot comment]
Please reference RFC 4648, Section 4 for [Base64].
  More than one alphabet is available in RFC 4648.
2012-01-18
08 Russ Housley
[Ballot discuss]
The Gen-ART Review by David Black on 10-Jan-2012 raised two concerns.
  There has been some discussion of those concerns, but the document …
[Ballot discuss]
The Gen-ART Review by David Black on 10-Jan-2012 raised two concerns.
  There has been some discussion of those concerns, but the document has
  not been updated yet to address them.  The Gen-ART Review can be found
  at: http://www.ietf.org/mail-archive/web/gen-art/current/msg07043.html
2012-01-18
08 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss
2012-01-18
08 Sean Turner
[Ballot comment]
Updated (add the last two)

I agree with Stephen's and Russ' discuss: I think this needs to be an HMAC.

You probably don't …
[Ballot comment]
Updated (add the last two)

I agree with Stephen's and Russ' discuss: I think this needs to be an HMAC.

You probably don't need to specify an algorithm because it's not an interoperability issue, but it might be nice to point to RFC 6151 and 6194 for recent info on HMAC-MD5 and HMAC-SHA1.  It would stop people from trying to do something over kill like HMAC-SHA256.

If you're going to stick with the plain ole hash then pointing to 6151 and 6914 still is worth considering (i.e., MD5 bad). 

Probably worth a reference to RFC 4086 for the pseudo-random # issues.
2012-01-18
08 Sean Turner
[Ballot comment]
I agree with Stephen's and Russ' discuss: I think this needs to be an HMAC.

You probably don't need to specify an algorithm …
[Ballot comment]
I agree with Stephen's and Russ' discuss: I think this needs to be an HMAC.

You probably don't need to specify an algorithm because it's not an interoperability issue, but it might be nice to point to RFC 6151 and 6914 for recent info on HMAC-MD5 and HMAC-SHA1.  It would stop people from trying to do something over kill like HMAC-SHA256.
2012-01-18
08 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded
2012-01-18
05 (System) New version available: draft-ietf-marf-redaction-05.txt
2012-01-18
08 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2012-01-17
08 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2012-01-17
08 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded
2012-01-17
08 Peter Saint-Andre [Ballot comment]
I agree with other IESG members that this document seems informational, not standards track.
2012-01-17
08 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2012-01-17
08 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2012-01-17
08 Russ Housley
[Ballot discuss]
The Gen-ART Review by David Black on 10-Jan-2012 raised two concerns.
  There has been some discussion of those concerns, but the document …
[Ballot discuss]
The Gen-ART Review by David Black on 10-Jan-2012 raised two concerns.
  There has been some discussion of those concerns, but the document has
  not been updated yet to address them.  The Gen-ART Review can be found
  at: http://www.ietf.org/mail-archive/web/gen-art/current/msg07043.html
2012-01-17
08 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded
2012-01-17
08 Dan Romascanu
[Ballot comment]
This is a rather short and aparently straight-forward document, but it raised a couple of questions. None of them is that critical to …
[Ballot comment]
This is a rather short and aparently straight-forward document, but it raised a couple of questions. None of them is that critical to deserve a blocking DISCUSS, but yet I would be glad if these were answered and clarified before approval and publication.

1. It is not clear why this document is on standards track. I do not know how to establish interoperability of implementations and thus what the critieria would be for advancement from Proposed Standard to Standard. Moreover the Abstract describes the scope in a rather non-commital manner (suggests one method for ... the report generator ... to redact or elide the sensitive portions of the message) - so this looks like a recommendation about one (good way) to perform redaction, but not the <standard way> of doing it.

2. I know too little about the operational model of configuring a report generator, so I was left wondering how are the first two recommendations implemented in practice:

> 1.  Select an arbitrary string that will be used by an Administrative
      Management Domain (ADMD) that generates reports.  This string
      will not be changed except according to a key rotation policy or
      similar.  Call this the "redaction key".
>  2.  Identify string(s) (such as local-parts of email addresses) in a
      message that need to be redacted.  Call these strings the
      "private data".

Some text that clarifies how this is supposed to be implemented and configured in practice would be useful.
2012-01-17
08 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2012-01-16
08 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2012-01-15
08 Stephen Farrell
[Ballot comment]
- I don't get why this is not informational - where's the interop
consequence?

- While the idea of only listing JD is …
[Ballot comment]
- I don't get why this is not informational - where's the interop
consequence?

- While the idea of only listing JD is laudable, I think having a
concactable author is best so I'd suggest Murray be kept as an
author.

- Last para of section 1 - such correlation is not theoretical,
delete that word.
2012-01-15
08 Stephen Farrell
[Ballot discuss]
(Updated-discuss - thought about it a bit more;-)

(1) The construct here is output=H(redaction-key|sensitve-value).
I don't think that's ok. I think you want …
[Ballot discuss]
(Updated-discuss - thought about it a bit more;-)

(1) The construct here is output=H(redaction-key|sensitve-value).
I don't think that's ok. I think you want HMAC() and not H().

If I could supply a redactor with a zero length "private" string,
e.g. message with a header field like "To: @example.org" then the
redactor will send H(redaction-key) which can then allow (via
hash-continuation) checking if any value matches a value from an
output here.

If the alphabet for sensitive values has N characters
then I can also send "To: "+char[i]+"@example.org" for
each i and then play the continuation game on that.
Same for two character prefixes etc.

(2) I can also use this to validate guesses of the redaction
key value. I need to think about how one might avoid that
or if its possible to avoid that.
2012-01-15
08 Stephen Farrell
[Ballot comment]
- I don't get why this is not informational - where's the interop
consequence?

- While the idea of only listing JD is …
[Ballot comment]
- I don't get why this is not informational - where's the interop
consequence?

- While the idea of only listing JD is laudable, I think having a
concactable author is best so I'd suggest Murray be kept as an
author.

- Last para of section 1 - such correlation is not theoretical,
delete that word.
2012-01-15
08 Stephen Farrell
[Ballot discuss]
The construct here is output=H(redaction-key|sensitve-value).  I
don't think that's ok. I think you want HMAC() and not H().

If I could supply a …
[Ballot discuss]
The construct here is output=H(redaction-key|sensitve-value).  I
don't think that's ok. I think you want HMAC() and not H().

If I could supply a redactor with a zero length "private" string,
e.g. message with a header field like "To: @example.org" then the
redactor will send H(redaction-key) which can then allow (via
hash-continuation) checking if any value matches a value from an
output here.
2012-01-15
08 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded
2012-01-15
08 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded
2012-01-13
08 Stewart Bryant
[Ballot comment]
I am not a crypto expert, and thus do not know the severity of the attack vector in this case, but isn't there …
[Ballot comment]
I am not a crypto expert, and thus do not know the severity of the attack vector in this case, but isn't there a plain text attack when encrypted material has a constant string included as seems to be the case here.
2012-01-13
08 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2012-01-12
08 Jean Mahoney Request for Last Call review by GENART is assigned to David Black
2012-01-12
08 Jean Mahoney Request for Last Call review by GENART is assigned to David Black
2012-01-12
08 Amanda Baber We understand that this document doesn't require any IANA actions.
2012-01-11
08 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded
2012-01-11
08 David Black Request for Last Call review by GENART Completed. Reviewer: David Black.
2012-01-06
08 Jean Mahoney Request for Last Call review by GENART is assigned to David Black
2012-01-06
08 Jean Mahoney Request for Last Call review by GENART is assigned to David Black
2012-01-06
08 Mary Barnes Assignment of request for Last Call review by GENART to Allyn Romanow was rejected
2012-01-04
08 Cindy Morgan
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <marf@ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call: <draft-ietf-marf-redaction-04.txt> (Redaction of Potentially Sensitive Data from Mail Abuse Reports) to Proposed Standard


The IESG has received a request from the Messaging Abuse Reporting Format
WG (marf) to consider the following document:
- 'Redaction of Potentially Sensitive Data from Mail Abuse Reports'
  <draft-ietf-marf-redaction-04.txt> as a Proposed Standard

Note: This document was previously considered for Informational, but
it is now being considered as a Proposed Standard after comments
from the previous Last Call.

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 2012-01-18. 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


  Email messages often contain information that might be considered
  private or sensitive, per either regulation or social norms.  When
  such a message becomes the subject of a report intended to be shared
  with other entities, the report generator may wish to redact or elide
  the sensitive portions of the message.  This memo suggests one method
  for doing so effectively.

  [NOTE TO EDITOR: Murray Kucherawy is listed as an author only to
  enable him to complete the publication process on behalf of J.D.
  Falk.  Please remove Murray from the author list prior to
  publication.]




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/


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


2012-01-04
08 Pete Resnick [Ballot Position Update] New position, Yes, has been recorded for Pete Resnick
2012-01-04
08 Pete Resnick Ballot has been issued
2012-01-04
08 Pete Resnick Created "Approve" ballot
2012-01-04
08 Pete Resnick
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he …
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

I (Murray Kucherawy) am a co-chair of the MARF working group and the
shepherd for this document. I have reviewed all versions of it, and
I believe it is ready for IESG review.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

This document was developed both inside and outside the IETF, mainly within
the membership of the Messaging Anti-Abuse Working Group (MAAWG) where the
work of the MARF working group originated. I have no concerns about the
review it has received, especially as it is not a Standards Track document.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

It will receive an automatic SECDIR review, which should complete the
reviews I feel are necessary and appropriate.

(1.d) Does the Document Shepherd have any specific concerns or
issues 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. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

There is a need for what's in this document to be published as it documents
current practice of some members of the feedback loop community.

I have no concerns about any part of the document. There are no IPR
disclosures.

(1.e) 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?

MARF is not a large working group, but it has received adequate review from
its participants enough that I believe rough consensus has been achieved.

(1.f) 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
entered into the ID Tracker.)

No appeals have been threatened. The material is non-controversial.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

I have personally verified that no ID nits are raised. No pre-IESG formal
review criteria need to be met.

(1.h) Has the document split its references into normative and
informative? 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
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The references have been so divided. There are no downward references.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

This memo has no actions for IANA.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

No formal languages are used in this memo.

(1.k) 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.

Email messages often contain information which might be considered
private or sensitive, per either regulation or social norms. When
such a message becomes the subject of a report intended to be shared
with other entities, the report generator may wish to redact or elide
the sensitive portions of the message. This memo suggests one method
for doing so effectively.

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?

There was little controversy. This is obviously something needed and is
in current use within production feedback loops.

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 are some existing implementations of feedback loops that follow this
process, and others that vary a little because they are earlier
implementations which informed this specification. There is certainly
consensus within industry that this is an appopropriate specification
upon which to converge.
2012-01-04
08 Pete Resnick Last Call was requested
2012-01-04
08 Pete Resnick State changed to Last Call Requested from Waiting for AD Go-Ahead.
2012-01-04
08 Pete Resnick Last Call text changed
2012-01-04
08 Pete Resnick Intended Status has been changed to Proposed Standard from Informational
2012-01-03
04 (System) New version available: draft-ietf-marf-redaction-04.txt
2011-12-29
08 Pete Resnick Telechat date has been changed to 2012-01-19 from 2012-01-05
2011-12-15
08 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-12-14
08 Pete Resnick Placed on agenda for telechat - 2012-01-05
2011-12-09
08 Amanda Baber We understand that this document doesn't require any IANA actions.
2011-12-08
08 Jean Mahoney Request for Last Call review by GENART is assigned to Allyn Romanow
2011-12-08
08 Jean Mahoney Request for Last Call review by GENART is assigned to Allyn Romanow
2011-12-04
08 Samuel Weiler Request for Last Call review by SECDIR is assigned to Julien Laganier
2011-12-04
08 Samuel Weiler Request for Last Call review by SECDIR is assigned to Julien Laganier
2011-12-01
08 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <marf@ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call: <draft-ietf-marf-redaction-03.txt> (Redaction of Potentially Sensitive Data from Mail Abuse Reports) to Informational RFC


The IESG has received a request from the Messaging Abuse Reporting Format
WG (marf) to consider the following document:
- 'Redaction of Potentially Sensitive Data from Mail Abuse Reports'
  <draft-ietf-marf-redaction-03.txt> as an 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 2011-12-15. 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


  Email messages often contain information which might be considered
  private or sensitive, per either regulation or social norms.  When
  such a message becomes the subject of a report intended to be shared
  with other entities, the report generator may wish to redact or elide
  the sensitive portions of the message.  This memo suggests one method
  for doing so effectively.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/


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


2011-12-01
08 Pete Resnick Last Call was requested
2011-12-01
08 Pete Resnick State changed to Last Call Requested from Publication Requested.
2011-12-01
08 Pete Resnick Last Call text changed
2011-12-01
08 (System) Ballot writeup text was added
2011-12-01
08 (System) Last call text was added
2011-12-01
08 (System) Ballot approval text was added
2011-11-21
08 Pete Resnick State changed to Publication Requested from AD is watching.
2011-11-21
08 Murray Kucherawy IETF state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2011-11-21
08 Murray Kucherawy Publication requested.
2011-11-21
08 Murray Kucherawy Annotation tag Doc Shepherd Follow-Up Underway cleared.
2011-11-21
03 (System) New version available: draft-ietf-marf-redaction-03.txt
2011-11-19
08 Murray Kucherawy Wrong state
2011-11-19
08 Murray Kucherawy IETF state changed to Waiting for WG Chair Go-Ahead from Adopted by a WG
2011-11-19
08 Murray Kucherawy IETF state changed to Adopted by a WG from In WG Last Call
2011-11-19
08 Murray Kucherawy WGLC completed; review of changes pending
2011-11-19
08 Murray Kucherawy Annotation tag Doc Shepherd Follow-Up Underway set.
2011-11-19
02 (System) New version available: draft-ietf-marf-redaction-02.txt
2011-11-17
08 Murray Kucherawy Changed protocol writeup
2011-11-04
08 Cindy Morgan WG Last Call Ends 2011-11-18.
2011-11-04
08 Cindy Morgan IETF state changed to In WG Last Call from WG Document
2011-10-25
01 (System) New version available: draft-ietf-marf-redaction-01.txt
2011-10-16
08 (System) Document has expired
2011-10-16
08 (System) State changed to Dead from AD is watching.
2011-06-10
08 Pete Resnick Area acronym has been changed to app from gen
2011-06-10
08 Pete Resnick State changed to AD is watching from Publication Requested.
2011-06-10
08 Pete Resnick Draft added in state Publication Requested
2011-04-14
00 (System) New version available: draft-ietf-marf-redaction-00.txt