How many are coming? I have me, Scott, Brian, John Loughney that have
confirmed...
Spencer
So, who is making a reservation? Not me...
Brian
Scott W Brim wrote:
On 11/03/2005 10:01 AM, Spencer Dawkins allegedly wrote:
Either Monday or Friday (on Brian's list) would work for me
are being copied.
Summary: this document is on the right track for publication as Proposed
Standard, but some changes may make the document more usable.
Thanks,
Spencer Dawkins
Details:
1. Introduction
We describe elements for providing a business card, references to
the homepage, map
If this satisfies the review, I'm happy to submit it to the I-D editor and
resume the process.
Henning
Spencer Dawkins wrote:
Background for those on the CC list, who may be unaware of GenART:
GenART is the Area Review Team for the General Area of the IETF. We
advise the General Area Director (i.e
Dear Mary,
It's actually easier for me to pick up batches of review assignments - any
idea what kind of latency you usually have in your batches?
Spencer
- Original Message -
From: Mary Barnes [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; gen-art@ietf.org
Sent: Friday, December 02, 2005
Hi, Brian,
Responding as the author of most of the problematic text, and an
unintentional instigator in at least one over-interpretation (so please
filter appropriately)...
Q: I have comments from a Gen-ART reviewer - do I revise the document
immediately?
A: Ask your AD/document shepherd.
Hi, Yetik,
Thanks for the speedy response and for the explanations. It looks like most
of my notes can be closed.
(Please remember to talk to your AD/document shepherd before submitting an
updated draft - Brian and Mark could disagree with my comments - they are
ADs and I am not - and it
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).
Summary: Well, given that this document is being balloted for publication as
Historic, I'm not sure what criteria I should
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).
Summary: This document is very close to being ready for publication as a
Proposed Standard.
Details: I found some text
networks.
Thanks,
Spencer Dawkins
___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
of the process for extending the DHCPoption code
space
in RFC 3924.
I hope that information answers your high-level questions.
I agree with your editorial commentthat the sentence you cite could be
more
clearly worded and I'll be happy to revise it.
- Ralph
On 1/14/06 1:40 AM, Spencer Dawkins [EMAIL
?)
Thanks,
Spencer Dawkins
Other Comments for Editors:
I'm somewhat surprised to see two methods of forward without download
described in Section 2.4 (extended APPEND and BURL/BDAT), because I would
have thought that profiles were trying to prevent this kind of duplication,
but the WG should know
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).
Summary: This document is on the right track for publication as an
Informational RFC. It is also on the right track for
RFCs. Doing major surgery at this point, after WG
consensus, seems excessive.
Thanks,
Spencer
- Original Message -
Spencer Dawkins wrote:
I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no
Dear Mark,
Apparently some Gen-ART review assignments are more random than others :-)
I do share your pain on forgetting the PILC documents, because I hadn't
really been thinking about whether they would be present until I saw RFC
2757 and thought, why is that one in there?, and then started
Just to be complete - this document was very close to being ready for
Informational at 02, and I still think it's OK now.
(I won't annoy the authors or WG chairs this time).
Thanks,
Spencer
___
Gen-art mailing list
Gen-art@ietf.org
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).
Summary: This document is on the right track for publication as a BCP.
Although the document is pretty densely written, it's
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).
Summary: This document is on the right track for publication as a Proposed
Standard. I do have some comments, but overall
Dear Brian,
Nice catch - thanks!
And my apologies (I've never seen a jumbogram on a network trace, so this
was mentally mis-filed).
Spencer
From: Brian E Carpenter [EMAIL PROTECTED]
Specific review comments:
There are a couple of places in the document that refer to 2^31-octet
link MTUs
Hi, Arnt,
I'm ok with most of your responses - just to follow up on a couple of places
where my comment may not have been well-explained...
Spencer
From: Arnt Gulbrandsen [EMAIL PROTECTED]
Spencer Dawkins writes:
I was selected as General Area Review Team reviewer for this
specification
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).
Summary: This document is a relatively minor revision to a Proposed
Standard, and the revisions are reasonable. It's ready
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).
Summary: This document is a fairly significant revision to a Proposed
Standard. The most significant revisions are adding
, by ballot time, so
adding Magnus as well as Jon...
Thanks for the quick turnaround!
Spencer
From: Spencer Dawkins [EMAIL PROTECTED]
To: General Area Review Team gen-art@ietf.org
Cc: [EMAIL PROTECTED]; Bob Braden [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; Jon Peterson
[EMAIL
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).
Summary: This document is almost ready for publication as a Proposed
Standard. I do have a question on Section 5.3, listed
Hi, Simon,
ABSOLUTELY no one asked my opinion about this, but
I was expecting a short, pithy name for each alphabet that would allow
them to be distinguished. I didn't feel that the whole of the section
title constituted a 'name', whereas some of them have (nearly) got
names: base32, etc. I
Hi, Keith,
The changes you propose would would for me.
Thanks especially for your proposed change to 5.3. I don't think a lot of
description is required, just enough to clearly identify what's being
discussed.
Spencer
Spencer,
Thnaks for the comments.
I was selected as General Area
receive.
Thanks,
Spencer Dawkins
___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
with any other Last Call comments you
may receive.
Thanks,
Spencer Dawkins
___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
___
Gen-art mailing list
Gen-art
I do that selectively, not systematically, since what goes in
the tracker as *my* comment needs to be something I will stand
behind. And sometimes (not referring to this case or reviewer
in particular) I decide that the Gen-ART comments aren't of
enough concern to be put in the tracker. My
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ
athttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html.
Summary - this draft is ready for publication as a Proposed Standard. Clear
enough for me to understand.
Thanks,
Spencer
This one is already listed in the tracker as approved, announcement sent -
could you note this in the Review database?
Thanks!
Spencer
p.s. Version 11 did correct the updates and obsoletes text that I choked
on previously, so they fixed the problem that I cared about - thanks!
This draft was approved for publication (at 06), and then pulled from the
RFC Editor queue for revisions to meet requirements of other SDOs, including
OMA. It's being re-Last Called, because of the scope of changes made after
approval.
As the Gen-ART reviewer for 06
I am the assigned Gen-ART reviewer for this draft, currently on an IESG
telechat agenda. For background on Gen-ART, please see the FAQ at
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
other Last Call comments you
may receive.
Thanks,
Spencer Dawkins
Abstract
IKEv2 supports several mechanisms for authenticating the parties,
including signatures with public-key certificates, shared secrets,
and Extensible Authentication Protocol (EAP) methods. Currently,
each endpoint
at these comments along with
any other Last Call comments you may receive.
Thanks,
Spencer Dawkins
p.s. I have no editorial nits for this draft - thanks! It was clean and easy
to understand...
---
- this draft is targeted as a BCP - just seems strange, because it's a lot
more like
Just for completeness - version 13 has turned several SHOULDs with no
conditional text into MUSTs - thank you!
Still ready for publication as a proposed standard.
Thanks,
Spencer
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ
PROTECTED]
To: Spencer Dawkins [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; General Area Review
Team gen-art@ietf.org; Lisa Dusseault [EMAIL PROTECTED]
Sent: Tuesday, August 15, 2006 5:00 PM
Subject: Re: [Gen-art] Gen-ART Review of draft-newman-i18n-comparator-13.txt
Spencer Dawkins
publication.
Thanks,
Spencer Dawkins
1. Introduction
This document specifies operations of the 6PE approach for
interconnection of IPv6 islands over an IPv4 MPLS cloud. The approach
requires the edge routers that are connected to IPv6 islands to be
Dual Stack MP-BGP-speaking routers
Hi, Arnt,
These look good.
Thanks,
Spencer
- Original Message -
From: Arnt Gulbrandsen [EMAIL PROTECTED]
To: Spencer Dawkins [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; General Area Review
Team gen-art@ietf.org; Lisa Dusseault [EMAIL PROTECTED]
Sent: Friday, August
This also looks good.
Thanks,
Spencer
- Original Message -
From: Arnt Gulbrandsen [EMAIL PROTECTED]
To: Spencer Dawkins [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; General Area Review
Team gen-art@ietf.org; Lisa Dusseault [EMAIL PROTECTED]
Sent: Friday, August 18
Hi, Arnt,
I apparently forgot to reply back in March. Sorry.
Spencer Dawkins [EMAIL PROTECTED]
I was thinking about this from the client's perspective (if the collation
doesn't report error, how does the client know to report anything to
someone who might be able to fix the input
look at these comments along with any other Last Call comments you
may receive.
Thanks,
Spencer Dawkins
Before I start - this draft has gotten a fair amount of Last Call traffic,
so I'll try to limit my review to new comments. But I did want to mention
two areas that are important enough
I am the assigned Gen-ART reviewer for this draft. For
background on Gen-ART, please see the FAQ at
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html.
Summary - This document is ready for publication as an Informational RFC.
Thanks,
Spencer
(before
L2VPN and L3VPN split into two working groups). If there is any energy left
for editorial changes, it might be nice to make it more clearly an L3VPN
document - less confusing for the reader, anyway.
Thanks,
Spencer Dawkins
___
Gen-art
-over-l2tpv3-01.txt
Reviewer: Spencer Dawkins
Review Date: 2006-09-22
IETF LC Date: 2006-10-04
IESG Telechat date:
Summary: This draft is almost ready for publication as a Proposed Standard.
Comments: The gaps I saw are mostly in the area of readability, so I don't
expect any of my comments
Hi, Carlos,
Thanks for the quick feedback. I think we can finish this up today.
Please see inline.
Spencer
Spencer,
Thank you for your review and comments. Please see inline.
On 9/22/2006 3:37 PM, Spencer Dawkins allegedly said the following:
I have been selected as the General Area
Hi, Brian,
I would say good to go on this draft, with the editorial changes I
have discussed with Carlos.
Thanks,
Spencer
On 9/25/06, Carlos Pignataro [EMAIL PROTECTED] wrote:
Hi Spencer,
Thanks again, please see inline.
On 9/25/2006 2:59 PM, Spencer Dawkins allegedly said the following
.
Document: draft-ietf-tls-psk-null-02.txt
Reviewer: Spencer Dawkins
Review Date: 2006-10-09
IETF LC Date: 2006-10-19
IESG Telechat date: (not known)
Summary: This document is almost ready to publish as a Proposed Standard.
Although I do have some comments, all of them would fit in an RFC Editor
.
There are no show-stoppers, but there are some places where the text was
not clear to me, that the editors may wish to look at before publication.
My notes follow.
Thanks,
Spencer Dawkins
In section 2.2, I was somewhat lost reading this text - I'm not sure I
understand what abnormal operation
been
accepted, but they weren't showstoppers, and the RFC Editor can catch items
like Existing solutions for localized mobility management fall into three
classes: with only two items in the list that follows, I guess.
Thanks,
Spencer
From: Spencer Dawkins [EMAIL PROTECTED]
Subject: [Gen-art
: draft-ietf-radext-delegated-prefix-05.txt
Reviewer: Spencer Dawkins
Review Date: 8 December 2006
IESG Telechat date: 14 December 2006
Summary: This document is ready for publication as a Proposed Standard.
Comments: All of my Last Call comments for 01 have been addressed (thanks
-sigcomp-impl-guide-09.txt
Reviewer: Spencer Dawkins
Review Date: 2006-12-18
IETF LC End Date: 2006-12-21
IESG Telechat date: (if known)
Summary: This document is almost ready for publication as a Proposed
Standard, although I do have questions and comments for the authors.
Comments
Hi, Adam,
Thanks for the feedback. On your direct response below, if the authors
happened to stick words that sounded like your explanation in during AUTH48,
it would make the rationale for the decision even clearer - which is to say
that the choice the working group made seems very
Hi, Magnus,
I've looked at version 10 of this specification and all my comments from 09
have been addressed. I'm pointing this review to you (as sponsoring AD),
because I'm not sure whether the RFC Editor will know what to do with this
abstract text:
This document (if approved) clarifies
-dnsext-rollover-requirements-04
Reviewer: Spencer Dawkins
Review Date: 2007-01-23
IETF LC End Date: 2007-01-29
IESG Telechat date: (
Summary: This document is almost ready for publication as an Informational
RFC. I have some questions and suggestions, but no objections.
Comments:
3 Background
-hc-over-mpls-protocol-07
Reviewer: Spencer Dawkins
Review Date: 2007-01-30
IETF LC End Date: 2007-07-07
IESG Telechat date: (not known)
Summary: This document is on the right track for publication as Proposed
Standard. I had some questions (please see below), but the quality seemed
very good
they always be so easy, if this works for you :-)
Thanks,
Spencer
- Original Message -
From: Andrew G. Malis
To: Spencer Dawkins
Cc: [EMAIL PROTECTED] ; [EMAIL PROTECTED] ; [EMAIL PROTECTED] ; Jerry Ash ;
Mark Townsley ; ext Cullen Jennings ; General Area Review Team ; Andrew
The AD gets to pick, but I do see small revisions handled with RFC Editor notes.
And thanks!
Spencer
- Original Message -
From: Andrew G. Malis
To: Spencer Dawkins
Cc: [EMAIL PROTECTED] ; [EMAIL PROTECTED] ; [EMAIL PROTECTED] ; Jerry Ash ;
Mark Townsley ; ext Cullen Jennings
Hi, Martin,
Thanks for the quick response. Now I can remember what I was thinking when I
wrote the review...
I deleted everything that we're already good on. Rest is inline.
Spencer
2.5. Fragment Identifier Robustness
Hash sums may specify the character encoding that has been used when
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).
Document: draft-ietf-avt-hc-over-mpls-protocol-08
Reviewer: Spencer Dawkins
Review Date: 2007-03-01
IETF LC End
: draft-ietf-pkix-scvp-31.txt
Reviewer: Spencer Dawkins
Review Date: 02 April 2007
IESG Telechat date: 05 April 2007
Summary: Basically ready for publication, with some questions about 2119
language and a couple of places where the text wasn't clear to me, but
should be fixable with an RFC Editor
: draft-ohara-capwap-lwapp-04
Reviewer: Spencer Dawkins
Review Date: 16 April 2007
IESG Telechat date: 19 April 2007
Summary: Given that this document is an Independent Submission, and will
include an IESG Note pointing to current work in CAPWAP, the General Area
director should vote no-obj
to the shepherd, to the AD and to Gen-ART.
Document: draft-ietf-dhc-dhcpv6-leasequery-00.txt
Reviewer: Spencer Dawkins
Review Date: 06 June 2007
IESG Telechat date: 07 June 2007
Summary: On the right track with open issues described in the ID Tracker
under other ADs
Comments:
I agree with Lars' suggestion
-pana-15
Reviewer: Spencer Dawkins
Review Date: 2007-6-14
IETF LC End Date: 2007-06-07 (my bad)
IESG Telechat date: 2007-06-21
Summary: This document is almost ready for publication as a Proposed
Standard. I do have some questions, but almost all involve either
clarifications beyond nits or 2119
Hi, Alper,
(1) I've already pointed out to Mary that if I was late enough on the Last
Call review, it magically turned into the first review for this coming
telechat :-( Sorry!
(2) Because I started out with the Last Call review template, I didn't use
the please wait for your AD before
Hi, Alper,
(adding the security ADs as a heads-up on the last item in this note, just
because we're less than a week away from the telechat date for this
document).
Hi Spencer,
Mark said if we can revise the spec by Monday, he can pass the revision to
the IESG. Otherwise I guess either we
Hi, Alper,
Skipping stuff where we were mostly in sync before...
There is a confusion here, and let's see if we can improve the document to
prevent it.
There is either a secure channel (against eaves-dropping and spoofing)
prior
to running PANA (as in cdma2K and DSL networks), or one has to
Document: draft-ietf-lemonade-rfc2192bis-08
Reviewer: Spencer Dawkins
Review Date: 2007-08-02
IETF LC End Date: 2007-06-28 (yes, this review is late).
IESG Telechat date: 2007-08-23
Summary: This document is close to being ready for publication as a Proposed
Standard, but there is some more
Document: draft-hunt-avt-rtcpxnq-00
Reviewer: Spencer Dawkins
Review Date: 2007-08-03
IETF LC End Date: 2007-08-07
IESG Telechat date: Not known
Summary: This document is ready for publication as an Informational RFC.
Comments: I did find two points odd about this draft - some metrics (vrange
).
Thanks,
Spencer
From: Alexey Melnikov [EMAIL PROTECTED]
Spencer Dawkins wrote:
Document: draft-ietf-lemonade-rfc2192bis-08
Reviewer: Spencer Dawkins
Review Date: 2007-08-02
IETF LC End Date: 2007-06-28 (yes, this review is late).
IESG Telechat date: 2007-08-23
Abstract
This document
Hi, Alexey,
Just a follow-up note - I'm good with the proposed text as you describe it
(Gen-ART reviewer is happy).
I'm still somewhat confused about unpredictable mailbox access keys, but I
better understand your point (128 bits of entropy is the important part).
Thanks for working with me
Document: draft-ietf-manet-iana-05.txt
Reviewer: Spencer Dawkins
Review Date: 2007-08-15
IETF LC End Date: 2007-08-18
IESG Telechat date: 2007-09-06
Summary: This document looks ready for publication as a Proposed Standard.
Comments:
https://datatracker.ietf.org/idtracker/draft-ietf-manet
Document: draft-ietf-lemonade-rfc2192bis-09
Reviewer: Spencer Dawkins
Review Date: 2007-08-17
IETF LC End Date: 2007-06-28 (for 08)
IESG Telechat date: 2007-08-23
Summary: This document is ready for publication as a Proposed Standard
Comments:
My questions and comments from the 08 Gen-ART
Document: draft-ietf-pana-pana-18
Reviewer: Spencer Dawkins
Review Date: 17 Sept 2007
IESG Telechat date: 20 Sept 2007
Summary: This document is ready for publication as a Proposed Standard.
Comments: I would love to see a clarification in 4.1, as follows, but even
if the ADs agree
Hi, Alper,
The text you are pointing to is extremely helpful. It seems appropriate to
explicitly point to the framework draft in sections 4.1 and 5.6, with
something like
For reasons described in section 3 of [PANA-FRAMEWORK] (or whatever the
reference turns out to be), the PaC may need to
: draft-wilde-text-fragment-08
Reviewer: Spencer Dawkins
Review Date: 28 Sept 2007
IESG Telechat date: 04 Oct 2007
Summary: This document is ready for publication as a Proposed Standard, with
some whining.
Comments: The authors have been very responsive in resolving most of my Last
Call review
-unicode-escapes-06.txt
Reviewer: Spencer Dawkins
Review Date: 2007-11-08
IETF LC End Date: 2007-11-15
IESG Telechat date:
Summary: This document is ready for publication as a BCP, with one question
and one comment for the sponsoring AD. I should also mention that the
document is very clear
.
Document: draft-cheshire-ipv4-acd-05.txt
Reviewer: Spencer Dawkins
Review Date: 2007-11-14
IETF LC End Date: 2007-11-23
IESG Telechat date: (not known)
Summary: This document is ready for publication as a Proposed Standard.
Comments: Any draft that was added by Steve Coya, was DISCUSSed by Randy
Bush
Sudden burst of insanity - I was interrupted when I was typing this part of
the review, and now realize that in
Spencer: Section 2.2 talks about timeout values that you DO expect to
change, but some of these are number of PPP packets - you might point
out
PPP doesn't look like generic
Have we penciled in a lunch date yet?
Thanks,
Spencer
___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
: draft-ietf-shim6-hba-04
Reviewer: Spencer Dawkins
Review Date:
IETF LC End Date: 2007-11-23
Summary: This document is on the right track, but in some places is just not
clear enough for publication yet. I'll call Russ's attention to my comments
about Perform duplicate address detection if required
Document: draft-ietf-sip-uri-list-message-02.txt
Reviewer: Spencer Dawkins
Review Date: 2007-11-28
IETF LC End Date: 2007-12-10
IESG Telechat date: (not known)
Summary: This document is on the right track for publication as a Proposed
Standard, but some open issues remain (see comments
Hi, Miguel,
Thanks for the quick response while I can still remember what I was thinking
when I did the review. I think we're almost completely good. There are some
places I'm not sure I commented clearly - let me try again.
Thanks,
Spencer
REQ-2: It MUST be possible for the
with the specification.
Thanks!
Spencer
Spencer:
Thanks for the review. Inline discussion.
Spencer Dawkins wrote:
Hi, Miguel,
Thanks for the quick response while I can still remember what I was
thinking when I did the review. I think we're almost completely good.
There are some places I'm not sure I
Spencer,
thanks for the review
see comments below...
El 24/11/2007, a las 3:59, Spencer Dawkins escribió:
For multihoming applications, it is also relevant to verify if a
given HBA address belongs to a certain HBA set. An HBA set is
identified by a CGA Parameter Data structure
additional suggestion below, based on text that Marcelo
proposed as a response to my previous review, but it was a nit. If anyone
agrees, and still remembers by AUTH48 time, it could easily be changed then.
Thanks,
Spencer
- Original Message -
From: Spencer Dawkins [EMAIL PROTECTED
-rfc2026-changes-02
Reviewer: Spencer Dawkins
Review Date: 2008-02-14
IETF LC End Date: 2008-02-18
IESG Telechat date: (if known)
Summary: This document is a very reasonable contribution to IETF process
discussion, but these changes need to be much more widely reviewed, and I'd
much prefer
: draft-melnikov-imap-search-res-07.txt
Reviewer: Spencer Dawkins
Review Date: 15 Feb 2008
IESG Telechat date: 21 Feb 2008
Summary: Ready for publication as a Proposed Standard
Comments: My comments from Last Call review for 06 have been addressed in
this version
-imapext-sort-19.txt
Reviewer: Spencer Dawkins
Review Date: 2008-02-28
IETF LC End Date: 2008-03-04
IESG Telechat date:
Summary: This document is ready for publication as a Proposed Standard
Comments: Mark Allman said ready for publication as a proposed standard in
March 2004, reviewing -14. I saw
-sha2-03.txt
Reviewer: Spencer Dawkins
Review Date: 2008 02 28
IETF LC End Date: 2008-03-07
IESG Telechat date: (if known)
Summary: This document isn't ready for publication as a Proposed Standard -
it's got enough cut-and-paste errors and apparently-omitted text that I'd
think twice about trying
-Original Message-
From: Spencer Dawkins [mailto:[EMAIL PROTECTED]
Sent: Friday, February 29, 2008 12:27 AM
To: General Area Review Team
Cc: Sean Turner; Blake Ramsdell; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Gen-ART Review of draft-ietf-smime-sha2-03.txt
I have been selected
Hi, Harald,
Thanks for the quick feedback (Gen-ART reviewers like this because we can
remember writing the review, and at least part of what we were thinking
about :-)
Looks like mostly goodness. If we're in synch, I dropped it from this
e-mail.
Spencer
1.2. Relation to other standards
Hi, Bharat,
I'm getting
The following message to [EMAIL PROTECTED] was undeliverable.
The reason for the problem:
5.1.0 - Unknown address error 550-'5.1.1 [EMAIL PROTECTED]... User unknown'
for your co-author... it would be great if that got updated, too.
Thanks,
Spencer
Hi, Bharat,
What follows is my suggestion only, so please filter it appropriately...
5. Definitions
pimBsrCandidateRPStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
The status of this row, by
Hi, Eric,
Inline. Sorry for the delay.
No problem. I deleted everything we're in synch on.
o Disposition type: the type of IMDN that can be requested. This
specification defines three, namely delivery, processing and
read disposition types.
Spencer (nit): I understand
-base-08
Reviewer: Spencer Dawkins
Review Date: 2008-04-30
IETF LC End Date: 2008-05-07
IESG Telechat date: (if known)
Summary: This document is almost ready for publication as a Proposed
Standard.
Comments: I have a small number of review comments that involve 2119
language.
There are a small
Spencer:
Does -07 resolve your concerns?
Russ
Hi, Russ,
Version 07 (with the RFC Editor Notes that are currently in the tracker)
resolves my concerns. My apologies for not saying so, anywhere you would
have seen it (discussions were off-list, did not go to Gen-ART).
Ready for publication
-sieve-refuse-reject-07
Reviewer: Spencer Dawkins
Review Date: 2008-08-10
IETF LC End Date: 2008-08-10 (oops!)
IESG Telechat date: N/A
Summary: Almost ready for publication as a Proposed Standard. I have some
clarity questions below, and two technical questions involving 2119 language
...
Comments
-forces-mib-07
Reviewer: Spencer Dawkins
Review Date: 2008-09-01
IETF LC End Date: 2008-09-08
IESG Telechat date: (not known)
Summary: This document is very close to ready for publication as a Proposed
Standard. I have two technical comments below, but both are minor issues
that could resolved
OK...
Summary: This document is very close to ready for publication as a
Proposed
Standard. I have two technical comments below, but both are minor issues
that could resolved in AUTH48 if you think they have merit.
An aside: The purpose of AUTH48 state is not (should not be) to resolve
even
Hi, Robert,
Thanks for the quick response on all the comments - to be explicit, version 8
addresses all my comments, except for one question (below).
It actually could be OK to retain the OtherMsg name and definition, if there is
a reason to do so (one reason might be deployed systems use this
1 - 100 of 196 matches
Mail list logo
