Down below, for the proposed HTTP/2.0 work it says:
* Reflecting modern security requirements and practices
In some earlier discussion I asked what modern means
there. It seems to mean at least working well with TLS,
but I'm not sure what else is meant, if anything.
In particular, I think
On 2012-02-21 19:26, Stephen Farrell wrote:
Down below, for the proposed HTTP/2.0 work it says:
* Reflecting modern security requirements and practices
In some earlier discussion I asked what modern means
there. It seems to mean at least working well with TLS,
but I'm not sure what else is
On 02/21/2012 06:33 PM, Julian Reschke wrote:
On 2012-02-21 19:26, Stephen Farrell wrote:
Down below, for the proposed HTTP/2.0 work it says:
* Reflecting modern security requirements and practices
In some earlier discussion I asked what modern means
there. It seems to mean at least
On 2012-02-21 19:37, Stephen Farrell wrote:
...
I believe this should be orthogonal to HTTP/2.0. Is there a specific
thing that makes it impossible to use the existing authentication
framework?
Who knows? We don't have a protocol on the table yet. I
would imagine that some level of backwards
Joe,
Thank you for your review.
My responses are indented, below...
On Feb 13, 2012, at 5:00 PM, Joe Touch wrote:
Hi, all,
I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the
On Feb 13, 2012, at 5:16 PM, Joe Touch wrote:
Hi, all,
One additional transport suggestion:
- it would be useful to include recommended configurations for TCP
connections. Given these are multi-byte request/response exchanges, Nagle
should be disabled, e.g.
One of the
On Feb 17, 2012, at 5:47 PM, Joe Touch wrote:
Thanks. In this case, it's important to suggest why others should not add
conventional DHCP query support to the TCP port.
The idea of doing DHCP stateful autoconfiguration over TCP is nonsensical: DHCP
clients start out with no IP address, so it is
Jari,
I appreciate that brevity is desirable. I think in this case, the compression
process may have been unintentionally lossy. Let me say what in my view was
lost:
1. In discussions within the LISP WG it's frequently stated that
experimentation will resolve some disputed question. Given
On Thu, Feb 16, 2012 at 00:52, Livingood, Jason
jason_living...@cable.comcast.com wrote:
To be more specific, at least section 5.5 (it is unclear
how implementers will judge when the network conditions will have
changed sufficiently to justify turning off DNS Resolver Whitelisting
Hi,
I'm looking for the better understanding for the RFC 2560 Online Certificate
Status Protocol - OCSP.
The section 4.1 defines the ASN.1 structure for the OCSP request. Follows the
shortened structure.
OCSPRequest
TBSRequest
OPTIONAL Signature,
where the signature is marked as
On 2/21/12 2:54 AM, Lorenzo Colitti
lore...@google.commailto:lore...@google.com wrote:
I think the suggested change does not go far enough. The high-service-level
domains that prompted this draft to be written, and all the implementers I'm
currently aware of, are decommissioning the practice.
Robert Hernady wrote:
I'm looking for the better understanding for the
RFC 2560 Online Certificate Status Protocol - OCSP.
The section 4.1 defines the ASN.1 structure for the OCSP request.
Follows the shortened structure.
OCSPRequest
TBSRequest
OPTIONAL Signature,
where the
I wanted to inform the community of the results of the second Last Call
issued for draft-ietf-sieve-convert and
draft-ietf-sieve-notify-sip-message. To remind you of the circumstances:
After these two documents were approved by the IESG and sent on to the
RFC Editor, an IPR disclosure was made
Hi Julian,
On 02/21/2012 06:50 PM, Julian Reschke wrote:
On 2012-02-21 19:37, Stephen Farrell wrote:
...
I believe this should be orthogonal to HTTP/2.0. Is there a specific
thing that makes it impossible to use the existing authentication
framework?
Who knows? We don't have a protocol on
browser id, openid, and oauth are all authentication frameworks built
on top of HTTP
OAuth is an authorization framework, not an authentication one. Please be
careful to make the distinction.
What we're looking at here is the need for an HTTP authentication system
that (for example) doesn't
On 22/02/2012, at 9:19 AM, Stephen Farrell wrote:
Hi Julian,
On 02/21/2012 06:50 PM, Julian Reschke wrote:
On 2012-02-21 19:37, Stephen Farrell wrote:
...
I believe this should be orthogonal to HTTP/2.0. Is there a specific
thing that makes it impossible to use the existing
[in-line]
On Tue, Feb 21, 2012 at 2:40 PM, Mark Nottingham m...@mnot.net wrote:
And then should it include adding some new options
or MTI auth schemes as part of HTTP/2.0 or even looking
at that? (I think it ought to include trying for that
personally, even if there is a higher-than-usual
On 02/21/2012 10:40 PM, Mark Nottingham wrote:
On 22/02/2012, at 9:19 AM, Stephen Farrell wrote:
So as in my initial mail the 1st question here is, what
does modern mean in this draft charter? E.g. does it
mean same as the current framework with different
bits or something else? If so,
Stephen,
The approach we're advocating for this WG is to solicit well-formed proposals,
select one and develop it.
If there isn't one for HTTP authentication, how are you advocating we proceed?
Regards,
On 22/02/2012, at 9:53 AM, Stephen Farrell wrote:
On 02/21/2012 10:40 PM, Mark
We like to see interoperability reports contain information about features of a
protocol that are used vs. unused, so that if and when the protocol seeks
advancement along the standards track, we can decide whether we want to keep it
in the revision.
Should we consider a protocol feature only
On 02/21/2012 10:55 PM, Mark Nottingham wrote:
Stephen,
The approach we're advocating for this WG is to solicit well-formed proposals,
select one and develop it.
If there isn't one for HTTP authentication, how are you advocating we proceed?
I'm not thinking now in terms of advocating a
Seems like it depends on your definitions of abusive and legitimate. Do
you have an example?
On Feb 21, 2012, at 5:56 PM, Murray S. Kucherawy wrote:
We like to see interoperability reports contain information about features of
a protocol that are used vs. unused, so that if and when the
Barry == Barry Leiba barryle...@computer.org writes:
Barry OAuth is an authorization framework, not an authentication
Barry one. Please be careful to make the distinction.
Barry What we're looking at here is the need for an HTTP
Barry authentication system that (for example)
On Tue, 21 Feb 2012, Michael Richardson wrote:
Barry == Barry Leiba barryle...@computer.org writes:
Barry OAuth is an authorization framework, not an authentication
Barry one. Please be careful to make the distinction.
Barry What we're looking at here is the need for an
The IESG has received a request from the Decoupled Application Data
Enroute WG (decade) to consider the following document:
- 'DECoupled Application Data Enroute (DECADE) Problem Statement'
draft-ietf-decade-problem-statement-05.txt as an Informational RFC
The IESG plans to make a decision in
Thank you for testing the new Datatracker. You have uncovered several bugs,
and they have all been fixed.
We still want to achieve a nearly unnoticeable change-over, so please make sure
the Datatracker fully supports the way that you use the current Datatracker.
Unless a significant bug is
A modified charter has been submitted for the Hypertext Transfer
Protocol Bis (httpbis) working group in the Applications Area of the
IETF. The IESG has not made any determination as yet. The modified
charter is provided below for informational purposes only. Please send
your comments to
The Basic Level of Interoperability for SIP Services (bliss) working
group in the Real-Time Applications and Infrastructure Area of the IETF
has been rechartered. For additional information, please contact the
Area Directors or the working group Chairs.
Basic Level of Interoperability for SIP
The BiDirectional or Server-Initiated HTTP (hybi) working group in the
Applications Area of the IETF has been rechartered. For additional
information, please contact the Area Directors or the working group
Chairs.
BiDirectional or Server-Initiated HTTP (hybi)
The IESG has approved the following document:
- 'A URN Namespace For The ucode'
(draft-ishikawa-yrpunl-ucode-urn-03.txt) as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Peter Saint-Andre.
A URL of
The IESG has approved the following document:
- 'IPv6 Multihoming without Network Address Translation'
(draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt) as an
Informational RFC
This document is the product of the IPv6 Operations Working Group.
The IESG contact persons are Ron Bonica
The IESG has approved the following document:
- 'Bulk Binding Update Support for Proxy Mobile IPv6'
(draft-ietf-netext-bulk-re-registration-12.txt) as a Proposed Standard
This document is the product of the Network-Based Mobility Extensions
Working Group.
The IESG contact persons are Jari
The IESG has approved the following document:
- 'Source Address Validation Improvement Framework'
(draft-ietf-savi-framework-06.txt) as an Informational RFC
This document is the product of the Source Address Validation
Improvements Working Group.
The IESG contact persons are Jari Arkko and
The IESG has approved the following document:
- 'Prefix Exclude Option for DHCPv6-based Prefix Delegation'
(draft-ietf-dhc-pd-exclude-04.txt) as a Proposed Standard
This document is the product of the Dynamic Host Configuration Working
Group.
The IESG contact persons are Ralph Droms and Jari
The IESG has approved the following document:
- 'Use of SHA-256 Algorithm with RSA, DSA and ECDSA in SSHFP Resource
Records'
(draft-os-ietf-sshfp-ecdsa-sha2-07.txt) as a Proposed Standard
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG
The IESG has approved the following document:
- 'Authentication-Results Registration Update for SPF Results'
(draft-kucherawy-authres-spf-erratum-02.txt) as a Proposed Standard
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person
The IESG has approved the following document:
- 'Transmission of Syslog Messages over TCP'
(draft-gerhards-syslog-plain-tcp-14.txt) as a Historic
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Dan Romascanu.
A URL of
37 matches
Mail list logo
