Dear IETF secretariat,
The IPPM group would like to ask for publication of draft-ietf-ippm-more-twamp
as an RFC. The shepherd note for the document is attached.
Henk
- - - -
Document shepherd writeup for draft-ietf-ippm-more-twamp-00, as required by
rfc4858, and specfied in the 17-Sep-2008
Original Message
Subject: [ippm] Milestone completed
Date: Wed, 22 Apr 2009 12:21:35 +0200
From: Henk Uijterwaal h...@ripe.net
To: IETF IPPM WG i...@ietf.org, Lars Eggert lars.egg...@nokia.com, Matthew J
Zekauskas m...@internet2.edu
Dear secretariat,
Please mark this IPPM
On 2009-4-21, at 9:00, Sam Hartman wrote:
Keith, I've considered your points and continue to disagree. I'm
mostly replying in the interest of judging consensus.
I believe that the primary use cases identified in the MIF BOF are use
cases that are not going to go away. I think that saying
I agree with Christian that there are two orthogonal issues. Comments
in line...
- Ralph
On Apr 22, 2009, at 1:19 AM 4/22/09, Christian Vogt wrote:
Folks -
It seems that folks are considering two related, yet still orthogonal
topics for inclusion in the MIF charter:
- Conflicts between
Lars,
- Conflicts between configuration parameters.
- Issues with address selection.
I agree that both of these are important and should be worked on (and
with the rest of your email, basically).
The first one is what I thought MIF would be focusing on, as an INT WG
is IMO the right
I agree with Lars.
Giyeong
-Original Message-
From: mif-boun...@ietf.org [mailto:mif-boun...@ietf.org] On Behalf Of
Lars Eggert
Sent: April 22, 2009 9:42 AM
To: Sam Hartman
Cc: Ted Hardie; Adrian Farrel; mif; Keith Moore; IETF Discussion
Subject: Re: [mif] WG Review: Multiple InterFaces
One of the commentators in a recent thread suggested that another
person was beyond reproach
That has been worrying me as a security person for a number of
reasons. Not least the fact that in my business nobody is ever beyond
reproach
For the past eight years the establishment press in
Jari Arkko a écrit :
But my main point is that the MIF charter covers -- on purpose -- a
relatively large problem area. We need to describe the problem as
experienced by real-life implementations without constraining ourselves
too much at this stage. Once we finally understand the problem
I don't see any compelling reason to change the name of this group at
this point...
We obviously could change the name if we wanted to, but it would
significant cost -- setting up a new mailing list, getting everyone
subscribed there, renaming all of the drafts (and thus losing the edit
Keith Moore wrote:
It seems to me that the general problem is not multiple interfaces, but
multiple addresses per host. It doesn't matter (much) whether those
addresses result from multiple physical interfaces, a combination of
physical and virtual network interfaces, multiple prefixes being
George Tsirtsis wrote:
There is, however, significance in the presence of different
interfaces in a given non-router node...I do not think either of the
other two points (multiple IFs, multiple routes) should be lost
completely in the effort to widen/clarify the charter.
George
P.S.: It would
Hui Deng wrote:
Hi, Jari,
What I suggest is like the below:
Connections to Multiple Networks (mif)
Personally, I think that this sort of disconnect between WG name and
acronym would create long-lived confusion about the name of the
Multiple InterFaces (mif)
Last Modified: 2009-04-20
I like this version of the charter very much. I think it does a good
job of capturing the area that we need to discuss within MIF. I am
hopeful that we can get our charter approved ASAP, so
Dean Willis wrote:
My shaman once said For God, everything is just a question of
policy. But, we need to reduce this problem to a more mortal scope,
and I'm not quite certain that the proposed charter text accomplishes
this goal.
I agree with you that this is a complex problem. The
Christian Vogt wrote:
The second topic talks about a problem of applications: When initiating
a connection, which pair of source and destination address (and
consequently which pair of interfaces) should be used? Again, this
issue may come up independently of whether a host has one or
Hi Lars,
Lars Eggert wrote:
On 2009-4-22, at 2:19, Christian Vogt wrote:
It seems that folks are considering two related, yet still orthogonal
topics for inclusion in the MIF charter:
- Conflicts between configuration parameters.
- Issues with address selection.
I agree that both of these
If you are saying multiple address for multiple interface, that's fine.
but if you are talking multiple address for single interface, could you help to
point out any IPv4 scenario except VPN,
MIF is targeting at least half billion of subscribers who have this
real problem,
The problems you raised
...Popper said that it is reasonable to assume that sooner or later
some rotten scoundrels will gain power. It's not important who they
will be precisely, but whatever your political views might be you must
agree that a likelihood of such an event is rather high. So whatever
law you want to have
If anyone is looking for a theme for a t-shirt at any upcoming IETF, this
one would be awesome...
:-)
Spencer
There is an old saw that my work is a cross-layer optimization; yours is
a layer violation, and that guy's is a hideous hack.
___
Excerpts from Margaret Wasserman on Wed, Apr 22, 2009 10:29:07AM -0400:
Lars Eggert wrote:
On 2009-4-22, at 2:19, Christian Vogt wrote:
It seems that folks are considering two related, yet still orthogonal
topics for inclusion in the MIF charter:
- Conflicts between configuration parameters.
Excerpts from Ted Hardie on Wed, Apr 22, 2009 10:21:10AM -0700:
At 7:29 AM -0700 4/22/09, Margaret Wasserman wrote:
(1) As I pointed out in my previous message to Christian, address
selection is not (today) a transport-layer or application-layer function
in most cases. Given that this is
At 1:55 PM -0700 4/22/09, Scott Brim wrote:
As I understand it, the ICE client is not deciding on what address to
use on its packets, it is _discovering_ what address it is using and
then communicating that to its peers as payload (not providing it as
fodder for a forwarding function).
I think
(2) There is no way that these decisions can be made solely at the
transport or application layer, because source (and to a lesser degree
destination) address selection is tightly tied to the first-hop
forwarding decision. The outbound interface, source address and default
router all have to
On Apr 22, 2009, Margaret Wasserman wrote:
This topic, address selection, is not currently handled by
applications.
In many cases, it is handled entirely by the stack (through ordering
of
the destination ddresses in DNS replies and source address selection
in
the IP stack), and in other
Excerpts from Christian Vogt on Wed, Apr 22, 2009 04:03:39PM -0700:
My main point, though, was that we are talking about two orthogonal
issues -- conflicting configuration and address selection. This
holds independently of the fact that an application may let the
operating system accomplish
On Apr 22, 2009, Margaret Wasserman wrote:
(2) There is no way that these decisions can be made solely at the
transport or application layer, because source (and to a lesser degree
destination) address selection is tightly tied to the first-hop
forwarding decision. [...]
Margaret -
FWIW:
Christian - I think address selection is part but not all of the
problem.
I would be happy to see a summary of current practice in dealing with
simultaneous attachment to multiple networks. How does an iPhone
decide between its WiFi and dell interfaces? How does an RG that can
reach
A new Request for Comments is now available in online RFC libraries.
RFC 5507
Title: Design Choices When Expanding the DNS
Author: P. Faltstrom, Ed.,
R. Austein, Ed.,
P. Koch, Ed.
Status:
A new Request for Comments is now available in online RFC libraries.
RFC 5526
Title: The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System
(DDDS) Application for Infrastructure ENUM
A new Request for Comments is now available in online RFC libraries.
RFC 5528
Title: Camellia Counter Mode and Camellia
Counter with CBC-MAC Mode Algorithms
Author: A. Kato, M. Kanda,
S. Kanno
Status:
A new Request for Comments is now available in online RFC libraries.
RFC 5529
Title: Modes of Operation for Camellia
for Use with IPsec
Author: A. Kato, M. Kanda, S. Kanno
Status: Standards Track
Date:
31 matches
Mail list logo
