Subject: [SAVA] new bof proposal, take one

From: jari.arkko at piuha.net (Jari Arkko)
Date: Mon, 22 Oct 2007 17:40:57 +0200

IETF BOF Proposal: Source Address Validation Improvements (SAVI)
 
Co-chairs
Paul Ferguson <paul_ferguson at trendmicro.com>
 
Internet Area Directors:
Jari Arkko <jari.arkko at piuha.net>
Mark Townsley <townsley at cisco.com>
 
Technical Advisors:
Fred Baker <fred at cisco.com>
Jianping Wu <jianping at cernet.edu.cn>
 
Mailing Lists:
General Discussion: sava at nrc.tsinghua.edu.cn
To Subscribe: http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava
Mailing List Archive: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/
Document Repository: http://narl.tsinghua.edu.cn/sava
 
The Current situation in IPv4 and IPv6 is that the source IP address is
not  
checked in most cases. The purpose of the proposed "Source Address  
Validation Improvements " working group is to standardise mechanisms to
prevent source
address spoofing in the access network. Sepecifically:
 
1. Ensure that a host only uses IP source addresses that are assigned to
it.
2. Support IPv4 and IPv6 with mechanisms as similar as possible.
3. Support multiple IPv4/IPv6 address assignment types.
 
The source address validation points may include:
 
1. At the first hop in a local area network (where can see the port and  
MAC address information)
2. On an upstream exit router.
3. Or on a remote host.
 
There are many cases in enterprise networks and residential broadband  
networks, all requiring their own solutions:
1 Ethernet/IEEE 802.3.
2 Wireless: 802.11/16.
3 DSL.
4 Cable Modem, etc.
 
With this in mind, the goals of the WG are to complete the following
work items:
1 Document the problem statement and submit it to the IESG as an
Informational  
Standard.
2 Survey all existing methods and evaluate compliance to the framework
model,  
then submit architectural framework document to the IESG.
3 For exisiting solutions, document or encourage vendor to document as RFC.
4 Identify any remaining gaps and devise solutions, then submit them to
the IESG.
 
Milestones:
Dec 07 Plan to hold BoF in IETF 70, asking for this Charter to be approved
Jan 08 Plan to get Final version of Charter approved and WG created.
March 08 Plan to submit WG Draft 00 on Problem Statement and
Architectural Framework for SAVI
July 08 Plan to submit WG draft 00 SAVI solutions
Dec 08 Plan to submit final Drafts of Problem Statement and Framework to
IESG
March 09 Plan to submit final Drafts of SAVI solutions to IESG

---

From: bgreene at cisco.com (Barry Greene (bgreene))
Date: Mon, 22 Oct 2007 08:53:37 -0700

Restating - again and again.

The problem with deployment of source address policing in networks is
NOT Standardization! It is economics!

This proposal is ignoring operational input from the networks who
have to deploy, operate and maintain the "framework."

> -----Original Message-----
> From: sava-bounces at mail.nrc.tsinghua.edu.cn 
> [mailto:sava-bounces at mail.nrc.tsinghua.edu.cn] On Behalf Of Jari
> Arkko Sent: Monday, October 22, 2007 8:41 AM
> To: SAVA Mailing List
> Subject: [SAVA] new bof proposal, take one
> 
> General Discussion: sava at nrc.tsinghua.edu.cn To Subscribe: 
> http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava
> Mailing List Archive:
> http://mail.nrc.tsinghua.edu.cn/pipermail/sava/ Document
> Repository: http://narl.tsinghua.edu.cn/sava
>  
> The Current situation in IPv4 and IPv6 is that the source IP 
> address is not checked in most cases. The purpose of the 
> proposed "Source Address Validation Improvements " working 
> group is to standardise mechanisms to prevent source address 
> spoofing in the access network. Sepecifically:
>  
> 1. Ensure that a host only uses IP source addresses that are 
> assigned to it.
> 1. At the first hop in a local area network (where can see 
> the port and MAC address information) 2. On an upstream exit
> router. 3. Or on a remote host.
>  
> There are many cases in enterprise networks and residential 
> broadband networks, all requiring their own solutions:
> 1 Ethernet/IEEE 802.3.
> 2 Wireless: 802.11/16.
> 3 DSL.
> 4 Cable Modem, etc.
>  
> With this in mind, the goals of the WG are to complete the 
> following work items:
> 1 Document the problem statement and submit it to the IESG as 
> an Informational Standard.
> 2 Survey all existing methods and evaluate compliance to the 
> framework model, then submit architectural framework document 
> to the IESG.
> 4 Identify any remaining gaps and devise solutions, then 
> submit them to the IESG.
>  
> Milestones:
> Dec 07 Plan to hold BoF in IETF 70, asking for this Charter 
> to be approved Jan 08 Plan to get Final version of Charter 
> approved and WG created.
> Architectural Framework for SAVI July 08 Plan to submit WG 
> draft 00 SAVI solutions Dec 08 Plan to submit final Drafts of 
> Problem Statement and Framework to IESG March 09 Plan to 
> submit final Drafts of SAVI solutions to IESG
>  
>  
> 
> 
> _______________________________________________
> SAVA mailing list
> SAVA at mail.nrc.tsinghua.edu.cn
> http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava

---

From: marc.blanchet at viagenie.ca (Marc Blanchet)
Date: Mon, 22 Oct 2007 11:55:22 -0400

- should it have a specific reference to MobileIP support, since the  
use of MIP may have an impact on this work?
- s/Sepecifically/Specifically/
- s/of the proposed "Source Address Validation Improvements" working  
group/of the working group/

Marc.

Le 07-10-22 ? 11:40, Jari Arkko a ?crit :

> address is
> assigned to

-----
IPv6 book: Migrating to IPv6, Wiley, 2006, http://www.ipv6book.ca

---

From: miw at juniper.net (Mark Williams)
Date: Mon, 22 Oct 2007 23:57:52 +0800

So you are saying.....

1. it is a good thing to have source policing....

2. it is a bad thing to have a recommended way in which to do it

??

cheers,

Mark

Barry Greene (bgreene) wrote:
>  
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.1
>
> iQA/AwUBRxzHgb/UEA/xivvmEQKL9gCgrAgHCnmVu+GxneZEcBWFdL2u+yMAn0Vk
> PXJo5XfDtQqGXHjHYAihaNWr
> =C+gr
> -----END PGP SIGNATURE-----
>

-- 
"Product roadmap and/or product discussion in this email set forth
Juniper Networks' current intention and is subject to change at any
time without notice.  No purchases are contingent upon Juniper
Networks delivering any feature or functionality expressed or implied
in this roadmap or product discussion."
-----------------------------------------------------------------
Mark Williams                        Juniper Networks
Liaison                              Beijing Office
Academic Networking Sector           Tel: +86 10 6528 8800 x16032
Asia Pacific                         FAX: +61 7 3251 0155
miw at juniper.net                      Cell: +86 1370-111-4749

---

From: bgreene at cisco.com (Barry Greene (bgreene))
Date: Mon, 22 Oct 2007 09:02:29 -0700

> 1. it is a good thing to have source policing....

That funny. I guess you don't know me or know the work I've been
doing to get source address spoofing technologies built (uRPF, IP
Source Verify, DHCP Lease Query, etc.) and deployed. The deployment
in really big SPs across the planet is important.
 
> 2. it is a bad thing to have a recommended way in which to do it

This is not needed. We have those documents now. If you want to work
on a document, help finish the RIPE document.

> > This proposal is ignoring operational input from the 
> networks who have 
> > to deploy, operate and maintain the "framework."
> >
> >  
> >
> >   
> >> The Current situation in IPv4 and IPv6 is that the source 
> IP address 
> >> is not checked in most cases. The purpose of the proposed "Source 
> >> Address Validation Improvements " working group is to standardise 
> >> mechanisms to prevent source address spoofing in the 
> access network. 
> >> Sepecifically:
> >>  
> >> 1. Ensure that a host only uses IP source addresses that 
> are assigned 
> >> to it.
> the port 
> >> and MAC address information) 2. On an upstream exit 
> router. 3. Or on 
> >> a remote host.
> >>  
> following 
> >> Informational Standard.
> >> framework model, then submit architectural framework 
> document to the 
> >> IESG.
> >> 3 For exisiting solutions, document or encourage vendor to 
> document 
> >> as RFC.
> submit them 
> >> Dec 07 Plan to hold BoF in IETF 70, asking for this Charter to be 
> >> approved Jan 08 Plan to get Final version of Charter 
> approved and WG 
> >> created.
> draft 00 
> >> SAVI solutions Dec 08 Plan to submit final Drafts of Problem 
> >> Statement and Framework to IESG March 09 Plan to submit 
> final Drafts 
> >> of SAVI solutions to IESG
> >>  
> >>  
> >>
> >>
> "Product roadmap and/or product discussion in this email set 
> forth Juniper Networks' current intention and is subject to 
> change at any time without notice.  No purchases are 
> contingent upon Juniper Networks delivering any feature or 
> functionality expressed or implied in this roadmap or product 
> discussion."

---

From: junbi at cernet.edu.cn (Jun Bi)
Date: Tue, 23 Oct 2007 01:27:21 +0800

Hi Barry,

I should say, this SAVI WG isn't going to ignore anything.
Please see the goals:
"3 For existing solutions, document or encourage vendor to document as RFC."

So please join this WG and contribute your work to IETF.
During the "interim meeting" held in Finland, I belive Fred introduced some of the cisco work. 
You may give the WG more inputs. 

BTW, you may already found that the WG goal is rescoped to the access network.

thanks,
Jun Bi
.

----- Original Message ----- 
From: "Barry Greene (bgreene)" <bgreene at cisco.com>
To: <miw at juniper.net>
Cc: "SAVA Mailing List" <sava at nrc.tsinghua.edu.cn>
Sent: Tuesday, October 23, 2007 12:02 AM
Subject: Re: [SAVA] new bof proposal, take one

> iQA/AwUBRxzJlb/UEA/xivvmEQLSMgCfd7cym9khjUvXjASvqJEmXx2creoAn0K3
> GXjDdx6B+SMyV5FJIXGm4DGL
> =L/ya

---

From: bgreene at cisco.com (Barry Greene (bgreene))
Date: Mon, 22 Oct 2007 10:40:06 -0700

You can have a multitude of "technology," "solutions," and
"standards" to achieve BCP38. But, if you do not take the factors of
how you deploy, maintain, and manage cost, none of these "tools" will
ever get deployed through out the Internet.

I'm glad SAVA is waking up to the fact that there are other
technologies. Now how about waking up to the fact that there have
been people working to get deployment for close to a decade. That
"deployment experience" needs to be pulled into any new IETF work. If
not, then there is no need for a new WG. We already have BCP 38.

> From: Jun Bi [mailto:junbi at cernet.edu.cn] 
> Sent: Monday, October 22, 2007 10:27 AM
> To: Barry Greene (bgreene); miw at juniper.net
> Cc: SAVA Mailing List

---

From: fred at cisco.com (Fred Baker)
Date: Mon, 22 Oct 2007 11:59:14 -0700

> have to deploy, operate and maintain the "framework."

Remind me. I thought it was brought to us by a network that wanted to  
deploy, operate, and maintain the framework?

---

From: christian.vogt at nomadiclab.com (Christian Vogt)
Date: Tue, 23 Oct 2007 00:01:54 +0300

Marc:

> - should it have a specific reference to MobileIP
> support, since the use of MIP may have an impact on this
> work?

It would be worthwhile to depend this on the extent of 
deployment of Mobile IP*v4* without support for reverse 
tunneling because IP source addresses may be topologically 
incorrect only in case of this Mobile IP variant.

If deployment of Mobile IPv4 without reverse tunneling is
negligible, we may not need to handle Mobile IP separately 
in this working group.

- Christian

---

From: junbi at cernet.edu.cn (Jun Bi)
Date: Tue, 23 Oct 2007 13:28:54 +0800

I believe the incentive mechnism for deployment is also within the scope of the proposed WG.
I also believe any deployment experience form opereators or vendors are valuable inputs for this WG.

thanks,
Jun Bi

---

From: junbi at cernet.edu.cn (Jun Bi)
Date: Tue, 23 Oct 2007 13:37:23 +0800

I think, as one of the network operators, CERNET is willing to deploy some cost-effective solutions 
so that the administrators and users can be away from the source address spoofing problem.

thanks,
Jun Bi

---

From: pekkas at netcore.fi (Pekka Savola)
Date: Tue, 23 Oct 2007 12:18:21 +0300 (EEST)

On Mon, 22 Oct 2007, Jari Arkko wrote:
> The Current situation in IPv4 and IPv6 is that the source IP address 
> mechanisms to prevent source address spoofing in the access network.

The first sentence seems somewhat loose, and the charter does not 
emphasize strongly enough its focus on host-specific checking.

Maybe reword:

While the MIT Spoofer project has measured that about 75% of networks 
deploy ingress filtering, ingress filtering at a finer granularity is 
not yet as common.  A number of proprietary mechanisms exist (e.g., 
"IP source guard") which offer partial solutions to prevent hosts from 
spoofing the source address of another host in the same subnet.  The 
purpose of the proposed "Source Address Validation Improvements" 
working group is to standardise mechanisms to prevent source address 
spoofing in the access network.

> 1. At the first hop in a local area network (where can see the port and

"hop" is not a good word here, as we're not talking about the _IP_ 
hop.  Maybe:

1. At the first network device in a local area network (e.g., Ethernet
    switch, where you can see the port and MAC address information)

[[ note: the term 'local area network' is somewhat ethernet-centric 
and a better more generic word would be better..]]

> 2. On an upstream exit router.

Too ambiguous: in the context of SAVI, you're referring to the 
first-hop router, right, not e.g., site's exit router?  Maybe:

2. On the local area network's first-hop exit router(s).

> 3. Or on a remote host.

Misleading: in the context of SAVI, we're talking about the host in 
the same subnet.  Remote host verification is out of scope.  Maybe:

3. Or on another host in the same local area network.

> 1 Document the problem statement and submit it to the IESG as an

s/Standard/RFC/

> then submit architectural framework document to the IESG.

"evaluate compliance to the framework model, ... submit architectural 
framework document".  I'm not sure what this is supposed to mean.

Which category would this document be?

I guess you'd first write up the "framework model", look how existing 
mechanisms fit in there, revise as needed, and then submit the 
document to the IESG.

Maybe the formulation of this could be more straightforward.

Is this even needed?  I suspect the problem statement draft needs to 
discuss existing approaches to some degree and maybe the framework 
would not be needed after all.

> 3 For exisiting solutions, document or encourage vendor to document as RFC.

Informational RFC?  Through RFC-editor's process or through this WG?

> 4 Identify any remaining gaps and devise solutions, then submit them to

This seems to imply that the work items of the WG are not well thought 
out.  If the WG would need to produce (or help significantly in others 
doing so) problem statement/framework/existing solutions, do we wait 
until that work is complete before starting something new?

My suggestion would be that the WG would recharter after the first 
steps, i.e., when it thinks it knows what kind of protocol it needs to 
develop (if any).  Getting a couple of general documents out and 
helping in vendors documenting, or documenting in the WG, existing 
solutions probably already takes 1-2 years (even with optimistic 
estimiates).

> March 09 Plan to submit final Drafts of SAVI solutions to IESG

"draft 00 SAVI solutions" -- is that one document?  March 09 DL seems 
to imply multiple drafts.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: miw at juniper.net (Mark Williams)
Date: Tue, 23 Oct 2007 23:44:48 +0800

I've incorporated most of these suggestions and a couple of others into 
the document attached. I didn't do anything about the three points 
below, not because I necessarily disagree but because they are probably 
worth more discussion.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: savi-ietf70-BoF proposal.txt
Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20071023/a82f2eed/attachment-0001.txt

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Tue, 23 Oct 2007 13:16:18 -0400

Jari, thanks for this proposal.

This proposed charter is clear enough that I can think about it and
come to a crisp opinion on whether I think the work should proceed.
That has not been true in the past.

To that end, I don't think the problem stated in this charter
justifies creation of a working group.

The charter makes it clear that we're not even sure that there are
gaps in this area requiring standardization within the IETF.  The
charter also hints that the problem space is likely to be very layer-2
specific.

I do not think the criteria of RFC 2418 for forming a working group
have been met.  I don't think a second BOF will help.  A study group
is inappropriate because there has not been demonstrated IETF
consensus that the problem area is one we'd like to work on.  So, I
think we should say no.

I appreciate your efforts in getting to a point where it's clear
enough what we're discussing.

---

From: junbi at cernet.edu.cn (Jun Bi)
Date: Wed, 24 Oct 2007 11:42:07 +0800

Hi Sam, 

I am not quit catch your point. 
Do you mean, the new SAVI WG should include the work rather than the access network ?
Let me try to give some explanation.

First, because the problem to fix in the whole Internet is too complicated, so during the parts 
months, most participants suggested that the WG should resolve the problem in the access network as the first step. 
The access network is an administration level that is feasible to be deployed with doable solutions, which are based on 
the improvement of existing (but may no be fully  IETF standardized ) technologies. 
The remaining problem in the Internet will  be resolved later. Actually, the "interim meeting" did discuss the inter-/intra-AS 
problem and ideas, please refer to documents on the meeting website. 

Second, it's not the layer2-only stuff. At the access network level, we have difference validation points (e.g. switch, exit router), 
so we need difference src addr validation solutions for different validation points. I guess only the first validation point is 
layer-2 related (because at other validation point, the Layer-2 information carried in the packet/frame is lost). 
So that will be within the scope of IETF.

Thanks,
Jun Bi

---

From: jari.arkko at piuha.net (Jari Arkko)
Date: Wed, 24 Oct 2007 10:59:55 +0200

I tend to agree with the comments made so far. Version one was way too
vague about the scope of the proposed work, and some of that still
remains in version two.

But we need everyone to wipe their minds about the earlier SAVA
proposals. What we have now on the table is completely different, and
very focused.

For background, the SAVA effort started a year ago from a very ambitious
plan that involved improvements in being able to validate decisions made
networks on the other side of the planet. For various reasons the IETF
community has not found this approach worthwhile to pursue. The primary
reason in my mind is that the required changes in the routers and
supporting infrastructure would be extremely costly for what appears to
be an improvement of debatable value. However, this does not necessarily
imply that there is no work in this space. Indeed, when talking about
the topic we found vendors and users doing simple things to provide
better support against address spoofing in their local networks.

With this in mind, we met in Helsinki a couple of weeks ago to do a
reset and see if there was something concrete that we could do. My
conclusion from those discussions was that there's plenty of research
topics in this space that should stay as such. But at the same time,
there were also concrete items relating to checking for address spoofing
in a local network that would seem to benefit from standardization.

One of these items was what Cisco and other vendors do for IPv4 address
spoofing checks in a switch; the question is whether an IETF
specification of such behavior would be useful. I think so, because an
IETF document of an existing practice can make it more attractive to a
wider range of users and vendors. Another item was the same feature in
IPv6. This is currently not implemented, and is technically more
challenging than the IPv4 version. However, it appeared to be a feasible
task for IETF work. And I believe doing this would be useful, because if
left to individual programmers, we probably have many different versions
of it, some not completely functional in all circumstances.

Relating to Sam's comment: yes, this is a link layer dependent effort.
But making IP run over link layers is within IETF's scope, and I believe
we are better equipped than the link layer organizations to think about
what IP layer messages need to be tracked to achieve the desired
functionality.

I personally believe these two tasks would justify a focused WG.
However, one of the gating items is whether the proponents of the WG are
capable of delivering an early draft of the IPv6 specification. As of
today, I still do not have this draft. Fred, Pekka: please submit the
IPv4 version that you already have, and see if you can come up with the
early version for IPv6 -- preferably today! (We need to take decisions
tomorrow.)

Please find a third revision of the charter proposal below:

Source Address Validation Improvements (SAVI)

Co-chairs
TBD

Internet Area Directors:

Internet Area Advisor:

Mailing Lists:

While the MIT Spoofer project has measured that about 75% of networks
deploy ingress filtering, ingress filtering at a finer granularity is
not yet as common.  A number of proprietary mechanisms exist (e.g., "IP
source guard") which offer partial solutions to prevent hosts from
spoofing the source address of another host in the same subnet.  The
purpose of the proposed "Source Address Validation Improvements" working
group is to standardize mechanisms to prevent source address spoofing in
the access network.

Specifically, the group shall define solutions such that hosts attached
to the same router cannot spoof each other's addresses. The following
assumptions apply:

- The WG considers only solutions on layer 3 aware Ethernet switches.
- Two solutions are needed, one for IPv4 and another one for IPv6
- The IPv4 solution depends on tracking the DHCP traffic on a port.
- The IPv6 solution depends on tracking the ND and DHCP traffic on a port.
- All address assignment mechanisms in IPv6 need to be supported,
including stateless, stateful, privacy, and so on.
- The solutions are turned on for on host ports by configuration, and do
not apply to routers.

The WG recognizes anti-spoofing deployment efforts, motivation, and best
practices development in various forums around the world (including
RIPE). The WG is only chartered to deliver two specific solution
components that such efforts could employ. The bigger questions are out
of scope.

Milestones:

Done      First draft on IPv4 solution
Oct 07    First draft on IPv6 solution
Oct 07    BOF decision
Dec 07   BOF in IETF-70
Jan 08    WG approval
Feb 08    First WG draft on IPv4 solution
Apr 08    First WG draft on IPv6 solution
Jun 08    Submit IPv4 solution to IESG for Proposed Standard
Dec 08   Submit IPv6 solution to IESG for Proposed Standard

---

From: miw at juniper.net (Mark Williams)
Date: Wed, 24 Oct 2007 22:51:33 +0800

Let me give a perspective on SAVI based on a previous life. Note here 
that I am talking specifically about SAVI and not SAVA. SAVA is 
basically two problems: (1.) How do I establish the validity of a 
packet's source address, and (2.) Once it is established, how do I 
preserve the knowledge of its validity as the packet traverses the 
Internet. SAVI only addresses problem (1). It's not the full story, but 
it is a precondition for really solving (2), and it is useful in itself 
as I will discuss.

Before I ran off and joined the circus I was the engineer in charge of 
design, operation and procurement of a campus network with about 7,000 
Ethernet ports which was quite big in those days in Australia. One of 
the issues I had was that I had no bulletproof way of ascribing activity 
to an individual. I could take dumps of activity using TCPDump, but 
since IP addresses and of course MAC addresses were easily spoofable 
within a broadcast domain, about the only way to collar people was to 
catch them when they used dialup (because our dialup servers, unlike 
Ethernet were *not* spoofable) or hope that they used the campus email 
servers. Note that we didn't have the time or the interest to chase 
minor stuff like copyright offendors. In those distant days the RIAA had 
not yet bought our legislators. In order to get us to go to the expense 
and trouble of building a case against someone, it had to be a case of 
racketeering, drug dealing, child pornography or major hacking, which 
are more common on campuses than one would like to think. I guess if you 
have a community in excess of 30,000 people some of them wil not be nice 
people.

So IP address spoofing in the campus was definitely a problem then. Is 
it still a problem? in fact, yesterday I was talking to an engineer for 
an NREN backbone and his opinion was that most campus networks in his 
country were still spoofable. I asked why people didn't specify 
infrastructure that had something that could enforce anti-spoofing. He 
said it was because there are no standards. If there are no standards, 
you can't specify in a public tender process. "If I specify IP source 
Guard, then everyone other than Cisco will sue us". In other words, in 
the many parts of the world where public tender processes are important 
in procurement, they need an RFC or at least a generally accepted de 
facto standard in order to be able to buy the appropriate kit.

I would respectfully submit:

1) Source IP address spoofing *is* a problem, and the ease with which 
Source IP addresses can be spoofed in many places is a fundamental flaw 
in the way the Internet is built today. It cases problems in the 
assignment of responsibility for evil/illegal acts and it also 
represents a threat to the Internet's infrastructure.
 
     Packets with Spoofed Source Addresses are Undeniably unwanted.

2) IP source address spoofing in the access network is a problem for 
which there are solutions. Some of them have been implemented. There 
needs to be at least one openly specified set of mechanisms so that 
there is a good way for people to specify and procure compliant equipment.

3) Vendors will implement what comes out of the process. (in fact, some 
already have implemented proprietary solutions, simply because of 
customer demand.)

4) There is a community of people within the IETF who want to work on 
this, and they are drawn from a mix of vendors, backbone operators and 
campus network operators.

5) Since this is specific to IP networking (yes, each mechanism may be 
link-layer specific, but the problem is that of validating an IP 
address, not a link-layer address), the IETF is the right place for this 
work to be done. The only other candidate might be the IEEE, but I feel 
they are not the right choice. Someone suggested a European Internet 
Registry as the right place to specify a global standard. I certainly 
differ on that score.

Each of these points is open to debate, which is obviously welcome, but 
I'd suggest if they stand, then the WG charter and goals satisfies 
section 2.1 of  RFC2418

cheers,

Mark

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Wed, 24 Oct 2007 11:31:33 -0400

>>>>> "Jun" == Jun Bi <junbi at cernet.edu.cn> writes:

    Jun> Hi Sam, I am not quit catch your point.  Do you mean, the new
    Jun> SAVI WG should include the work rather than the access

No, I mean the WG should not exist.

---

From: junbi at cernet.edu.cn (Jun Bi)
Date: Thu, 25 Oct 2007 11:09:20 +0800

Now, some peoeple discussed your questions and I found the bof proposal is also improved according to suggestions posted on the mailing-list.
So do you feel the new charter is better ?

Begards,
Jun

---

From: Hannes.Tschofenig at gmx.net (Hannes Tschofenig)
Date: Sun, 28 Oct 2007 10:40:05 +0100

I promised to send the pictures from the Helsinki SAVA meeting around.
Here they are:
http://www.tschofenig.com/private/SAVA_Oct2007/

Ciao
Hannes