IESG Review: draft-ietf-seamoby-mobility-terminology (Re: ID Tracker State Update Notice)

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 before submitting revision - see 3.

Is the next to last point in 4 below, the Ops-Dir review (source route including
loose source routes) any problem?  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 AD:  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.

  [Note from AD:  OPS AD and I agree there is no action to take
   on this point, just FYI].

    
------- End of Forwarded Message