On 01/19/2014 08:30 AM, Eliot Lear wrote:
> Jari,
>
> I oppose changes made to the document in the last round as stated
> below. If they remain, I would urge publication as Informational and
> not BCP:
>
>>In particular, architectural decisions, including which existing
>>technology is
On 25/11/14 22:26, Martin Thomson wrote:
> On 25 November 2014 at 07:59, Jari Arkko wrote:
>> I agree with many of these comments (were they observed?) but I also agree
>> with the part about “ship it” :-)
>
> I have not seen a response.
I asked Viktor to produce one. He's rolling the existin
Hi David,
Sorry for the slow response, end of year rush and all that...
And thanks for the review, responses inline and a proto-08
version (handling the various IETF LC comments) is at [1]
with a diff vs. 07 at [2]. I'll plan to publish that as an
official -08 in a few days if there are no comme
ure algorithm
>
> [... nit snipped ...]
>
>>> The minor issue is
>>> whether that is the signature algorithm that's wanted, on which I'll defer
>>> to the crypto experts on that (e.g., I seem to recall a negative saag
>>> comment on PKCS 1.
On 27/12/14 02:44, Black, David wrote:
> in addition to
> what's noted below, -08 also addresses [B]
Oops - yes I did make changes (which are real improvements) there
but didn't note those in my mail. Sorry for the omission - it was
simply due to window-bloat but your comment in that case was
On 05/01/15 21:00, Benjamin Kaduk wrote:
> Hi Meral,
>
> An update is pending which should address your comments, along with some
> comments from the OPS-DIR reviewer and a couple of IESG members.
>
> The responsible AD has given a go-ahead to submit an update of the
> document.
Sigh - apologi
On 23/01/15 02:12, Martin Thomson wrote:
> I definitely want to avoid making prescriptive statements about what to
> protect, even couched as suggestions. However, I think that a more generic
> statement that describes the characteristics of a header that might need
> protection is definitely a g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23/01/15 15:35, Jari Arkko wrote:
>
>> I made a proposal at
>> https://github.com/http2/http2-spec/pull/704
>
> Looked reasonable to me.
Me too. Quibbling, I'd suggest:
OLD:
The decision on whether a header field is sensitive or
not is high
Thanks, we'll pick up editorials as we go, yes.
S
On 09/04/15 12:36, Jari Arkko wrote:
> Thanks for your review, Tom. Have you authors seen these comments?
>
> I have balloted NoObj, but wanted to check that the editorial comments were
> not missed.
>
> Jari
>
> On 30 Mar 2015, at 02:21, Tom
On 26/05/15 22:36, Jari Arkko wrote:
> I assume the authors will work through the nits.
Yep, we'll unpick any nits as required
Ta,
S.
signature.asc
Description: OpenPGP digital signature
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org
Thanks Elwyn,
I've noted those nits as an RFC editor note for now so
they don't get lost.
Cheers,
S.
On 03/07/15 15:01, Elwyn Davies wrote:
> Hi, Viktor.
>
> I had a quick look through the new version 13 and it has addressed
> almost all the various nits I identified and looked at the issues I
Hi Adam,
Can you post a revision of this with those changes before Thursday?
If so, I'll put this on the Sep 3 IESG telechat for approval.
I didn't see any other changes that need to be made as a result of
the IETF LC, but please correct me if that's wrong.
Thanks,
S.
On 18/08/15 01:31, Adam L
On 24/08/15 18:32, Adam Langley wrote:
> On Mon, Aug 24, 2015 at 6:55 AM, Stephen Farrell
> wrote:
>> Can you post a revision of this with those changes before Thursday?
>> If so, I'll put this on the Sep 3 IESG telechat for approval.
>
> Done. https://datatracke
Russ and Suresh have a discussion going on, that I think is almost
resolved. In any case I'll make sure that stuff is handled before
we send to RFC editor. (There are a couple of other threads that'll
result in minor changes too.)
Cheers,
S.
On 02/09/15 20:04, Jari Arkko wrote:
> Suresh, thanks
Hi Brian, Hannes,
On 08/09/15 20:24, Hannes Tschofenig wrote:
>> > The downref to RFC7251 was not mentioned in the last call and that RFC
>> > isn't
>> > in the downref registry. ((Yes, I've been in the IESG and I know how
>> > annoying this can be, but it's a process glitch.))
>> >
> Thanks fo
On 14/09/15 21:10, Brian E Carpenter wrote:
> I promise not to appeal. The downref rules are quite creaky and annoying,
> so I'd support them being overhauled anyway, as long as egregious downrefs
> can still be prevented or appealed.
Yep. Anything can always be appealed of course, and ID nits d
(This combines the distributions for Simon's mail to gen-art
and secdir. I think one thread responding to my question(s)
below will work better.)
Hi Simon, all,
Thanks for the reviews and updates.
Does anyone think we need more review for this or is
it now ready for IESG eval? Modulo one questi
Hiya,
On 10/12/15 07:32, Alejandro Pérez Méndez wrote:
> Dear Roni and chairs of the ABFAB WG,
>
> thank you for the revision. Please, see my responses inline (specially
> the one related to point #2)
>
> El 03/12/15 a las 15:31, Roni Even escribió:
>>
>> I am the assigned Gen-ART reviewer for
Hiya,
Are we all set with this one now?
I won't put it on the Dec17 IESG telechat (as I've already
got a bunch of stuff on that one) but will tee it up for
Jan7 if nobody tells me otherwise.
Thanks,
S.
On 20/11/15 12:29, Simon Josefsson wrote:
> Executive Summary: I have submitted
> https://to
On 11-12-2015 18:10, Klaas Wierenga (kwiereng) wrote:
Hi Stephen,
2.In general I was wondering why this is an Informational
document. It
defines procedures and has normative language.
That sounds like kind of an unfortunate bug. For some reason, it
changed
from Standards Track to Informa
On 14/12/15 10:04, Sam Hartman wrote:
>> "Klaas" == Klaas Wierenga (kwiereng) writes:
>
>
> It's also important that the new LC make a note about the normative
> down-ref to RADIUS over TLS.
>
Good catch - thanks! ID-nits (which I'd not re-run until you reminded
me;-) didn't object to it
2985 is a normative reference in 5750 which is standards track
so I think we can safely claim precedent and I can put 2985 in the
downref registry if nobody objects.
Cheers,
S.
On 11/03/16 18:05, Elwyn Davies wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review T
Hi Roni, and gen-art (other cc's dropped)
So, a gen-art question to the gen-art reviewers :-)
What is the criterion for major issue?
I'd not have thought that the issues below (which do deserve
a response) would be such a big deal. I do get that various
collections of IETFers will disagree abou
On 21/04/16 11:13, Jari Arkko wrote:
> Thanks for the detailed review, Matt!
>
> Authors, have you noted these points?
Not explicitly so far, no, as the review was fairly recent
I think. However, I'll ensure that Paul responds to Matt's
review.
Cheers,
S.
>
> Jari
>
signature.asc
Descrip
Hi Pete,
On 06/09/16 16:55, Pete Resnick wrote:
> However, I believe Suresh was incorrect in suggesting the first "MUST",
> and it should be removed. There is no harm being prevented here. "If a
> client wants X, it MUST send Y" is absolutely no different protocol-wise
> from "If a client wants X
Hi Ondřej,
On 12/12/16 09:38, Ondřej Surý wrote:
> I would be happy to upload next revision after Last Call
> is finished or just let the RFC editors to fix it.
Please do upload a new version at the end of last call
with these and any other non-controversial changes.
Thabks,
S.
smime.p7s
Des
Hi,
Thanks Dale for the detailed review and the discussion.
I've had a read through the resulting thread and don't
see anything that wasn't discussed in the WG that needs
a major change (please do yell if I've missed something),
so I'll leave this on the March 16th IESG telechat for
IESG evaluat
Hi Russ,
I should probably re-read the draft after the latest changes
but ISTM that the crypto-break reason for problems here is
far far less likely than the mucked-up-HSM reason. I think
that means that calling out the more likely reason is perhaps
a better plan.
In addition, (and this is the b
Thanks for the review Ben. Couple of comments below.
Ben Campbell wrote:
> 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
On 11/15/2011 04:38 AM, Brian E Carpenter wrote:
It's been pointed out that there are actually two normative references
to OpenID documents in this draft. The second one is
http://openid.net/specs/openid-simple-registration-extension-1_0.html
which is also an XML2RFC document.
There's also a r
Hi Klaas,
Looks like those would justify a revised ID. If you've
time to do that in the next week then please go ahead
and shoot out a new version. IESG folk won't have
started reviewing it before then probably and this
review would probably generate a discuss or comment
we'd want to fix anyway.
metic.
Well, at least he now has the choice and won't be peeved
if your new one pops out when he half-way done;-)
S.
Klaas
On Jan 6, 2012, at 11:08 AM, Stephen Farrell wrote:
Hi Klaas,
Looks like those would justify a revised ID. If you've
time to do that in the next week t
vious reference to RFC 2818 was
changed to RFC 6125 in draft 14 at the request of Security Area
Director Stephen Farrell.
I've quickly chatted with Stephen and he said that he only asked the
question and didn't necessarily instructed the WG to do the change from
RFC 2818 to RFC 6125. Keepi
have just done the update. Diff from previous version:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-hokey-erp-aak-08
Would you like to go ahead?
Regards!
-Qin
- Original Message -
From: "Stephen Farrell"
To: "Tina TSOU"
Cc:;
Sent: Wednesday, February 08, 2012 7:41 PM
Hi,
On 05/28/2012 10:01 PM, ssakane wrote:
> All,
>
> I have corresponded all you suggested, and made a new version of the draft.
> But, I haven't submitted it yet.
>
> Corresponding to Alexey's review, I have merged both client operation
> and server operation into a single section: client and
Thanks Francis,
Fixed in working copy [1] other than #authors.
Cheers,
S.
[1] http://down.dsg.cs.tcd.ie/misc/draft-farrell-decade-ni.txt
On 07/09/2012 02:15 PM, Francis Dupont wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
>
>
Folks. Please don't develop any new revisions for these
documents right now. I know you can't officially post
'em anyway, but I don't want us to get tempted to roll
new versions handling unrelated comments. (Alexey's
comments are not unrelated.)
I'd like to handle any tweaks needed as RFC editor
On 03/01/2013 12:11 PM, Francis Dupont wrote:
>> > > - 1 page 5: misbehaviours -> misbehaviors
>> > > (and 3.3 page 16, and others too)
>> >
>> > I am not American.
> => nor I am: I just applied an american English spell checker and
> reported what it considered as spelling errors. Note t
FYI, I started the same discussion on the secdir list. [1]
I'll summarise to the IESG when appropriate.
S.
[1] http://www.ietf.org/mail-archive/web/secdir/current/msg03968.html
On 05/23/2013 11:28 PM, Jari Arkko wrote:
> Thanks again for all your hard work in doing the reviews. They make it
>
On 10/02/2020 19:56, Eric Rescorla wrote:
> https://blog.mozilla.org/security/2020/01/21/crlite-part-3-speeding-up-secure-browsing/
Nice! Hope the experiment goes well as it seems
a good-looking idea. Bit of a pity this mechanism
also pushes towards more centralisation, (IIUC). But
on balance,
On 25/11/2020 11:46, Mohit Sethi via Datatracker wrote:
Reviewer: Mohit Sethi
Review result: Ready
Thanks. Will look at those nits when next editing.
Cheers,
S.
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being proce
41 matches
Mail list logo