The Atom "deleted-entry" Element
RFC 6721

[Ballot discuss]
The most recent version helped some, but I still have the same concerns with section 3:

  An Atom feed MAY contain atom:entry elements and at:deleted-entry
  elements sharing the same atom:id value.  Atom processors SHOULD
  ignore any at:deleted-entry elements sharing an atom:id value with an
  atom:entry whose atom:updated element specifies a date and time more
  recent than or equal to the at:deleted-entry element's when value.

What exactly are the semantics associated with a feed that has both an atom-entry and at:deleted-entry for the same atom:id? Is it something like "marked for delete before purged"? How might this situation come up? I'm worried that there is not enough information in here (and the SHOULD is making me more worried) to be able to implement this in an interoperable fashion. You do explain the meaning of an at:deleted-entry that is *older* than the 'when' element of of an atom:entry's atom-updated element, but you don't explain what it means to have an at:deleted-entry that is *newer*. Please explain.

  Implementors should note that the at:deleted-entry element is
  informative in nature only and may be ignored by Atom processors.

I'm not sure what the above means. What is it informative of? Do you really mean "advisory" instead of "informative"? Or do you mean "probabilistic" (which would concern me)? Are you saying that an Atom processor can't rely on an at:deleted-entry?

  The presence of an at:deleted-entry element does not guarantee that
  the atom:entry to which it is referring will no longer be available.

Again, I'm not sure what the above means in practice. If it doesn't guarantee it, does it probabilistically indicate it? Again, what are the semantics of the thing?

[Ballot discuss]
I don't think I have seen a reply to the Chris' review below, part of the OPS-DIR review.

-------- Original Message --------
Subject: Re: [OPS-DIR] Ops directorate review of draft-snell-atompub-tombstones-14.txt
Date: Tue, 7 Feb 2012 05:21:14 -0800
From: Christopher LILJENSTOLPE
To: ops-dir@ietf.org
CC: draft-snell-atompub-tombstones@tools.ietf.org


> Greetings,
>
> I have performed an Operations Directorate review of draft-snell-atompub-tombstones-14.txt
>
> Operations directorate reviews are solicited primarily to help
> the area directors improve their efficiency, particularly when
> preparing for IESG telechats, and allowing them to focus on
> documents requiring their attention and spend less time on the
> trouble-free ones. Improving the documents is important, but
> clearly a secondary purpose. A third purpose is to broaden the
> OpsDir reviewers' exposure to work going on in other parts of
> the IETF.
>
> Reviews from OpsDir members do not in and of themselves cause
> the IESG to raise issue with a document. The reviews may,
> however, convince individual IESG members to raise concern over
> a particular document requiring further discussion. The reviews,
> particularly those conducted in last call and earlier, may also
> help the document editors improve their documents.
>
> ----
>
> Review result:
>
> I believe there is an operational impact in this document, or, at lest a technical issue that may result in operational confusion.
>
> Section 5 discusses digital signatures of a atom removal message.  Specifically, the paragraph:
>
> Section 4.4.2 of [W3C.REC-xmldsig-core-20020212] requires support for
>  DSA signatures and recommends support for RSA signatures.  However,
>  because of the much greater popularity in the market of RSA versus
>  DSA, Atom Processors that verify signed Atom Documents MUST be able
>  to verify RSA signatures, but do not need be able to verify DSA
>  signatures.  Due to security issues that can arise if the keying
>  material for message authentication code (MAC) authentication is not
>  handled properly, Atom Documents SHOULD NOT use MACs for signatures.
>
> Is where I have my issue.  By reading this document, it seems as if we are suggesting an exactly opposite selection of mandatory digital signature algorithms as the W3C does for XML.  W3C MUST's DSA, and SHOULD's RSA, and this draft is suggesting a MUST for RSA and a MAY for DSA.  I would suggest that the authors either consider harmonizing with W3C, or requiring both RSA and DSA.  If not, toolchains created to validate XML signatures may not work in this application.
>
> I also believe that the authors should outline the expected behavior if a processor can validate an XML message signature, and that validation proves that the message is invalid.  There is NO mention that that should be a MUST NOT or SHOULD NOT for further processing of the message.
>
> These could lead to operational behavior issues and should, in my opinion, be addressed before the document is published.
>
> Regards,
> Chris
>
>

[Ballot discuss]
DISCUSS:
I don't think I have seen a reply to the Chris' review below, part of the OPS-DIR review.

-------- Original Message --------
Subject: Re: [OPS-DIR] Ops directorate review of draft-snell-atompub-tombstones-14.txt
Date: Tue, 7 Feb 2012 05:21:14 -0800
From: Christopher LILJENSTOLPE
To: ops-dir@ietf.org
CC: draft-snell-atompub-tombstones@tools.ietf.org


> Greetings,
>
> I have performed an Operations Directorate review of draft-snell-atompub-tombstones-14.txt
>
> Operations directorate reviews are solicited primarily to help
> the area directors improve their efficiency, particularly when
> preparing for IESG telechats, and allowing them to focus on
> documents requiring their attention and spend less time on the
> trouble-free ones. Improving the documents is important, but
> clearly a secondary purpose. A third purpose is to broaden the
> OpsDir reviewers' exposure to work going on in other parts of
> the IETF.
>
> Reviews from OpsDir members do not in and of themselves cause
> the IESG to raise issue with a document. The reviews may,
> however, convince individual IESG members to raise concern over
> a particular document requiring further discussion. The reviews,
> particularly those conducted in last call and earlier, may also
> help the document editors improve their documents.
>
> ----
>
> Review result:
>
> I believe there is an operational impact in this document, or, at lest a technical issue that may result in operational confusion.
>
> Section 5 discusses digital signatures of a atom removal message.  Specifically, the paragraph:
>
> Section 4.4.2 of [W3C.REC-xmldsig-core-20020212] requires support for
>  DSA signatures and recommends support for RSA signatures.  However,
>  because of the much greater popularity in the market of RSA versus
>  DSA, Atom Processors that verify signed Atom Documents MUST be able
>  to verify RSA signatures, but do not need be able to verify DSA
>  signatures.  Due to security issues that can arise if the keying
>  material for message authentication code (MAC) authentication is not
>  handled properly, Atom Documents SHOULD NOT use MACs for signatures.
>
> Is where I have my issue.  By reading this document, it seems as if we are suggesting an exactly opposite selection of mandatory digital signature algorithms as the W3C does for XML.  W3C MUST's DSA, and SHOULD's RSA, and this draft is suggesting a MUST for RSA and a MAY for DSA.  I would suggest that the authors either consider harmonizing with W3C, or requiring both RSA and DSA.  If not, toolchains created to validate XML signatures may not work in this application.
>
> I also believe that the authors should outline the expected behavior if a processor can validate an XML message signature, and that validation proves that the message is invalid.  There is NO mention that that should be a MUST NOT or SHOULD NOT for further processing of the message.
>
> These could lead to operational behavior issues and should, in my opinion, be addressed before the document is published.
>
> Regards,
> Chris
>
>

[Ballot comment]
COMMENT:
I have the same comment as Adrian Farrel: the 3 lines introduction is very very light, and doesn't give much background and references.

[Ballot comment]
No objection.
However, I have the same comment as Adrian Farrel: the 3 lines introduction is very very light, and doesn't give much background and references.

[Ballot comment]
My Comment raised on -14 persists in -15.

I have no objection to the publicaiton of this document. I think that the Introduction could have been more extensive - a good place for citations and explanations.

[Ballot discuss]
I intend to move to Yes, but I've got a couple of concerns with text in section 3:

  An Atom feed MAY contain atom:entry elements and at:deleted-entry
  elements sharing the same atom:id value.  Atom processors SHOULD
  ignore any at:deleted-entry elements sharing an atom:id value with an
  atom:entry whose atom:updated element specifies a date and time more
  recent than or equal to the at:deleted-entry element's when value.

What exactly are the semantics associated with a feed that has both an atom-entry and at:deleted-entry for the same atom:id? Is it something like "marked for delete before purged"? How might this situation come up? I'm worried that there is not enough information in here (and the SHOULD is making me more worried) to be able to implement this in an interoperable fashion. Please explain.

  Implementors should note that the at:deleted-entry element is
  informative in nature only and may be ignored by Atom processors.

I'm not sure what the above means. What is it informative of? Do you really mean "advisory" instead of "informative"? Or do you mean "probabilistic" (which would concern me)? Are you saying that an Atom processor can't rely on an at:deleted-entry?

  The presence of an at:deleted-entry element does not guarantee that
  the atom:entry to which it is referring will no longer be available.

Again, I'm not sure what the above means in practice. If it doesn't guarantee it, does it probabilistically indicate it? Again, what are the semantics of the thing?

[Ballot comment]
Most of s5 and s6 are copied from RFC 4287 can't you just point to RFC 4287 for the text?  In both s5 and s6, it's the last 3 paragraphs.  Was the last paragraph of s6 supposed to be titled signing and encrypting like it was in 4287?

I guess this made sense to the atom folks but those blurbs only talk about the processors of the feed, but where is the requirement for the generator of the feed?  It's great to require that only RSA be supported instead of DSA and that AES-128 CBC be the only choice for the processor, but if the generator uses one of the other allowed W3C allowed algs how do you get interop?

Assuming you import the text from RFC 4287 this is probably moot but ... in the following:

  Section 5.1 of [W3C.REC-xmlenc-core-20021210] requires support of
  TripleDES, AES-128, and AES-256.  Processors that decrypt Deleted
  Entry Documents MUST be able to decrypt with AES-128 in Cipher Block
  Chaining (CBC) mode.

What does the second sentence add?  Was it trying to say that processors only have to support AES 128 CBC because it's the only thing that's going to be used?

Nothing to do on this one: I really hate MACs being characterized as signatures.

Note added 'This document switched from Informational to Standards Track,
because of Robert's DISCUSS suggestion.  But that happened
across the transition to new IESG members, so the document
needs two more positions.  ADs with no positions, please add
your ballot, and I'll put this back on the telechat for 24 May.'

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

Reply-To: ietf@ietf.org

Subject: Last Call:  (The Atom "deleted-entry" Element) to Proposed Standard





The IESG has received a request from an individual submitter to consider

the following document:

- 'The Atom "deleted-entry" Element'

  as a Proposed Standard



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





  This specification adds mechanisms to the Atom Syndication Format

  which publishers of Atom Feed and Entry documents can use to

  explicitly identify Atom entries that have been removed.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-snell-atompub-tombstones/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-snell-atompub-tombstones/ballot/





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

[Ballot discuss]
This is a solid document. Before moving to Yes, I would like to ask if publishing it as Proposed Standard rather than Informational was considered? I don't object to publishing it as Informational, but suggest that Proposed Standard is a better track for it.

[Ballot comment]
I have no objection to the publicaiton of this document. I think that the Introduction could have been more extensive - a good place for citations and explanations.

[Ballot comment]
1. I didn't really get what's meant by

"  When an at:deleted-entry element appears in a Feed document other
than it's source Feed or when an at:deleted-entry element that has a
source Feed document is used in the context of a Deleted Entry
Document, it MUST contain an atom:source element."

But I guess Atom developers probably do so that's ok.

2. Last para of section 6: I guess that if someone did MAC and then
symmetrically encrypt one of these (is that as unlikely as I think?)
then it might be useful to tell them not to use the same key for
both.

3. Digital signatures by themselves do not provide non-repudiation.
Please delete that term.

IANA understands that, upon approval of this document, there is a single
IANA action that must be completed.

In the Application Media Types registry located at:

http://www.iana.org/assignments/media-types/application/index.html

a new application media type will be added as follows:

Type: atomdeleted+xml
Reference: [ RFC-to-be ]

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (The Atom "deleted-entry" Element) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'The Atom "deleted-entry" Element'
  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 2012-02-21. 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


  This specification adds mechanisms to the Atom Syndication Format
  which publishers of Atom Feed and Entry documents can use to
  explicitly identify Atom entries that have been removed.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-snell-atompub-tombstones/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-snell-atompub-tombstones/


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

The PROTO writeup follows.

###

  (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, Peter Saint-Andre, am the document shepherd.

This review covers version -14 of the document. I have reviewed this
version as well as several previous versions.

In my opinion this document is ready for consideration by the IESG.

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

The document has been reviewed by participants in the Atom community via
the atom-syntax@imc.org discussion list (previously used by the ATOM WG).
Archives are here:

http://www.imc.org/atom-syntax/mail-archive/

  (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?

The document has received adequate review.

  (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 interested community has discussed those issues and has
        indicated that it still wishes to advance the document, detail
        those concerns here.

I do not have concerns with the document, and it appears to be needed
since there are implementations.

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

Although it is difficult to declare consensus outside the context of a
working group, based on discussion on the atom-syntax list I would say
that there is strong support for this work and agreement that this
document specifies the right approach.

  (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 and I know of no one who is dissatisfied
with this work.

  (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 checked the document against ID-nits. There are no errors.

The media type registration was reviewed on the ietf-types@ietf.org list.

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

There are only normative references. 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 suggested a reasonable name for the new registry? See
        [I-D.narten-iana-considerations-rfc2434bis]. 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?

The IANA considerations section is up to date and appropriate.

  (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?

The Relax NG schema has been checked using a schema validator.

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

Technical Summary

  This specification adds mechanisms to the Atom Syndication Format
  which publishers of Atom Feed and Entry documents can use to
  explicitly identify Atom entries that have been removed.

Working Group Summary

  This document is not the product of a working group, but has been
  reviewed and discussed on the list of the former ATOM WG.

Document Quality   

  The document has received adequate review. There is agreement
  among the implementation community that this feature is needed
  and that this document defines the right approach. In addition,
  there are existing implementations.

###