[Gen-art] RE: Review assignments for 19 April 2007

2007-04-17 Thread Mary Barnes 
I've uploaded the reviews received to date and updated the spreadsheets.
Let me know if there's any errors or omissions.

Thanks,
Mary

-Original Message-
From: Barnes, Mary (RICH2:AR00) 
Sent: Thursday, April 12, 2007 9:04 PM
To: 'gen-art@ietf.org'
Subject: Review assignments for 19 April 2007


Hi all,

Here's the assignments for the April 19th, 2007 telechat:
http://www.alvestrand.no/ietf/gen/art/reviewers-070419.html

With the updated spreadsheets:
http://www.alvestrand.no/ietf/gen/art/gen-art.html
http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html

For your convenience, the review boilerplate template is included below.


Mary. 

---

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

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: 
Reviewer: 
Review Date:  
IESG Telechat date: 19 April 2007

Summary:

Comments:





___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art

[Gen-art] Review: draft-ietf-pkix-lightweight-ocsp-profile-09.txt

2007-04-17 Thread Lucy Lynch 
I am the assigned Gen-ART reviewer for: 
draft-ietf-pkix-lightweight-ocsp-profile-08.txt


For background on Gen-ART, please see the FAQ at 
. Please resolve 
these comments along with any other Last Call comments you may receive.


Note that since assignment this document was updated to: 
draft-ietf-pkix-lightweight-ocsp-profile-09.txt and I reviewed the v.09


This draft is basically ready for publication, but has nits that should be 
fixed before publication.


Nits Outstanding:

** Obsolete normative reference: RFC 2246 (ref. 'TLS')
   (Obsoleted by RFC 4346)
** Obsolete normative reference: RFC 3546 (ref. 'TLSEXT')
   (Obsoleted by RFC 4366)

There is a direct reference to "3.6. Certificate Status Request" 
in RFC 3546 inline in the text but a diff on sec 3.6 in 3546 vs 4366 shows 
only a few changes in punctuation and line breaks (see attached). Is there 
a reason why these Refs have not been updated?


History:

The last substantive discussions of this draft on the WG list happened in 
2004.


A Last Call Notice was posted Thu, 15 Jun 2006 (v.05) and Ron Bonica 
reviewed the document at that time: 
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-pkix-lightweight-ocsp-profile-05-bonica.txt 
At that time the document was tagged as Informational. The document moved 
to "Proposed Standard" with v.07.


There have been several DISCUSS tokens set on this document and the 
tracker doesn't show the final resolution but given that Sam and Russ are 
still sitting, I'll assume that their concerns have been addressed. I note 
that David Kessens flagged the use of SHA1 as a requirement in a comment 
and I'm guessing that a change in that requirement would require an 
amendment to the current document if it advances to standard.


Review Comments:

One small area of confusion. Is there a potential for a gap in timely 
update given both a "tolerance period" (sec 3) and "using the 
cache-control:max-age directive (sec 5.1) in time-based calculations ??? 
Sorry if I'm being dense here.


Revision Only Comments:

If/when the document gets another revision, two small changes in sec. 
1.2.1 OCSPResponse Structure


  "In the case a responder does not have the ability to respond"
  ^ where

and

  "case a responder only"
   ^ where


Other Remarks:

Learn something new every time: sec 5 "aka stapling". Cool.


- Lucyhttp://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>

 
 

 
 
 
 
 
 
   
  Diff: 
3546.txt - 4366.txt 
   
   
body{ margin: 0.4ex; margin-right: auto; } 
tr  { } 
td  { white-space: pre; font-family: monospace; vertical-align: top; 
font-size: 0.86em;} 
th  { font-size: 0.86em; } 
.small  { font-size: 0.6em; font-style: italic; font-family: Verdana, 
Helvetica, sans-serif; } 
.left   { background-color: #EEE; } 
.right  { background-color: #FFF; } 
.diff   { background-color: #CCF; } 
.lblock { background-color: #BFB; } 
.rblock { background-color: #FF8; } 
.insert { background-color: #8FF; } 
.delete { background-color: #ACF; } 
.void   { background-color: #FFB; } 
.cont   { background-color: #EEE; } 
.linebr { background-color: #AAA; } 
.lineno { color: red; background-color: #FFF; font-size: 0.7em; text-align: 
right; padding: 0 2px; } 
.elipsis{ background-color: #AAA; } 
.left .cont { background-color: #DDD; } 
.right .cont { background-color: #EEE; } 
.lblock .cont { background-color: #9D9; } 
.rblock .cont { background-color: #DD6; } 
.insert .cont { background-color: #0DD; } 
.delete .cont { background-color: #8AD; } 
.stats, .stats td, .stats th { background-color: #EEE; padding: 2px 0; } 
   
   
   3546.txt  
 4366.txt  
   
  skipping to 
change at line 35 skipping to change at line 
35

ResponderID responder_id_list<0..2^16-1>;   ResponderID responder_id_list<0..2^16-1>;

Extensions  request_extensions;   
Extensions  request_extensions;
} 
OCSPStatusRequest;   } 
OCSPStatusRequest;
   

opaque 
ResponderID<1..2^16-1>;   opaque 
ResponderID<1..2^16-1>;
opaque 
Extensions<0..2^16-1>;   opaque 
Extensions<0..2^16-1>;
   

 In the 
OCSPStatusRequest, the "ResponderIDs" provides a list of OCSPIn the OCSPStatusRequest, the "ResponderIDs" provides a list 
of OCSP
 responders 
that the client trusts.  A zero-length "responder_id_list"responders that the client trusts.  A zero-length 
"responder_id_list"
 sequence has 
the special meaning that the responders are implicitlysequence has the special meaning that the responders are 
implicitly
  
 known to 
the server - e.g., by prior arrangement.  
"Extensions" is aknown to the server, e.g., by prior arrangement.  "Extensions" is a
 DER encoding 
of OCSP request extensions.DER encoding of

[Gen-art] review of draft-shacham-sipping-session-mobility-03.txt

2007-04-17 Thread Francis Dupont 
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-shacham-sipping-session-mobility-03.txt
Reviewer: Francis Dupont
Review Date:  17 April 2007
IESG Telechat date: 10 May 2007?

Summary: Ready

Comments: some details which should be handled by the RFC editor:
 - 2 page 4: expand PSTN abbrev at its first use.
 - I don't really like the last sentence of REQ 1/Page 4
 - 3 page 5: UA is expanded only at its second use (it should be once
   and at the first time).
 - 4 page 6: ie., -> i.e.,
 - 5.2.1.2 page 12: possiblity
 - 5.2.2 page 14: unidectional
 - 5.4 page 23: expand CPL?
 - 6.1 page 24: twice the paragraph "If the CN and the local..."
 - 6.1 page 4 (next paragraph): which need -> which needs?

Regards

[EMAIL PROTECTED]

PS: I believe this is more readdressing than mobility but as SIP is routed
and the Abstract is very clear about the intended meaning of the word
mobility IMHO there is no need to change this.


___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art