On 20 Sep 2013, at 05:54, Brian E Carpenter wrote:
> I got my arm slightly twisted to produce the attached:
Thanks for getting that done
S
Hi,
we are extremely pleased to report that for the 2013 award period of
the Applied Networking Research Prize (ANRP), 36 eligible nominations
were received. Each submission was reviewed by eight members of the
selection committee according to a diverse set of criteria, including
scientific excel
Hi Hadriel,
to summarize the status of this IETF LC, we are still expecting (at
least) an additional IPR disclosure on this draft (as announced on the
INSIPID list). When that happens, I will IETF LC it again.
In the mean time, we need to address the comments related to the IANA
registration the
Thanks David.
- JOuni
On Sep 20, 2013, at 2:57 AM, "Black, David" wrote:
> And the -12 version is likewise ready for publication as an Informational RFC.
>
> Thanks,
> --David
>
>> -Original Message-
>> From: Black, David
>> Sent: Tuesday, August 27, 2013 12:41 PM
>> To: Ben Campbel
I confess that I am confused by much of this discussion. As I understand
it, PRISM is not a signals intelligence activity; it only addresses that
data at rest within those organisations who have partnered with the NSA.
As such, improving protocol security will achieve nothing against PRISM;
it is a
One of things that I feel is important for the chair to do is to talk to
various IETF contributors - not just on this list! :-) - and try to understand
what issues they have, either technical or otherwise. Here's a small overview
report of my recent effort to talk to various participants and org
I'd like to snippet Phil's suggestion to an abbreviated version of one
sentence, becaue I think this is right on.
On 09/19/2013 05:37 PM, Phillip Hallam-Baker wrote:
The issue we need to focus on is how to convince our audience that our
specifications have not been compromised
To my mind, th
This is a second reminder about an upcoming deadline: If you are working on a
new proposal for work at the IETF, it needs to be submitted by September 23rd,
i.e., on Monday. If you have been talking about new topics that require a new
meeting slot in Vancouver, hopefully you have already talked
Josh Howlett wrote:
> I confess that I am confused by much of this discussion.
Several people in IETF is under control of NSA, maybe.
> As I understand
> it, PRISM is not a signals intelligence activity; it only addresses that
> data at rest within those organisations who have partnered with the
On 09/20/2013 10:59 AM, Josh Howlett wrote:
> I confess that I am confused by much of this discussion. As I understand
> it, PRISM is not a signals intelligence activity; it only addresses that
> data at rest within those organisations who have partnered with the NSA.
> As such, improving protoco
On 20.09.2013 13:20, Harald Alvestrand wrote:
To my mind, the first thing to focus on is making our specs readable, so
that it's possible to understand that they have not been compromised.
Three questions for you Harald:
1) When you say that our documents have to be "readable" then you have
t
Josh, Stephen,
It is important to understand the limitations of technology in this discussion.
We can improve communications security, and in some cases reduce the amount
information communicated. But we cannot help a situation where you are
communicating with a party that you cannot entirely t
(2013/09/20 21:15), Jari Arkko wrote:
> Josh, Stephen,
>
> It is important to understand the limitations of technology in this
> discussion. We can improve communications security, and in some
> cases reduce the amount information communicated. But we cannot
> help a situation where you are commun
On 09/20/2013 01:38 PM, Hannes Tschofenig wrote:
On 20.09.2013 13:20, Harald Alvestrand wrote:
To my mind, the first thing to focus on is making our specs readable, so
that it's possible to understand that they have not been compromised.
Three questions for you Harald:
1) When you say that ou
On Fri, Sep 20, 2013 at 6:20 AM, Harald Alvestrand wrote:
> I'd like to snippet Phil's suggestion to an abbreviated version of one
> sentence, becaue I think this is right on.
>
>
> On 09/19/2013 05:37 PM, Phillip Hallam-Baker wrote:
>
>> The issue we need to focus on is how to convince our audien
On Fri, Sep 20, 2013 at 6:20 AM, Harald Alvestrand wrote:
> I'd like to snippet Phil's suggestion to an abbreviated version of one
> sentence, becaue I think this is right on.
>
> On 09/19/2013 05:37 PM, Phillip Hallam-Baker wrote:
>>
>> The issue we need to focus on is how to convince our audienc
On Fri, Sep 20, 2013 at 8:15 AM, Jari Arkko wrote:
> It is important to understand the limitations of technology in this
> discussion. We can improve communications security, and in some cases reduce
> the amount information communicated. But we cannot help a situation where you
> are communica
On 19/09/13 17:59, Hannes Tschofenig wrote:
I am personally not worried that the standardization work in the IETF
can be sabotaged by governments since our process is open, and
transparent to everyone who cares to see what is going on.
Isn't it the other way round? That exactly because IETF pr
On Sep 20, 2013, at 9:12 AM, Harald Alvestrand wrote:
> From the stack I'm currently working on, I find the ICE spec to be
> convoluted, but the SDP spec is worse, becaue it's spread across so many
> documents, and there are pieces where people seem to have agreed to ship
> documents rather tha
On Sep 20, 2013, at 13:38, Hannes Tschofenig wrote:
> 2) Are there documents you find non-readable?
I'm not sure you aren't mocking us, but...
*Yes*, there are documents in the IETF that are highly non-accessible.
I could name examples from areas other than security, but probably the most
gla
On Fri, Sep 20, 2013 at 11:25 AM, Noel Chiappa wrote:
> > From: Martin Sustrik
>
> > Isn't it the other way round? That exactly because IETF process is
> open
> > it's relatively easy for anyone to secretly introduce a backdoor
> into a
> > protocol?
> > ...
> > With IETF
On 9/20/2013 8:25 AM, Noel Chiappa wrote:
Iff enough people are _carefully_ reviewing specs, that ought to find all the
backdoors. An open process does have potential issues, but it's also the one
with the best chance of producing a 'good' product.
As has been said, the premise of open standard
Hi Masataka,
On 20.09.2013 16:06, Masataka Ohta wrote:
> (2013/09/20 21:15), Jari Arkko wrote:
>> Josh, Stephen,
>>
>> It is important to understand the limitations of technology in this
>> discussion. We can improve communications security, and in some
>> cases reduce the amount information commu
What would be the preferred way to provide a mixed list of IPv4 and IPv6
addresses, in a DHCPv6 option? IPv4-mapped addresses?
Or, is it assumed that any service which can be reached over IPv4 or
IPv6 by any given (dual-stack) client would use DNS FQDNs exclusively,
rather than addresses?
By
On 20.09.2013 16:23, Phillip Hallam-Baker wrote:
For example, do we really need 30 different authentication algorithms in
a protocol? Whenever we talk about authentication we end up with a new
framework on the existing frameworks rather than just picking one.
I don't think that there is somethi
Issues: OK lets start here...
1)Structure and Political Representation inside the IETF
Bluntly the IETF@IETF WG is a silo which has erected a wall around
itself to make it the controlling power - the problem is its failure to
provide proper integration and acceptance practices for all othe
Hi Spencer,
I read your DISCUSS about draft-ietf-homenet-arch-10:
'Is there a useful reference that could be provided for "dotless"?'
draft-moonesamy-dotless-domains-00 discusses about dotless. I leave
it to you to decide about whether it qualifies as a better reference
than one to a web p
--On Friday, September 20, 2013 10:15 -0400 Ted Lemon
wrote:
> On Sep 20, 2013, at 9:12 AM, Harald Alvestrand
> wrote:
>> From the stack I'm currently working on, I find the ICE spec
>> to be convoluted, but the SDP spec is worse, becaue it's
>> spread across so many documents, and there are p
On 20.09.2013 18:28, Steve Crocker wrote:
Are we conflating back doors in implementations with back doors in
protocol specifications? It's certainly a conceptual possibility for
there to be a back door in a protocol specification, but I don't
recall ever hearing about one.
Of course backdoors
Martin, I have no clue how you come up with that conclusion. Have you
ever worked in organizations that are closed to a small number of
members where decisions are being made behind closed doors? Do you think
that would help to produce better results?
I think the openness and transparency is t
>From my experience, some people not as familiar with the IETF have trouble
>understanding how to fit RFCs together. That leads to a readability problem
>in itself. Some also don't realize that you can reference part of one RFC and
>not the whole thing rather than reinventing the wheel or docu
I'm glad the process aspects have been brought up again. When a WG is
finished with a draft, there is still a lot more work to do. WG last
call is or should be closer to the middle of a draft's development
trajectory than the end. I would say this is true not just for the
ones that someone close
> From: Steve Crocker
> Are we conflating back doors in implementations with back doors in
> protocol specifications?
Good point, but I was thinking specifically of protocol specs, since that's
what the IETF turns out.
> It's certainly a conceptual possibility for there to be a
On Fri, Sep 20, 2013 at 10:02 AM, Martin Sustrik wrote:
> On 19/09/13 17:59, Hannes Tschofenig wrote:
>
> I am personally not worried that the standardization work in the IETF
>> can be sabotaged by governments since our process is open, and
>> transparent to everyone who cares to see what is go
> From: Hannes Tschofenig
> * Prefer performance over privacy in protocol designs
You forgot:
* Prefer privacy over performance in protocol designs
and its cousin:
* Prefer privacy over usability in protocol designs
both of which, as we have seen extensively over the last cou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In article <6.2.5.6.2.20130920070952.0664d...@elandnews.com> you write:
>Hi Spencer,
>
>I read your DISCUSS about draft-ietf-homenet-arch-10:
>
> 'Is there a useful reference that could be provided for "dotless"?'
Another possibility is draft-hoffin
Total of messages in the last 7 days.
script run at: Fri Sep 20 14:38:57 EDT 2013
Messages | Bytes| Who
+--++--+
+--++--+
Carsten,
I am not saying all the specifications are great but I wanted to know
first what target audience Harald is talking about.
You are talking about us, guys who have been in the IETF for a long
time, as the target audience. If we find specifications difficult to
read then that's a real
Total of messages in the last 7 days.
script run at: Fri Sep 20 14:39:19 EDT 2013
Messages | Bytes| Who
+--++--+
+--++--+
Hi Kathleen,
you are responding to the question about the target audience* and I saw
your video. That's an interesting idea to reach out to those who are not
yet involved in an IETF group.
Of course, our working group pages and the Wikis are not necessarily are
great way to communicate with
The only back door necessary is the BGP4 route flap and private
transport networks do the rest.
Todd
On 09/20/2013 09:02 AM, Noel Chiappa wrote:
> From: Steve Crocker
> Are we conflating back doors in implementations with back doors in
> protocol specifications?
Good point, b
Hi Hannes,
I would also like to reach developers that may not be familiar with the IETF
and find themselves assigned with developing protocols we designed. I'll see
if I (or my co-chair) can get something together in short order. ENISA was
reviewing materials and asked for this type of inform
On Sep 20, 2013, at 10:02 AM, Martin Sustrik wrote:
> Isn't it the other way round? That exactly because IETF process is open it's
> relatively easy for anyone to secretly introduce a backdoor into a protocol?
No, this is exactly wrong.
What is important about openness is not who is allowed to
Total of 209 messages in the last 7 days.
script run at: Fri Sep 20 14:42:33 EDT 2013
Messages | Bytes| Who
+--++--+
3.83% |8 | 7.47% | 133327 | o...@nlnetlabs.nl
5.74% | 12 | 4.92% |87860 | john-i...@jck.c
Are we conflating back doors in implementations with back doors in protocol
specifications? It's certainly a conceptual possibility for there to be a back
door in a protocol specification, but I don't recall ever hearing about one.
On the other hand, back doors, both intended and unintended, i
On Sep 20, 2013, at 11:38 AM, Thomas Narten wrote:
> Total of messages in the last 7 days.
>
> script run at: Fri Sep 20 14:38:57 EDT 2013
>
>Messages | Bytes| Who
> +--++--+
> +--++--+---
> From: Martin Sustrik
> Isn't it the other way round? That exactly because IETF process is open
> it's relatively easy for anyone to secretly introduce a backdoor into a
> protocol?
> ...
> With IETF standard there can very well be several unknown backdoors
> introduc
At 06:12 20-09-2013, Harald Alvestrand wrote:
By those who implement them, and those who try to understand how it
works to the degree that they feel assured that there are no
non-understood security risks (intentional or otherwise).
Yes.
From the stack I'm currently working on, I find the ICE
Hannes Tschofenig wrote:
>> We can discourage people communicating with a party that are
>> under full control of USG, which is why using cloud services
>> should be discouraged, which is a technical issue.
>
> An open standardization process means that everyone can participate,
> including peopl
On 20/09/2013, at 9:16 PM, Masataka Ohta
wrote:
>> As such the only practical way for a typical user to protect themselves
>> against PRISM is to switch to other providers based in jurisdictions that
>> provide the appropriate protections, or agitate to change the applicable
>> laws within thei
Mark Nottingham wrote:
>> Not necessarily.
>>
>> The proper protection is to avoid cloud services and have our
>> own end systems fully under control of ourselves.
>>
>> Toward the goal, IETF should shutdown all the cloud related
>> WGs and never develop any protocol to promote cloud service.
>
>
Hi Brian,
At 21:54 19-09-2013, Brian E Carpenter wrote:
I got my arm slightly twisted to produce the attached: a simple
concatenation of some of the actionable suggestions made in the
discussion of PRISM and Bruce Schneier's call for action.
Thanks for writing the draft. For the sake of disclo
Hello,
At 01:52 20-09-2013, Gonzalo Camarillo wrote:
to summarize the status of this IETF LC, we are still expecting (at
least) an additional IPR disclosure on this draft (as announced on the
INSIPID list). When that happens, I will IETF LC it again.
There was a discussion about IPR on this mai
On 21/09/2013, at 11:33 AM, Masataka Ohta
wrote:
> Cost for monitoring should be large?
>
> Then, protocols not have any authoritative specification and
> should never be standardized and there should be no central
> authority to manage different versions of the protocols.
From a PRISM viewpo
54 matches
Mail list logo
