I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments you may
receive.
Document: draft-ietf-pkix-caa-10
Reviewer: Richard
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-nfsv4-federated-fs-admin-11
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-appsawg-about-uri-scheme-05
Forgot to copy gen-art.
Begin forwarded message:
From: Richard L. Barnes rbar...@bbn.com
Subject: Gen-ART review of draft-ietf-dnsext-dnssec-bis-updates-18
Date: May 25, 2012 5:02:28 PM EDT
To: IESG i...@ietf.org, i...@ietf.org
Cc: draft-ietf-dnsext-dnssec-bis-upda...@tools.ietf.org
I am
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Document: draft-ietf-oauth-v2.txt
Reviewer: Richard Barnes
Review Date: 10 Apr 2012
IETF LC End Date:
IESG Telechat Date: 12 Apr 2012
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-payload-rtp-klv-02
Reviewer:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-6lowpan-nd-18
Reviewer:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document:
Hi David,
Thanks for your review. Glad to provide clarification on these points.
Responses inline below. Let me know if these address your concerns.
--Richard
This draft specifies policy URIs for management of privacy policy for location
information obtained and maintained by Location
Hi David,
Thanks for your review. Glad to provide clarification on these points.
Responses inline below. Let me know if these address your concerns.
--Richard
This draft specifies policy URIs for management of privacy policy for location
information obtained and maintained by Location
Section 5.6, Note that a particular text frame might include a partial
UTF-8 sequence, however the whole message MUST contain valid UTF-8
This requirement is meaningless, since the concept of a message is not
defined here. Suggest going back to a requirement that a frame MUST contain
No, you have to process at most three bytes, four if you include the opcode.
See sample code.
--Richard
On Sep 6, 2011, at 10:47 AM, Willy Tarreau wrote:
On Tue, Sep 06, 2011 at 10:43:38AM -0400, Richard L. Barnes wrote:
Clearly it already has to be WebSocket aware, and it already has
Section 2, Implementations MAY impose implementation-specific limits...
This paragraph has been removed in -13.
No, it got moved to its own section Implementation-Specific Limits under
the Security Considerations
Yeah, sorry, wrote that before I got to the Security Considerations :)
On Sep 6, 2011, at 10:58 AM, Tobias Oberstein wrote:
In contrast, *not* requiring breaking at UTF-8 code points means that clients
can't do any meaningful validation on text frames. Which means you might
as well get rid of text frames entirely.
Why?
You can do streaming validation of
I strongly propose changing the meaning of 1007 status code from:
1007 indicates that an endpoint is terminating the connection
because it has received data that was supposed to be UTF-8 (such
as in a text frame) that was in fact not valid UTF-8 [RFC3629].
to:
1007
While the MAY doesn't specify a requirement, it seems like it would be
helpful to implementers in light of the exhaustion/DoS possibilities
presented by huge frames and fragmentation. I would even argue that it
Why should that impose exhaustion/DoS possibilities?
A WS impl. offering a
Well, ok. No state related to UTF-8. Any intermediary that deals with
fragmentation will have to remember the opcode/extensions.
--Richard
On Sep 6, 2011, at 12:38 PM, Bjoern Hoehrmann wrote:
* Richard L. Barnes wrote:
If frames are valid utf-8, then you don't need to keep any state
In total:
3 bits: opcode of first frame
1 bit: continuation state
4 bit: UTF-8 DFA state
1 octet state
forgot of course:
for servers:
client mask (4 octets)
last frame end % 4 : 2 Bits = to know where within mask to start for
unmasking the next masked frame
to SlowLoris if
they imposed limits on the number of HTTP headers of the length of time that a
request must take? All I'm suggesting is that this document suggest similar
good habits.
--Richard
On Sep 6, 2011, at 1:37 PM, Iñaki Baz Castillo wrote:
2011/9/6 Richard L. Barnes rbar...@bbn.com
While the MAY doesn't specify a requirement, it seems like it would be
helpful to implementers in light of the exhaustion/DoS possibilities
presented by huge frames and fragmentation. I would even argue that it
should be a SHOULD.
I am Ok with changing MAY to SHOULD.
I'm
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-lisp-map-versioning-02.txt
Hey all,
I was selected for the Gen-ART review of draft-ietf-hybi-thewebsocketprotocol,
and submitted a review during IETF LC:
Since it's coming up for telechat, I thought I would give it a second look.
Comments on the diff are below.
--Richard
Section 2, Implementations MAY impose
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments you may
receive.
Document: draft-ietf-yam-rfc44099bis-02
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-opsawg-mib-floats-02.txt
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document:
mentioned.
Thanks,
Zhenkai
On Feb 28, 2011, at 5:45 PM, Richard L. Barnes wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please wait for direction from your document
That's fine, just thought it would be an interesting area to discuss.
--Richard
On Mar 7, 2011, at 3:36 PM, Lixia Zhang wrote:
On Mar 7, 2011, at 12:22 PM, Richard L. Barnes wrote:
Zhenkai,
Thanks for following up. With regard to security/NATs: These could be
relevant in your
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document:
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments you may
receive.
Document: draft-groves-sakke-00
Reviewer: Richard
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments you may
receive.
Document: draft-ietf-avt-srtp-big-aes-05
Reviewer:
Hey Adam,
Thanks for following up. Responses inline.
[S8.6] Many of these integrity issues are caused by user agents accepting
cookies from outside the context where they would send them, in particular
with the Secure and Path attributes. It seems like this document, in
specifying the
Hey Adam,
I'm OK letting the remainder of these go as you prefer. Thanks for working
this through with me.
--Richard
On Nov 29, 2010, at 7:04 PM, Adam Barth wrote:
On Mon, Nov 29, 2010 at 3:18 PM, Richard L. Barnes rbar...@bbn.com wrote:
Minor issues:
[General] It would be very
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments you may
receive.
Document: draft-ietf-httpstate-cookie-18
Reviewer:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft. For background on Gen-ART, please see the FAQ
at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq
Please resolve these comments along with any other comments you may receive.
Document:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-tcpm-urgent-data-06
Francis,
Thanks for your review. We'll try to get the issue you note resolved
with RFC editor notes.
--Richard
On Jul 19, 2010, at 10:56 AM, Francis Dupont wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
36 matches
Mail list logo
