[shim6] APPSDIR review of draft-garcia-shim6-applicability-03

[Carsten Bormann <[e-mail]>]

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on APPSDIR, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Gruesse, Carsten
---------------------------------

Document: draft-garcia-shim6-applicability-03.txt
Title: Applicability Statement for the Level 3 Multihoming Shim Protocol (Shim6)
Reviewer: Carsten Bormann
IETF Last Call Date: 2012-02-15
Review Date: 2012-02-29

** Summary: This draft is ready for publication as an Informational
   RFC with small changes, but maybe requires a better title.

Note: I reviewed this with the expectation that the intended audience
will read this *before* looking at RFC5533–5535 in detail.

** Major Issues:

General:

The document provides useful discussion of considerations around the
usage of Shim6.  At the end, it leaves the reader confused: What *is*
the applicability/area of application of Shim6?  Who should decide
whether Shim6 is activated for a specific connection?  (There is an
API in RFC 6316, but clearly that is meant for advanced applications.)
While the document successfully relates Shim6 to SCTP and HIP, what
about other approaches to multi-addressing?  When is happy-eyeballs
enough?  When should MPTCP be used?  (The introduction to 7 then goes
ahead and destroys any remaining hope that this document provides the
answers -- maybe this should be split into "Open Issues" and the solid
information about where Shim6 is not needed.)

The document may have started out as an applicability statement half a
decade ago, but maybe renaming it to "Considerations on the
Application of Shim6" provides a more appropriate title now.

Again, this is meant as a comment on the expectations raised by the
title and abstract, not as an attempt to belittle the usefulness of
the document's content.

** Minor Issues:

(1)
I'm not so fond of the DHCP speculation in 3.3.  An applicability
statement should talk about what is, not what could be.  As of today,
DHCP is not applicable, and that should be clearly stated.  (Work in
progress can, of course, be pointed to, but it is not clear there is
much more than a problem statement.)

(2)
This sentence in 3.4 is opaque, unless it is talking about the state
of implementations (or is this another piece of DHCP speculation?):

           There is no current mechanism designed to allow an administrator to
           enforce the configuration of a CGA or an HBA in a host.

(3)
Section 3.4, 7.2:  The term "hybrid" does not occur in RFC 5535.
Adapt the terminology.

(4)
Section 5.2:

           One such solution is being developed at the MP-TCP Working Group.

That is not the name of the WG, and referring to ephemeral IETF WGs is
not very useful in an archival document such as an RFC.  It is
probably most appropriate to reference RFC 6182.

More generally speaking, one would expect some more guidance when
MPTCP is appropriate and when Shim6 is appropriate.  Oddly, RFC 6181
seems to provide more information about Shim6 on this point than the
present document.

(5)
(On a related note, avoid discussion of the Shim6 WG's charter in 7.5.)

** Nits:

[I-D.ietf-mif-problem-statement] is now RFC 6418.

The document will benefit from some micro-editing, e.g.
s/different to/different from/g
s/specific of/specific to/g
s/associated to/associated with/g
s/is developed/has been developed/
The usage of "suffer" in several places
(in particular, should "These problems are suffered by other solutions
            supporting multihoming such as SCTP [RFC4960] or HIP
            [RFC4423]." in section 4 not be "relevant to" instead?)
"Shim6 has no means to enforce neither host nor network forwarding..."
"does not require also"
s/should be review/should be reviewed/
"...which security features can expect applications and users of the Shim6 protocol."
As this is typically done by the RFC editor, I'm not providing a
detailed list here.

Section 4: s/not being used/not be used/

Define "REAP" (I know, RFC5533 doesn't, either).

Section 6: This sentence is hard to read:
"As long as the address exchanged, IP_A is the ULID..."