On Nov 16, 2011, at 3:31 PM, Tero Kivinen wrote:
Frederic Detienne writes:
Again, I urge you to be specific because there is nothing tangible
in your claims. I understand what you mean but if you rationalized
it, you would see your intuition fools you.
When one does not know what problem
On Nov 16, 2011, at 3:38 PM, Tero Kivinen wrote:
Frederic Detienne writes:
Frederic Detienne writes:
And like I said earlier, the amount of negotiation when there are
multiple prefixes to protect is limited to one. With modern ipsec
tunneling (got to love that), there is still a lot of
On Nov 15, 2011, at 10:24 AM, Brian E Carpenter wrote:
Please can everybody who doesn't upload PDF to the meeting materials page
at least take care to upload PPT instead of PPTX?
Not everybody has paid the ransom necessary to open PPTX files.
The latest LibreOffice (and I think also
What Paul said, mostly, but see below.
On Nov 15, 2011, at 2:39 AM, Paul Wouters wrote:
On Sun, 13 Nov 2011, Vilhelm Jutvik wrote:
From page 62, RFC 4301:
...
4. Apply AH or ESP processing as specified, using the SAD entry
selected in step 3a above. Then match the packet against the
Hi Frederic
Inline...
On Nov 15, 2011, at 11:42 AM, Frederic Detienne wrote:
Hi Yoav,
We will be there (following offline with you for the details).
I do not think there is a need to spend 20 minutes on the draft which
everyone should have read. There are three vague points in it and
Also, who's going to present for Cisco?
On Nov 13, 2011, at 10:49 PM, Yoav Nir wrote:
Cool. You can use slides, or just handwave. Whatever works for you.
Too bad IETF rooms don't come with whiteboards.
If you are making slides, please send them to me in advance (powerpoint,
OpenOffice
Hi all
This is to announce a side meeting about peer to peer VPN, as described in our
recently published draft: http://tools.ietf.org/html/draft-nir-ipsecme-p2p-00
In the meeting we will discuss the use case of directly connecting two IKE
implementations that already have a path of trust
Hi all
I am glad to see the great volume of comments about our draft. However, we
do seem to be talking about too many things at the same time.
The problems people are talking about can be divided into two broad
categories:
- Setting up tunnels between perfect strangers.
- Setting up tunnels
On 11/7/11 9:44 PM, Michael Richardson m...@sandelman.ca wrote:
Praveen == Praveen Sathyanarayan pravee...@juniper.net writes:
Praveen In this solution, HUB is the trust entity that all spoke
Praveen establish static IPSec tunnel (either using Site to site
Praveen tunnel or spoke
On 11/7/11 10:19 PM, Michael Richardson m...@sandelman.ca wrote:
Yoav == Yoav Nir y...@checkpoint.com writes:
Yoav I don't see how DNS figures into this. We have three
Yoav gateways: - hub-gw, which knows the protected domains of
Yoav everyone - spoke32, which protects
:
ipsec-boun...@ietf.orgmailto:ipsec-boun...@ietf.org
[mailto:ipsec-boun...@ietf.org] 代表 Yoav Nir
发送时间: 2011年10月14日 13:24
收件人: ipsec@ietf.orgmailto:ipsec@ietf.org
主题: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem
Statement
Hi all
For years, one of the barriers to the adoption of IPsec
Hi Yaron
Sorry for taking so long to respond. My comments inline.
On Oct 14, 2011, at 11:37 AM, Yaron Sheffer wrote:
I am going on vacation, but I did want to post these before. Sorry if I
cannot take part in the ensuing discussion.
Overall, this is a good start for an important set of
On 11/1/11 7:51 PM, Keith Welter welt...@us.ibm.com wrote:
Having been working for the same vendor for 10 years, I've gotten used to
our marketing jargon. Anyway, I'd like to have some short term for the
set of addresses that are behind a certain gateway, or the set of
addresses that you can
On 10/31/11 3:30 PM, Michael Richardson m...@sandelman.ca wrote:
Jorge == Jorge Coronel jcoro...@live.com writes:
Jorge +1
Jorge I agree DNSSEC cannot be assumed, its deployments have been
Jorge marginal.
DNSSEC is *one* *public* trusted third party. It's not the only way to
Chris' case is a little different, because he is willing to do some work to
establish trust between the two administrative domains, so it's not really
opportunistic (although doing it with OE might be a solution)
So there could be some hub gateway that could do the introducing, perhaps
over
decisions based on the results
combined with a policy.
I hope that helps!
Chris
-Original Message-
From: Yoav Nir [mailto:y...@checkpoint.com]
Sent: Sunday, October 23, 2011 10:37 PM
To: Ulliott, Chris; Michael Richardson; ipsec@ietf.org
Subject: Re: [IPsec] New -00 draft: Creating Large Scale
Cheaper, yes. Easier?
Sure, a 5-hour flight to Paris sure beats a 12-hour flight to New York plus a 4
hour flight to Minneapolis, but you end up in Paris, and if the conference
hotel is too expensive for your corporate budget (it usually is for mine), you
have to go really far away to find a
Hi Chris
As I've asked you off-list, I'm still trying to understand the initial
condition.
It's one thing if Za believes that host 2 is behind *some* gateway, and
it's only a matter of finding out which gateway that is.
It's a different thing if host 2 might also be not behind any gateway at
/12_0t5/feature/guide/ted.html
Dan.
On Thu, October 13, 2011 10:23 pm, Yoav Nir wrote:
Hi all
For years, one of the barriers to the adoption of IPsec was that
configuration didn't scale. With thousands of peers, the PAD and SPD
would
become unwieldy, so even where IPsec was deployed
Hi all
For years, one of the barriers to the adoption of IPsec was that
configuration didn't scale. With thousands of peers, the PAD and SPD would
become unwieldy, so even where IPsec was deployed it was often built in
hub-and-spoke configurations, not because policy demanded this, but
because it
On 9/27/11 12:45 AM, Martin Rex m...@sap.com wrote:
So there seem to be two problems:
- The server (svn.tools.ietf.org) does not seem to be sufficiently
aware of the server names that it is servicing.
If it takes more than a server configuration file change to make it
aware of that
On 9/27/11 12:45 AM, Martin Rex m...@sap.com wrote:
- The server (svn.tools.ietf.org) does not seem to be sufficiently
aware of the server names that it is servicing.
If it takes more than a server configuration file change to make it
aware of that additional hostname, then there is a
On Sep 26, 2011, at 5:25 AM, Paul Hoffman wrote:
On Sep 25, 2011, at 7:20 PM, Stuart Cheshire wrote:
% svn info https://svn.tools.ietf.org/svn/wg/hybi
svn: OPTIONS of 'https://svn.tools.ietf.org/svn/wg/hybi': SSL negotiation
failed: SSL error code -1/1/336032856
forgot to attach.
tls.cap
Description: tls.cap
On Sep 26, 2011, at 11:11 PM, Yoav Nir wrote:
On Sep 26, 2011, at 5:25 AM, Paul Hoffman wrote:
On Sep 25, 2011, at 7:20 PM, Stuart Cheshire wrote:
% svn info https://svn.tools.ietf.org/svn/wg/hybi
svn: OPTIONS of 'https
On Sep 20, 2011, at 9:08 PM, Chris Palmer wrote:
Is attached, now in XML. The main change is that I got rid of widely
and rightly reviled pin revocation business, and replaced it with a
better idea from Trevor Perrin. Big thanks to everyone who reviewed
and commented on the previous draft.
On Sep 21, 2011, at 3:57 AM, Chris Palmer wrote:
And one comment as to substance. Section 3.1 says Have a safety net.
Generate a backup key pair, get it signed... I agree that this is a good
idea for e-commerce site that lose sales on any outage. But what if I
generate a backup key pair
On Sep 19, 2011, at 9:19 PM, Keith Moore wrote:
On Sep 19, 2011, at 12:27 PM, Peter Saint-Andre wrote:
On 9/19/11 10:14 AM, Alejandro Acosta wrote:
+1
I also support the idea of every RFC havving the associated wiki.
I think that if some people support the idea, they can easily create a
On Sep 14, 2011, at 2:06 AM, SM wrote:
Hi Yoav,
At 11:41 13-09-2011, Yoav Nir wrote:
Six months ago we would not have thought that Comodo or DigiNotar
were easy to hack. In the latter case, the customers of DigiNotar
were left out in the cold. Without
The DigiNotar partnership has
: Friday, August 26, 2011 7:27 PM
To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir'
Cc: 'ipsec@ietf.org'
Subject: RE: [IPsec] DH keys calculation performance
-Original Message-
From: Naveen B N (nbn)
Sent: Friday, August 26, 2011 1:37 AM
To: Naveen B N (nbn); Scott Fluhrer (sfluhrer
On Aug 11, 2011, at 6:58 PM, Martin Rex wrote:
Richard Kulawiec wrote:
Let me start with a preamble: I think that those of us who choose
to drink from the firehose by subscribing to many mailing lists
List-Id: is only useful for folks who have either lots of time on
their hands, or want
On Aug 8, 2011, at 10:56 AM, Ole Jacobsen wrote:
Nothing is a reasonable walk when the average temperature is 32 C.
At least not for the average IETF attendee.
(34 in April, 31 in December, lowest nightime temp 21 in December and
27 in April-May-June).
Pretty much like Tel Aviv in
Hi
At the meeting in Quebec, I gave a presentation at the hokey meeting about
http://tools.ietf.org/html/draft-nir-ipsecme-erx .
The draft covers using the EAP extensions for re-authentication in IKEv2. The
obvious (to me) use-case is a phone connected to a 802.1x network. As you leave
the
On 8/3/11 4:55 PM, Tero Kivinen kivi...@iki.fi wrote:
Yoav Nir writes:
There is no such consensus that protocol variants are a good thing.
I think it's just the opposite. Although I don't think it's Tero's
job to stop the publication of three documents that are for the
same thing
On 8/1/11 5:14 PM, Keith Moore mo...@network-heretics.com wrote:
On Aug 1, 2011, at 9:39 AM, John Leslie wrote:
For one, I suggest we take remote-participation _seriously_ for the
Friday meetings. Many of us are waiting-for-Godot at airports on Friday,
and could certainly wear a
I think this is a terrible idea.
IKEv2 has a way for mutual authentication with a shared key.
A concern was raised that this method was vulnerable to guessing if trivial
shared keys were configured.
There were several proposals for a better cryptographic method.
The IPsecME working group
Alright, here's one.
http://tools.ietf.org/html/draft-nir-ipsecme-erx-01 defines an extension to
IKEv2 so that ERX (as defined by the HOKEY group) can be used with IKEv2.
This will allow a seamless transfer from a local network protected by 802.1x to
a public network where your access needs to
I think this is a terrible idea.
IKEv2 has a way for mutual authentication with a shared key.
A concern was raised that this method was vulnerable to guessing if trivial
shared keys were configured.
There were several proposals for a better cryptographic method.
The IPsecME working group
On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote:
Hello,
The DH exchange (Calculation of Public/Private key and the Secret) in
IKEV2 Initial exchange
seems to be very expensive. This is slowing down the overall IKEv2
tunnel establishment.
Is there a way to optimize it?
Hi
Hi
Very appropriate for XKCD to post this just a few days before an IETF
meeting.
http://www.xkcd.com/927/
(For those who are not familiar with XKCD, don't miss the alt-text on the
picture)
Yoav
___
Ietf mailing list
Ietf@ietf.org
[Helmet on]
Maybe they should first move the 14 competing standards to Historic.
On 7/20/11 10:17 AM, Bert (IETF) Wijnen berti...@bwijnen.net wrote:
I LOVE this one.
Bert
On 7/20/11 8:23 AM, Yoav Nir wrote:
Hi
Very appropriate for XKCD to post this just a few days before an IETF
meeting
On Jul 15, 2011, at 10:20 AM, Julian Reschke wrote:
On 2011-07-11 16:50, Internet-Drafts Administrator wrote:
This is a reminder that the Internet Draft Final Submission (version -01
and up) cut-off is today, July 11, 2011.
All Final Version (-01 and up) submissions are due by 17:00 PT
Extremist-A should be to publish a 6to4 considered dangerous draft with lots
of MUST NOT language.
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Martin
Rex
Sent: 06 July 2011 23:50
To: Doug Barton
Cc: v6...@ietf.org; ietf@ietf.org
Subject:
IPsec usually runs in kernels, so C seems to be the norm
I'm not aware of any C++ implementations.
On Jun 1, 2011, at 9:23 AM, Muhammad Nasir Mumtaz Bhutta wrote:
hi,
i need to change the IPSec functionality, is there any implementation of
IPSec in higher order languages like java, .net
Yup.
Years ago, when I was at university, I learned that the best way to find an
article was to google the author's name, find his or her personal website, and
the article would probably be linked from there.
Worked about 75% of the time.
Yoav
-Original Message-
From:
A bargain! RFC 5996 goes for $58.
Does it come leather-bound with the title gold-stamped on the cover?
On May 9, 2011, at 1:06 AM, Bob Braden wrote:
I just discovered an astonishing example of misinformation, shall we say, in
the IEEE electric power community. There is an IEEE standards
On May 5, 2011, at 11:41 PM, Yaron Sheffer wrote:
Hi,
I think we are going down a rathole on the issue of authenticated identity.
Most IKE gateways, like many other security devices, normally make policy
decisions based on groups. I will provide secure connectivity to
On May 5, 2011, at 9:17 AM, Dan Harkins wrote:
Hello,
On Wed, May 4, 2011 10:45 pm, Yoav Nir wrote:
OK. I see what you mean. Certificates are not necessarily better. She
might have a certificate with a subject like
UID=alice,OU=people,O=intranet,DC=example,DC=com, or the AAA
Hi Balaji.J
For the most part, a VPN gateway uses sufficiently few addresses (hundreds or a
few thousands) that IPv6 is not necessary. This is the reason that there was
little interest in changing the way IPv6 addresses are assigned in CONFIG
payloads.
There's also the idea that with IPv6
On May 4, 2011, at 9:18 AM, Qin Wu wrote:
Hi,
- Original Message -
From: Yoav Nir y...@checkpoint.com
To: Qin Wu sunse...@huawei.com
Cc: ipsec@ietf.org
Sent: Wednesday, May 04, 2011 1:30 PM
Subject: Re: [IPsec] New I-D: draft-nir-ipsecme-erx-00
On May 4, 2011, at 4:50 AM
Hi Dan,
On May 4, 2011, at 9:47 PM, Dan Harkins wrote:
On Tue, May 3, 2011 10:30 pm, Yoav Nir wrote:
[snip]
The Authenticator needs the true identity to make policy decisions.
Well then DO NOT use EAP for authentication.
Dan.
I'm sure I don't understand your point. The IKE
On May 2, 2011, at 11:54 PM, Yaron Sheffer wrote:
[Responding to IPsec only:]
Hi Yoav,
thanks for the new draft. I'm afraid one needs to read RFC5296bis before
commenting, but here's a few questions anyway:
- Sending the domain in the IKE_SA_INIT response obviously contradicts
the
On May 4, 2011, at 4:50 AM, Qin Wu wrote:
- I am missing the authenticated peer identity, which I would assume
should arrive from the AAA server. This should be the basis of RFC4301
policy decisions on the IKE gateway. Does ERP provide this identity?
The EAP-Initiate/Re-auth packet
Hi.
Qin and I have just posted the subject draft. The title is An IKEv2 Extension
for Supporting ERP, although it has nothing to do with enterprise resource
planning.
This draft brings the ERP extension for EAP, which is developed by the Hokey
group into the IKEv2 authentication exchange,
On Apr 12, 2011, at 3:17 PM, Tero Kivinen wrote:
This kind of framework would allow using any of the secure password
authentication methods in a way where they can co-exist in the same
implementation. If the implementation is done properly, then it might
be even possible to make it so that
On Mar 31, 2011, at 6:39 PM, Bhatia, Manav (Manav) wrote:
Yoav Nir (from IPSecME) had raised a point suggesting that RFC4301 doesn't
mandate all traffic to go via the IPSec tunnel and one could implement
policies such that PTP traffic doesn't go via the tunnel. This imo will not
work
Hi all
Yesterday, the IESG has started last call on three documents:
- draft-harkins-ipsecme-spsk-auth-03
- draft-shin-augmented-pake-03
- draft-kuegler-ipsecme-pace-ikev2-05
All three seek to improve the authentication in IKEv2 when using pre-shared
keys, as compared with RFC 5996. The IPsecME
Hi all
Yesterday, the IESG has started last call on three documents:
- draft-harkins-ipsecme-spsk-auth-03
- draft-shin-augmented-pake-03
- draft-kuegler-ipsecme-pace-ikev2-05
All three seek to improve the authentication in IKEv2 when using pre-shared
keys, as compared with RFC 5996. The IPsecME
On Mar 16, 2011, at 1:08 AM, Brian E Carpenter wrote:
To make clear which documents were issued under the original regime
and which were issued under the new, there should probably be
an obvious gap in the number range (going to 5 digit or 6 digit numbers).
Oh, have you any guess how many
Hi all.
This version includes remarks by Magnus Nyström.
To see the differences, follow this link:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-failure-detection-06
Yoav
On Mar 10, 2011, at 10:15 PM, internet-dra...@ietf.org
internet-dra...@ietf.org wrote:
A New Internet-Draft is
I also agree that this draft is useful, and I support its going forward, either
as a WG document or as an individual document.
While data communications may originate from either side (sensor notifies
controller, controller queries sensor, controller sends command to actuator), I
think it is
On Feb 28, 2011, at 10:40 AM, Bob Hinden wrote:
Pete,
On Feb 27, 2011, at 11:32 PM, Pete Resnick wrote:
I'm sorry, but how could this *not* be posted to the IETF list?
http://xkcd.com/865/
I did a rough calculation and think they would have not run out of IPv6
addresses :-)
I
Yup. It's posted (right after mine)
On Feb 28, 2011, at 12:39 PM, Chris Elliott wrote:
Bob, et al.:
I took the liberty of informing Randall that he hit the IETF list on his
forum here:
http://forums.xkcd.com/viewtopic.php?f=7t=68893
May take a bit for my post to get approved.
And,
On Mar 1, 2011, at 5:00 AM, John Levine wrote:
http://www.ntia.doc.gov/frnotices/2011/fr_ianafunctionsnoi_02252011.pdf
I'm glad to see they are up to date:
Paper submissions should include a three and one-half inch computer
diskette in HTML, ASCII, Word or WordPerfect format (please
so far!
--Paul Hoffman
On Feb 11, 2011, at 11:54 AM, IETF I-D Submission Tool wrote:
A new version of I-D, draft-ietf-ipsecme-failure-detection-04.txt has been
successfully submitted by Yoav Nir and posted to the IETF repository.
Filename: draft-ietf-ipsecme-failure-detection
Hi Yaron
I think this addresses the issues well. However, there is one more thing.
Section 3 is currently in skeleton form and needs to be expanded a lot.
For example, RFC 6027 says the following:
o It requires multiple parallel SAs, for which the peer has no use.
Section 2.8 of
Hi all.
Following last week's conf call, Scott Moonen has proposed text to resolve
issue #202. The idea is to remove section 9.4 entirely, and change section 9.2
as follows:
OLD:
9.2. QCD Token Transmission
A token maker MUST NOT send a QCD token in an unprotected message for
an
Hi Keith.
Thanks for the comments. My responses inline.
On Jan 19, 2011, at 2:36 AM, Keith Welter wrote:
1. The last paragraph of section 2 seems to be making an argument against
supporting QCD. Would it be possible to add a counterpoint or to reword the
paragraph? When I got to the end of
Hi Scott.
Thanks for your comments. My replies inline.
On Jan 12, 2011, at 10:45 PM, Scott C Moonen wrote:
Comments on the draft, mostly editorial in nature:
(1) There are still some blockquotes that start with excessive first-line
indents, eg., the three quotes on page 5.
Those are
On Jan 30, 2011, at 10:00 AM, Yoav Nir wrote:
(13) Page 8, the last line is an orphan.
Not sure what you mean. It says In any case, the lack of a QCD_TOKEN
notification MUST NOT be taken and then continues on the next page.
OK. Now that Yaron has helped me figure out what an orphan
I'd like to also point out that Scott and Keith have pointed out some nits in
the spec (on the 12th and 19th of January respectively), which will also be
included in the final version.
Yoav
On Jan 27, 2011, at 6:42 PM, Paul Hoffman wrote:
This message closed out the WG LC. There remains one
1. Yes
2. No. In that case, the correct response in NO PROPOSAL CHOSEN.
3. That is not correct processing. First the responder should match the SA
payload to its own policy. If a match it found, the responder can compare the
DH group in the matched proposal to the one in the KE payload
On Jan 10, 2011, at 11:31 AM, Lars Eggert wrote:
Hi,
On 2011-1-8, at 19:41, R. B. wrote:
I'm really in a rush, but I want to send my 0.02 too. I like the idea of a
poster session, since a single I-D could go unobserved in the churn of other
I-Ds.
many areas have open meetings where
On Jan 10, 2011, at 1:22 PM, Loa Andersson wrote:
ALl,
what is here called poster session reminds me a awful lot of the
bar bof's we been running for a long time.
No coincidence. There's been a lot of criticism of these bar BoFs, and we keep
looking for better ways to present new ideas.
On Jan 10, 2011, at 1:09 PM, Henk Uijterwaal wrote:
The costs for a poster session are almost 0. Isn't this something we
can just try?
I don't agree that the costs are zero. You can't have the poster session last
all week long, because the presenter may want to go to other sessions. So we
We can have as high a barrier as necessary to ensure there are no more than,
say, 12 posters.
On Jan 11, 2011, at 3:39 AM, John C Klensin wrote:
+1. Very strongly.
Whether the logistics of space and times could be worked out or
not, poster sessions strike me as a really bad idea and Fred
Greetings.
We have just submitted version -03 of the draft. This closes issues, #198,
#199, #200, and #201.
Which leaves us with just one issue: #202
= Issue #202: Token makers generating the same tokens without
synchronized DB
Section 10.4 of the draft has a use-case where a
Hi Kaushal.
This mailing list is about the IKE and IPsec protocols, not some particular
implementation.
IIRC on Ubuntu you can install either StrongSwan or racoon, with StrongSwan
being the default on recent versions.
I suggest you seek support either at the StrongSwan site (
On Jan 6, 2011, at 11:26 AM, Alessandro Vesely wrote:
I've never attended an IETF meeting. Why? Because it seems to me quite
unlikely to have a chance to say something useful by going there. I mean
useful with respect to a problem that I consider important. That is, not
just a minimal
Sigh.
You'd think they would have learned by now.
A native IPv6 network will restore end-to-end connectivity with a vastly
expanded address space...
On Jan 5, 2011, at 11:56 PM, Richard L. Barnes wrote:
This seems like a document that might interest some on this list...
From: Robert Cannon
On Jan 4, 2011, at 5:55 PM, Phillip Hallam-Baker wrote:
It could be the 11a support.
Or it might well be the vendor that supplies the 11a equipment.
At home I have a box with 7 defunct WiFi routers that I discarded after they
started to fail. Specifically the wireless side of the router
Hi
The Prague meeting is still nearly 3 months away, but I'm wondering why there's
only a date yet.
No hotel, no registration, no details.
Some of us need to get the corporate wheels or authorization moving.
Thanks
Yoav
___
Ietf mailing list
Thanks
On Dec 30, 2010, at 2:15 PM, Ray Pelletier wrote:
On Dec 30, 2010, at 4:38 AM, Yoav Nir wrote:
Hi
The Prague meeting is still nearly 3 months away, but I'm wondering why
there's only a date yet.
No hotel, no registration, no details.
Some of us need to get the corporate
Hi all.
Issue #200 is about some text in section 8 (Interaction with Session
Resumption). The text says that a rebooted peer (and thus a defunct SA) may go
undetected for the lifetime of the SA. However, RFC 5996 says that at some
point, a peer that did not receive incoming traffic on a
Hi Gaurav.
In IKEv2, we don't call them cookies any more, but IKE SPIs. Since you're
initiating, you start with just the initiator IKE SPI (not a pair), and the
message ID for the first message is zero, not 1.
IKE SA INIT messages always have message ID zero. I would bet that many
Hi all
An issue that has come up on this mailing list, and also in Beijing, is what
implementations should assume either of the two roles (token maker and token
taker).
The current text is in section 9.1, and is summarized as follows:
o For remote-access clients it makes sense to implement
Hi all
This issue is about some of the wording of section 7.4. I don't agree that this
is mostly wrong, but I think the group's energies are better spent elsewhere.
Section 7, in its entirety is about alternative solutions that were not adopted.
I think we can either delete the whole section,
On Nov 15, 2010, at 10:41 PM, Masataka Ohta wrote:
Phillip Hallam-Baker wrote:
You are incorrect.
Firewalls can be used for many purposes. Authenticated traversal is well
established in the firewall model.
Given the diversity of firewalls and their operations, it's
practically
To: Yoav Nir y...@checkpoint.com
Cc: i...@ietf.org i...@ietf.org, IETF discussion list ietf@ietf.org,
jordi.pa...@consulintel.es jordi.pa...@consulintel.es
Subject: Re: [IAOC] Badges and blue sheets
On Nov 12, 2010, at 4:08 AM, Yoav Nir wrote:
On Nov 12, 2010, at 7:36 AM, JORDI PALET
On Nov 14, 2010, at 10:06 AM, SM wrote:
At 04:03 12-11-10, Shane Kerr wrote:
It is sometimes possible to create systems to meet the needs of privacy
and oversight - for example a closed review board - but I think just
publishing a list of who gets free access to each IETF is probably good
a
On Nov 14, 2010, at 10:50 PM, SM wrote:
enough, because the corruption that we're trying to solve would
require collaboration between the IETF chair and the IAOC. I would
say that the risk is low enough that privacy trumps transparency.
As you used the term corruption, I'll go with it.
On Nov 12, 2010, at 7:36 AM, JORDI PALET MARTINEZ wrote:
Hi Henk,
I don't agree. If there is people essential to the meeting but can't pay,
as we all pay for that, we have the right to know.
I disagree with that. There is a privacy issue here. If x can't pay his way,
and needs a comp
On Nov 3, 2010, at 1:42 PM, t.petch wrote:
tp
Perhaps we should step back a little further, and refuse to charter work that
will become an RFC unless there are two or more independent organisations that
commit to producing code. There is nothing like interoperability for
demonstrating the
Strange. I look at the same facts, and reach the opposite conclusions.
The fact that there were many implementations based on drafts of standards
shows that industry (not just us, but others as well) does not wait for SDOs to
be quite done. They are going to implement something even we label
On Oct 29, 2010, at 10:39 PM, Andrew Sullivan wrote:
If all of those things are right and we're actually trying to solve
them all, then it seems to me that the answer is indeed to move to _n_
maturity levels of RFC, where _n_ 3 (I propose 1), but that we
introduce some new document series
On Oct 30, 2010, at 10:01 AM, Glen Zorn wrote:
The second biggest thing that IETF could do to raise productivity in
meetings is to ban Internet use in meetings except for the purpose of
remote participation.
Harder to do not clearly an improvement: it clear out meeting rooms a bit,
but
.
Yoav
On Oct 28, 2010, at 3:57 AM, Keith Moore wrote:
On Oct 27, 2010, at 8:58 AM, Yoav Nir wrote:
This comes back to the question or why have maturity levels at all. Ideally, an
implementer should prefer to implement a mature standard over a less-mature
one. In practice, adopting the more
This comes back to the question or why have maturity levels at all. Ideally, an
implementer should prefer to implement a mature standard over a less-mature
one. In practice, adopting the more advanced standard may give you an obsolete
protocol, rather than a more stable one. IOW the
On Oct 27, 2010, at 10:56 PM, Bob Braden wrote:
In this environment, the only thing that seems to make sense is for WGs
to start usually at Experimental (someone else suggested this, I
apologize for not recalling who it was).
You might mean me. But having authored 2 experimental
and
complexity.
Thanks,
Yaron
On 10/24/2010 10:55 AM, Yoav Nir wrote:
#195 was closed as a duplicate of (the already closed) #191.
#193, #194, and #197 will be closed with the publishing of draft -02.
#202 (below) is newly submitted, and I expect a lively discussion
Hi all. Tero Kivinen sent the message included below to the mailing list on
September 8th.
I am fine with this text.
Please read it thoroughly, and if there are no objections, I will incorporate
it into the next version of the draft (which I intend to publish at the last
possible moment on
1001 - 1100 of 1334 matches
Mail list logo
