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

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


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

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



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


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


>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?

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


>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," ...


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.


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

xml2rfc does have some quirky behaviours in lists.

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

agreed

and yes to the rest.


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