On Oct 25, 2013, at 11:23 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:
Section 2.5.1 recommends using 1280-byte max IP datagram size for
IPv6 (based on RFC 2460), and 576 bytes (based on RFC 1122). The big
difference between those two RFCs is not some technical difference
between IPv6
Hi, Yaron
Suppose that instead of sending the message to the list yesterday, Valery had
submitted his comments as errata a few months ago, before Sean asked us to do
the revision. Would those errata not have been verified?
If so (and I think it's true for at least #3, #4, #7, and #11, and #6
On Oct 17, 2013, at 5:13 PM, Paul Wouters p...@cypherpunks.ca wrote:
While updating the retransmit timers in libreswan, I found no useful
information in 5996. Is that something we could add? I know it is
local policy but perhaps it would be good to add some guidance for
implementors. Do
Yes, it says so in RFC 1122. Microsoft sends 576-byte packets when it does
IKEv1 fragmentation.
Still, I don't think you're going to find on the modern Internet any networks
that aren't usable by IPv6. So I think we should be pretty safe in adoption
IPv6's minimum of 1280
Yoav
On Oct 17,
The message [2] references a discussion on the list. Reading over that
discussion, I see that everyone who participated (with the exception of Scott
Fluhrer) ended up on the design team, all 5 of us. Within the design group
there was intense discussion until we settled on the encoding in the
Third version of this draft, now including Tero's comments.
Begin forwarded message:
From: internet-dra...@ietf.orgmailto:internet-dra...@ietf.org
Subject: New Version Notification for draft-nir-ipsecme-cafr-03.txt
Date: October 15, 2013 9:49:06 AM GMT+03:00
To: Yoav Nir y
On Oct 15, 2013, at 1:26 PM, Stephen Farrell stephen.farr...@cs.tcd.ie
wrote:
Following up on my own point - not stylish but I think
in this case justified:-)
On 10/15/2013 12:41 AM, Stephen Farrell wrote:
I don't
see why we shouldn't be equally comfortable in saying don't
send
On Oct 9, 2013, at 2:10 PM, Tero Kivinen kivi...@iki.fi wrote:
In section 2.2. Verifying the HAND_OVER_CHILD_SAS Notification the
document lists operations which needs to be done when handling the
notification. The process seems otherwise quite good, expect the error
handling seems to be bit
On Oct 9, 2013, at 5:12 PM, Michael Richardson mcr+i...@sandelman.ca
wrote:
Michael Richardson mcr+i...@sandelman.ca wrote:
The call-in details are:
Tele: +1 712-775-7400
Code: 809604#
mcr Two LD suppliers (entirely different phones) tell me that I can not
reach
mcr this
On Oct 7, 2013, at 11:56 PM, Martin Rex m...@sap.com wrote:
Dearlove, Christopher (UK) wrote:
dcroc...@bbiw.net
From what you've written, your basic point seems to be that 51% isn't
enough; it's worth making that explicit.
To add to the confusion, and to emphasise the point about
On Oct 3, 2013, at 4:57 PM, Michael Richardson mcr+i...@sandelman.ca wrote:
I also read: draft-mao-ipsecme-ad-vpn-protocol and while conceptually I found
it okay, I think that the protocol should be inside IKE.
Funny, I came to the opposite conclusion. I think it's too much like IKE.
But
Hi
There is something that I think is missing from all three proposals, and that
is the handling of duplicate protected networks. As long as we live in a
predominantly IPv4 world, we have a lot of NATs and a lot of RFC 1918 addresses.
So unprotected traffic from such networks gets NATted by
Hi
I have read the DM-VPN draft. I would not call my reading a review, as it was
quite superficial, but here's some thoughts:
- I have to admit that I'm still having trouble wrapping my head around some of
the concepts. I understand domain-based and route-pased VPNs, as well as IPsec
and GRE
On Oct 1, 2013, at 9:29 PM, Michael Richardson mcr+i...@sandelman.ca wrote:
This morning I had reason to re-read parts of RFC3777, and anything
that updated it. I find the datatracker WG interface to really be
useful, and so I visited http://datatracker.ietf.org/wg/nomcom/
first. I guess
, Yoav Nir wrote:
Hi Arturo.
This BoF, like any other BoF or WG meeting, will have an audio stream and a
jabber room, and comments from the Jabber room will be channeled to the
room microphones.
The BoF chairs (yet to be determined) or the AD MAY request that the
meeting be covered
Hi Arturo.
This BoF, like any other BoF or WG meeting, will have an audio stream and a
jabber room, and comments from the Jabber room will be channeled to the room
microphones.
The BoF chairs (yet to be determined) or the AD MAY request that the meeting be
covered with MeetEcho or WebEx.
On Sep 24, 2013, at 3:04 PM, Valery Smyslov sva...@gmail.com wrote:
I just reread the introduction of RFC 4945 and I don't understand its
purpose. So I'm not sure it should be referenced from 5996bis.
Ok, if there is any disagreement about it, then I think it is better
to leave it out from
Hi David
I believe this would require a separate document. But I'm not sure that tying
it to an IP address is appropriate. IKE implementations work from behind NAT
devices and sometimes move around (see MOBIKE), so I think it would be more
appropriate to tie the record to any type of ID
On Sep 17, 2013, at 10:44 PM, Hector Santos hsan...@isdg.net
wrote:
On 9/17/2013 1:55 PM, Michael Tuexen wrote:
On Sep 17, 2013, at 7:48 PM, Scott Brim scott.b...@gmail.com wrote:
On Tue, Sep 17, 2013 at 1:37 PM, Michael Tuexen
michael.tue...@lurchi.franken.de wrote:
I was always
On Sep 17, 2013, at 11:17 PM, joel jaeggli joe...@bogus.com
wrote:
On 9/16/13 5:23 PM, Tom Ritter wrote:
On 16 September 2013 17:10, Bruce Morton bruce.mor...@entrust.com wrote:
Sounds reasonable. One question is that since it is not widely used, does it
meet the 0.1 percent of connections
On Sep 16, 2013, at 11:31 PM, John Levine jo...@taugh.com wrote:
How do I know that the sender of this message actually has the right
to claim the ORCID in question (-0001-5882-6823)? The web page
doesn't present anything (such as a public key) that could be used
for authentication.
I
Hi
While working on some text for the AD-VPN document, I came across some
weirdness in the base IKEv2 specification:
The IDi and IDr payloads have any of several types: ID_IPV4_ADDR, ID_FQDN,
ID_RFC822_ADDR, ID_IPV6_ADDR, ID_DER_ASN1_DN, ID_DER_ASN1_GN, and ID_KEY_ID.
Section 4 (conformance
On Sep 11, 2013, at 2:45 AM, Ted Lemon ted.le...@nominum.com wrote:
On Sep 10, 2013, at 6:50 PM, Phillip Hallam-Baker hal...@gmail.com wrote:
Could be but I have been working through what we know versus what would be
required and I really can't see how a group of people who would let Snowden
Why not both?
Regular network interfaces in most operating systems are dual-atack: they can
have an IPv4 address and several IPv6 addresses. So it makes sense for the
client to ask for both, and for the IRAS to offer both, if it runs both IPv4
and IPv6 traffic. If for example IPv6 is missing
Hi
I believe this report should be rejected. The address returned in the
INTERNAL_IP6_ADDRESS attribute is not a /64 subnet, it is just one address. The
fact that it belongs to a /64 subnet is besides the point, and in fact the TSi
payload in both the original and corrected versions contains
On Aug 30, 2013, at 5:26 PM, SM s...@resistor.net wrote:
The nit is why is the IETF still using PDT.
Because we don't want to get into a religious war of GMT vs UTC.
PM
To: Yoav Nir
Subject: New Version Notification for draft-nir-ipsecme-cafr-02.txt
A new version of I-D, draft-nir-ipsecme-cafr-02.txt has been successfully
submitted by Yoav Nir and posted to the IETF repository.
Filename:draft-nir-ipsecme-cafr
Revision:02
Title
On Aug 25, 2013, at 9:45 AM, Yaron Sheffer yaronf.i...@gmail.com wrote:
Hi Yoav,
I started by reading -01, then went back to -00. And I think the two can be
merged to create a better solution.
Including the notification as soon as the peers know they want a handover is
cleaner. So
I guess, but it's still using one notification to announce another notification.
On Aug 25, 2013, at 1:08 PM, Yaron Sheffer yaronf.i...@gmail.com
wrote:
And this would imply support for Childless, too?
Thanks,
Yaron
On 2013-08-25 13:01, Yoav Nir wrote:
Or do my other favorite
22, 2013 11:26 AM
To: Yoav Nir
Subject: New Version Notification for draft-nir-ipsecme-cafr-01.txt
A new version of I-D, draft-nir-ipsecme-cafr-01.txt has been successfully
submitted by Yoav Nir and posted to the IETF repository.
Filename:draft-nir-ipsecme-cafr
Revision:01
Title
-21 06:47, Yoav Nir wrote:
Hi IPsec-WG,
Based on the review comments from various working group members, we have
made a revision to our original proposal for ADVPN protocol. In this
revision, we have tried to address most review comments. More review
comments will be addressed in future
Hi Trevor.
I think (a) is definitely worth doing, but I also think that (b) can be done
along the way. Is there some reason why (a) and (b) can't be requirements
filled by a single mechanism?
Regarding smart cookies vs channel ID: Not changing TLS is a definite advantage
of Smart Cookies.
On Aug 20, 2013, at 9:01 PM, Trevor Perrin tr...@trevp.net wrote:
On Tue, Aug 20, 2013 at 1:39 AM, Yoav Nir y...@checkpoint.com wrote:
Hi Trevor.
I think (a) is definitely worth doing, but I also think that (b) can be done
along the way.
Interesting... If we were to prioritize them
On Aug 10, 2013, at 6:30 PM, Hadriel Kaplan hadriel.kap...@oracle.com wrote:
But, if the IESG feels an encoding mechanism doesn't need any targeted
use-case to be published as a PS, then please ignore my email for purposes of
consensus. I'm not strongly for/against - just answering
On Aug 10, 2013, at 10:55 PM, Phillip Hallam-Baker
hal...@gmail.commailto:hal...@gmail.com wrote:
On Sat, Aug 10, 2013 at 7:12 PM, Yoav Nir
y...@checkpoint.commailto:y...@checkpoint.com wrote:
On Aug 10, 2013, at 6:30 PM, Hadriel Kaplan
hadriel.kap...@oracle.commailto:hadriel.kap
On Aug 9, 2013, at 12:21 AM, Jorge Contreras cntre...@gmail.com wrote:
Can you elaborate on why the license makes a difference?
We have been told it would make it easier for people to make and distribute
translations.
--Paul Hoffman
Actually, verbatim translations are already
On Aug 5, 2013, at 2:43 PM, Scott Brim scott.b...@gmail.com wrote:
On 08/05/13 07:31, Hadriel Kaplan allegedly wrote:
Yup, afaict we were doing ok until IETF 87... but at least one anonymous
jabber participant (named Guest) did remotely speak multiple times at the
mic on one of the RAI
Hi
Let me try to summarize where we are with this discussion.
There has been some suggestions that all policy headers such as CSP. However, a
well-known URI is unique per domain, while CSP can be different for each
resource. So only policy elements that are domain-specific rather than
On Aug 4, 2013, at 9:09 PM, Ted Lemon ted.le...@nominum.com wrote:
On Aug 3, 2013, at 10:23 PM, Yoav Nir y...@checkpoint.com wrote:
The participation in the IETF is already pseudonymous. I have a driver's
license, a passport, and a national ID card, all proving that my name is
indeed Yoav
On Aug 4, 2013, at 11:11 PM, John Levine jo...@taugh.com wrote:
At last week's very successful Berlin meeting, the finances were
thrown of whack by the late discovery that the IETF had to pay 19%
German VAT on the registration fee. At the IAOC session they said
that about half of that is
the requirements of the
note well acceptance in my view.
Hi Olle
The participation in the IETF is already pseudonymous. I have a driver's
license, a passport, and a national ID card, all proving that my name is indeed
Yoav Nir. But I have never been asked to present any of them at the IETF. I
claim
There's the slight matter of $123.50 in VAT.
To me personally that is minor compared with the much lower price of a flight
to Germany as compared with a flight to the US. But for people working in the
US, there's the more expensive flight, and the more expensive meeting.
Yoav
On Aug 2, 2013,
On Aug 2, 2013, at 1:19 PM, Martin Thomson martin.thom...@gmail.com wrote:
On 2 August 2013 13:04, Yoav Nir y...@checkpoint.com wrote:
There's the slight matter of $123.50 in VAT.
This was such a good meeting, I think that I could justify paying
extra to cover VAT.
I agree, but it's easy
On Aug 1, 2013, at 11:14 AM, Andy Bierman a...@yumaworks.com wrote:
Hi,
Isn't it obvious why humming is flawed and raising hands works?
(Analog vs. digital). A hand is either raised or it isn't.
The sum of all hands raised is comparable across tests.
The sum of the amplitude of all hums
On Aug 1, 2013, at 6:43 PM, Phillip Hallam-Baker
hal...@gmail.commailto:hal...@gmail.com wrote:
On Thu, Aug 1, 2013 at 12:30 PM, Chris Palmer
pal...@google.commailto:pal...@google.com wrote:
On Mon, Jul 29, 2013 at 9:13 AM, Phillip Hallam-Baker
hal...@gmail.commailto:hal...@gmail.com
On Jul 30, 2013, at 6:10 PM, Michael Richardson mcr+i...@sandelman.ca
wrote:
Keith Moore mo...@network-heretics.com wrote:
Rooms are set up not to facilitate discussion, but to discourage it. The
lights are dim, the chairs are facing forward rather than other participants,
the
On Jul 28, 2013, at 6:23 AM, l.w...@surrey.ac.uk
wrote:
I would be very sorry to see IETF *working* meetings turned into
something closer to conferences,
with poster sessions!
And mandatory suit and tie (or women's equivalent business attire) for
presenters and chairs.
On Jul 28, 2013, at 7:35 AM, Keith Moore mo...@network-heretics.com wrote:
On Jul 28, 2013, at 6:17 AM, Melinda Shore wrote:
On 7/27/13 8:13 PM, Randy Bush wrote:
yup. i guess it is time for my quarterly suggestion to remove the
projectors and screens.
Then I guess it's time for my
On Jul 28, 2013, at 9:33 AM, Marc Petit-Huguenin petit...@acm.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/28/2013 09:10 AM, Yoav Nir wrote:
On Jul 28, 2013, at 7:35 AM, Keith Moore mo...@network-heretics.com
wrote:
On Jul 28, 2013, at 6:17 AM, Melinda Shore
On Jul 28, 2013, at 10:14 AM, Marc Petit-Huguenin petit...@acm.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/28/2013 09:47 AM, Yoav Nir wrote:
On Jul 28, 2013, at 9:33 AM, Marc Petit-Huguenin petit...@acm.org wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
On Jul 19, 2013, at 3:10 PM, Yaron Sheffer
yaronf.i...@gmail.commailto:yaronf.i...@gmail.com wrote:
Hi,
the comments below are focused on the protocol, rather than on its fit with our
requirements. So in a sense I'm jumping the gun here.
Summary
First, the document is very well written,
On Jul 14, 2013, at 4:34 PM, Hector Santos hsan...@isdg.net wrote:
On 7/13/2013 2:20 PM, Yoav Nir wrote:
So finding your site is not that difficult for first-timers. But regardless,
the people who type in addresses or DNS names in full are rare and far
between.
Agreed. Just
On Jul 13, 2013, at 7:58 PM, Hector Santos hsan...@isdg.net wrote:
Try typing out my domain, winserver.com. First timers will not get the
WINSERVER.COM web site, but Microsoft's WIN SERVER 201x and/or WINDOWS SERVER
web sites first.
I did as you suggested earlier, and typed winserver, but
On Jul 12, 2013, at 5:03 PM, Scott Brim scott.b...@gmail.com
wrote:
On Fri, Jul 12, 2013 at 1:14 AM, Hui Deng denghu...@gmail.com wrote:
I really don't know whether IETF should recommend Deng Hui or Hui Deng
That's the question! :-D
I believe the Chinese participants should reach this
On Jul 11, 2013, at 12:32 AM, Trevor Perrin
tr...@trevp.netmailto:tr...@trevp.net wrote:
ChannelID seems to solve these problems, seems more polished than other
proposals, and apparently is being experimentally deployed (see Chrome |
Preferences | Cookies and site data |
On Jul 11, 2013, at 7:51 PM, Trevor Perrin
tr...@trevp.netmailto:tr...@trevp.net wrote:
But even if we restrict our solution to HTTPS, I don't see how ChannelID helps
a problem like the BEAST and CRIME attacks. In both cases, the issue is the
scoping of cookie use. An attacker's web page or
On Jul 10, 2013, at 12:07 AM, Ted Lemon ted.le...@nominum.com
wrote:
On Jul 9, 2013, at 4:58 PM, Scott Brim scott.b...@gmail.com wrote:
Is the great majority of the wisdom in the IETF incorporated into a
few megacorporations?
(That might reflect market share, in which case, is it a
On Jun 27, 2013, at 1:03 PM, Eggert, Lars l...@netapp.com wrote:
Hi,
Section 2 says:
RFC 3777 [RFC3777], Section 5, Nominating Committee Operation,
Paragraph 1 of Rule 14, is replaced as follows:
Members of the IETF community must have attended at least 3 of
last 5 IETF
there.
--
HLS
On 6/24/2013 4:18 PM, Yoav Nir wrote:
On Jun 24, 2013, at 10:52 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
On 6/24/13 1:47 PM, Michael Thornburgh wrote:
my feeling and belief is that RFC 2119 only gives SHOULD and
RECOMMENDED the same normative requirement level
On Jun 24, 2013, at 10:52 PM, Peter Saint-Andre stpe...@stpeter.im wrote:
On 6/24/13 1:47 PM, Michael Thornburgh wrote:
my feeling and belief is that RFC 2119 only gives SHOULD and
RECOMMENDED the same normative requirement level, but that it does
not override or change the distinct meanings
I think remembering the nullified and expired pins for max-max-age adds
complexity. It's fine to do, but we shouldn't require it.
A website that issues a bad pin for 30 days has to live with the consequences
of that pin for all of those 30 days. Getting a pre-loaded pin list could save
you and
Hi David
As far as I know, this idea was not discussed before. If we were to do this,
the proper URI for this would be some kind of RFC 5785 URI like
/.well-known/pins or /.well-known/hpkp.
Looking at the examples in the key-pinning draft, an HPKP header using SHA-1
takes just under 120
On Jun 19, 2013, at 10:07 PM, SM s...@resistor.net
wrote:
Hi Aaron,
At 11:40 19-06-2013, Aaron Yi DING wrote:
Relating to the statement above(I assume Phillip is addressing the US
Academia), not quite sure are we still discussing the same topic?
sorry, I am bit confused .. since IETF is
On Jun 19, 2013, at 10:12 PM, Doug Barton do...@dougbarton.us
wrote:
On 19/06/13 18:33, Phillip Hallam-Baker wrote:
Academia is still one of the worst environments for discrimination.
They don't have formal barriers as in the past but the informal
barriers are steep.
Relating to
On Jun 19, 2013, at 6:26 PM, Brian Haberman br...@innovationslab.net wrote:
To help facilitate the mentoring aspect, there will be a call soon for
volunteers to act as mentors for newcomers (starting with IETF 87). Once the
web page for the mentoring program with all the information is up,
://windows.microsoft.com/en-us/windows7/smartscreen-filter-frequently-asked-questions-ie9
[4] http://www.imperialviolet.org/2012/02/05/crlsets.html
On Sat, Jun 1, 2013 at 11:41 PM, Yoav Nir
y...@checkpoint.commailto:y...@checkpoint.com wrote:
Hi
Just trying to get us close to consensus. Still
On Jun 2, 2013, at 10:38 AM, l.w...@surrey.ac.uk wrote:
Always Europe gets better results because it is the favoriate
meeting-location for ALL
businesses
{{citation needed}}
Here you go:
http://en.wikipedia.org/wiki/Edsel_Citation
(idea taken from http://what-if.xkcd.com/47/ - is this a
On May 29, 2013, at 5:09 AM, Melinda Shore melinda.sh...@gmail.com wrote:
On 5/28/13 3:06 PM, l.w...@surrey.ac.uk wrote:
The centres for networking industry in Australia are Melbourne and Sydney,
in that order.
It's a bit like IETF 51 being held in Grimsby, not London or Cambridge.
I agree. I think that this non-strict behavior is something that UAs will
implement anyway, because otherwise the UA doesn't work in any place that has a
next generation firewall (which is pretty much any firewall these days)
And if they did stick to only strict behavior, pretty much none of
LCD?
Anyway, What I found most useful when I was starting out 9 years ago, was to
look over the list of areas and working groups ( http://tools.ietf.org/area/ )
and find out which of them are working on something that is of interest to me.
In my case it was mostly the security area, and the
On May 27, 2013, at 5:23 PM, Dave Crocker d...@dcrocker.net wrote:
On 5/27/2013 4:13 PM, Yoav Nir wrote:
Anyway, What I found most useful when I was starting out 9 years ago,
One might wish for a document that gives such guidance to folk who are new to
the IETF.
And indeed
I used Expedia to price flights for me on March 2014:
- Buenos Aires: $1401 (21h each way)
- London (where the meeting actually happens): $413 (7h each way. Direct costs
a bit more)
- Vancouver: $1217 (24 h each way? $1288 with a more reasonable 16h)
- Honululu: $1535 (28h each way)
-
On May 22, 2013, at 3:10 PM, John C Klensin john-i...@jck.com wrote:
--On Tuesday, May 21, 2013 11:07 +0200 Stephane Bortzmeyer
bortzme...@nic.fr wrote:
...
Although these tests certainly contributed to the good
technical quality of the name servers, they were removed both
for
On May 16, 2013, at 11:55 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote:
I think Dave's idea is worth looking at, but have one comment:
On 05/16/2013 09:46 PM, Yoav Nir wrote:
There is a problem, though, that this will increase the load on ADs.
There is that. But don't forget
On May 17, 2013, at 12:58 AM, Keith Moore mo...@network-heretics.com wrote:
On 05/16/2013 04:46 PM, Yoav Nir wrote:
The time for asking whether the group has considered making this field fixed
length instead of variable, or whether RFC 2119 language is used in an
appropriate way
On May 17, 2013, at 1:38 AM, Fred Baker (fred) f...@cisco.com wrote:
On May 16, 2013, at 1:46 PM, Yoav Nir y...@checkpoint.com wrote:
There is a problem, though, that this will increase the load on ADs. Other
concerns raised during IETF LC may lead to revised I-Ds, which the ADs
On May 17, 2013, at 6:37 PM, Dave Crocker d...@dcrocker.net wrote:
On 5/17/2013 7:01 AM, Keith Moore wrote:
But WGs should be able to periodically summarize what they're doing -
what problem they're trying to solve, what approach they're taking, what
technologies they're using, what major
On May 17, 2013, at 2:54 AM, Brian Weis b...@cisco.com wrote:
[snip]
Yaron: do we want to stay with the current TCP-based solution?
Brian: might be running on sensors that don't have a TCP stack
Someone made this comment, but it wasn't me.
That was Daniel.
Yoav
On May 16, 2013, at 9:08 PM, Scott Brim
scott.b...@gmail.commailto:scott.b...@gmail.com wrote:
On Thursday, May 16, 2013, Dave Crocker wrote:
By the time the IESG schedules the vote, ADs need to already have educated
themselves about the document.
Oh, so you're suggesting adding another phase
+1
On May 16, 2013, at 10:43 PM, Valery Smyslov sva...@gmail.com
wrote:
Hi,
I approved the conclusion.
Regards,
Valery.
- The group still thinks this is an important problem that needs an
interoperable solution.
- We would like to abandon the work on IKE-over-TCP.
- And to work
On May 15, 2013, at 6:06 PM, Keith Moore mo...@network-heretics.com
wrote:
IMO, IESG should have grounds to reject any document that isn't specifically
authorized in a WG's charter.
- Keith
Why? There's definitely a process failure there, and it should be blamed on the
WG chairs
Hi Matthew.
Actually, that section makes it all the more puzzling. It lists 3 disclosures
that relate to several RFCs, but none of those RFCs relates to Diffie-Hellman.
Instead they relate to lists of algorithms, so I'm not sure how this helps
cover the concerns.
Yoav
On May 13, 2013, at
Hi Martin
Such guidance in the spec is relevant for the rightful domain owners. Suppose
an attacker got some CA to issue a bad certificate for facebook.com. The
attacker now sets up this certificate on some public proxy, and sets a pin for
20 years. Within days the attack is discovered, the
On May 7, 2013, at 1:08 AM, SM s...@resistor.net wrote:
At 13:23 06-05-2013, Brian E Carpenter wrote:
I don't that is quite right. The problem in this case is not to do
with linguistic quality. It's due to a lack of formal verification
Quoting from the detective story:
At [censored] we
Hi Valery.
I agree with your conclusion (that we should do an IKE fragment thing, maybe
based on your draft).
However, 2 comments:
1. You can never know if anything is IPR free. At best you can say that nobody
has said anything yet.
2. IKE over TCP has worked for over 10 years in my
Hi folks
We think it's time to move on with Key Pinning, as there haven't been
substantial issues raised in months. The one outstanding contentious issue is
the one in the subject: http://trac.tools.ietf.org/wg/websec/trac/ticket/57
We've heard the argument that allowing pins to exist for
On May 2, 2013, at 4:32 PM, Michael Richardson mcr+i...@sandelman.ca wrote:
SM == SM s...@resistor.net writes:
SM There is an open position which has not been filled. Is NomCom
SM 2012 still continuing its work?
SM The IETF usually has a NomCom Chair. Who is the current
Hi Toby.
Let's see if I understand the issue. I'll describe this with an example. Please
let me know if I got it.
Suppose we have satellite gateways A, B, C, D, and E. A through D each have a
bandwidth of 10 Mb/s, while E has 20 Mb/s.
The center gateway, Z, has plenty of bandwidth and the
Hi Martin,
On Apr 30, 2013, at 6:21 PM, Martin Stiemerling martin.stiemerl...@neclab.eu
wrote:
Hi Ted,
On 04/30/2013 01:19 AM, Ted Hardie wrote:
So, this page: http://www.ietf.org/iesg/members.html still has TBD
listed for one of the transport ADs. Is there a projected date for
On Apr 27, 2013, at 8:02 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:
Dear IPsec folks,
The ipsecme working group is chartered to come up with a solution for
transporting long IKEv2 messages over networks that do not perform IP
fragmentation correctly, and as a result drop overly long
a wg. But still worth documenting as
experimental.
Lloyd Wood
http://sat-net.com/L.Wood/
From: Yoav Nir [y...@checkpoint.com]
Sent: 19 April 2013 10:02
To: Wood L Dr (Electronic Eng)
Cc: wor...@ariadne.com; ietf@ietf.org
Subject: Re
reputation.
On Apr 19, 2013, at 11:23 AM, l.w...@surrey.ac.uk wrote:
and the point of your ad-hominem argument is what, exactly?
Lloyd Wood
http://sat-net.com/L.Wood/publications/internet-drafts
From: Yoav Nir [y...@checkpoint.com]
Sent: 18 April
On Apr 19, 2013, at 10:31 PM, Ted Hardie
ted.i...@gmail.commailto:ted.i...@gmail.com
wrote:
On Fri, Apr 19, 2013 at 11:47 AM, Dave Cridland
d...@cridland.netmailto:d...@cridland.net wrote:
Nice post.
I wonder whether a better mechanism for drawing newcomers into the inner circle
- which is
Not entirely true.
It is true that getting management positions (chairs, AD, NomCom) requires
meeting attendance. But a non-attender can get recognition for quality
technical points, and can even progress technical work. RFC 4478 was published
long before I attended my first meeting. My own
attend because I think that makes me more effective. If for any reason I
were no longer able to attend, I think I would still participate meaningfully.
-Original Message-
From: l.w...@surrey.ac.uk [mailto:l.w...@surrey.ac.uk]
Sent: Thursday, April 18, 2013 1:12 PM
To: Yoav Nir
Cc: wor
On Apr 11, 2013, at 6:11 PM, Ray Pelletier rpellet...@isoc.org wrote:
All
The IETF is concerned about diversity. As good engineers, we would like
to attempt to measure diversity while working on addressing and increasing
it. To that end, we are considering adding some possibly sensitive
Hi
tl;dr: Looks fine, please publish
I am not a cryptographer and not competent to comment on the issues that this
draft is trying to solve or on the quality of this solution.
Speaking strictly as a developer, the text is clear and understandable. Doing
the mental exercise of estimating what
On Apr 8, 2013, at 10:19 PM, Måns Nilsson mansa...@besserwisser.org wrote:
Subject: Re: Proposed solution for DPEP (Diversity Problem Entry Point) -
IETF April 1 jokes. Date: Mon, Apr 08, 2013 at 05:57:54AM -0800 Quoting
Melinda Shore (melinda.sh...@gmail.com):
I am absolutely not
I mostly share the sentiment that this is just humor, so what's the harm.
That said, I did at one point have to exercise my diplomatic skills when I got
forwarded a customer (nameless here for evermore) question about whether
support for RFC 3514 was on our roadmap.
While the people on this
On Apr 7, 2013, at 6:41 PM, Måns Nilsson mansa...@besserwisser.org wrote:
Subject: RE: [IETF] Comments for Humorous RFCs or uncategorised RFCs or
dated?April the first Date: Sun, Apr 07, 2013 at 11:59:30AM + Quoting
Yoav Nir (y...@checkpoint.com):
I mostly share the sentiment
701 - 800 of 1331 matches
Mail list logo
