LISP Canonical Address Format (LCAF)
draft-ietf-lisp-lcaf-22

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
Cc: lisp-chairs@ietf.org, lisp@ietf.org, "Luigi Iannone" <ggx@gigix.net>, ggx@gigix.net, "The IESG" <iesg@ietf.org>, draft-ietf-lisp-lcaf@ietf.org, db3546@att.com, rfc-editor@rfc-editor.org
Subject: Document Action: 'LISP Canonical Address Format (LCAF)' to Experimental RFC (draft-ietf-lisp-lcaf-22.txt)

The IESG has approved the following document:
- 'LISP Canonical Address Format (LCAF)'
  (draft-ietf-lisp-lcaf-22.txt) as Experimental RFC

This document is the product of the Locator/ID Separation Protocol
Working Group.

The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah
Brungard.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-lcaf/

Ballot Text

Technical Summary

This document describes a canonical address format encoding
used in the ocator/ID Separation Protocol (LISP), more precisely
in the lookup keys of the LISP mapping system and related control
messages. The intent is to define a general syntax that includes
Address Family Identifier (AFI), length, and value fields.
Such general syntax aims at enabling an easy evolution of the
protocol to support future applications.
   
Working Group Summary

The document has been around for a while, and has been discussed
several times. From the beginning, there was strong support, because
the WG felt that the flexibility introduced by a canonical address
encoding was an important feature, which would enable using LISP
to be used for use-cases and applications which are not in the
original scope of the protocol. Such support never faded.
Discussion in the WG group mostly focused on the initial type allocation
and their definition. The WG converged on splitting the initial type allocation
and their usage in two different sections. Section 4 of the document
defines types for which the use-cases are well defined and
implementation exists or are ongoing. Section 5 contains
types that have a more experimental nature, for which they usage
is either not yet clearly identified or not completely defined.

Document Quality

The LCAF is currently supported by various LISP implementations.
May be not all of the types are supported but the basic encoding
syntax and types are there.
  
Personnel

   Who is the Document Shepherd for this document?  Luigi Iannone
   Who is the Responsible Area Director?  Deborah Brungard

RFC Editor Note