Draft-ietf-ippm-more-twamp

[Henk Uijterwaal]

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 version of
.

(1.a) Who is the Document Shepherd for this document? Has the
  Document Shepherd personally reviewed this version of the
  document and, in particular, does he or she believe this
  version is ready for forwarding to the IESG for publication?

The document shepherd is Henk Uijterwaal .  I have personally
reviewed this document and would not have bothered to write this note if I
didn't feel it was ready for the IESG.

(1.b) Has the document had adequate review both from key WG members
  and from key non-WG members? Does the Document Shepherd have
  any concerns about the depth or breadth of the reviews that
  have been performed?

I believe the document has received sufficent review from WG members.
This is a small extension to a thoroughly reviewed protocol.  I have no
concerns about the depth or breadth of reivews for this document.

(1.c) Does the Document Shepherd have concerns that the document
  needs more review from a particular or broader perspective,
  e.g., security, operational complexity, someone familiar with
  AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
  issues with this document that the Responsible Area Director
  and/or the IESG should be aware of?

None.

  Has an IPR disclosure related to this document been filed?

No.

(1.e) How solid is the WG consensus behind this document? Does it
  represent the strong concurrence of a few individuals, with
  others being silent, or does the WG as a whole understand and
  agree with it?

This is an extension to an existing protocol (TWAMP, RFC 5357).  The issue
came up when the TWAMP protocol was close to completion.  As the WG wanted
to finish TWAMP, it was decided to put possible extensions in another
document.  TWAMP is actively being used by several groups these days,
none of them raised any issues with the document.  The document authors are
both involved with 2 of the implementations of the protocol and would
have flagged any issues.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?

No.

(1.g) Has the Document Shepherd personally verified that the
  document satisfies all ID nits?

There are the following issues:

  ** It looks like you're using RFC 3978 boilerplate.  You should update this
 to the boilerplate described in the IETF Trust License Policy document
 (see http://trustee.ietf.org/license-info), which is required from
 December 16, 2008.  Version 1.34 of xml2rfc can be used to produce
 documents with boilerplate according to the mentioned Trust License
 Policy document.

It is not clear to me if this is correct, as the document was submitted
before Nov 10 (i.e. pre-5378).

  == Missing Reference: '0-31' is mentioned on line 257, but not defined

This looks like an error in the tool.

  == Unused Reference: 'RFC2434' is defined on line 292, but no explicit
 reference was found in the text

  ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)

This reference can go.


  Has the document met all formal review criteria it needs to, such
  as  the MIB Doctor, media type and URI type reviews?

None of these are necessary.

(1.h) Has the document split its references into normative and
  informative?

Yes, the informative reference section can be removed on publication as
there are none.

  Are there normative references to documents that
  are not ready for advancement or are otherwise in an unclear
  state?

No.

(1.i) Has the Document Shepherd verified that the document IANA
  consideration section exists and is consistent with the body
  of the document?

There is an IANA considerations section, it is consistent.

(1.j) Has the Document Shepherd verified that sections of the
  document that are written in a formal language, such as XML
  code, BNF rules, MIB definitions, etc., validate correctly in
  an automated checker?

Not applicable.

(1.k) The IESG approval announcement includes a Document
  Announcement Write-Up. Please provide such a Document
  Announcement Write-Up? Recent examples can be found in the
  "Action" announcements for approved documents. The approval
  announcement contains the following sections:

  Technical Summary

   The IETF has completed its work on TWAMP - the Two-Way Active
   Measurement Protocol.  This memo describe

[Fwd: [ippm] Milestone completed]

[Henk Uijterwaal]

 Original Message 
Subject: [ippm] Milestone completed
Date: Wed, 22 Apr 2009 12:21:35 +0200
From: Henk Uijterwaal 
To: IETF IPPM WG ,	Lars Eggert ,	Matthew J 
Zekauskas 


Dear secretariat,

Please mark this IPPM milestone as done.

Mar 2009Assemble editorial team to work on the process draft 
(WG version of
draft-bradner-metricstest)

Thanks,

Henk

--
Henk Uijterwaal   Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre  http://www.amsterdamned.org/~henk
P.O.Box 10096  Singel 258 Phone: +31.20.5354414
1001 EB Amsterdam  1016 AB Amsterdam  Fax: +31.20.5354445
The NetherlandsThe NetherlandsMobile: +31.6.55861746
--

Belgium: an unsolvable problem, discussed in endless meetings, with no
 hope for a solution, where everybody still lives happily.
___
ippm mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/ippm


--
--
Henk Uijterwaal   Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre  http://www.amsterdamned.org/~henk
P.O.Box 10096  Singel 258 Phone: +31.20.5354414
1001 EB Amsterdam  1016 AB Amsterdam  Fax: +31.20.5354445
The NetherlandsThe NetherlandsMobile: +31.6.55861746
--

Belgium: an unsolvable problem, discussed in endless meetings, with no
 hope for a solution, where everybody still lives happily.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Multiple InterFaces (mif)

[Lars Eggert]

Hi,

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 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 venue for this.


The second one is also important, but much more tricky, because it  
ties in with transports and applications (as Keith and others have  
pointed out already). Topics that cross area boundaries are always a  
bit difficult to charter. I'm at this point not fully convinced that  
simply throwing this in with topic #1 into one WG is going to work.


Lars

smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Multiple InterFaces (mif)

[Lars Eggert]

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 "avoid
multiple addresses" is likely to be the same kind of head-in-sand
thinking that caused us to get where we are today with a number of
areas where there is a disconnect between what the market wants and
what we're willing to include in our engineering model.


Agree with Sam. If you want a host to have a more reliable  
connectivity to the network than any one of its interfaces can give  
it, or if you want to aggregate capacity of multiple network  
connections, you have no choice but to assign it multiple interfaces  
in today's Internet. Nokia alone has probably shipped over a billion  
devices by now that have at least WLAN + 3G, and there are obviously  
many other vendors. Any IETF activity that enables better use of those  
interfaces simultaneously is consequently very interesting.


Lars

smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [mif] WG Review: Multiple InterFaces (mif)

[Ralph Droms]

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 configuration parameters.

- Issues with address selection.

(These two topics also span "issues with multiple network  
connections",

which has been brought up as well.)

The first topic talks about a problem of the network stack:  How are
conflicting parameters for host or interface configuration reconciled
with each other, or, if not reconcilable, which parameters win?  This
issue may come up if configuration parameters are received from  
multiple

sources, such as from any set of default routers, DHCP servers, and
manual configuration.  Hosts with multiple interfaces are more  
likely to
be confronted with this issue, but the issue may also come up for  
hosts

with a single interface.


Yes...this topic arises whenever there are multiple sources of  
"information", and those sources of information may be delivered over  
a single "interface".


I think the topic is modified by the existence of multiple  
"administrative domains".  We could hand-wave away the topic of  
conflicting information from multiple sources in a single admin domain  
as "misconfiguration".  Information from multiple admin domains might  
be conflicting, or might be appropriate only for traffic related to  
the admin domain.  Roughly speaking, there is a vague description of  
the related problem of per-interface and host-wide information  
supplied through DHCP.


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 multiple
interfaces -- though the presence of multiple interfaces makes the  
issue

more difficult to tackle and, since it determines which interface pair
is used, also more important.


In some circumstances, the order of selection might be reversed: pick  
an interface (WiFi versus wired Ethernet) and then choose addresses.


Hm.  Perhaps that would be better expressed as "order of preference";  
some destination might not be reachable through one interface, even if  
that interface might be preferred for other reasons.



Both topics need work; the arguments that have been put forth clearly
show this.  And we have to make a decision whether to tackle either or
both of these topics in the MIF working group.  Personally, I feel  
that

the workload of both topics will be manageable for a single working
group.  Though, if we decide to tackle both, then the working group
charter would have to explicitly list these topics as two separate  
ones.

This would require some, but not much, rewriting of the charter.

In any case, the working group acronym could actually stay as is.  If
the working group will tackle both topics, we could re-use the acronym
for "Multiply Interface Addressing and Configuration".  If only one of
the topics will be tackled, then we could just remove from this the
words "and Configuration" or "Addressing and", respectively.

- Christian


___
mif mailing list
m...@ietf.org
https://www.ietf.org/mailman/listinfo/mif


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [mif] WG Review: Multiple InterFaces (mif)

[Jari Arkko]

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 venue for this.


The second one is also important, but much more tricky, because it 
ties in with transports and applications (as Keith and others have 
pointed out already). Topics that cross area boundaries are always a 
bit difficult to charter. I'm at this point not fully convinced that 
simply throwing this in with topic #1 into one WG is going to work.


First, a minor point: I think everyone is mindful about the fact that 
address selection is a problem that affects apps, transports, and IP 
layer. However, I'll note that address selection has been an Internet 
area topic for some time (RFC 3484, 6MAN work, etc).


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 fully, 
then it is a time to start narrowing down the scope to something 
implementable. However, we are not there yet. The WG needs to complete 
its problem definition task first. When it does, it may be that we no 
longer need a specific WG and the rest can be handled in, say, DHC -- if 
the chosen scope is just parameters conflicts, for instance.


I would also echo what Margaret said about this discussion being 
excellent input for the problem definition work. From my point of view 
I'd like to get the group chartered so that they can do that work, as 
opposed to us writing the full problem definition into the charter. The 
latter would consume quite a bit of IETF discussion list and AD cycles :-)


Jari

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [mif] WG Review: Multiple InterFaces (mif)

[Giyeong Son]

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 (mif)

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 "avoid 
> multiple addresses" is likely to be the same kind of head-in-sand 
> thinking that caused us to get where we are today with a number of 
> areas where there is a disconnect between what the market wants and 
> what we're willing to include in our engineering model.

Agree with Sam. If you want a host to have a more reliable connectivity
to the network than any one of its interfaces can give it, or if you
want to aggregate capacity of multiple network connections, you have no
choice but to assign it multiple interfaces in today's Internet. Nokia
alone has probably shipped over a billion devices by now that have at
least WLAN + 3G, and there are obviously many other vendors. Any IETF
activity that enables better use of those interfaces simultaneously is
consequently very interesting.

Lars

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Beyond reproach

[Phillip Hallam-baker]

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 this country told  
us daily that suggesting that the 'president' was not beyond reproach  
was tantamount to committing treason


It seems to me that many of the social infrastructures that have  
developed over the years by ietf members suffer from being dependent  
on being run by individuals who are and must be beyond reproach


That is a very fragile model

If someone is beyond reproach they are beyond accountability




Sent from my iPhone
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [mif] WG Review: Multiple InterFaces (mif)

[Marc Blanchet]

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 fully,
> then it is a time to start narrowing down the scope to something
> implementable. However, we are not there yet. The WG needs to complete
> its problem definition task first.

fully agree. I was going to write about the same thing!

Marc.

 When it does, it may be that we no
> longer need a specific WG and the rest can be handled in, say, DHC -- if
> the chosen scope is just parameters conflicts, for instance.
> 
> I would also echo what Margaret said about this discussion being
> excellent input for the problem definition work. From my point of view
> I'd like to get the group chartered so that they can do that work, as
> opposed to us writing the full problem definition into the charter. The
> latter would consume quite a bit of IETF discussion list and AD cycles :-)
> 
> Jari
> 
> ___
> mif mailing list
> m...@ietf.org
> https://www.ietf.org/mailman/listinfo/mif


-- 
=
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [mif] WG Review: Multiple InterFaces (mif)

[Margaret Wasserman]

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 
trail), changing entries in the secretariat database, etc.  Personally, 
I haven't seen a justification for changing the name that would be worth 
the effort.  The name we have chosen is fairly general, I agree, but it 
is the purpose of the charter to actually scope the work, not just the 
WG name.


Margaret

Jari Arkko wrote:

Ted,


Huh?  Why on earth is it hard?  Strings are cheap.
  


On some previous WG creation exercise I was told that once the WG 
creation process is in the IETF's database system, the WG acronym 
cannot be changed, you can delete it and create a new one, but you 
cannot the acronym. Of course, I could create a new one and ask it to 
be brought to the right state... hopefully without having to re-do any 
real-life steps, like announcements going out or the topic being on 
the IESG telechat. This might work, but I'd have to investigate 
further to ensure that it actually is possible. If it was the only 
problem I would.


The other problem is that people may already recognize the name. And I 
don't have a nice replacement acronym in mind. Multple Interfaces is a 
very concrete description of the problem, even if its not the most 
generic one. Multiple Attachments to Networks (MAN, but too close to 
6MAN), Connections to Multiple Networks (CMN, a bit boring), etc. But 
its too late in the day here to be creative. I'm sure someone sends 
the coolest acronym in reply :-)


Bottom line: not impossible, but requires some effort.

Jari

___
mif mailing list
m...@ietf.org
https://www.ietf.org/mailman/listinfo/mif



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Multiple InterFaces (mif)

[Margaret Wasserman]

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
advertised on the network attached to any particular interface, or even
a mixture of v4 and v6.
  
Not quite right, IMO.  I think that the problem stems from having 
multiple _prefixes_ per host, because IP hosts don't generally have a 
way to associate configuration information with a particular prefix, nor 
do they have good ways of telling which prefix is most appropriate for 
reaching a certain destination.  Hosts that implement all of the IETF 
protocols (and nothing that tries to do better) currently use 
longest-match, but that doesn't always work well in the "real world".

So that might have some impact on the name, particularly if you want to
attract the breadth of interests whom this affects.  Something like
Hosts Addressed Multiply (HAM), perhaps
As I indicated in my previous message, I don't see the point of changing 
the name, especially not to reflect a concept that this is a multiple 
addresses problem when I don't think that is actual the case.  One of 
the things that this group can/should do is try to figure out where the 
problem lies.  We know that some multi-interface hosts work just fine -- 
where all of their interfaces are under a signal administrative control 
and/or connect to all of the services that a host wants to use.  But, 
there are other cases (corporate VPN, WLAN/cell devices, etc.) where our 
current standards don't work well.  Figuring out exactly where things 
break down is part of this effort.


Margaret

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Multiple InterFaces (mif)

[Margaret Wasserman]

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 be kind of funny to figure out that this WG really has
nothing to do with Multiple IFs, and yet maintain the MIF name... it
would enhance the already obscure tradition of nonsensical terms like
BOFs, RFCs etc ..not to mention other rather funny WG names :-)
I agree with you.  If, for example, the outcome of is that we should 
charger a WG to develop specific standards and/or BCPs for hosts with 
multiple addresses, we should charter that effort under a new name.  Or 
if it were about multiple prefixes, or multiple access networks, or 
multiple administrative domains...  But, at this point, I think that the 
only thing we're sure that we have consensus about is that we run into 
trouble in many cases where hosts have multiple interfaces.


Margaret
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [mif] WG Review: Multiple InterFaces (mif)

[Margaret Wasserman]

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 group.  
While I don't favor changing the name at this point (because I don't 
think we know what to change it to), if we do change the name we should 
change the acronym, too, in my opinion.


Margaret


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [mif] WG Review: Multiple InterFaces (mif)

[Margaret Wasserman]

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 that we can begin 
working on the July milestone of producing a problem statement draft 
that is acceptable to the WG.  I think that much of the recent 
discussion about the charter will be great intput for the problem 
statement work.


Margaret


Current Status: Proposed Working Group

Chair(s):
TBD

Internet Area Director(s):
Ralph Droms 
Jari Arkko 

Internet Area Advisor:
TBD

Mailing Lists:
General Discussion: m...@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/mif
Archive: http://www.ietf.org/mail-archive/web/mif

Description of Working Group:

Many hosts have the ability to attach to multiple networks 
simultaneously. This can happen over multiple physical network 
interfaces, a combination of physical and virtual interfaces (VPNs or 
tunnels), or even through multiple default routers being on the same 
link. For instance, current laptops and smartphones typically have 
multiple access network interfaces.


A host attached to multiple networks has to make decisions about 
default router selection, address selection, DNS server selection, 
choice of interface for packet transmission, and the treatment of 
configuration information received from the various networks. Some 
configuration objects are global to the node, some are local to the 
interface, and some are related to a particular prefix. Various issues 
arise when multiple configuration objects that are global to the node 
are received on different interfaces. At best, decisions about these 
matters have an efficiency effect. At worst, they have more 
significant effects such as security impacts, or even lead to 
communication not being possible at all.


A number of operating systems have implemented various techniques to 
deal with attachments to multiple networks. Some devices employ only 
one interface at a time and some allow per-host configuration of 
preferences between the interfaces but still use just one at a time. 
Other systems allow per-application preferences or implement 
sophisticated policy managers that can be configured by users or 
controlled externally.


The purpose of the MIF working group is to describe the issues of 
attaching to multiple networks on hosts, document existing practice, 
and make recommendations about best current practice. The WG shall 
employ and refer to existing IETF work in this area, including, for 
instance, strong/weak models (RFC 1122), address selection (RFC 3484), 
DHCP mechanisms, Router Advertisement mechanisms, and DNS 
recommendations. The focus of the working group should be on 
documenting the system level effects to host IP stacks and 
identification of gaps between the existing IETF recommendations and 
existing practice. The working group shall address both IPv4 and IPv6 
as well as stateless and stateful configuration.


Network discovery and selection on lower layers as defined by RFC 5113 
is out of scope. Also, the group shall not develop new protocol or 
policy mechanisms; recommendations and gap analysis from the group are 
solely based on existing solutions. The group shall not assume any
software beyond basic IP protocol support on its peers or in network 
nodes. No work will be done to enable traffic flows to move from one 
interface to another. The group recognizes existing work on mechanisms 
that require peer or network support for moving traffic flows such as 
RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile 
IPv6. This group does not work on or impact such mechanisms.


Once the group has completed its work items, the IETF can make an 
informed decision about rechartering the working group to define new 
mechanisms or asking other, specialized working groups (such as DHC or 
6MAN) to deal with specific issues.


Milestones:

May 2009 WG chartered
July 2009 Initial draft on problem statement adopted by the WG
September 2009 Initial draft on existing practices adopted by the WG
Jan 2010 Initial best current practices draft adopted by the WG
March 2010 Problem statement draft submitted to the IESG for 
publication as an Informational RFC
July 2010 Existing practices draft submitted to the IESG for 
publication as an Informational RFC
September 2010 Best current practices draft submitted to the IESG for 
publication as a BCP

October 2010 Recharter or close

___
mif mailing list
m...@ietf.org
https://www.ietf.org/mailman/listinfo/mif



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [mif] WG Review: Multiple InterFaces (mif)

[Margaret Wasserman]

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 purpose of the 
_WG_ (not the charter) is to try to reduce this problem to a more mortal 
scope.  The actual work in the current charter is _not_ to develop a 
solution to this problem, it is to define the problem(s) clearly, and to 
document how current implementations (some of which do some interesting 
things that aren't reflected in any IETF standard) are dealing with this 
problem in the real world.  If/when we fully understand the problem and 
the current status of implementations, we'll be in a better situation to 
start discussing how to solve it.


Margaret

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Multiple InterFaces (mif)

[Margaret Wasserman]

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 multiple
interfaces -- though the presence of multiple interfaces makes the issue
more difficult to tackle and, since it determines which interface pair
is used, also more important.
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 cases the application 
chooses a destination address with the stack choosing a source address.  
There are certain cases (sometimes in solutions to the problems that we 
are discussing here) where applications do choose both the destination 
and sourece address, but they are not common.


Margaret
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [mif] WG Review: Multiple InterFaces (mif)

[Margaret Wasserman]

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 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 venue for this.


The second one is also important, but much more tricky, because it 
ties in with transports and applications (as Keith and others have 
pointed out already). Topics that cross area boundaries are always a 
bit difficult to charter. I'm at this point not fully convinced that 
simply throwing this in with topic #1 into one WG is going to work.


I disagree with your conclusion for two reasons:

(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 currently an Internet-layer function, 
I think it makes sense to analyze the issues with address selection (as 
part of the whole address/interface/router selection process)  in an 
Internet Area group.  If we find that one of the problems we have is 
that the Internet layer doesn't have the right information to make these 
decisions, then possibly some follow-on work might need to be chartered 
elsewhere.


(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 be selected in a coordinate process, to avoid sending 
traffic that will be discarded on the outbound path, due to router filters.


So, while agree that address selection affects transport layers and 
applications, and that it might be necessary for transport layers and 
applications to have better ways of influencing it, I do not believe 
that address selection is a transport layer or applications layer 
function today, nor do I think it can be done solely at those layers in 
the future.


Margaret

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Multiple InterFaces (mif)

[Hui Deng]

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 here is valuable to resolve, but MIF at the early stage
may only solve some simple and easy to solve work,

thanks

-Hui

> I'm saying there is a set of problems that exist if there are multiple
> addresses associated with a host for any reason.  This could be multiple
> addresses on a single interface (including aliases and multiple v6
> prefixes advertised on the network segment), multiple addresses because
> there are multiple active interfaces, multiple addresses because the
> host supports both v4 and v6, multiple addresses because the host has
> some sort of tunnel endpoint (which might be IPvX in IPvY, or an IPsec
> tunnel, or mobileIP), multiple addresses because the host is behind a
> NAT (any kind of NAT, including a v4/v6 NAT), and so on.
>
> And among those problem areas are: address selection (which differs
> depending on the needs of the app, and the configuration of the network
> to which the host is attached), referrals, sorting out policy conflicts,
> sorting out non-policy related configuration, security, etc.
>
> Keith
>
>> Are you saying multiple addresses on one interface of the host?
>>
>> thanks
>>
>> -Hui
>>
>>
>> 2009/4/21 Keith Moore :
>>> Jari Arkko wrote:
 There has been some discussion on whether the key issue is merging
 configuration from multiple sources (the "DHCP view"), multiple
 interfaces (the "original view"), multiple default routers (the "routing
 view"), multiple addresses (the "IP layer view"), multiple
 administrative domains (the "operational view"), and so on.

 I would like to make the point that there is no single, perfect answer.
 Its easy to find examples where the key issues above do not capture
 everything that we want to capture (see, e.g., George's response to
 Keith). Its really about the combination of these issues. And I think
 that is the way it should be.

 The charter text that I sent out yesterday attempts to explain what the
 problem space is without prejudicing ourselves to a view from just one
 perspective (except perhaps through the group's acronym). I think the
 rest is work on the problem statement, and we should let the group write
 that.

 The IESG telechat where this could be approved is two days away. Does
 someone have a big problem with the charter as written, serious enough
 to warrant a change?
>>> 1. I really think that the emphasis on "attachment to multiple networks"
>>> is too narrow, as this is far from the only source of the problem.  As
>>> long as the WG is just trying to understand the problem and identify
>>> existing solutions, it seems appropriate to broaden the scope to
>>> consider the more general problem of multiple addresses per host.
>>>
>>> 2. I also think that, when considering the effect on applications, it
>>> needs to be explicitly pointed out that p2p and distributed apps need to
>>> be considered separately from client-server apps that many people regard
>>> as representative.
>>>
>>> More generally I think that various kinds of effects need to be
>>> considered (i.e. not just the effects on applications) and it would be
>>> very helpful if the charter could lists some examples of these as
>>> illustrations of the breadth of scope.  That would minimize the
>>> potential for the WG to start off with many participants thinking "_the_
>>> problem is X" when the actual problem is much broader and hopefully
>>> get the WG in the mode where it tries to enumerate the various problems
>>> and impacts rather than to try to nail down _which_ problem it is and
>>> ignore the others.
>>>
>>> 3. I am a bit concerned by the charter's mentioning of BCP documents as
>>> a possible output from the WG.  I thought I had seen language in the
>>> charter text saying that the group should write a BCP, but either I was
>>> mistaken or that language has since been removed.  But there's still a
>>> BCP mentioned as a deliverable in the milestones.  My concern is that
>>> the WG will take this as license to try to define best current practice,
>>> which I think is somewhat of a conflict of interest with trying to
>>> identify the problem - especially given the broad scope.
>>>
>>> Keith
>>> ___
>>> Ietf mailing list
>>> Ietf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf
>>>
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [mif] WG Review: Multiple InterFaces (mif)

[Ted Hardie]

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 currently an Internet-layer function,
>I think it makes sense to analyze the issues with address selection (as
>part of the whole address/interface/router selection process)  in an
>Internet Area group.  If we find that one of the problems we have is
>that the Internet layer doesn't have the right information to make these
>decisions, then possibly some follow-on work might need to be chartered
>elsewhere.

So this may be simply one of those cases where address selection
does not fit your model, but at what layer would you describe the ICE
spec as working?  Clearly, one aim in ICE is to provide a signalling-path
mechanism for flow endpoint selection, which certainly relates to the question
of address/interface selection.

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.  However we have arrived
here, it seems at least reasonable to say that we currently have this
work muddled across a variety of layers.  If we can focus it and solve it
at a single layer, the architecture gets easier and the protocol smog
clear a bit.  But I seem to be hearing that tackling the big problem is
ocean-boiling; what I am not clear on is whether the end result of piece work
shifts the pain or actually reduces the smog.

Perhaps it is just me; this is not stuff I am following in any depth.  But the
impression I'm getting from following the thread is that there is some
disagreement about how to structure the work to make sure it really
does reduce pain, rather than just shift it around.

regards,
Ted
Ted
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Beyond reproach

[Clint Chaplin]

"...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 in your country, don't ask yourself the question
"how this law can be used in good hands".  Ask the question "how this
law can be used when the filthiest, dirtiest, stupidest bastards will
rule my country (and sooner or later they probably will)".  Only the
law that cannot be used to do anything wrong EVEN by the most vicious
ruler is truly good"



On 4/22/09, Phillip Hallam-baker  wrote:
> 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 this country told us
> daily that suggesting that the 'president' was not beyond reproach was
> tantamount to committing treason
>
>  It seems to me that many of the social infrastructures that have developed
> over the years by ietf members suffer from being dependent on being run by
> individuals who are and must be beyond reproach
>
>  That is a very fragile model
>
>  If someone is beyond reproach they are beyond accountability
>
>
>
>
>  Sent from my iPhone
>  ___
>  Ietf mailing list
>  Ietf@ietf.org
>  https://www.ietf.org/mailman/listinfo/ietf
>


-- 
Clint (JOATMON) Chaplin
Principal Engineer
Corporate Standardization (US)
SISA
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [mif] WG Review: Multiple InterFaces (mif)

[Spencer Dawkins]

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. 




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [mif] WG Review: Multiple InterFaces (mif)

[Scott Brim]

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.
>>>
>>> - 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 venue for this.
>>
>> The second one is also important, but much more tricky, because it  
>> ties in with transports and applications (as Keith and others have  
>> pointed out already). Topics that cross area boundaries are always a  
>> bit difficult to charter. I'm at this point not fully convinced that  
>> simply throwing this in with topic #1 into one WG is going to work.
>
> I disagree with your conclusion for two reasons:
>
> (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 currently an Internet-layer function,  
> I think it makes sense to analyze the issues with address selection (as  
> part of the whole address/interface/router selection process)  in an  
> Internet Area group.  If we find that one of the problems we have is  
> that the Internet layer doesn't have the right information to make these  
> decisions, then possibly some follow-on work might need to be chartered  
> elsewhere.
>
> (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 be selected in a coordinate process, to avoid sending  
> traffic that will be discarded on the outbound path, due to router 
> filters.
>
> So, while agree that address selection affects transport layers and  
> applications, and that it might be necessary for transport layers and  
> applications to have better ways of influencing it, I do not believe  
> that address selection is a transport layer or applications layer  
> function today, nor do I think it can be done solely at those layers in  
> the future.
>
> Margaret

The first problem (configuration conflicts) is best dealt with before
the second problem (address selection) even arises.  First I
initialize my interface, and then I use it.  They impinge on each
other but they are not tightly bound to each other -- they do not have
to be worked on in the same Working Group.  

I suggest chartering MIF to focus on problem #1, let it make progress,
and in the meantime figure out how to organize work on problem #2 in
parallel.

Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [mif] WG Review: Multiple InterFaces (mif)

[Scott Brim]

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 currently an Internet-layer function,
> >I think it makes sense to analyze the issues with address selection (as
> >part of the whole address/interface/router selection process)  in an
> >Internet Area group.  If we find that one of the problems we have is
> >that the Internet layer doesn't have the right information to make these
> >decisions, then possibly some follow-on work might need to be chartered
> >elsewhere.
> 
> So this may be simply one of those cases where address selection
> does not fit your model, but at what layer would you describe the ICE
> spec as working?  Clearly, one aim in ICE is to provide a signalling-path
> mechanism for flow endpoint selection, which certainly relates to the question
> of address/interface selection.

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).

Scott
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [mif] WG Review: Multiple InterFaces (mif)

[Ted Hardie]

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 if you go back and review the "Gathering Candidates"
section of http://tools.ietf.org/html/draft-ietf-mmusic-ice-19,
you'll see that the Host Candidate portion covers this area:

  The first step is to gather host candidates.  Host candidates are
   obtained by binding to ports (typically ephemeral) on a IP address
   attached to an interface (physical or virtual, including VPN
   interfaces) on the host.

Those candidates become part of the overall candidate list (and
it gets much, much more complicated than this small snippet would
indicate), and the SDP exchange is then a signalling-path mechanism
for working out the best flow pairing. 

regards,
Ted
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [mif] WG Review: Multiple InterFaces (mif)

[Christian Huitema]

> (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 be selected in a coordinate process, to avoid sending
> traffic that will be discarded on the outbound path, due to router
> filters.

Actually, applications can to do that today, using the socket API, if the stack 
implements the "strong host" model. The application just needs to bind the 
socket to a specific IP address. Doing that ensures that packets sourced by the 
application will use the specified address, will go out through the interface 
corresponding to that address, and will use the default gateway associated with 
that interface.

-- Christian Huitema



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Multiple InterFaces (mif)

[Christian Vogt]

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 cases the application chooses a  
destination

address with the stack choosing a source address.  There are certain
cases (sometimes in solutions to the problems that we are discussing
here) where applications do choose both the destination and sourece
address, but they are not common.



Margaret -

From a system perspective, you are certainly right:  Applications
typically do get help from the operating system in selecting their
addresses.  From an OSI layering perspective, though, address selection
still is performed at application layer.  In fact, if an application
wants to do a complete job, especially a peer-to-peer application, it
needs to select both source and destination address itself, possibly
after running STUN, TURN, or ICE.

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 part or all of address selection.

Whether we take this to mean that both issues should be tackled in the
same working group is a different story.  I personally don't see the
orthogonality of the two issues as a reason not to tackle both issues in
the same working group.  We just ought to be aware that the issues are
separate, and the charter should describe them as such.  This said,
there might be work-load- or work-scope-specific reasons that suggest
splitting the work into separate working groups, like those brought up
by Lars, Sam, and Scott.  Those arguments should be discussed as well.

- Christian



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: WG Review: Multiple InterFaces (mif)

[Scott Brim]

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 part or all of address selection.
>
> Whether we take this to mean that both issues should be tackled in
> the same working group is a different story.  I personally don't see
> the orthogonality of the two issues as a reason not to tackle both
> issues in the same working group.  We just ought to be aware that
> the issues are separate, and the charter should describe them as
> such.  This said, there might be work-load- or work-scope-specific
> reasons that suggest splitting the work into separate working
> groups, like those brought up by Lars, Sam, and Scott.  Those
> arguments should be discussed as well.

Exactly.  Thanks.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [mif] WG Review: Multiple InterFaces (mif)

[Christian Vogt]

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:  The fact that address selection determines the first hop does not
mean that address selection could not be performed at the application
layer.  In fact, applications can select their addresses.  This just  
some-

times does not work well, which is what we should analyze and document.

- Christian



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [mif] WG Review: Multiple InterFaces (mif)

[Ralph Droms]

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 multiple next hop routers on its WAN interface select which  
router to forward to?  How does a laptop choose between its WiFi and  
wired interfaces?


- Ralph

On Apr 22, 2009, at 7:03 PM 4/22/09, Christian Vogt wrote:


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 cases the application chooses a  
destination

address with the stack choosing a source address.  There are certain
cases (sometimes in solutions to the problems that we are discussing
here) where applications do choose both the destination and sourece
address, but they are not common.



Margaret -

From a system perspective, you are certainly right:  Applications
typically do get help from the operating system in selecting their
addresses.  From an OSI layering perspective, though, address  
selection

still is performed at application layer.  In fact, if an application
wants to do a complete job, especially a peer-to-peer application, it
needs to select both source and destination address itself, possibly
after running STUN, TURN, or ICE.

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 part or all of address selection.

Whether we take this to mean that both issues should be tackled in the
same working group is a different story.  I personally don't see the
orthogonality of the two issues as a reason not to tackle both  
issues in

the same working group.  We just ought to be aware that the issues are
separate, and the charter should describe them as such.  This said,
there might be work-load- or work-scope-specific reasons that suggest
splitting the work into separate working groups, like those brought up
by Lars, Sam, and Scott.  Those arguments should be discussed as well.

- Christian



___
mif mailing list
m...@ietf.org
https://www.ietf.org/mailman/listinfo/mif


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf