Subject: [Seamoby] Fw: ID Tracker State Update Notice: draft-ietf-seamoby-mobility-terminology

From: "James Kempf" <[email-masked]>
Date: Thu, 20 Nov 2003 15:35:18 -0800

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

> 'State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation
by Amy Vezza'
> ID Tracker URL:
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=9277&rfc_flag=0

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

---

From: Allison Mankin <[email-masked]>
Date: Thu, 20 Nov 2003 16:30:15 -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 - 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.

---

From: "James Kempf" <[email-masked]>
Date: Fri, 21 Nov 2003 10:28:17 -0800

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-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, November 20, 2003 4:30 PM
Subject: Re: [Seamoby] Fw: ID Tracker State Update Notice:
draft-ietf-seamoby-mobility-terminology

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 26 Nov 2003 12:48:39 +0200 (EET)

Hi all,

I am doing the final edits to the terminology draft, and I would need 
answers to the following questions raised by the IESG and Thierry Ernst in 
a separate email.

Jukka

1) What would be the definition of a subnet? Thierry thought one should be 
added.

2) The definition of source route?

     Source Route

Allison: This is a stricter definition of Source Route than is usual.
Normally SR includes ("Loose SR") the possibility to omit intermediate
hops.  Consider clarifying.

[JM]: Suggestion to remove "all the", and add at the end "The list of 
intermediate hops might not include all visited nodes, some hops might 
be omitted for a reason or another."

3) Is the definition of "link" sufficient? Does it need to be very
detailed? There was this email quite some time ago:

<SNIP>

Hi,

I have a question about the definition of "link" in

draft-ietf-seamoby-mobility-terminology-04.txt

It is said:

"A communication facility or physical medium that can sustain data
communications between multiple network nodes, such as an
Ethernet (simple or bridged). A link is the layer immediately
below IP."

As I undestand, the definition of link is not directly related to an
IPv6 link.
For example, consider the following example:

One ethernet link where a router advertises a single IPv6 prefix, and an
802.11b access point connected to this ethernet link as illustrated here:

         AR
   ____ |__________________
                |                         |
             AP                     Fixed node
                         MN2
 MN1

In this situation, is it right to say that :
    - there are 2 links
and
    - there is one IPv6 link
?

Thanks

Regards,
Nicolas

</SNIP>

[JM]: (don't know how the figure was meant to be formatted...) Isn't an
802.11b AP just a wireless bridge between the AR/FN and MN1, and, thus,
not its own link? Still, you could say there are two links and one "IPv6 
link", for example. Comments?

4) Do we need an index of terms (Appendix B)?