Re: Multi6 WG Last Call (1 of 3) draft-ietf-multi6-architecture-01.txt

[Pekka Savola <pekkas@netcore.fi>]

On Thu, 21 Oct 2004, Brian E Carpenter wrote:
> It is proposed to forward
>    draft-ietf-multi6-architecture-01.txt
> to the IESG for approval as an Informational RFC
>
> Any final comments must be sent to the WG list at multi6@ops.ietf.org
> within two weeks, i.e. at the latest on November 3, 2004.

I've two bigger concerns here.  While they aren't changes which must 
be adopted, I think doing so would improve the document's readability 
a lot and help in clarifying its scope, so it might be worth the 
effort..

1)

The document is rather long and conversational in tone.  That's 
probably not a big problem, but I found it difficult to read, because 
there was not a clear structure in the document.  In particular, 
section 4.3 "Multi-homing: Identity Considerations" (which was 
discussing generic issues for further subsections) seemed ill placed 
to section 4.  More appropriate place for quite a bit of this 
discussion would be under section 5, possible under 5.3.2 in 
particular.

I'd like to reduce the amount of generic discussion in section 4, just
making it lay out the different approarches in sufficient detail, and
refer to the following sections for lengthier (and more structured)
discussion of the details.

There are also some rather long sections or long paragraphs, which 
could be split into more digestible pieces.  E.g., section 5.1 could 
possibly be split into subsections based on the approach.  That could 
give more structure and make the document easier to consume.

2)

I've griped before about this document not having enough 'truth in 
advertising', i.e., it says it describes the architectural approaches 
to multihoming in IPv6, but does not go in sufficient detail to e.g., 
traffic engineering possibilities (the mention of this has been 
sprinkled along the draft though).  Still, I think this is a bit of 
misleading and we should try to avoid this.  I'd just make it clearer 
that this document focuses on connection survivability and not the 
whole multihoming problem space.

How to go about this (just an idea):
 - a note at the end of section 3 (or after the list quoted from 3582) that
the focus is on ensuring connection survivability
 - rename section 4, Approaches to Multi-Homing, to include a note about
connection survivability and the like
 - note in section 4.1 that this also provides more than just conn. surv.
 - maybe some minor tweaks in the abstract, introduction and the title

mostly editorial
----------------

   In addition, [2] documents further considerations for IPv6
   multi-homing.  Again, the reader is referred to this document for the
   detailed enumeration of these considerations.  The general topic
   areas considered in this study include:
   o  interaction with routing systems,
   o  aspects of a split between end-point-identifier and forwarding
      locator,
   o  changes to packets on the wire, and
   o  the interaction between names, endpoints and the DNS.

==> does this call for minor edits to update to the latest think-about-...
organization?

   All transit providers for the site accept a prefix advertisement from
   the multi-homed site, and advertise this prefix globally in the
   inter-domain routing table.

==> s/accept/need to accept/ (a slightly different nuance)?

   The possible application of the MIPv6 protocol to the multihoming
   problem would be to use BU messages to convey information about
   alternative addresses to be used after the outage.

==> clarify: s/convey/convey prior to the outage/ ?

   the network.  IN the latter case there is also the consideration of

==> s/IN/In/

   IPSEC is necessary in this case, in order to avoid making changes to

==> s/IPSEC/IPsec/

   changes to the end-to-end interaction, as both endS of the

==> s/endS/ends/

  reasonable to assume that the identity assignation is not necessarily

==> s/assignation/assignment/ ?

6.1  Establishing Session State


      What form of token is passed to the transport layer from the upper
      level protocol element as an identification of the local protocol
      stack?
      What form of token is passed to the transport layer from the upper
      level protocol element as an identification of the remote session
      target?

==> could there be an empty line between the questions, so it would be more
readable ?

   [4]  Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E.
        Nordmark, "Mobile IP version 6 Route Optimization Security
        Design Background", Work in progress: Internet Drafts
        draft-ietf-mip6-ro-sec-01.txthttp://bgp.potaroo.net/ietf/idref/
        draft-ietf-multi6-things-to-think-abou, July 2004,
        <http://bgp.potaroo.net/ietf/idref/draft-ietf-mip6-ro-sec/>.

==> there's some crap here ('draft-ietf-multi6-things-to-think-abou').

10  Informative References

==> shouldn't some of these really be normative references ?


--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings