The Atom "deleted-entry" Element
draft-snell-atompub-tombstones-18

Note: This ballot was opened for revision 14 and is now closed.

(Barry Leiba; former steering group member) Yes

(Pete Resnick; former steering group member) (was Discuss) Yes

(Peter Saint-Andre; former steering group member) Yes

(Robert Sparks; former steering group member) (was Discuss) Yes

(Adrian Farrel; former steering group member) No Objection

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.

(Benoît Claise; former steering group member) (was Discuss, No Objection) No Objection

(Brian Haberman; former steering group member) No Objection

(Gonzalo Camarillo; former steering group member) No Objection

(Jari Arkko; former steering group member) No Objection

(Martin Stiemerling; former steering group member) No Objection

(Ralph Droms; former steering group member) No Objection

(Ron Bonica; former steering group member) No Objection

(Russ Housley; former steering group member) No Objection

(Sean Turner; former steering group member) No Objection

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.

(Stephen Farrell; former steering group member) No Objection

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.

(Stewart Bryant; former steering group member) No Objection

(Wesley Eddy; former steering group member) No Objection