ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)
draft-irtf-rrg-ilnp-icmpv4-06

[Ballot comment]
I have cleared my Discuss on the basis of the new revision to this document. Thanks to the authors for moving to an experimental code point for this work.

---

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]
[Updated Discuss to reflect new discoveries in the IANA registries]
[Updated in line with new 5742 response]

I am very uneasy about allocating a new code point for ILNP from the
ICMP message type registry. This seems incompatible with reducing the
work on extensions that keep IPv4 viable and detract from moving to
IPv6. It seems that (as with LISP) the bulk of the research work should
be focussed on IPv6, and the IPv4 work should be archival not
experimental.

Thus, I do not think the IESG should grant the request for a code point
in this case.

Two ICMP messages types (253 and 254) are provided for
experimentationand could be used in this case.

The authors also note in this document:

  there is no
  architectural difference between using ICMP and using some
  different framing, for example UDP.

therefore I believe that our refusal of a code point would not prevent
experimentation from being done.

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

IANA understands that, upon approval of this document, there are two
IANA actions which must be completed.

First, in the ICMP Type Numbers subregistry of the Internet Control Message
Protocol (ICMP) Parameters registry located at:

www.iana.org/assignments/icmp-parameters/icmp-parameters.xml

a new ICMP Type Number will be registered as follows:

Type: [ tbd at time of registration ]
Name: ICMP Locator Update for ILNPv4
Reference: [ RFC-to-be ]

Second, a new Code Fields subregistry will be established in the ICMP Type
Numbers subregistry of the Internet Control Message Protocol (ICMP) Parameters
registry located at:

www.iana.org/assignments/icmp-parameters/icmp-parameters.xml

for the new Code Type: [ tbd at time of registration ]

as follows:

Type [ tbd at time of registration ] — ICMP Locator Update for ILNPv4

Reference: [ RFC-to-be ]

Codes Description Reference
-----+-----------+--------------
0 No Code [ RFC-to-be ]

IANA understands that these are the only actions required upon approval
of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

[Ballot discuss]
[Updated Discuss to reflect new discoveries in the IANA registries]

I think that the IESG's 5742 response on this document should note that
this is related to the work in LISP and HIP. I wonder whether it should
also note that it is related to Sunset4.

---

I am very uneasy about allocating a new code point for ILNP from the
ICMP message type registry. This seems incompatible with reducing the
work on extensions that keep IPv4 viable and detract from moving to
IPv6. It seems that (as with LISP) the bulk of the research work should
be focussed on IPv6, and the IPv4 work should be archival not
experimental.

Thus, I do not think the IESG should grant the request for a code point
in this case.

Two ICMP messages types (253 and 254) are provided for
experimentationand could be used in this case.

The authors also note in this document:

  there is no
  architectural difference between using ICMP and using some
  different framing, for example UDP.

therefore I believe that our refusal of a code point would not prevent
experimentation from being done.

[Ballot discuss]
I think that the IESG's 5742 response on this document should note that
this is related to the work in LISP and HIP. I wonder whether it should
also note that it is related to Sunset4.

---

I am very uneasy about allocating a new code point for ILNP from the
ICMP message type registry. This seems incompatible with reducing the
work on extensions that keep IPv4 viable and detract from moving to
IPv6. It seems that (as with LISP) the bulk of the research work should
be focussed on IPv6, and the IPv4 work should be archival not
experimental.

Thus, I do not think the IESG should grant the request for a code point
in this case.

However, I note that the registry does not currently include any
experimental code point for general use. That prevents any new
experiment from using ICMP.

As the authors note in this document:

  there is no
  architectural difference between using ICMP and using some
  different framing, for example UDP.

therefore I believe that our refusal of a code point would not prevent
experimentation from being done, and UDP can be used as appropriate.

[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.

The IETF is working to phase out IPv4, and yet the proposal here seems to be to
extend the capabilities of IPv4, which is contra to that goal. If this draft is
to be published it should surely go straight to historic status.

I do not think that we should be authorizing the assignment of ICMPv4
codepoints  to this protocol. The purpose of the protocol is to run an
experiment and as such it should preferably be run on one of the existing
experimental codepoints. If the existing experimental codepoints are not
of a suitable type, a new experimental option could be considered.
This is consistent with the advice given to the author of draft-templin-aero
wanted to do experimental work using  ICMPv6 we directed them to using
an experimental identifier.

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