Remaining open issues for RFC-2401bis

["Theodore Ts'o" <tytso@mit.edu>]

In an attempt to try to drive rfc2401bis to closure, the following
represent the open issues with the draft.  Please let us know if we have
missed anything.

As you will note, we are starting a working-group last call on the new
process model, and selector name clarification issues for the end of the
week.  For the rest of the issues, we would like to encourage the
working group to focus the discussion and try to come to a consensus as
soon as possible.  

We are am particularly concerned by the fact that there has been
essentially no discussion for issue #91 (Incoming ICMP handling).  If we
do not get any support for issue #91, we propose that we revert to RFC
2401 text with respect to this issue.

					- Ted and Barbara


1.  New processing model (issues #44, #45)

	There appears to be current consensus on the list about the
	overall approach, although there have been some requests to
	clarify the text.  If any disagree with the general direction
	utilized by the processing model, please make your concerns
	known by the end of the week.  At that time, issues #44 and #45
	will be marked as closed in the roundup database.  People who
	have suggestions on how to clarify any part of the specification
	are encouraged to continue make them.

2.  fragmentation handling (issue #92, #88)

        Actively being discussed.  Steve Kent is preparing a five page
	exposition on the issues that will hopefully help to focus the
	discussion.  

3.  Incoming ICMP error message handling (issue #91)

	There has currently been no discussion on issue #91.  If we
	don't get movement, we may need to go back to the RFC 2401 text,
	which makes it be a local matter.  If so, we will need to add
	back the path mtu handling text which was dropped in the -01
	version of the ID.

4.  selector name clarification (issue #93)

        Seems straightforward, and there has been no disagreement on the
        mailing list.  If any disagree with the text suggested by Karen
        on February 25th, please make your conerns known by the end of
        the week.

5.  Defined ICMP response to unprotected inbound packets that require
    protection.  (Issue #83)

	This was initially raised by Steve Kent and Karen Seo, and
	accepted by the working group.  It was later withdrawn by Steve
	because of performance concerns in high-speed applications.
	Possible outcomes: 

	1.  The working group explicitly chooses to drop this issue.
	    In this case, what to do in the case where an inbound
	    packet is dropped is a local issue, with the text being
	    completely silent about what should happen when a packet
	    is discarded.

	2.  The "SHOULD be capable of generating an ICMP message" is
	    changed to "MAY", with the definition of the ICMP packet to
	    be sent (should the implementation so choose and/or is
	    configured to do so) being defined in RFC 2401bis.