Session PEERing for Multimedia                                  O. Lendl
INTerconnect                                                     enum.at
Internet-Draft                                           August 10, 2006
Expires: February 11, 2007


                   The Domain Policy DDDS Application
                   draft-lendl-domain-policy-ddds-02

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 February 11, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This documents proposes the use of the DNS to publish a domain's
   policy regarding incoming communication.  The algorithm used is
   defined as a new application of the Dynamic Delegation Discovery
   System (DDDS).  Such policy announcements can be used to facilitate
   selective SIP peering.






Lendl                   Expires February 11, 2007               [Page 1]


Internet-Draft             Domain Policy DDDS                August 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Policy Rules . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Atomic Policy Rules  . . . . . . . . . . . . . . . . . . .  4
       2.1.1.  Notification . . . . . . . . . . . . . . . . . . . . .  4
       2.1.2.  Publication  . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Complex Policies . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Policy Enforcement . . . . . . . . . . . . . . . . . . . .  5

   3.  DDDS Specification . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Application Unique String  . . . . . . . . . . . . . . . .  6
     3.2.  First Well Known Rule  . . . . . . . . . . . . . . . . . .  6
     3.3.  Expected Output  . . . . . . . . . . . . . . . . . . . . .  6
     3.4.  Valid Databases  . . . . . . . . . . . . . . . . . . . . .  6
       3.4.1.  Services Parameter . . . . . . . . . . . . . . . . . .  6
       3.4.2.  Flags  . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.5.  DNS considerations . . . . . . . . . . . . . . . . . . . .  8

   4.  Registration mechanism for policy-types  . . . . . . . . . . .  8
     4.1.  Functionality Requirement  . . . . . . . . . . . . . . . .  8
     4.2.  Naming requirement . . . . . . . . . . . . . . . . . . . .  9
     4.3.  Publication Requirements . . . . . . . . . . . . . . . . .  9
     4.4.  Registration Template  . . . . . . . . . . . . . . . . . .  9

   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  9

   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11

   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12

   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12

   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 13

   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 15











Lendl                   Expires February 11, 2007               [Page 2]


Internet-Draft             Domain Policy DDDS                August 2006


1.  Introduction

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [7].

   The DNS [5] is widely used to map a domain name to the lower layer
   parameters needed to connect to the service offered by this domain.
   At a basic level, an A record maps a domain name to an IP address.
   MX and SRV [8] records offer application specific mappings and define
   sets of alternative routes and their associated priorities.

   NAPTR records as used in RFC 3263 [4] provide even more abstraction:
   They announce over which transport protocol a Session Initiation
   Protocol (SIP [9]) server prefers to be contacted.

   This document defines another abstraction: Even if the service is
   announced by MX or SRV records and suitable A (or AAAA) records,
   access controls may apply.  Not all URIs are reachable to anybody on
   the public Internet.  Access restrictions can be implemented on
   various layers (IP, TLS, Application) and due to various reasons
   (technical, security, commercial, ...).  Somebody wanting to use the
   service announced by MX or SRV records has usually no means to find
   out whether his connection will be accepted other than by trying to
   connect.

   Such trial and error behavior is good enough for most applications,
   but in some cases it is vital that the service can announce to
   prospective clients the conditions under which a connection attempt
   is likely to succeed.  This is mainly relevant for applications with
   the following properties:

   o  Real-time services: Any delay in establishing the connection is
      visible (and annoying) to the user.  Waiting for a timeout is no
      problem for an email transmission or a background file transfer.
      This is an issue for interactive applications like e.g. web or
      VoIP services.

   o  Alternatives exist: If there are multiple technical ways to
      fulfill the customer's request then a fail-over from one method to
      another is possible.  The sooner the sender knows that the first
      method he tries will fail, the earlier he can switch to the
      alternative.

   The prime example for such an application is VoIP peering: Users are
   very sensitive to delays in the call-setup time, thus the originating
   network should not waste time on fruitless tries to reach the
   destination network via a direct SIP call.  Currently the public



Lendl                   Expires February 11, 2007               [Page 3]


Internet-Draft             Domain Policy DDDS                August 2006


   switched telephone network (PSTN) acts as a backup interconnection
   network over which VoIP networks based on E.164 telephone number can
   interconnect.

   This document thus defines a protocol with which a domain can
   announce its policies regarding incoming communications for a
   specific protocol.


2.  Policy Rules

   The Domain Policy DDDS Application is built upon the concept of
   atomic policy rules.  Complex policies are defined as a boolean
   combination of individual rules.  This document does not define the
   semantics of any individual rule, this will be done by companion
   documents.

2.1.  Atomic Policy Rules

   Individual policy rules in the Domain Policy framework are expressed
   as Uniform Resource Identifiers (URI, RFC 2396 [1]).  URIs can be
   used both as compact identifiers for standards (using e.g.
   "urn:ietf:rfc:XXXXX", "http://sippeering.example.com/release1") as
   well as URLs pointing to more elaborate policy statements.

   Using URIs as identifiers is a common technique in the XML world.
   See for example XML namespaces [11] or XML DSIG [12] (1.3).  The fact
   that these URIs are often URLs may be a bit confusing at first.
   Clients are not supposed to fetch and interpret the document to which
   these URLs refer to.  These URLs are just convenient as unique and
   descriptive identifiers.

   Simple protocol parameters (e.g. a list of X.509 CAs) can be included
   into the policy rule URI (e.g. in the query part) itself.

2.1.1.  Notification

   Policy rules can contain notifications about policies: Such rules do
   not by themselves describe the conditions under which calls will be
   accepted.  Instead, such atomic rules reference other, potentially
   complex documents which need not be available online.  Examples are
   contracts or other non-technical documents.  On the sender side the
   support for such rules will have to be manually configured (e.g. "we
   are a member of federation X").

2.1.2.  Publication

   On the other hand, policy rules can describe very concrete



Lendl                   Expires February 11, 2007               [Page 4]


Internet-Draft             Domain Policy DDDS                August 2006


   restrictions, e.g. the support for a certain protocol standard.  In
   that case, a software package implementing the sender side can
   include a default set of policy rules which it fulfills out of the
   box.

2.2.  Complex Policies

   To link individual policy rules into one complex policy the
   disjunctive normal form of boolean logic is used.  In simple words:
   The policy is written as a set of valid (according to the policy)
   alternatives.  These alternatives may themselves consist of
   individual rules which must all be fulfilled to yield a positive
   result.

   If the simple boolean logic and the limited space in the DNS answers
   are insufficient for an application then a type of policy rule URIs
   can be defined which links to policy statements written in a fully
   featured policy description language like SAML [13] or XACML [14].

2.3.  Policy Enforcement

   This document does not specify if and how the announced policies are
   enforced.  The Domain Policy DDDS just gives operators the option to
   document and publish what kind of communications their servers are
   configured to accept.


3.  DDDS Specification

   This section contains the formal definition of the Domain Policy DDDS
   application according to RFC 3401 [2].

   RFC 3401 describes DDDS as follows:

      The Dynamic Delegation Discovery System is used to implement lazy
      binding of strings to data, in order to support dynamically
      configured delegation systems.  The DDDS functions by mapping some
      unique string to data stored within a DDDS Database by iteratively
      applying string transformation rules until a terminal condition is
      reached.

   The Domain Policy DDDS Application maps a domain name and a protocol
   name to an ordered boolean expression of atomic policy rules.  It
   does not define how individual rules should be interpreted (except
   that unknown rules must be regarded as not fulfilled).  It defines
   how these rules are retrieved and how they are combined and
   processed.




Lendl                   Expires February 11, 2007               [Page 5]


Internet-Draft             Domain Policy DDDS                August 2006


   As a domain's policy may be different for the various protocols (e.g.
   SMTP vs. SIP), the name of the protocol is another input into the
   DDDS application.

3.1.  Application Unique String

   The Application Unique String is the URI which describes the service
   the originating network wants to access.

   Examples: "sip:user@example.com", "mailto:sales@example.org"

3.2.  First Well Known Rule

   The First Well Known Rule extracts the domain part of the URI.  This
   key thus has the form of a fully qualified domain name.

3.3.  Expected Output

   The Expected Output of this algorithm is a set of URIs which describe
   the conditions the sender can fulfill.

3.4.  Valid Databases

   This DDDS application uses the DNS as the database as defined in RFC
   3403 [3].  The rewriting rules are stored in NAPTR DNS resource
   records.  As the key is already in the form of a FQDN, no
   transformations are necessary.

3.4.1.  Services Parameter

   The "services" field in the NAPTR record is used to
   o  identify this NAPTR as part of the Domain Policy DDDS application,
   o  define to which protocol this policy applies to, and
   o  identify which type of policy is contained in this record.
   This document does not define actual policy types, that is left to
   companion documents.  The formal specification for the service field
   is as follows:

           service-field        = "D2P+" protocol *1policy
           protocol             = 1*32(ALPHA / DIGIT)
           policy               = ":" policy-type
           policy-type          = 1*32(ALPHA / DIGIT)

   In other words, the service-type starts with "D2P+" (which marks this
   as part of the Domain Policy DDDS) followed by the name of the
   protocol to which this policy applies to (e.g. "sip", "xmpp", "smtp",
   ...).  Optionally the policy-type (which follows after a colon)
   indicates what kind of policy rule is contained in the regexp field.



Lendl                   Expires February 11, 2007               [Page 6]


Internet-Draft             Domain Policy DDDS                August 2006


   All matching operations on the service-field MUST be done in a case-
   insensitive way.

   The Domain Policy DDDS Application client MUST ignore all records
   where the protocol in the service-field does not match the protocol
   for which the policy is sought.

3.4.2.  Flags

   The "flags" field in the NAPTR record signals when the DDDS algorithm
   has finished.

   An empty (non-existent) flag means that this rule is non-terminal and
   the client MUST use the key resulting from this rule as the input
   into a new DDDS loop.  Such non-terminal NAPTRs have an empty
   "regexp" field and contain a new domain name in the "replacement"
   field.  They MUST NOT contain a policy-type element in the service-
   field.

   Such non-terminal NAPTRs are referrals: They indicate that
   communications to the original domain can be routed via the
   replacement domain.  This implies that if this referral is selected
   then all further DNS lookups (both for policy and signalling
   parameters) MUST be done by querying the new domain.

   A non-terminal NAPTR can lead to another non-terminal NAPTR record.
   Clients need to limit the recursion depth to prevent looping.

   A flag containing "U" signals that the algorithm has found a valid
   policy record for this domain.  This rule MUST be considered in
   conjunction with all other rule which share the same protocol (from
   the service-field), the same flag and the same order field.  If the
   client can determine that he is able to fulfill all the requirements
   in this set of atomic rules then the DDDS algorithm terminates and
   the result is this set of rules.

   If the policy-type of a rule is not known to the client it MUST
   consider this rule as not fulfill-able.

   No other values for the flag field are defined as of now and clients
   MUST ignore all records not containing either "U" or and empty flag
   field.

   The treatment of the "order" and "preference" fields as defined here
   deviates slightly from RFC 3403.  The reason is that this DDDS
   application does not return a single URI as found in a single NAPTR
   record but a set of URIs which are generated by grouping NAPTR
   records based on their "order" field.  The "preference" field is not



Lendl                   Expires February 11, 2007               [Page 7]


Internet-Draft             Domain Policy DDDS                August 2006


   evaluated.

3.5.  DNS considerations

   The NAPTR records containing the policy announcements for a domain
   can be quite large for DNS responses, especially if elaborate rules
   are used or if this mechanism is used for more than one protocol.

   To accommodate these larger DNS responses the DNS servers and the
   clients MUST utilize EDNS0 [6] to minimise fall-backs to TCP queries.
   This requirement is the equivalent of [10].

   Storing policy rules directly in the DNS is very efficient as long as
   the rule-set is small.  One must take care not to overload this
   database.  If more elaborate rules are needed it is recommended to
   use the DNS only to refer to a policy statement stored elsewhere.


4.  Registration mechanism for policy-types

   The service-field of the NAPTR records used in this document contain
   three fields:
   o  The constant string "D2P".
   o  The protocol name.  Protocol names are to be taken from the IANA
      registry at http://www.iana.org/assignments/port-numbers.  No new
      registry functions are needed for this field.
   o  The policy-type.  This field indicates the interpretation rules
      for the URI contained in the NAPTR record.  An IANA registration
      procedure is thus needed for this field.

   New entries in the IANA policy-type registry need to specify not only
   the name of the new policy-type, but also need to include the allowed
   URI schemes, a functional specification on how to interpret the URI,
   security considerations, intended usage, and any other information
   needed for to evaluate policy rules of this type.  In order to be a
   registered policy-type, the entire specification, including the
   template, requires approval by the IESG and publication of the
   policy-type registration specification as an RFC.

4.1.  Functionality Requirement

   A registered policy-type acts as selector within the policy
   evaluation engine of the client.  The specification in the
   registration MUST be sufficient such that the client can determine
   whether he can fulfill the policy requirements encoded in the URI.
   Specifically, a registered policy-type MUST specify the URI scheme(s)
   that may be used, and, when needed, other information which will have
   to be transferred into the policy evaluation process itself.



Lendl                   Expires February 11, 2007               [Page 8]


Internet-Draft             Domain Policy DDDS                August 2006


4.2.  Naming requirement

   Registered policy-types must by unique and conform to the ABNF
   specified in Section Section 3.4.1, and MUST NOT start with the facet
   "X-" which is reserved for experimental, private use.

4.3.  Publication Requirements

   Proposals for policy-type registrations MUST be published as one of
   the following documents; RFC on the Standards Track, Experimental
   RFC, or as a BCP.

   IANA will retain copies of all policy-type registration proposals and
   "publish" them as part of the policy-type Registration tree itself.

4.4.  Registration Template


      Policy Type:

      URI Scheme(s):

      Functional Specification:

      Security considerations:

      Intended usage: (One of COMMON, LIMITED USE or OBSOLETE)

      Author:

      Any other information that the author deems interesting:


5.  Examples

   In order to give meaningful examples, we need to define a few types
   of rules.  The definitions here are purely meant to illustrate the
   possibilities.  They MUST NOT be considered as valid examples of real
   entries.
   o  The policy-type "fed" shall indicate that the URI denotes a
      federation of service providers.  All members of a federation know
      how to talk to each other.
   o  The policy-type "std" shall indicate that the URI indicates a
      standard the sender has to fulfill.
   o  A record with policy-type "saml" shall contain an URL of a SAML
      document which contains further policy information.





Lendl                   Expires February 11, 2007               [Page 9]


Internet-Draft             Domain Policy DDDS                August 2006


   o  In this example "customer.example.org" is a customer domain for
      which the service-provider "example.com" hosts the SIP server.
      Thus, for incoming SIP calls for customer.example.org an
      originating VSP is directed to to use example.com as the next hop,
      and use the supported policies of example.com to deliver the call.

      $ORIGIN customer.example.org.
      ;      order pref flags service regexp replacement
       IN NAPTR 10 50   "" "D2P+SIP" ""   example.com.

      Please note that there is no policy-type in this record.  The
      protocol name is needed though, as e.g. this customer could have
      his email hosted at a different provider and thus refer to a
      different domain with a "D2P+SMTP" NAPTR.

      An orginating SIP provider trying to establish a call to
      <sip:bob@customer.example.org> will thus look at the domain
      example.com for further policy rules.  If he finds matching ones
      (eg. a shared federation) he will use "example.com" and not
      "customer.example.org" as the input into the RFC 3263 "Locating
      SIP Servers" algorithm.

   o  In the second example the SIP services at "example.com" is only
      reachable via a private interconnection arrangement maintained by
      a federation called "http://sipxconnect.example.org/".

      $ORIGIN example.com.
       IN NAPTR 10 50 (                                 ; order priority
             "U" "D2P+SIP:fed"                          ; flags service
             "!^.*$!http://sipxconnect.example.org/!" . ; regexp repl
             )


   o  In this example the SIP services at "example.com" from above also
      buys transit services from "example.net".  Other providers
      (especially those which are not members of
      "http://sipxconnect.example.org/") can additionally reach users of
      "example.com" by routing calls via "example.net".

      $ORIGIN example.com.
       IN NAPTR 10 50 (                                 ; order priority
             "U" "D2P+SIP:fed"                          ; flags service
             "!^.*$!http://sipxconnect.example.org/!" . ; regexp repl
             )
       IN NAPTR 20 50   "" "D2P+SIP" ""   example.net.






Lendl                   Expires February 11, 2007              [Page 10]


Internet-Draft             Domain Policy DDDS                August 2006


   o  In the next example the "example.com" also allows incoming
      connections as long they use SIP over TLS.  Calls according to
      federation rules are preferred.

      $ORIGIN example.com.
       IN NAPTR 10 50 (                                 ; order priority
             "U" "D2P+SIP:fed"                          ; flags service
             "!^.*$!http://sipxconnect.example.org/!" . ; regexp repl
             )
       IN NAPTR 20 10 (                                 ; order priority
             "U" "D2P+SIP:std"                          ; flags service
             "!^.*$!urn:ietf:rfc:2246!" .               ; regexp repl
             )

   o  If the carrier example.com only accepts SIP calls (in addition to
      PSTN interconnect) if the PSTN emulation is good, he might publish
      a policy like this:

      $ORIGIN example.com.
      ;      order pref flags service       regexp           replacement
       IN NAPTR 10 10   "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:3578!" .
       IN NAPTR 10 11   "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:3666!" .
       IN NAPTR 10 12   "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:3960!" .


   o  A restrictive SIP service might only accept calls from peers from
      two federations, while subjecting calls from the public Internet
      to a complex policy.  The policy records could look like this:

      $ORIGIN example.com
       IN NAPTR 10 10 (                                 ; order priority
             "U" "D2P+SIP:fed"                          ; flags service
             "!^.*$!http://sipxconnect.example.org/!" . ; regexp repl
             )
       IN NAPTR 20 10 (                                 ; order priority
             "U" "D2P+SIP:fed"                          ; flags service
             "!^.*$!http://sip.federation.com/!" .      ; regexp repl
             )
       IN NAPTR 30 10 (                                 ; order priority
             "U" "D2P+SIP:saml"                         ; flags service
             "!^.*$!http://www.example.com/sip-policy.saml!" .
             )


6.  Security Considerations

   The publishing of the access policy via the DNS RR described in this
   draft will reduce the amount of unwanted communication attempts, as



Lendl                   Expires February 11, 2007              [Page 11]


Internet-Draft             Domain Policy DDDS                August 2006


   all well-meaning clients will follow them, but these records cannot
   substitute measures to actually enforce the published policy.

   In the case of SIP Peering, the NAPTRs proposed here publish
   information which is not public if service providers just rely on
   private interconnection agreements.  These records are similar to the
   public routing registries for BGP4 as maintained by the RIRs.  They
   are just records indicating who peers with whom but do not hold
   details on how the interconnection is achieved.

   The published technical requirements for incoming calls could be used
   by malicious callers to find possible attack vectors.


7.  IANA Considerations

   This document defines an IANA registry for the policy-type field.
   See Section 4.


8.  Acknowledgements

   The author would like to thank Richard Shockey, Michael Haberler,
   Alexander Mayrhofer, Richard Stastny, and John Todd for their
   contributions.


9.  References

9.1.  Normative References

   [1]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
        Resource Identifiers (URI): Generic Syntax", RFC 2396,
        August 1998.

   [2]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        One: The Comprehensive DDDS", RFC 3401, October 2002.

   [3]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        Three: The Domain Name System (DNS) Database", RFC 3403,
        October 2002.

   [4]  Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
        (SIP): Locating SIP Servers", RFC 3263, June 2002.

   [5]  Mockapetris, P., "Domain names - concepts and facilities",
        STD 13, RFC 1034, November 1987.




Lendl                   Expires February 11, 2007              [Page 12]


Internet-Draft             Domain Policy DDDS                August 2006


   [6]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
        August 1999.

9.2.  Informative References

   [7]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [8]   Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
         specifying the location of services (DNS SRV)", RFC 2782,
         February 2000.

   [9]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [10]  Conroy, L. and J. Reid, "ENUM Requirement for EDNS0 Support",
         draft-conroy-enum-edns0-01 (work in progress), October 2005.

   [11]  Hollander, D., Bray, T., and A. Layman, "Namespaces in XML",
         W3C REC REC-xml-names-19990114, January 1999.

   [12]  Solo, D., Reagle, J., and D. Eastlake, "XML-Signature Syntax
         and Processing", W3C REC REC-xmldsig-core-20020212,
         February 2002.

   [13]  Maler, E. and J. Hughes, "Security Assertion Markup Language
         (SAML) V2.0 Technical Overview", July 2005.

   [14]  Godik, S. and T. Moses, "OASIS eXtensible Access Control Markup
         Language (XACML)", OASIS Committee Working Draft xacml-schema-
         policy, July 2002, <http://www.oasis-open.org/committees/xacml/
         repository/draft-xacml-schema-policy-15.doc>.


















Lendl                   Expires February 11, 2007              [Page 13]


Internet-Draft             Domain Policy DDDS                August 2006


Author's Address

   Otmar Lendl
   enum.at GmbH
   Karlsplatz 1/9
   Wien  A-1010
   Austria

   Phone: +43 1 5056416 33
   Email: otmar.lendl@enum.at
   URI:   http://www.enum.at/








































Lendl                   Expires February 11, 2007              [Page 14]


Internet-Draft             Domain Policy DDDS                August 2006


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




Lendl                   Expires February 11, 2007              [Page 15]