Martin Rex wrote:
How do you think about P2P applications?
NAT-PMP or IGD over UPnP come to mind.
P2P applications need seed peers with fixed addresses and ports.
Masataka Ohta
___
Ietf mailing list
On 06/30/2011 02:12 AM, Mikael Abrahamsson wrote:
My high level comment/question is: the proposed charter seems to
stress that IPv6 is the driver behind this potential wg effort...
however, I think that this deserves more discussion -- it's not clear
to me why/how typical IPv6 home networks
On 06/30/2011 12:56 AM, Masataka Ohta wrote:
Fernando Gont wrote:
I personally consider this property of end-to-end connectivity as
gone.
How do you think about P2P applications?
I think about applications that would benefit from e2e connectivity, but
since it is gone, they have to spend
On 06/30/2011 02:26 AM, Keith Moore wrote:
Rather than having another of an endless series of discussions about
the merits of NAT or lack thereof, can we just agree that it should
not be pre-ordained that this WG should assume NAT as a solution?
I was originally arguing, at the very least, in
Fernando Gont wrote:
I personally consider this property of end-to-end connectivity as
gone.
How do you think about P2P applications?
I think about applications that would benefit from e2e connectivity, but
since it is gone, they have to spend quite a bit of effort to traverse
Fernando,
First off, I'm switching the reply headers to f...@ietf.org now, deleting
the old homegate list from this discussion.
Secondly, I would like to explain the motivation behind focusing this
work on IPv6. Its not so much about IPv6 being different (though I hope
it is in some
Fernando,
My point was that, except for the mechanism for PD, I don't see a
substantial difference here that would e.g. prevent this from being
developed for IPv4 (in addition to IPv6). -- Yes, I know we need to
deploy IPv6... but I don't think you can expect people to get rid of
their
Jari,
On 06/30/2011 06:38 AM, Jari Arkko wrote:
But their architecture is largely done and cannot be easily affected.
Vendors are now looking into adding IPv6 into their home routers and
other devices. I want to be able to show them how to do it right. They
can, of course, replicate
Fernando,
My point is: Will implementation of the produced RFCs lead to home
networks in which stuff works for IPv6 differently from how it works for
IPv4?
That is the plan. And when I say differently, I mean differences such as
* prefix delegation
* global addresses and firewalls instead
Dear Peter,
The work group is a discussion/e-meeting where issues/topics are raised and
deliberated on. The issues has to do the internet and its related issues.
Kind regards,
Otueneh
Sent from my BlackBerry wireless device from MTN
-Original Message-
From: Amenawon Osa Peter
Hi, Mark (and Jari),
Thanks so much for your clarification! All my questions/comments have
been addressed.
Thanks,
Fernando
On 06/30/2011 06:57 AM, Mark Townsley wrote:
I think the consensus we had in the past BoFs and discussion in and
around this topic can be summed up as stating that
On Jun 30, 2011, at 12:51 AM, Melinda Shore melinda.sh...@gmail.com wrote:
On 6/29/11 8:32 PM, Keith Moore wrote:
However it does not follow that home networks need NAT or private address
space. Those are hacks of the 1990s. They always were shortsighted, and
they turned out to be an
On Jun 30, 2011, at 5:47 AM, Fernando Gont wrote:
Jari,
On 06/30/2011 06:38 AM, Jari Arkko wrote:
But their architecture is largely done and cannot be easily affected.
Vendors are now looking into adding IPv6 into their home routers and
other devices. I want to be able to show them how to
On 06/30/2011 09:21 AM, Keith Moore wrote:
If our work focuses only on IPv6, I get the impression that we're
heading in that direction.
nothing says that some results of the work can't also apply to IPv4.
but people are far too mired in outdated assumptions today, such as
the idea that
I am conufsed by this review of the KARP design guidelines document.
My first reaction was that I had trouble understanding the general
points. However, when I looked at the more detailed explaantion, what I
see is The threats document should But this is not a review of
the threats
Hi Joel,
On 6/30/2011 6:13 AM, Joel M. Halpern wrote:
I am conufsed by this review of the KARP design guidelines document.
My first reaction was that I had trouble understanding the general
points. However, when I looked at the more detailed explaantion, what I
see is The threats document
From: Melinda Shore melinda.sh...@gmail.com
The focus really needs to be on producing good, secure protocols
The majority of intrusions now seem to be exploiting bugs (and in some cases
bad configurations) in the end-hosts; protocol security flaws are rarely the
problem. This makes
How much of this would change if the abstract began with:
This document captures the design guidance that the KARP working group
is using at the time of publication for guiding the chartered security
analysis and proposal work that it is doing.
And we put that in the front of the intro as
Hi, Joel,
On 6/30/2011 7:14 AM, Joel M. Halpern wrote:
How much of this would change if the abstract began with:
This document captures the design guidance that the KARP working group
is using at the time of publication for guiding the chartered security
analysis and proposal work that it is
I've reviewed this document as part of the transport area directorate's ongoing
effort to review key IETF documents. These comments were written primarily for
the transport area directors, but are copied to the document's authors for
their information and to allow them to address any issues
Hello,
This email is to announce that we will be holding a side meeting for a
pre-working group to review the proposed charter and some of the work to be
completed in the proposed group. The side meeting will take place Monday, July
25th following the Technical Plenary, at 19:30 PM.
Thank
On 29/06/11 23:18 -0300, Fernando Gont wrote:
On 06/29/2011 05:47 AM, Jari Arkko wrote:
[]
o Service providers are deploying IPv6, and support for IPv6 is
increasingly available in home gateway devices. While IPv6 resembles
IPv4 in many ways, it changes address allocation principles and
On Wed, 29 Jun 2011, Fernando Gont wrote:
My high level comment/question is: the proposed charter seems to stress
that IPv6 is the driver behind this potential wg effort... however, I
think that this deserves more discussion -- it's not clear to me why/how
typical IPv6 home networks would be
On Thu, 30 Jun 2011, Fernando Gont wrote:
My point was that, except for the mechanism for PD, I don't see a
substantial difference here that would e.g. prevent this from being
developed for IPv4 (in addition to IPv6). -- Yes, I know we need to
deploy IPv6... but I don't think you can expect
I think the consensus we had in the past BoFs and discussion in and around this
topic can be summed up as stating that homenet deliverables will:
- coexist with (existing) IPv4 protocols, devices, applications, etc.
- operate in a (future) IPv6-only home network in the absence of IPv4
- be
[Please note that this message is going to many mailing lists, please trim as
appropriate when responding.]
I submitted a new version of the draft which addresses most, if not all
comments.
The most notable change, which I would like to ask previous reviewers to look
at again, is the handling
-Original Message-
From: homegate-boun...@ietf.org [mailto:homegate-boun...@ietf.org] On Behalf Of
Mikael Abrahamsson
Sent: 30. juni 2011 07:12
To: Fernando Gont
Cc: homeg...@ietf.org; IETF Discussion
Subject: Re: [homegate] HOMENET working group proposal
On Wed, 29 Jun 2011, Fernando
Agreed. I would phrase it this way:
How to do IPv6 in an IPv4 world.
Some points from the Description:
o Service providers are deploying IPv6, and support for IPv6 is
increasingly available in home gateway devices.
This is only *part* of the story. *Users* have lots of IPv4
devices in
Thanks Mark for stating that.
It would really be helpful if this type of text is included in the
description/charter.
The lack of of this information in the recently distributed material caused
several immediate allergic reactions...
regards, kiwin
On 6/30/2011 2:57 AM, Mark Townsley wrote:
Mark,
100% in agreement with this stance.
Just to echo what Fernando has already stated, you can't completely ignore
IPv4 in the home network especially when you are talking about a
multi-segmented network. For example RFC6204 calls for a separate /64 on
each LAN interface per the L-2
On 6/30/2011 8:06 AM, Weil, Jason wrote:
Overall I like the concept of not breaking core IPv4 functionality while
focussing all new functionality to IPv6.
It is more than just IPv4 functionality... it is all the deployed
applications and devices that utilize IPv4 and for whatever
On Jun 30, 2011, at 4:55 PM, Stephen [kiwin] PALM wrote:
Thanks Mark for stating that.
It would really be helpful if this type of text is included in the
description/charter.
The lack of of this information in the recently distributed material caused
several immediate allergic reactions...
On Jun 30, 2011, at 5:57 AM, Mark Townsley wrote:
I think the consensus we had in the past BoFs and discussion in and around
this topic can be summed up as stating that homenet deliverables will:
- coexist with (existing) IPv4 protocols, devices, applications, etc.
- operate in a
On Jun 30, 2011, at 11:59 AM, Fernando Gont wrote:
On 06/30/2011 12:46 PM, Keith Moore wrote:
I'd like for this group to relax the wherever possible bit, so as to not
preclude solutions where IPv6 can do a better job than IPv4.
IPv4 is a dinosaur gasping for its last breaths.
Just
Keith Moore wrote:
Perimeter security of some kind is probably appropriate.
Not just appropriate, it is an indispensible prerequisite.
That doesn't mean that it has to look like firewalls do today.
Not necessarily. But any sensible security requirements and
primarily the requirement of
On Jun 30, 2011, at 12:14 PM, Martin Rex wrote:
Keith Moore wrote:
Perimeter security of some kind is probably appropriate.
Not just appropriate, it is an indispensible prerequisite.
I could take some issue with the indispensable part, because I also think that
PCs are dinosaurs. For a
On Jun 30, 2011, at 12:33 PM, Mark Townsley wrote:
I think the consensus we had in the past BoFs and discussion in and around
this topic can be summed up as stating that homenet deliverables will:
- coexist with (existing) IPv4 protocols, devices, applications, etc.
- operate in a
(resending cc'd to the KARP WG rather than SIDR; please respond to this
post instead)
Hi, all,
I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are
On Jun 30, 2011, at 09:36 , Keith Moore wrote:
when the group can define something that is useful in IPv6, it shouldn't
matter whether it's also useful for IPv4.
please don't constrain home networks to work only within the confines of IPv4
brain damage.
I suspect what Mr. Townsley and Mr.
Weil, Jason wrote:
Overall I like the concept of not breaking core IPv4 functionality while
focussing all new functionality to IPv6.
Remember that IPv6 became unusably complex by impossible attempts
to add new functionality not available with IPv4, which implies
that there is no such thing as
In message 5c263f1c-a180-4efc-a44f-3e867c6cf...@apple.com, james woodyatt wri
tes:
On Jun 30, 2011, at 09:36 , Keith Moore wrote:
when the group can define something that is useful in IPv6, it shouldn't ma
tter whether it's also useful for IPv4.
please don't constrain home networks to
Keith Moore wrote:
On Jun 30, 2011, at 1:09 AM, Martin Rex wrote:
(a bunch of stuff in defense of NAT)
Rather than having another of an endless series of discussions about
the merits of NAT or lack thereof, can we just agree that it should
not be pre-ordained that this WG should assume
On Jun 30, 2011, at 18:46 , Martin Rex wrote:
And that [false police report incident] is really among the mild unpleasant
things...
It's also not even remotely relevant. Under the regime where that incident
happened, it's not even news anymore when the police do that without any
On Jun 30, 2011, at 9:46 PM, Martin Rex wrote:
Keith Moore wrote:
On Jun 30, 2011, at 1:09 AM, Martin Rex wrote:
(a bunch of stuff in defense of NAT)
Rather than having another of an endless series of discussions about
the merits of NAT or lack thereof, can we just agree that it should
Total of 170 messages in the last 7 days.
script run at: Fri Jul 1 00:53:01 EDT 2011
Messages | Bytes| Who
+--++--+
15.88% | 27 | 13.35% | 185247 | mo...@network-heretics.com
1.76% |3 | 15.97% | 221649 |
I'd like to second the relaxation of wherever possible, which may lead to a
suboptimal solution for several components.
JP Vasseur
Cisco Fellow
Sent from Blackberry
- Original Message -
From: Mark Townsley [mailto:m...@townsley.net]
Sent: Thursday, June 30, 2011 11:33 AM
To: Keith
Dear IETFers,
Let me remind you for the nomination of the Itojun Service Award.
The deadline is July 15.
Thanks,
Jun Murai
===
ANNOUNCING: CALL FOR CANDIDATES FOR ITOJUN SERVICE AWARD
The Itojun Service Award is presented every year to an individual or a
group who has made outstanding
The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Proactive Connectivity Verification, Continuity Check and Remote
Defect indication for MPLS Transport Profile'
draft-ietf-mpls-tp-cc-cv-rdi-05.txt as a Proposed Standard
The W3C Web Real-Time Communications working group will meet on Saturday
23 July 2011 afternoon, starting at 2PM, in Quebec City, Canada,
co-located with the IETF Meeting.
The choice of the date and place is meant to favor synergies between the
W3C WebRTC and the IETF RTCWEB groups. IETF
A new Request for Comments is now available in online RFC libraries.
RFC 6241
Title: Network Configuration Protocol (NETCONF)
Author: R. Enns, Ed.,
M. Bjorklund, Ed.,
J. Schoenwaelder, Ed.,
A.
A new Request for Comments is now available in online RFC libraries.
RFC 6242
Title: Using the NETCONF Protocol over
Secure Shell (SSH)
Author: M. Wasserman
Status: Standards Track
Stream: IETF
Date:
A new Request for Comments is now available in online RFC libraries.
RFC 6243
Title: With-defaults Capability for NETCONF
Author: A. Bierman, B. Lengyel
Status: Standards Track
Stream: IETF
Date: June 2011
A new Request for Comments is now available in online RFC libraries.
RFC 6244
Title: An Architecture for Network Management
Using NETCONF and YANG
Author: P. Shafer
Status: Informational
Stream: IETF
A new Request for Comments is now available in online RFC libraries.
RFC 6289
Title: A Uniform Resource Name (URN)
Namespace for CableLabs
Author: E. Cardona, S. Channabasappa,
J-F. Mule
Status:
A new Request for Comments is now available in online RFC libraries.
BCP 162
RFC 6302
Title: Logging Recommendations for Internet-Facing Servers
Author: A. Durand, I. Gashinsky,
D. Lee, S. Sheppard
Status: Best
A new Request for Comments is now available in online RFC libraries.
RFC 6318
Title: Suite B in Secure/Multipurpose Internet
Mail Extensions (S/MIME)
Author: R. Housley, J. Solinas
Status: Informational
Stream:
56 matches
Mail list logo
