Subject: [Gen-art] A *new* batch of IETF LC reviews - 27 April 2006

From: "Mary Barnes" <[email-masked]>
Date: Thu, 27 Apr 2006 07:33:58 -0500

Hi all,

Here's the latest round of LC assignments: 
http://www.alvestrand.no/ietf/gen/art/gen-art.html 
http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html 

I've also updated it with the most recent reviews for today's telechat.
Let me know if I've missed something. 

Thanks, 
Mary. 

--------------------------- 
Reviewer: David Black

- 'IKEv2 Clarifications and Implementation Guidelines'
   <draft-eronen-ipsec-ikev2-clarifications-08.txt> as an Informational
RFC

IETF LC ends on 2006-05-03.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-clarificati
ons-08.t
xt

--------------------------- 
Reviewer: Eric Gray

- 'SIEVE Email Filtering: IMAP flag Extension'
   <draft-ietf-sieve-imapflags-04.txt> as a Proposed Standard

IETF LC ends on 2006-05-04.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sieve-imapflags-04.txt

--------------------------- 
Reviewer: Francis Dupont

- 'Generalized Multi-Protocol Label Switching (GMPLS) Extensions for 
   Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy
(SDH) 
   Control '
   <draft-ietf-ccamp-rfc3946bis-01.txt> as a Proposed Standard

IETF LC ends on 2006-05-04.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc3946bis-01.txt

--------------------------- 
Reviewer: Gonzalo Camarillo

- 'Link Management Protocol (LMP) Management Information Base (MIB) '
   <draft-ietf-ccamp-rfc4327bis-01.txt> as a Proposed Standard

IETF LC ends on 2006-05-09.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc4327bis-01.txt

--------------------------
Reviewer: Joel Halpern

- 'Calendaring Extensions to WebDAV (CalDAV) '
   <draft-dusseault-caldav-12.txt> as a Proposed Standard

IETF LC ends on by 2006-05-24.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-dusseault-caldav-12.txt

--------------------------

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 29 Apr 2006 18:20:28 -0400

I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

This document is almost ready for publication as a Proposed 
Standard.  There is one item that at least requires some improvement 
in the wording, and a minor matter that should be considered.

The text in section 5.3.4 on strong ETags is somewhat 
confusing.  After describing what should happen in the case of 
storing something octet-identical to the PUT, the text then says that 
"the ETag response header is undefined" when the entity stored is not 
octet identical.  My confusion is that the following phrase says that 
"a strong entity tag MUST NOT be returned in the response."  From the 
context, an ETag header is a strong entity tag.  Thus, the first 
portion says that the content or presence of an ETag header in the 
response is not defined, and the second phrase says that it MUST NOT 
be included.  That seems to constitute a pretty clear definition, 
rather than "undefined".  The text needs work.

Further, and more debatable, since this text does not talk about the 
association of the ETag, just about the returning of the ETag, the 
protocol seems to be using the returning of the ETag as a means of 
flagging whether the server changed the content.  That seems an odd 
way of indicating that information.  (Not wrong, just odd.)  Did you 
consider using an additional HTTP header to indicate this 
condition?  At a guess, the motivation for the usage is that the ETag 
does not represent the contents provided in the PUT.  And hence, the 
text is trying to say that the ETag can not be returned in the PUT 
response because it is not actually the ETag for the PUT data (but 
rather for something derived from the PUT data.)  If that is the 
intent, it is defensible, but still seems odd to this reader (who is 
neither an HTTP expert, a WebDav expert, nor an iCalendar 
expert.)   Also, if it is anticipated that this situation is likely 
to be common, then this restriction, and the concomitant extra 
transactions to get the real ETag, would seem counter-productive.

minor: Is the recurrence handling described here consistent with that 
provided by iCalendar?  If so, it would be good to say so.  If not, 
it seems necessary to talk about how the inconsistency ought to be 
addressed. (I suspect that the two are consistent, and this just 
needs a sentence saying so.)

Yours,
Joel M. Halpern