Re: Fw: ID Tracker State Update Notice: draft-ietf-seamoby-mobility-terminology

Hi Allison,

Thanx for posting the IESG review. I will forward the IESG comments to Jukka
(who should actually have seen them since he's on the list but just to make
sure) for incorporation into the document. Also, Jukka and I will
co-ordinate asking Henrick to do a review for us. We will ask for a 10 day
turnaround as suggested.

I believe Thierry Ernst had a few comments from the NEMO perspective that
Jukka also needs to consider.

            jak


----- Original Message ----- 
From: "Allison Mankin" <[email protected]>
To: "James Kempf" <[email protected]>
Cc: <[email protected]>
Sent: Thursday, November 20, 2003 4:30 PM
Subject: Re: [Seamoby] Fw: ID Tracker State Update Notice:
draft-ietf-seamoby-mobility-terminology


> Hi, Folks,
>
> Jim sent the state change, but caught the tracker before I got to enter
any
> notes about today's telechat (TSV had a lot of documents).  Here forthwith
the
> report on the issues that came up on the document today.  Now Jim can
follow up
> on each point with the editors (if there are any ADish questions, don't
hesitate to
> ask), and shepherd the document through a quick, limited new rev.  One
review to come
> before the revision, so wait for that - see 3.
>
> Is the next to last point in the 4. Ops-Dir review (about source route
including
> loose source routes) any issue?  I think it should not be.   Other than
that
> item in 4, and 2, the points below do not challenge content.
>
> 1. Mostly the document is viewed as useful.  It was noticed
>    that both nemo and mipshop WGs are using it and view it as valuable.
>
> 2. Section 4.9 (user mobility etc.) is viewed as weak and* not needed
>    for the mission the document.  Because it touches on WGs such the
geopriv
>    (mentioning location tracking) and would be hard to get right even with
>    much involvement by Apps WGs, the suggestion is for this section to be
>    dropped.  I think this is a very good suggestion.
>
> 3. Thomas Narten thought that a very focused single additional review
>    by Henrik Levkowetz (co-Chair of the MIP4 WG) would dot the i's of
>    inter-WG checking - Thomas thought there might be a few considerations
>    seen from the Mobile IPv4 point of view that might come out of this
>    review, but he asked Henrik for this review to be done expeditiously.
>    Communicating with Henrik directly on this is correct, both to ask
>    for it (Jim, it's expected before 10 days) and to interact on it.
>    One last point:  as discussed in the plenary, we could do better
>    than to have such cross-checking review happen as late as IESG
>    review - discussions started on this!  But by the direct
>    communication of Jim/editors with Henrik, let's keep it short in time.
>
> 4. A review from the Operations Directorate found the following small
issues:
>
> - appendix B says it should list all the terms ("index"), but doesn't.
>
>     [Note from me:  you could leave out Appendix B]
>
> - s/Author's Addresses/Authors' Addresses/
> - to align better with the previous definition rephrase:
>
>        In a vertical handover the mobile node's network interface to the
>        access network changes.
>
>  to:
>
>        A handover in which the mobile node's network interface to the
>        access network changes.
>
>  (similar elsewhere as well..)
> ...
>
> - there is inconsistancy of capitalizing in sections 4.2, 4.5, 4.6,
> 4.9;  the definitions should start with capital letters, like the rest
> of the spec.  Clearly a result of merging definitions from someone
> else without properly integrating them?
>
> - section 4.6 starts by referring to Mobile Nodes, but the definitions
> at places describe Mobile Hosts.  Suggest replacing the latter with
> MN's.  Should probably grep -i for "host" or "MH" and check if these
> are valid..?
>
> - s/authentication/authenticate/ in sect 6, "Security context"
>
>
> Content:
>
>      Source Route
>       A source route from node A to node B is an ordered list of IP
>        addresses, starting with the IP address of node A and ending with
>        the IP address of the node B. Between A and B, the source route
>        includes an ordered list of all the intermediate hops between A
>        and B, as well as the interface index of the interface through
>        which the packet should be transmitted to reach the next hop.
>
> ==> this is a stricter definition of Source Route than is usual.
> Normally SR includes ("Loose SR") the possibility to omit intermediate
> hops.  Consider clarifying.
>
> ...
>
> "IP access address" is also a funny term, I probably wouldn't use it,
> but I have no more serious problems with it:
>
>      IP access address
>        An IP address (often dynamically allocated) which a node uses to
>        designate its current point of attachment to the local network.
>        The IP access address is typically to be distinguished from the
>        mobile node's home address; in fact, while visiting a foreign
>        network the former may be considered unsuitable for use as an
>        end-point address by any but the most short-lived applications.
>        Instead, the IP access address is typically used as the care-of
>        address of the node.
>
>
>
>