Hi
On 2011-1-27, at 2:12, Cullen Jennings wrote:
Big Issues 1: I don't like mandating one port for secure and not secure
versions of a protocol
I don't think this reflects IETF consensus given the number of protocols that
deliberately choses to use two ports. I also don't think that it is
--On Thursday, January 27, 2011 09:41 +0200 Gonzalo Camarillo
gonzalo.camari...@ericsson.com wrote:
Hi,
yes, I also agree the first one is the most important point
and has not been addressed so far. If we want a system that
works (and is used), it needs to include incentives to move
from
Cullen Jennings skrev 2011-01-27 01:12:
I'm really glad to see this draft in LC at long last and it is a great
improvement to the current situation - thank you to all the people that
put work into this. I have two significant problems with it that I think
should be resolved before being
On Jan 27, 2011, at 09:52, Lars Eggert wrote:
all new protocols should
be security-capable
Sure.
How is this relevant?
In some protocols, there is value to use them without communication security
(think TLS) for some applications, and with communication security for others.
We used to
On 2011-1-27, at 11:20, Carsten Bormann wrote:
With UDP-based protocols, it is harder to do this.
Please look at section 7.3 of
http://tools.ietf.org/html/draft-ietf-core-coap-04.html#section-7.3
and tell us whether this is how you would like this to be handled for
UDP-based
Roni
Thanks for the nit-catching.
I assume you RFC5087 not as a reference means you quote RFC5087 not as a
reference.
Due to Adrian's DISCUSS we are going to have to respin after the LC;
I will fix all the nits you mention (and Russ' nit as well) at that time.
Y(J)S
From: Roni Even
Cullen:
Big Issues 1: I don't like mandating one port for secure and not secure
versions of a protocol
I don't think this reflects IETF consensus given the number of protocols that
deliberately choses to use two ports. I also don't think that it is a good
idea in all cases. I believe
On 1/27/11 8:12 AM, IETF Chair wrote:
Originally, two ports were assigned for plain and over-TLS, which for HTTP
mapped to two different URL schemes: http and https.
Many people thought that this was a waste of a port, and the STARTTLS approach
was developed. You say that it does not work in
On 1/27/11 8:41 AM, Paul Hoffman wrote:
On 1/27/11 8:12 AM, IETF Chair wrote:
Originally, two ports were assigned for plain and over-TLS, which for
HTTP mapped to two different URL schemes: http and https.
Many people thought that this was a waste of a port, and the STARTTLS
approach was
And what happens when we have ProtocolX over SSH and ProtocolX over TLS?
Must they share a port, with ProtocolX, which has been quietly using its
assigned port for
20 years?
Tom Petch
- Original Message -
From: Lars Eggert lars.egg...@nokia.com
To: Cullen Jennings flu...@cisco.com;
On 2011-1-27, at 18:58, t.petch wrote:
And what happens when we have ProtocolX over SSH and ProtocolX over TLS?
Must they share a port, with ProtocolX, which has been quietly using its
assigned port for
20 years?
No. The expert reviewer can obviously assign a second port in that case (if
On 1/26/2011 7:29 PM, Scott O. Bradner wrote:
2/ I think the proposal must specifically deal with the 2026 IPR licence
requirement in section 4.1.2
If patented or otherwise controlled technology
is required for implementation, the separate implementations must
also
On 01/27/2011 01:10, John C Klensin wrote:
--On Thursday, January 27, 2011 09:41 +0200 Gonzalo Camarillo
gonzalo.camari...@ericsson.com wrote:
Hi,
yes, I also agree the first one is the most important point
and has not been addressed so far. If we want a system that
works (and is used), it
On 1/27/2011 12:52 AM, Lars Eggert wrote:
...
Small Issue #3: I object to anonymous review
The current review is anonymous and this draft does not seem to change that. I
don't like anonymous review - it's not how we do things at IETF and it
encourages really bad behavior. I have several
We are changing that process right now. We have begun to report the
reviewer (with the review) in the email to the requester.
We just need to make sure this small change is communicated to those experts
that are part of review teams as their individual names are not published
on the main list of
At 19:29 26-01-11, Scott O. Bradner wrote:
1/ I still do not think this (modified) proposal will have any real
impact on the number of Proposed Standard documents that move
to a (in this proposal, the) higher level since I do not see
how this makes any significant changes to the
Big Issues 1: I don't like mandating one port for secure and not secure
versions of a protocol
I don't either, so it's good that the document doesn't do that. It says:
Services are expected to include support for security, either as
default or dynamically negotiated in-band. The use of
Scott O. Bradner wrote:
1/ I still do not think this (modified) proposal will have any real
impact on the number of Proposed Standard documents that move
to a (in this proposal, the) higher level since I do not see
how this makes any significant changes to the underlying reasons
Total of 87 messages in the last 7 days.
script run at: Fri Jan 28 00:53:02 EST 2011
Messages | Bytes| Who
+--++--+
6.90% |6 | 8.09% |57034 | hal...@gmail.com
5.75% |5 | 7.75% |54689 |
This post would be much less confusing if you would name names, cite
examples, and point fingers.
The reason why so many documents are at proposed is that they're
often collections of bloat (limited-use features with an aggresive
requirements level) from various interest groups that is
not
The IESG has received a request from the Site Multihoming by IPv6
Intermediation WG (shim6) to consider the following document:
- 'Socket Application Program Interface (API) for Multihoming Shim'
draft-ietf-shim6-multihome-shim-api-15.txt as an Informational RFC
The IESG plans to make a
21 matches
Mail list logo
