Hi Linda,
Secure Frames are *not* decrypted by the SFU. The outer HBH encryption is
decrypted by the SFU, but the point of the E2E encryption is that the SFU
does not have the keys.
The document does not claim to save on SFU processing. For a switching
SFU, the processing should be roughly the
Hi Christer,
Sorry, just now seeing this. Responses inline. PR here:
https://github.com/ietf/perc-wg/pull/165
--RLB
On Sat, Oct 20, 2018 at 6:06 PM Christer Holmberg <
christer.holmb...@ericsson.com> wrote:
> Reviewer: Christer Holmberg
> Review result: Ready with Issues
>
> I am the assigne
Thanks for the review, Russ. Comments below (nothing major); pull request
here for your review:
https://github.com/ietf/perc-wg/pull/163
On Sat, Oct 20, 2018 at 4:24 AM Russ Housley wrote:
> Reviewer: Russ Housley
> Review result: Almost Ready
>
> I am the assigned Gen-ART reviewer for this dr
Hi Dale,
Thanks for the review. Responses inline below; changes in this PR:
https://github.com/ietf-wg-acme/acme/pull/424
On Wed, Apr 18, 2018 at 9:03 PM, Dale Worley wrote:
> Reviewer: Dale Worley
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. The
Hi Dale,
Thanks for the review. Responses inline below; changes in this PR:
https://github.com/ietf-wg-acme/acme/pull/424
On Wed, Apr 18, 2018 at 9:03 PM, Dale Worley wrote:
> Reviewer: Dale Worley
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. The
Hey Mike,
tl;dr: I agree "crit" needs to be required.
If I understand you correctly, you're observing that if the receiving
implementation supports "b64":false, then there's no need for
"crit":["b64"], so it's proper for the JWS to still verify. That
seems pretty tautological, given that the who
On Tue, Jul 8, 2014 at 12:20 PM, Dave Cridland wrote:
> On 8 July 2014 16:49, Romascanu, Dan (Dan) wrote:
>
>> Hi Dave,
>>
>>
>>
>> An implementor of RFC 6120 does not know that the XMPP over Websockets
>> binding option exists at all. It did not exist by the time 6120 was
>> written, so of cou
Hopefully things will go so smoothly :)
On Tue, Dec 17, 2013 at 11:36 AM, Jari Arkko wrote:
> Thanks for the review, Suresh! Magnus & Richard: the document is up for
> the IESG telechat on Thursday, and currently there are no Discusses. Make
> sure we're doing Approved::Revised ID Needed, in ca
This sounds like something we could take up with the RFC Editor?
On Sat, Oct 12, 2013 at 12:51 AM, Dale R. Worley wrote:
> > From: Suresh Krishnan
>
> > Enhancement request
> > ===
> >
> > * Maybe it is too much to ask, but it would be great if the mailing list
> > references c
Hi Stewart,
I think this resolves my issues.
Thanks,
--Richard
On Mon, Apr 8, 2013 at 6:53 AM, Stewart Bryant wrote:
> On 02/04/2013 15:28, Richard Barnes wrote:
>
>> Thanks for following up, and for the re-send. Just to be clear, I do not
>> mean these as blocking po
0:11:22:33:44:55". Is that the
case?)
On Tue, Apr 2, 2013 at 9:10 AM, Stewart Bryant wrote:
> Resending due to Richards change of address.
>
> Stewart
>
>
> On 11/02/2013 23:45, Richard Barnes wrote:
>
> I have been selected as the General Area Review Team
: draft-ietf-mpls-tp-ethernet-addressing-05
Reviewer: Richard Barnes
Review Date: 2013-02-11
IETF LC End Date: 2013-02-18
IESG Telechat date: TBD
Summary: Ready, with a couple of minor questions / clarifications.
Comment:
The document is mostly very clearly written. (Thanks!) It would have
Hey Lou,
That text looks fine to me!
--Richard
On Tue, Feb 5, 2013 at 9:24 AM, Lou Berger wrote:
> Dan/Richard,
>
>
> On 2/4/2013 10:05 PM, Lidan (Dan) wrote:
> > Hi Richard,
> >
> > Thanks for the review of this draft!
> >
> >> Section 2.1. Would be helpful to either include the old formats
: draft-ietf-ccamp-lmp-behavior-negotiation-10
Reviewer: Richard Barnes
Review Date: 2013-02-02
IETF LC End Date: 2012-01-21
IESG Telechat date: 2012-02-07
Summary: Ready, with a couple of minor questions / clarifications.
Comment:
Overall, this document seems very clear and readable. Thanks
.
Document: draft-ietf-ccamp-lmp-behavior-negotiation-06
Reviewer: Richard Barnes
Review Date: 2013-02-02
IETF LC End Date: 2012-01-21
IESG Telechat date: 2012-02-07
Summary: Ready, with a couple of minor questions / clarifications.
Comment:
Overall, this document seems very clear and readable. Thanks
.
Document: draft-ietf-6man-udpzero-06
Reviewer: Richard Barnes
Review Date: 2012-10-08
IETF LC End Date: 2012-10-02
IESG Telechat date: 2012-10-11
Summary: Ready
Comment:
In general, the document is well-written and seems to cover the relevant
considerations well. I agree with Barry's DISCUSS tha
bis-05
Reviewer: Richard Barnes
Review Date: 7 September 2012
IETF LC End Date: 29 August 2012
IESG Telechat date: (unknown)
Summary: Ready
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
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-pcp-base-23.txt
Reviewer: Richard Barnes
Review Date: 27 Feb 2012
IETF LC End Date: 27 Feb 2012
IESG Te
; that use the "http:" URI scheme.
> END
>
> One of my concerns behind wanting this general "SHOULD" is that there's no
> assurance that an "http:" URI will stay confined to the local network that is
> being relied upon to secure it.
>
Hi David,
The penalty for getting a quick response for the first time is that the second
response takes longer :) Inline.
> - The additional text in section 3.1 stating that the policy URI is a shared
> secret with a forward reference to the security considerations section
> removes
Ben,
Thanks for your review. With respect to the HTTP issue you raise, is
your claim that the HTTP binding prevents the use of Digest or Basic
based on this sentence from Section 6.3?
"
HELD error messages MUST be carried by a 200 OK HTTP/HTTPS response.
"
If so, then I think that's a misin
21 matches
Mail list logo