ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)
draft-irtf-rrg-ilnp-icmpv6-06

[Ballot comment]
The IESG failed to convince me that this work needs to be conducted
other than on experimental code points. However, I will not stand
against the IESG consensus, and will allow the IESG to make its
decision to allocate a code point.

---

The LISP documents (currently in the RFC Editor Queue for publication
as Experimental RFCs in the IETF Stream) have clear and unambiguous
text to caution the user about the unknown side-effects of conducting
the experiment on the Internet. For example, draft-ietf-lisp-23 says:

  This experimental specification has areas that require additional
  experience and measurement.  It is NOT RECOMMENDED for deployment
  beyond experimental situations.  Results of experimentation may lead
  to modifications and enhancements of protocol mechanisms defined in
  this document.  See Section 15 for specific, known issues that are in           
  need of further work during development, implementation, and
  experimentation.

  An examination of the implications of LISP on Internet traffic,
  applications, routers, and security is for future study.  This
  analysis will explain what role LISP can play in scalable routing and
  will also look at scalability and levels of state required for
  encapsulation, decapsulation, liveness, and so on.

It seems to me highly desirable that similar caveats be applied to this
work and added to the front of all ILNP documents. I strongly urge the
authors and IRSG to apply such text.

[Ballot discuss]
Agreeing with Stewart, I cannot see (from this document or from discussions in email threads) why ILNP cannot make use of Experimental code points to conduct this experiment.

Indeed, the Abstract says:

  This note specifies an experimental ICMPv6 message type used with
  the Identifier-Locator Network Protocol (ILNP).

...which seems to be in direct contradiction with the IANA considerations section.

I propose that the IESG refuse this request for a code point and refer the authors and IRSG to the existing experimental code points.

---

I think the 5742 review should note that this work is related to the work conducted in the LISP and HIP working groups. Presumably, if it is using ICMP, it is also related to work in 6man.

[Ballot discuss]
Agreeing with Stewart, I cannot see (from this document or from discussions in email threads) why ILNP cannot make use of Experimental code points to conduct this experiment.

[Ballot comment]
The LISP documents (currently in the RFC Editor Queue for publication
as Experimental RFCs in the IETF Stream) have clear and unambiguous
text to caution the user about the unknown side-effects of conducting
the experiment on the Internet. For example, draft-ietf-lisp-23 says:

  This experimental specification has areas that require additional
  experience and measurement.  It is NOT RECOMMENDED for deployment
  beyond experimental situations.  Results of experimentation may lead
  to modifications and enhancements of protocol mechanisms defined in
  this document.  See Section 15 for specific, known issues that are in           
  need of further work during development, implementation, and
  experimentation.

  An examination of the implications of LISP on Internet traffic,
  applications, routers, and security is for future study.  This
  analysis will explain what role LISP can play in scalable routing and
  will also look at scalability and levels of state required for
  encapsulation, decapsulation, liveness, and so on.

It seems to me highly desirable that similar caveats be applied to this
work and added to the front of all ILNP documents. I strongly urge the
authors and IRSG to apply such text.

[Ballot discuss]
I respectfully disagree with the evaluation of the IESG shepherd WRT this document not being in conflict with existing IETF work. The IETF is conducting experimental work in this area (LISP & HIP) and this needs to be referenced.

Additionally, when the author of draft-templin-aero wanted to do experimental work using ICMPv6 we directed them to using an experimental identifier. For consistency we should do the same in the case of the ILNP experiment. If a new experimental type is needed we should create that and make it available to all experiments.

IANA has reviewed draft-irtf-rrg-ilnp-icmpv6-02 and has the following
comments:

IANA understands that, upon approval of this document, there is a single
IANA action which must be completed.

In the ICMPv6 "type" Numbers subregistry of the Internet Control Message
Protocol version 6 (ICMPv6) Parameters registry located at:

http://www.iana.org/assignments/icmpv6-parameters

a new ICMPv6 type will be registered as follows:

Type: [ TBD ]
Description: Locator Update message for ILNPv6
Reference: [ RFC-to-be ]

IANA understands that this is the only action required upon approval of
this document.

this is a request for the IESG to perform an RFC5742 review of the following drafts describing ILNP from the RRG, to be published as RFCs on the IRTF Stream:

- draft-irtf-rrg-ilnp-adv-02 (Experimental)
- draft-irtf-rrg-ilnp-arch-02 (Experimental)
- draft-irtf-rrg-ilnp-arp-02 (Experimental)
- draft-irtf-rrg-ilnp-dns-02 (Experimental)
- draft-irtf-rrg-ilnp-eng-02 (Experimental)
- draft-irtf-rrg-ilnp-icmpv4-02 (Experimental)
- draft-irtf-rrg-ilnp-icmpv6-02 (Experimental)
- draft-irtf-rrg-ilnp-noncev6-02 (Experimental)
- draft-irtf-rrg-ilnp-v4opts-02 (Experimental)

These documents have been approved for publication by the IRSG. See http://wiki.tools.ietf.org/group/irtf/trac/ticket/42 for details on prior reviews. Please copy all correspondence to the document shepherd, Tony Li (tony.li@tony.li).

Also, please note that several of these documents require IESG Approval for codepoint registrations in various IANA registries. In the process of reviewing these documents under RFC5742 (i.e., for conflicts with IETF work), please also approve the necessary codepoints to enable experimentation with ILNP.

Thanks,
Lars