Internet DRAFT - draft-clausen-autoconf-criteria
draft-clausen-autoconf-criteria
MANET Autoconfiguration (AUTOCONF) T. Clausen
Internet-Draft J. Garnier
Expires: January 12, 2006 LIX, Ecole Polytechnique, France
S. Singh
Samsung AIT, South Korea
Chris. Christopher
Baesystems, UK
July 11, 2005
Evaluation Criteria for MANET Autoconf Mechanisms
draft-clausen-autoconf-criteria-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document gives a general set of objective criteria to evaluate
an autoconfiguration mechanism in a MANET environment. All criteria
are important to outline an evaluation of an autoconfiguration
mechanism. These criteria have been grouped into three classes:
Clausen, et al. Expires January 12, 2006 [Page 1]
Internet-Draft AUTOCONFCRITERIA July 2005
functional criteria, performance criteria and usability criteria.
For each of the criteria, a description is outlined, hints are given
on how to perform an adequate measure of the criterium, and an
evaluation features the importance of the criterium in the full
evaluation of a mechanism.
Clausen, et al. Expires January 12, 2006 [Page 2]
Internet-Draft AUTOCONFCRITERIA July 2005
1. Introduction
This document gives a general set of objective criteria to evaluate
an autoconfiguration mechanism in a MANET environment. All criteria
are important to outline an evaluation of an autoconfiguration
mechanism. These criteria have been grouped into three classes:
functional criteria, performance criteria and usability criteria.
For each of the criteria, a description is outlined, hints are given
on how to perform an adequate measure of the criterium, and an
evaluation features the importance of the criterium in the full
evaluation of a mechanism.
Clausen, et al. Expires January 12, 2006 [Page 3]
Internet-Draft AUTOCONFCRITERIA July 2005
2. Functional Criteria
This section describes functionalities that a mechanism must aim at
featuring. Besides Duplicate Address Avoidance, DAA, an autoconfiguration
mechanism implements at least one of these functionalities. These
address issues result from the MANET environment in addition to usual
issues of autoconfiguration. The more functionalities a system
implements, the better it should be evaluated provided that these
functionalities are correctly designed and that overall network
performance does not suffer from this variety.
2.1 Duplicate Address Avoidance
2.1.1 Presentation
This functionality is mandatory in an autoconfiguration mechanism.
It consists of making all functionalities assign addresses only after
checking their uniqueness. This principle must be the core of any
design of an autoconfiguration mechanism. It is consequently crucial
to test the efficiency of these functionalities from this point of
view. A mechanism often assigning duplicate addresses should be
disregarded quickly, for instance.
2.1.2 Measurement
Experimental evaluation could consist in counting misassignments,
i.e. assignments of already used addresses. Weak DAD is the result
of the application of this principle to all mechanisms involving
address assignments. Simple scenarios testing the functionalities of
a mechanism are sufficient to assess these misassignments.
2.1.3 Evaluation
This functionality is the only mandatory functionality in an
autoconfiguration mechanism, as it reflects the assumption of
uniqueness upon which the routing protocol is based.
2.2 Duplicate Address Detection
2.2.1 Presentation
Duplicate Address Detection, DAD consists in mechanisms aiming to detect
address collisions and solve them through address reassignment.
Draconian ways of doing so involve reconfiguration of all the
conflicting interfaces whereas more subtle mechanisms keep one
interface up and reconfigure the others. Evaluation should prefer
the latter way, since it allows more preservation of ongoing
connections. Such DAD mechanisms are in fact ways of enforcing the
Clausen, et al. Expires January 12, 2006 [Page 4]
Internet-Draft AUTOCONFCRITERIA July 2005
principle of uniqueness of address for each interface, if failures
happen, and should be evaluated the same way. Strong DAD may be an
idealization of such a mechanism.
2.2.2 Measurement
Simulations and experiments can easily be staged showing duplicate
addresses. Mechanisms can be tested and evaluated according to their
ability to handle such scenarios.
2.2.3 Evaluation
Duplicate address detection allows the adaptative approach to strong
DAD, i.e. a flexible way of controlling address uniqueness.
Therefore, it is a very important criterium.
2.3 Address Assignment for Incomming Nodes
2.3.1 Presentation
A mechanism in charge of assigning an address to an incoming node in
a network is a base for almost all other more complex
functionalities. It is also the first functionality expected from an
autoconfiguration mechanism.
2.3.2 Measurement
Simulations and experiments can be put up to test this functionality.
Simple simulations or experiments with an already configured network
and incoming nodes are sufficient. The number of incoming nodes,
their location and the frequency of appearance can vary to thoroughly
test the mechanism.
2.3.3 Evaluation
This criterium is about a functionality that is a basis to more
complex mechanisms. It is therefore central and must be evaluated in
depth. The widespread use of address assignment mechanism, the DHCP
protocol, shows the need for such a functionality.
Absent an address assignment mechanism, other functionalities
involving reconfiguration of nodes cannot properly be performed
without a mechanism to reconfigure the node. Duplicate address
detection cannot result in solutions to collisions.
Clausen, et al. Expires January 12, 2006 [Page 5]
Internet-Draft AUTOCONFCRITERIA July 2005
2.4 Full network configuration from scratch
2.4.1 Presentation
This functionality, also called bootstrap capability, is the ability
of unconfigured nodes to form a whole functional network, without any
user intervention.
2.4.2 Measurement
Simulations and experiments can be put up to test this
functionality, using adequate scenarios, i.e. sets of scattered
unconfigured nodes with various topology will be sufficient to test
this functionality.
2.4.3 Evaluation
This functionality is one among the several final goals of the design
of an autoconfiguration mechanism. A particular attention must be
paid to the prerequisites such a mechanism.
2.5 Network merger treatment
2.5.1 Presentation
This functionality consists in uniting or reuniting more than one
independent network in a way that preserves address uniqueness. The
most important here is to specify the situations in which it is
applicable. This can be done using a negotiation between the several
networks or a direct merger followed by an address collision
detection to eliminate the duplicate addresses.
2.5.2 Measurement
Simulations and experiments can be put up to easily test this
functionality, using scenarios showing two or more network of various
relative importance. This notion of relative importance, which is
basically the relative difference of size between the protagonists is
a significant parameter. For instance, the situation of two networks
of the same size showing as many conflicts as their number of nodes
is likely to be more difficult to handle than the case when one is
much bigger than the other. The structure of the network can indeed
be highly perturbed during the response to the merger.
Clausen, et al. Expires January 12, 2006 [Page 6]
Internet-Draft AUTOCONFCRITERIA July 2005
2.5.3 Evaluation
This functionality is complex because it involves the resolution of a
large possible number of concurrent address collisions. A MANET
lacking this functionality has a restrained mobility as this MANET
cannot handle any encounter with a similar network.
2.6 Network partitioning treatment
2.6.1 Presentation
An autoconfiguration mechanism implementing treatment of network
mergers should be able to handle network partitioning as what causes
difficulties in these situations is the merger after the
partitioning. However, if the merger mechanism involves
reconfiguring all the nodes of one of the 2 networks, this can be a
source of inefficiency especially in the case of partitioning due to
a lack of information diffusion.
2.6.2 Measurement
Simulations and experiments can here again be put up to easily test
this functionality, using adequate scenarios from the point of view
of the mobility of nodes. Groups of variable relative size must be
staged with motions leading to a splitting, followed by a merger. To
test the functionality properly, additional nodes must have been
added between the partitioning and the merger to simulate what the
issue really consists in.
2.6.3 Evaluation
Even though this functionality seems to highly depend on the
treatment of network mergers, it can be a separate problem in
mechanisms where networks can be discriminated. A MANET that cannot
handle partitionings does not profit from the mobility of the nodes
that constitute it.
2.7 Service Discovery
2.7.1 Presentation
Service discovery is not always mentioned in the required
functionalities of an autoconfiguration system. However,
autoconfiguration rmechanisms should advertise the required
information within the network. Furthermore, as forming a network
is about sharing resources, integrated systems can profit from more
general advertisement of such services.
Clausen, et al. Expires January 12, 2006 [Page 7]
Internet-Draft AUTOCONFCRITERIA July 2005
2.7.2 Measurement
Simulations and experiments to test this functionality must show the
behaviour of the mechanism with one or several service providers, of
one or different nature. A theoretical evaluation must also take
into account the ability to append additional information to the
advertisement service, including description or other parameters for
instance.
2.7.3 Evaluation
This criterium is not often mentioned as a important functionality.
As a secondary criterium, it can be left aside. However a treatment
of this problem indicates a complete mechanism.
Clausen, et al. Expires January 12, 2006 [Page 8]
Internet-Draft AUTOCONFCRITERIA July 2005
3. Performance Criteria
All MANET environments share a set of characteristics that are
specific to this sort of networks. A MANET autoconfiguration
mechanism must take these characteristics into account to achieve
properly their task. In this section are outlined criteria to
evaluate the compliance of autoconfiguration mechanisms to the
limitation of MANETs.
3.1 Nodes with Limited Ressources
3.1.1 Presentation
A mobile node in a MANET environment has finite resources. Power can
be limited by battery capacities, computation capabilities can be low
and memory can be scarce. Therefore, a mechanism should be highly
optimized to ensure it can be functional without using huge storage
structures and without the need of large amounts of computations.
3.1.2 Measurement
To evaluate this, one could measure the additional memory used by the
autoconfiguration mechanism and compare it with the memory used by
the single routing protocol at the same time. The same comparison
should be made as regards the computation time. Battery consumption
can be derived from the combination of these measures with the
lifetime of the node. Simulators such as NS2 can also give a direct
access to the power consumption.
3.1.3 Evaluation
This criterium is essential in MANET since one of the main assumption
as regards MANETs is the mobility, that implies compact nodes and the
use of batteries as power supply. A mechanism that would not take
such limitations into account is likely not to be adaptable to real
mobile networks.
3.2 Medium Overhead
3.2.1 Presentation
The medium on which the nodes can exchange packets suffers from
several limitations. As the nodes can only emit within a finite
range, the medium cannot be considered as unique. Any node A can be
within range from any other two nodes B and C that cannot listen to each
other. If both nodes decide to send a message at the same time, A can not
receive any of them. Such situations are called collisions. They
are very likely to occur in saturated networks with many nodes and
Clausen, et al. Expires January 12, 2006 [Page 9]
Internet-Draft AUTOCONFCRITERIA July 2005
many control messages to transmit, or in very dynamic networks, which
are networks with a quickly changing topology which must be
continually updated. The ideal bandwidth is already limitted without
such effects.
Two types of overhead must be studied:
Local overhead is the load of messages that are not forwarded but
occupy the medium around an active node during a local negociation
for instance. If the traffic is disturbed in the neighbourhood of a
point where something related to autoconfiguration is happening, it
can result in global problems, if the control messages intended to go
through this zone are not relayed, neither in the zone nor further.
Global overhead is the overhead induced by flooding procedures. As
flooding operation result in much traffic throughout the network,
such procedures should be avoided as much as possible.
3.2.2 Measurement
The overhead induced by the autoconfiguration must be studied both
theoretically through the count of the messages that must be sent in
any situation, and experimentally. Simulators give an immediate
access to the packets that were exchanged. The count is therefore
possible in simulations.
3.2.3 Evaluation
This criterium also reflects a key assumption and can be applied to
even more situations than the previous one. In fact, it is often
considered that the limitation of the medium is drastically more
constraining than the limitation of the abilities of the nodes.
Saturating the medium often leads to a collapse of the network as
information cannot be exchanged any more.
3.3 Tolerance to information losses
3.3.1 Presentation
Proactive protocols are based on knowledge of full and up-to-date
topological description of the network by each node. As pointed out
in the previous subsection, information diffusion is not guarantied.
On the contrary, information incompleteness should be considered as a
possibility.
Therefore, any autoconfiguration mechanism should provide lightweight
though efficient backup systems to solve the problems induced by
information losses.
Clausen, et al. Expires January 12, 2006 [Page 10]
Internet-Draft AUTOCONFCRITERIA July 2005
3.3.2 Measurement
This evaluation is primarily theoretic because the presence of such
systems can be checked at this level. Information lacks must not
make the whole system collapse.
An experimental analysis of this can be performed assigning
probabilities to transmissions so that packet diffusion is randomly
perturbated. The backup mechanisns can also be tested by staging the
situations resulting from such failures.
3.3.3 Evaluation
This criterium must not be neglected as it is based upon an important
characteristics of MANETs. A mechanism not tolerating information
losses would be exposed to many failures during its functioning time.
This must be prevented.
3.4 Convergence Time
3.4.1 Presentation
An address autoconfiguration mechanism aims at performing automatic
management of addresses in a network. The goal is to react as
quickly as possible to any changes and provide a solution to a new
situation. This is intended to ease the access to shared resources
within a MANET.
Here, what is referred to as convergence is the fact that after a
change, there is a period during which the network detects the change
and reacts to it. An event concerning autoconfiguration triggers
possible changes in the configuration of interfaces, information
diffusion. Convergence is achieved when all nodes are informed of
the new status and have adapted their configuration accordingly. A
possibly good indicator can be the amount of additional messages
induced by the event. When the emission of such messages ceases, one
can consider convergence is reached. Convergence time is the time
between the event and convergence. If this time is infinite,
convergence is never reached. In some cases, this could induce
instability or even collapse of the network.
3.4.2 Measurement
More practically, as the evaluated mechanism must adapt the routing
protocol to the changing environment, the responding times of the
autoconfiguration mechanism must be shorter than the characteristic
times for network changes, whatever their nature, for instance
topology changes or incoming new nodes. Measures must take into
Clausen, et al. Expires January 12, 2006 [Page 11]
Internet-Draft AUTOCONFCRITERIA July 2005
account different characteristic times. For instance, the
configuration of a network from scratch matches the lifetime of a
network and the convergence time should be much shorter than the
lifetime. The configuration of a new incoming node can be considered
as an event regarding topology. The time of this process must not
exceed much the time needed by topology information sharing, i.e. a
few control messages.
All needed times must be measured and compared to their expected
value: bootstrap time, address assignment time, merger time and
address conflict resolution time for instance.
3.4.3 Evaluation
This criterium is relevant for all functionalities and is of prime
importance. A system with an infinite or very long convergence time
is at best useless and can even be harmful in some cases.
3.5 Address Space Usage
3.5.1 Presentation
In the stateful case, a network is mostly assigned a specific address
space among which addresses can be picked and assigned to nodes. As
the number of available addresses can be little larger than the number
of possible nodes, it is important that no possible addresses should
be wasted. Wasted addresses are addresses that have not been assigned
and that cannot be assigned to requesting nodes due to the design of
the evaluated mechanism.
From this point of view, two different approaches can be used to assign
addresses to incoming nodes. Address ranges can be assigned to
different consistent parts of the network, each one responsible for
its own address domain. This will be called local responsability.
The other approach is to keep addresses common. Each new node must
upon configuration advertise its choice to the whole network. This
is global responsability. Global responsability implies a good
information exchange. Local responsability requires an additional
system to exchange addresses should an important need be felt in a
part of the network.
3.5.2 Measurement
This criterium must be evaluated mainly theoretically especially in
the case of local responsibility: idle addresses must not be blocked
by some nodes while other nodes lack addresses. It is relevant for
all functionalities and must be evaluated in each of them. It can be
detected in simulations and experiments through an analysis of the
Clausen, et al. Expires January 12, 2006 [Page 12]
Internet-Draft AUTOCONFCRITERIA July 2005
addresses that nodes can get hold on and assign. This is more
difficult an evaluation.
3.5.3 Evaluation
This criterium is important in networks that are assigned a short
range of addresses, as well as in large and dense networks. If too
many addresses are wasted by the autoconfiguration mechanism, such
that all idle and accessible addresses are in use, an incoming node
cannot be granted an address. This invalidates many of the
functionalities.
3.6 Saturation point: multiple concurrent conflicts
3.6.1 Presentation
Usual mechanisms are primarily designed to handle one situation at
once. For instance, the traditional situation for duplicate
addresses is one case at a time with several nodes bearing the same
address. But cases with several concurrent conflict are likely to
occur. Hence the need to assess the performance of the
functionalities of an autoconfiguration mechanism in situations where
several conflicts occur concurrently. A merger of two networks of the
same size with as many collision as the number of nodes in both is a
complex case as it also involves the possible destruction of the
whole structure of the network through reconfiguration for instance.
3.6.2 Measurement
Theoretically, the mechanism must be conceived so that multiple
concurrent problems can be resolved.
Experiments and simulations are good approaches to evaluate this
criterium. Scenarios with several concurrent conflicts can be staged
directly. Saturation point must be determined using the fact that
around this point, either convergence time becomes infinite, or
large, or odd phenomena occur.
3.6.3 Evaluation
This criterium allows a good evaluation of mechanisms. Solving more
complex situations with several conflicts indicates a well designed
mechanism. Moreover, concurrent conflicts are very likely to occur
and must therefore be treated by an autoconfiguration mechanism.
3.7 Saturation point: conflict size
Clausen, et al. Expires January 12, 2006 [Page 13]
Internet-Draft AUTOCONFCRITERIA July 2005
3.7.1 Presentation
The symmetric of the previous criterium is the size of conflicts.
Usual address collisions concern 2 nodes bearing the same address.
However, cases with more colliding nodes can occur. Usual mergers
involve 2 networks. However larger problems can happen with 3 or
more independent networks. Mobility for instance can make more than two
networks reunite at the same time with possibly big conflicts
involving at least as many protagonists as the number of connecting
networks.
Therefore, a serious mechanism must handle larger problems than the
basic 2 protagonist problem.
3.7.2 Measurement
Theoretically, the mechanism must be conceived so that multiple
protagonist problems can be resolved.
Experiments and simulations are a good approach to evaluate this
criterium. Scenarios with large conflicts can be staged directly.
The saturation point must be determined using the fact that around
this point, either convergence time becomes infinite, or large, or
odd phenomena occur.
3.7.3 Evaluation
This criterium allows a very efficient evaluation of mechanisms.
Solving situations with big conflicts indicates a well designed
mechanism. Big conflicts can happen and if a network is blocked in
such a case, this will cause problems.
3.8 Scalability
3.8.1 Presentation
An ideal autoconfiguration mechanism should be applicable to networks
of any size. However, as such a mechanism generates overhead to the
nodes as well as to the medium, scalability limitations should be
evaluated. Information diffusion also suffers from a large size as
the diffusion delay can increase such that information arrives at a
node from distant parts of the network with a long delay. In such
cases, DAA and DAD become uncertain processes if timeout times are
not adapted.
3.8.2 Measurement
The limit of the autoconfiguration mechanism is the number of nodes
Clausen, et al. Expires January 12, 2006 [Page 14]
Internet-Draft AUTOCONFCRITERIA July 2005
beyond which either the network collapses or the mechanism becomes so
slow it is not functional anymore. This limit can be a range of
values according to situations. The higher the limit, the better the
mechanism can be considered. As routing protocols have similar
limits, if the limits of the autoconfiguration mechanism and of the
routing protocol are approximately the same, one can consider the
autoconfiguration mechanism is well designed.
This matter can be decided theoretically mainly through an analysis
of the induced medium overhead. It can be evaluated experimentally
and through simulations. To achieve this, scenarios with various
sizes and various densities must be tested to determine the domain of
correct functioning.
3.8.3 Evaluation
Scalability is one of the most important criteria. A comprehensive
mechanism applicable to ten nodes at most is mostly not preferred.
The domain of correct functioning is a premiere feature of a mechanism.
Clausen, et al. Expires January 12, 2006 [Page 15]
Internet-Draft AUTOCONFCRITERIA July 2005
4. Usability Criteria
Usability criteria aim at characterizing the way the mechanism will
be adapted to its use. This means the adaptability to the whole
environment including users and other protocols.
4.1 Simple Prerequisites
4.1.1 Presentation
All mechanisms are based on assumptions that must be specified and
should aim at being as general as possible to allow a widespread
implementation.
4.1.2 Measurement
This criterium consists in a theoretical assessment of the
assumptions upon which the mechanism is based.
4.1.3 Evaluation
This criterium indicates whether a mechanism is useful, i.e. whether
it is worth implementing. If the prerequisites are too strict,
interest is greatly diminished.
4.2 User Interventions
4.2.1 Presentation
As an autoconfiguration system aims at automatically managing and
configuring addresses, its design must make it user independent, i.e.
should allow its correct functioning without any user intervention.
There should never be situations when nodes are blocked without any
access to the network. Errors should be handled automatically.
4.2.2 Measurement
This criterium can be theoretically evaluated. If a situation has no
adequate specified treatment, unresolved problems can occur.
Simulations and experiments with detection of unresolved problems can
also be very helpful to perform the evaluation of a mechanism through
this criterium. This approach assumes the definition of a problem
detection system especially in a simulation environment.
Clausen, et al. Expires January 12, 2006 [Page 16]
Internet-Draft AUTOCONFCRITERIA July 2005
4.2.3 Evaluation
This criterium is based on the assumption that the user will want to
have to perform as few maintenance operations as possible. This is
not always the case. However, a mechanism allowing a very low user
intervention can have modes with additional controls available and
therefore be adaptable to all degrees of wishes from the point of
view of user intervention.
4.3 Interoperability
4.3.1 Presentation
In fact, an ideal autoconfiguration system should both allow user-
free configuration and manual configuration. An autoconfiguration
system should also be able to comply to different environments such
as networks totally lacking infrastructure and more centralized
networks, with servers providing a stable resource. For instance, a
DHCP server or a gateway to the internet.
An autoconfiguration system should be able to carry out all the
address management tasks while tolerating user interventions. For
instance, an autoconfiguration mechanism designed to assign addresses
to incoming nodes in a network should additionaly be able to handle
manually configured nodes. Adaptability is the key goal here.
Additionally, it can be required of an autoconfiguration mechanism
that it allows the use of completely different mechanisms such as
stateless IPv6 autoconfiguration mechanism.
4.3.2 Measurement
Scenarios with mixed nodes, implementing several protocols can be
staged to test such a criterium.
4.3.3 Evaluation
Interoperability can be the key to a successful deployment of such a
mechanism as the MANETs implementing it are likely to encounter
environments implementing different protocols.
4.4 Independence from the routing protocol
4.4.1 Presentation
A good autoconfiguration mechanism should be based on as few
assumptions as possible, allowing its applicability on a large
variety of routing protocols. An autoconfiguration
Clausen, et al. Expires January 12, 2006 [Page 17]
Internet-Draft AUTOCONFCRITERIA July 2005
mechanism should consist in a series of guidelines applicable to a
whole class of routing protocols. Implementations would slightly
differ due to differences between protocols but those differences
should not be more than optimizations.
4.4.2 Measurement
This criterium has a theoretic basis. If a mechanism uses features
of a routing protocol as its core, it cannot be adapted easily to
another routing protocol.
4.4.3 Evaluation
This criterium is not essential. However it characterizes a degree
of universality of the considered mechanism. This is to be taken
into account when comparing 2 different mechanisms. It is obvious
that a mechanism well rated according to all other criteria but
limited in its use to one single routing protocol will not be as
widely used as the one complying to this particular criterium.
4.5 Simplicity
4.5.1 Presentation
To ensure an actual implementation of a mechanism can be performed
simplicity remains a key criterium. Algorithms must not be too
complex, nor involve computations whose termination is not
guarantied. Complex semantic analyses should not be necessary to
efficiently fulfill the goal of an autoconfiguration mechanism.
4.5.2 Measurement
Specifications should fit in a few pages and the mechanism must
be easy to test and deploy.
4.5.3 Evaluation
Non terminating algorithms are useless in real systems and too
complicated a specification makes it difficult to properly implement
and even evaluate a mechanism.
Clausen, et al. Expires January 12, 2006 [Page 18]
Internet-Draft AUTOCONFCRITERIA July 2005
Authors' Addresses
Thomas Heide Clausen
LIX, Ecole Polytechnique, France
Phone: +33 6 6058 9349
Email: T.Clausen@computer.org
URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/
Julien Garnier
LIX, Ecole Polytechnique, France
Email: Julien.Garnier@polytechnique.org
Shubhranshu Singh
Samsung AIT, South Korea
Phone: +82 10 2799 8296
Email: shubranshu@gmail.com
Christopher
Baesystems, UK
Email: chris.dearlove@computer.org
Clausen, et al. Expires January 12, 2006 [Page 19]
Internet-Draft AUTOCONFCRITERIA July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Clausen, et al. Expires January 12, 2006 [Page 20]
