The Atom "deleted-entry" Element
draft-snell-atompub-tombstones-18
Yes
(Barry Leiba)
(Pete Resnick)
(Peter Saint-Andre)
(Robert Sparks)
No Objection
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Jari Arkko)
(Martin Stiemerling)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)
(Wesley Eddy)
Note: This ballot was opened for revision 14 and is now closed.
Barry Leiba Former IESG member
Yes
Yes
(for -15)
Unknown
Pete Resnick Former IESG member
(was Discuss)
Yes
Yes
(for -17)
Unknown
Peter Saint-Andre Former IESG member
Yes
Yes
()
Unknown
Robert Sparks Former IESG member
(was Discuss)
Yes
Yes
(for -15)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2012-05-21 for -15)
Unknown
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 IESG member
(was Discuss, No Objection)
No Objection
No Objection
(2012-06-20 for -15)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -15)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -14)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -14)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -15)
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
(for -15)
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
(for -14)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(for -14)
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(2012-05-19 for -15)
Unknown
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 IESG member
No Objection
No Objection
(2012-02-24 for -14)
Unknown
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 IESG member
No Objection
No Objection
(for -14)
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
(for -15)
Unknown