WGLC comments on draft-ietf-multi6-architecture-02.txt

[<john.loughney@nokia.com>]

Geoff,

I support this draft going forward, I have a couple of issues, some questions
but mostly nits.

thanks,
John

Issues:
======

1) This document would benefit from a terminology section.  Perhaps a reference
   to the Terminology section in RFC3582 as well.  Terminology to include would be
   "session resilience"; add ULP, LLP and EIP; as well as others.

2) Section 5.3.1 - Triggering Locator Switches.  Inserting an information reference
   to http://www.ietf.org/internet-drafts/draft-iab-link-indications-00.txt could
   be useful. It seems to me that a crucial part of any multihoming solution will
   be the triggering of a multihoming event.  I don't think we need to explicitly
   list all of the potential triggers, but let the astute reader catch-up on some
   related work.

Questions:
=========

1) Section 4.3:

   "The intent of multi-homing in the IPv6 domain is to achieve a
   comparable functional outcome for multi-homed sites without an
   associated additional load being imposed on the routing system."

	This sentence seems incomplete, a comparable functional outcome 
	as compared to what?

2) 1st line, page 8:

   "In addition to this objective of session resilience across network
   reachability changes," ...

	I had a hard time parsing this at first, perhaps the coffee  didn't
	kick in.  Is it:

   "In addition to this objective of session resilience across network
   reachability changes," ...

	or

   "In addition to this objective of session resilience during network
   reachability changes," ...

	or

   "In addition to this objective of session resilience in spite of network
   reachability changes," ...


Nits:
====

1) Spacing problem, but this seems to be a Secretariat problem.

2) Page 6:

   "The environment of multi-homing is one that is intended to provide
   sufficient support to local hosts so as to allow local hosts to
   exchange IP packets with remote hosts, such that this exchange of
   packets is to be seamlessly supported across dynamic changes in
   connectivity."

	Change 'seamlessly' to another term, perhaps 'transparently'?  Seamlessly
	has a lot of mobility baggage, so it might be good to avoid that term.

3) Expand first usage of ULP in section 4.2.

4) Section 4.3 (and others) "vs" should be "vs."

5) Section 5.3.1 - adding a new line before each bullet would increase readability.

6) "5.3.5  Dynamic Capability Negotiation


   The common aspect of these approaches is that they all involve
   changes to the end-to-end interaction, as both endS of the"

	endS -> ends

7) Section 6 - insert a blank line between questions; otherwise it is somewhat 
   awkward to read.