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

From: <[email-masked]>
Date: Wed, 3 Nov 2004 09:12:35 +0200

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.

---

From: Geoff Huston <[email-masked]>
Date: Wed, 03 Nov 2004 19:48:09 +1100

John,

Thanks indeed for your careful review of this document. I've responded
inline to your questions, but in general I agree with the suggestions here

regards,

     Geoff

>    "session resilience"; add ULP, LLP and EIP; as well as others.

sounds like an excellent suggestion. I'll look into this

>    to
> http://www.ietf.org/internet-drafts/draft-iab-link-indications-00.txt could

Thanks for this. This has been a more recent contribution than the first
passes of the multi6 document, and I agree that a vcross reference here
would be useful

>         This sentence seems incomplete, a comparable functional outcome

I had implicitly added "to IPv4" in my head when I wrote that setence! :-)

>    reachability changes," ...

I think its the third. But it needs clarification in any case. What is
going through my head as I read your comments is the distinction between
session resilience DURING the period of routing instability while the
routing system reaches a new converged state as distinct to the objective
of session surviveability BEFORE and AFTER a routing change. I do not think
it is possible to undertake the former (DURING) given that there is no
reliable stable routing state during routing churn, so I did mean BEFORE
and AFTER.

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

xml2rfc does have some quirky behaviours in lists.

>         has a lot of mobility baggage, so it might be good to avoid that

agreed

and yes to the rest.