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

From: Allison Mankin <[email-masked]>
Date: Thu, 20 Nov 2003 17:30:26 -0800

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

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 21 Nov 2003 15:24:12 +0900

Hi,

A few more minor comments, if it's not too late:

- I would add "HoA" next to the term "Home Address" as this is done in
Care-of Address (CoA).

- a question concerning the term "link" was left unanswered. I attach
the mail. I also had interest into clarifying.

- a definition about what a subnet is may be useful since the term is
used in many places in the document.

- Mobile Node (MN)
       An IP node capable of changing its point of attachment to the
       network. A Mobile Node may or may not have forwarding
       functionality.

  -> I would add "MR" and "MH" in it:       

      An IP node capable of changing its point of attachment to the     
      network. A Mobile Node may either be a Mobile Host (no forwarding
      functionality) or a Mobile Router (forwarding functionality).

      or mention something about forwarding functionality in defs of MH and MR.

- Mobile Host (MH) 
  "....  A Mobile host..." -> capitalize Host.

- Mobile Router (MR)    

  In the middle paragraph, I would recommend to move the sentence about
"ingress interface" and the one about "egress interfaces" as standalones
definitions. Those 2 terms are extensively used in NEMO WG. The last
paragraph shall be kept under the definition of MR.

- Network mobility
  -> I would add something similar to first sentence of "host mobility"

  refers to the function of allowing an entire network to change its    
 point of attachment to the network, and thus its reachability in the
topology, without interrupting IP packet delivery to/from that mobile network.

And, as long as we are using the term "function" into the definition of
either "host mobility" or "network mobility", it would make sense to add
the word "support" to both terms:

-> replace "Host Mobility" with "Host Mobility Support" and "Network
Mobility" with "Network Mobility Support".

E.g: I don't have any support function on my laptop, so by doing host
mobility I cannot maintain sessions. It's the fact that I do have "host
mobility support" abilities that my sessions do not break.

Thierry.