+1
/Markku
On Mon, 28 Mar 2011, Michelle Cotton wrote:
+1
Michelle
On 3/28/11 5:46 AM, Lars Eggert lars.egg...@nokia.com wrote:
As one of the authors/editors, I am fine with this change. Thanks!
On 2011-3-28, at 14:14, Alexey Melnikov wrote:
After discussing this new text with IESG and
+1.
On 3/28/11 3:52 PM, Michelle Cotton wrote:
+1
Michelle
On 3/28/11 5:46 AM, Lars Eggert lars.egg...@nokia.com wrote:
As one of the authors/editors, I am fine with this change. Thanks!
On 2011-3-28, at 14:14, Alexey Melnikov wrote:
After discussing this new text with IESG and some
Alexey Melnikov wrote:
Peter Saint-Andre wrote:
Agreed, thanks to Paul for the proposed text.
On 2/15/11 9:02 PM, Cullen Jennings wrote:
Paul's text is much better than mine. That was what I trying to get
at.
Agreed, I will add this as an RFC Editor's note.
On Feb 15, 2011, at 8:59
On 3/28/11 2:14 PM, Alexey Melnikov wrote:
Alexey Melnikov wrote:
Peter Saint-Andre wrote:
Agreed, thanks to Paul for the proposed text.
On 2/15/11 9:02 PM, Cullen Jennings wrote:
Paul's text is much better than mine. That was what I trying to get
at.
Agreed, I will add this as an RFC
As one of the authors/editors, I am fine with this change. Thanks!
On 2011-3-28, at 14:14, Alexey Melnikov wrote:
After discussing this new text with IESG and some participants of the TSVWG,
it became clear that while there is clear agreement for adding the first
sentence quoted above (There
As one of the authors, I'm fine with this change too.
Joe
On 3/28/2011 5:46 AM, Lars Eggert wrote:
As one of the authors/editors, I am fine with this change. Thanks!
On 2011-3-28, at 14:14, Alexey Melnikov wrote:
After discussing this new text with IESG and some participants of the TSVWG, it
Joe Touch skrev 2011-03-28 15:33:
As one of the authors, I'm fine with this change too.
Me too,
Magnus Westerlund
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
+1
Michelle
On 3/28/11 5:46 AM, Lars Eggert lars.egg...@nokia.com wrote:
As one of the authors/editors, I am fine with this change. Thanks!
On 2011-3-28, at 14:14, Alexey Melnikov wrote:
After discussing this new text with IESG and some participants of the TSVWG,
it became clear that
Peter Saint-Andre wrote:
Agreed, thanks to Paul for the proposed text.
On 2/15/11 9:02 PM, Cullen Jennings wrote:
Paul's text is much better than mine. That was what I trying to get
at.
Agreed, I will add this as an RFC Editor's note.
On Feb 15, 2011, at 8:59 PM, Paul Hoffman
Cullen, there's a lot of history with port registrations. As you're
probably aware in the past, there was a procedure for experts to sign an
NDA before reviewing port requests. It's my understanding that is no
longer done. However, it does suggest there's strong desire for
proprietary protocol
I propose some text for the draft near the bottom of this email
On Feb 2, 2011, at 2:16 AM, Magnus Westerlund wrote:
Cullen Jennings skrev 2011-02-01 18:19:
So to summarize what you are saying, ports are allocated based on an
arbitrary view of the expert review. When this person will
On 2/15/11 7:34 PM, Cullen Jennings wrote:
I propose some text for the draft near the bottom of this email
For the user ports the document should have some text along the lines
of:
There is not IETF consensus on when it is appropriate to use a second
port for a secure version of protocol
Paul's text is much better than mine. That was what I trying to get at.
On Feb 15, 2011, at 8:59 PM, Paul Hoffman wrote:
On 2/15/11 7:34 PM, Cullen Jennings wrote:
I propose some text for the draft near the bottom of this email
For the user ports the document should have some text along
Agreed, thanks to Paul for the proposed text.
On 2/15/11 9:02 PM, Cullen Jennings wrote:
Paul's text is much better than mine. That was what I trying to get
at.
On Feb 15, 2011, at 8:59 PM, Paul Hoffman wrote:
On 2/15/11 7:34 PM, Cullen Jennings wrote:
I propose some text for the draft
I've been thinking more about this thread and my concerns about this draft. I
was originally looking for the draft to have advice for the expert review team
that gave them guidance on what the IETF thought was all right to approve or
not approve. It's become clear that this draft does not have
Hi Paul (and Cullen),
Paul Hoffman wrote:
On 1/29/11 9:34 PM, Joe Touch wrote:
On 1/29/2011 8:54 PM, Cullen Jennings wrote:
On Jan 27, 2011, at 17:10 , Joe Touch wrote:
...
AFAICT, the experts team reports to IANA. We make recommendations to
them. They are the ones who have the
Paul Hoffman wrote:
On 1/31/11 12:23 AM, Lars Eggert wrote:
On 2011-1-30, at 17:12, Paul Hoffman wrote:
The above emphatic statements means that IANA can reject a request
for an IETF-approved protocol that needs two ports without recourse.
I don't follow. Assignments through IETF-stream
Hi folks,
Sam Hartman wrote (and others suggest):
I think that being able to discuss concerns with reviewers and being
able to consider potential conflicts and other issues mean that an open
dialogue with identified reviewers is an important part of our
process. Anonymous contributions
I don't see that public identity (of expert reviewers) is required for
interactive discussion.
Or would anonymous interaction fail a Turing test of some kind?
Public identity is required for reviewer accountability. It is easy to imagine
how withholding registration of some required
On Feb 8, 2011, at 9:41 PM, Christian Huitema wrote:
I don't see that public identity (of expert reviewers) is required for
interactive discussion.
Or would anonymous interaction fail a Turing test of some kind?
Public identity is required for reviewer accountability. It is easy to
Regardless, we're already moving forward to make the identities public
(not sure if it's happening, or already happened).
Regardless, though, again, this is out of scope for this doc to address
in detail, IMO.
Joe
On 2/7/2011 1:24 PM, Chris Benson wrote:
Hi folks,
Sam Hartman wrote (and
Cullen Jennings skrev 2011-02-01 18:19:
So to summarize what you are saying, ports are allocated based on an
arbitrary view of the expert review. When this person will say yes or no too
can't be described and will change over time.
If that's how it works, there is not even any grounds
Cullen Jennings skrev 2011-01-31 18:44:
Magnus, I agree with what you are saying here but you are avoiding the issue
I am concerned with. Is allocating a second port for the secure version of a
document a frivolous use case or not? I read this draft as saying it is.
Others read the draft
+1 to everything Magnus says here. THis is exactly how I view the multiple port
issue.
I will also add that at least part of this fuss seems to be concern about how
human oversight is needed but what if the overseer misbehaves issue. Speaking
as someone who has been doing IANA reviews for well
On Tue, Feb 1, 2011 at 8:38 AM, ned+i...@mauve.mrochek.com wrote:
+1 to everything Magnus says here. THis is exactly how I view the multiple
port
issue.
I'll respond to this separately.
I will also add that at least part of this fuss seems to be concern about how
human oversight is
On 2/1/11 2:14 AM, Magnus Westerlund wrote:
Cullen Jennings skrev 2011-01-31 18:44:
Magnus, I agree with what you are saying here but you are avoiding the issue I
am concerned with. Is allocating a second port for the secure version of a
document a frivolous use case or not? I read this
So to summarize what you are saying, ports are allocated based on an arbitrary
view of the expert review. When this person will say yes or no too can't be
described and will change over time.
If that's how it works, there is not even any grounds for appeal of any given
decision. You can't
inline
On Feb 1, 2011, at 5:14 , Magnus Westerlund wrote:
Cullen Jennings skrev 2011-01-31 18:44:
Magnus, I agree with what you are saying here but you are avoiding the
issue I am concerned with. Is allocating a second port for the secure
version of a document a frivolous use case
To clarify some of this discussion, providing some context that might be
useful:
1) the current doc already explicitly states the procedures for
assignment in each range of ports (see Sec 8.1.1).
2) Sec 8.1.1 *already* states that IESG approval through IETF process is
a valid path for
On 2/1/2011 9:19 AM, Cullen Jennings wrote:
So to summarize what you are saying, ports are allocated based on an
arbitrary view of the expert review. When this person will say yes or no
too can't be described and will change over time.
See my other post. Section 8.1.1 already states that
On Tue, Feb 1, 2011 at 9:39 AM, Joe Touch to...@isi.edu wrote:
To clarify some of this discussion, providing some context that might be
useful:
1) the current doc already explicitly states the procedures for assignment
in each range of ports (see Sec 8.1.1).
2) Sec 8.1.1 *already* states
On 2/1/2011 10:00 AM, Eric Rescorla wrote:
On Tue, Feb 1, 2011 at 9:39 AM, Joe Touchto...@isi.edu wrote:
To clarify some of this discussion, providing some context that might be
useful:
1) the current doc already explicitly states the procedures for assignment
in each range of ports (see
On Tue, Feb 1, 2011 at 10:26 AM, Joe Touch to...@isi.edu wrote:
On 2/1/2011 10:00 AM, Eric Rescorla wrote:
On Tue, Feb 1, 2011 at 9:39 AM, Joe Touchto...@isi.edu wrote:
To clarify some of this discussion, providing some context that might be
useful:
1) the current doc already explicitly
On 2/1/2011 10:29 AM, Eric Rescorla wrote:
...
I'm sorry, but I'm still not clear.
This document has an affirmative statement against the use of multiple
ports for TLS.
I'm sorry, but it does not.
I states a goal, and a preference, and has plenty of wiggle room as I've
repeatedly quoted,
I'll add my +1 to Ned's comments in a slightly different way. As
someone who is a reviewer, I think we all owe a big debt to Joe Touch
and Pearl Liang for guiding applicants and reviewers through the process
(even if the applicants don't know it).
Eliot
On 2/1/11 5:38 PM, Ned Freed wrote:
+1
Joe == Joe Touch to...@isi.edu writes:
Joe On 1/27/2011 12:52 AM, Lars Eggert wrote:
Joe ...
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
On 2/1/2011 11:14 AM, Sam Hartman wrote:
...
Joe, the IESG had a fair amount of negative experience with this style
of review just before I joined; this type of review was just about out
of the process leading to blocking objections when I joined as an AD.
I think that being able to discuss
Joe == Joe Touch to...@isi.edu writes:
Joe On 2/1/2011 11:14 AM, Sam Hartman wrote:
Joe ...
Joe, the IESG had a fair amount of negative experience with this
style of review just before I joined; this type of review was
just about out of the process leading to blocking
On 2/1/2011 12:12 PM, Sam Hartman wrote:
Joe == Joe Touchto...@isi.edu writes:
Joe On 2/1/2011 11:14 AM, Sam Hartman wrote:
Joe ...
Joe, the IESG had a fair amount of negative experience with this
style of review just before I joined; this type of review was
On Tue, Feb 1, 2011 at 2:14 AM, Magnus Westerlund
magnus.westerl...@ericsson.com wrote:
Cullen Jennings skrev 2011-01-31 18:44:
Magnus, I agree with what you are saying here but you are avoiding the issue
I am concerned with. Is allocating a second port for the secure version of a
document
On 2011-1-30, at 17:12, Paul Hoffman wrote:
The above emphatic statements means that IANA can reject a request for an
IETF-approved protocol that needs two ports without recourse.
I don't follow. Assignments through IETF-stream documents do not go through
expert review. And I've never
Cullen Jennings skrev 2011-01-30 05:56:
I read the draft to say that there would only be one port allocated - I took
strive to mean that Joe would deny my port requests for two ports. If the
intention is actually for the draft to say that it strives for one port but
allows assignment of
On 1/31/11 12:23 AM, Lars Eggert wrote:
On 2011-1-30, at 17:12, Paul Hoffman wrote:
The above emphatic statements means that IANA can reject a request for an
IETF-approved protocol that needs two ports without recourse.
I don't follow. Assignments through IETF-stream documents do not go
Hi,
On 2011-1-31, at 16:51, Paul Hoffman wrote:
On 1/31/11 12:23 AM, Lars Eggert wrote:
On 2011-1-30, at 17:12, Paul Hoffman wrote:
The above emphatic statements means that IANA can reject a request for an
IETF-approved protocol that needs two ports without recourse.
I don't follow.
On 1/31/11 7:06 AM, Lars Eggert wrote:
But I see the point you're raising. The document should somewhere say
that Expert Review is the procedure used for assignment requests
made directly to IANA, whereas for documents on the IETF Stream,
IETF Consensus is sufficient to make the assignment. In
On Jan 31, 2011, at 8:14 , Paul Hoffman wrote:
On 1/31/11 7:06 AM, Lars Eggert wrote:
But I see the point you're raising. The document should somewhere say
that Expert Review is the procedure used for assignment requests
made directly to IANA, whereas for documents on the IETF Stream,
On 1/31/11 5:13 PM, Cullen Jennings wrote:
Hmm ... I don't agree that solves the issue.
Well lets say the request was coming from 3GPP for a protocol they designed -
why should IANA be able to tell them no but IETF yes.
Who, ultimately, is the steward of this precious resource? If it is
So IANA has a huge amount of technical expertise and takes maintaing the
registries very seriously. I've seen them catch technical mistakes that made
all the way through WG and IESG review. I've got huge respect for technical
competence of IANA and in particular Michelle. So I'm not questions
On 1/31/11 8:13 AM, Cullen Jennings wrote:
Hmm ... I don't agree that solves the issue.
Well lets say the request was coming from 3GPP for a protocol they
designed - why should IANA be able to tell them no but IETF yes.
Because IANA is responsible for maintaining the usefulness of the
Cullen Jennings skrev 2011-01-31 17:13:
Well lets say the request was coming from 3GPP for a protocol they designed -
why should IANA be able to tell them no but IETF yes.
I am not certain I understand what your issue is here. Is it that they
can come to different conclusions, and that IETF
Cullen,
We do have some technical expertise within the IANA staff, however our
expertise is more aligned with the process of creating and maintaining
registries. Part of that includes relying on the experts that the IESG
designates to make the decisions for requests that utilize the Expert
Lars,
On 1/31/2011 7:06 AM, Lars Eggert wrote:
Hi,
On 2011-1-31, at 16:51, Paul Hoffman wrote:
On 1/31/11 12:23 AM, Lars Eggert wrote:
On 2011-1-30, at 17:12, Paul Hoffman wrote:
The above emphatic statements means that IANA can reject a request for an
IETF-approved protocol that needs two
The procedures that are specified - for ALL assignments - are the
PROCEDURES - the word itself is used specifically in the heading of
section 8.
That does not refer to the principles - again for which there are more
than sufficient wiggle words, and which already cite existing RFCs that
On 1/31/2011 9:16 AM, Joe Touch wrote:
Lars,
On 1/31/2011 7:06 AM, Lars Eggert wrote:
Hi,
On 2011-1-31, at 16:51, Paul Hoffman wrote:
On 1/31/11 12:23 AM, Lars Eggert wrote:
On 2011-1-30, at 17:12, Paul Hoffman wrote:
The above emphatic statements means that IANA can reject a request
for
Thanks - yes that makes it clear and I like the way IANA handles all of this.
On Jan 31, 2011, at 9:55 , Michelle Cotton wrote:
Cullen,
We do have some technical expertise within the IANA staff, however our
expertise is more aligned with the process of creating and maintaining
registries.
On Jan 31, 2011, at 9:41 , Magnus Westerlund wrote:
Cullen Jennings skrev 2011-01-31 17:13:
Well lets say the request was coming from 3GPP for a protocol they designed
- why should IANA be able to tell them no but IETF yes.
I am not certain I understand what your issue is here. Is it
So first, we already have a BCP that says more or less all protocols must
implement a secure version but deployment is optional. This is a good BCP, and
it comes from the right area to say that - security. It's probably impacts
design work in working groups more than any other BCP. It has
On 1/31/11 6:51 PM, Cullen Jennings wrote:
So first, we already have a BCP that says more or less all protocols must
implement a secure version but deployment is optional. This is a good BCP,
and it comes from the right area to say that - security. It's probably
impacts design work in
Fwiw please see sec 8.1 of our doc which states which procedures of RFC 5226
are specified for each range, and already allows IESG approval as a path for
user ports.
Joe
On Jan 31, 2011, at 9:25 AM, Joe Touch to...@isi.edu wrote:
On 1/31/2011 9:16 AM, Joe Touch wrote:
Lars,
On
On Mon, Jan 31, 2011 at 11:41 AM, Eric Rescorla e...@skype.net wrote:
So first, we already have a BCP that says more or less all protocols must
implement a secure version but deployment is optional. This is a good BCP,
and it comes from the right area to say that - security. It's probably
Eric,
Clearly, if you're going to do a negotiation design you want a single port.
If you're going to do a non-negotiated design, then I don't see a huge
amount of value in using a single port. It's true that there is a port
consumption issue, but OTOH ports are there for protocol demuxing and
On Mon, Jan 31, 2011 at 2:11 PM, Eliot Lear l...@cisco.com wrote:
Eric,
Clearly, if you're going to do a negotiation design you want a single port.
If you're going to do a non-negotiated design, then I don't see a huge
amount of value in using a single port. It's true that there is a port
On 1/29/11 9:34 PM, Joe Touch wrote:
On 1/29/2011 8:54 PM, Cullen Jennings wrote:
On Jan 27, 2011, at 17:10 , Joe Touch wrote:
...
AFAICT, the experts team reports to IANA. We make recommendations to
them. They are the ones who have the conversation with the applicant.
They can take our
Paul (et al.),
See below.
Note that IANA can't just make its own decisions either and ignore IETF
process *AND* expert review.
I wasn't trying to imply that, but it appears to have been inferred from
my claim that neither document binds IANA to the advice of a reviewer.
IANA is bound by
Cullen,
On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote:
AFAICT, the experts team reports to IANA. We make recommendations to
them. They are the ones who have the conversation with the applicant.
They can take our advice or not - that's their decision.
I think you are pretty
David has said this well. Thank you.
Please let me know if there are any other questions.
--Michelle
On 1/30/11 10:52 AM, David Conrad d...@virtualized.org wrote:
Cullen,
On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote:
AFAICT, the experts team reports to IANA. We make
On Jan 27, 2011, at 17:29 , Michelle Cotton wrote:
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
On Jan 27, 2011, at 17:10 , Joe Touch wrote:
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
On Jan 27, 2011, at 8:12 , 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
I read the draft to say that there would only be one port allocated - I took
strive to mean that Joe would deny my port requests for two ports. If the
intention is actually for the draft to say that it strives for one port but
allows assignment of two where the that is what the protocol design
On 1/29/2011 8:53 PM, Cullen Jennings wrote:
On Jan 27, 2011, at 17:29 , Michelle Cotton wrote:
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
On 1/29/2011 8:54 PM, Cullen Jennings wrote:
On Jan 27, 2011, at 17:10 , Joe Touch wrote:
...
AFAICT, the experts team reports to IANA. We make recommendations to
them. They are the ones who have the conversation with the applicant.
They can take our advice or not - that's their decision.
On Jan 27, 2011, at 1:26 , Lars Eggert wrote:
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
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
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
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
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
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
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 published
Big Issues 1: I don't like
I would like to see more clarity in 8.1
For assignments done through IETF-published RFCs, the Contact will be the
IESG.
in that I am unclear what IETF-published RFCs are; presumably that is Standards
Track, BCP
and Individual Submissions, but not Independent Submissions or IRTF RFC.
I think
t.petch skrev 2011-01-21 12:43:
I would like to see more clarity in 8.1
For assignments done through IETF-published RFCs, the Contact will be the
IESG.
in that I am unclear what IETF-published RFCs are; presumably that is
Standards
Track, BCP
and Individual Submissions, but not
86 matches
Mail list logo
