Re: [Gen-art] re-review of draft-ietf-mipshop-pfmipv6-11.txt

2009-12-28 Thread Hidetoshi Yokota
Hi Jari and Francis,

I understand that some abbreviations familiar to me are not necessarily
so to others. In the latest document (v12), MN and LMA are spelled out
as mobile node and local mobility anchor as many as possible. Also,
the itemized descriptions for Figures 2 and 3 in Section 4.1 use more
unabbreviated words.

Apologize for this delay, but the latest version was submitted earlier
as v12. Hope that the readability has improved even a bit...

Regards,
-- 
Hidetoshi

Jari Arkko wrote:
 Francis,
 
 = BTW I am familiar with most of these abbrevs (I worked a lot in Mobile
 IPv6 area) but it is just a matter of taste: the abuse of abbrevs is
 IMHO a bad style for a written text. And this includes the use English
 words the first time, introduce abbrevs and use them in place of plain
 English after.
 
 I agree, by the way. We can, of course, WR (Write) TXT (Text) with ABs 
 (Abbreviations) but it just produces HTRT (Hard To Read Text). Its so 
 much easier to just say the mobile node or the home agent than use 
 one of the abbreviations.
 
 (And I'm not demanding this conversion be done for the current document. 
 But I find many of the documents that I see a little overusing the 
 abbreviations.)
 
 Jari
 
 
 
 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art


Re: [Gen-art] re-review of draft-ietf-mipshop-pfmipv6-11.txt

2009-12-13 Thread Jari Arkko

Francis,


= BTW I am familiar with most of these abbrevs (I worked a lot in Mobile
IPv6 area) but it is just a matter of taste: the abuse of abbrevs is
IMHO a bad style for a written text. And this includes the use English
words the first time, introduce abbrevs and use them in place of plain
English after.


I agree, by the way. We can, of course, WR (Write) TXT (Text) with ABs 
(Abbreviations) but it just produces HTRT (Hard To Read Text). Its so 
much easier to just say the mobile node or the home agent than use 
one of the abbreviations.


(And I'm not demanding this conversion be done for the current document. 
But I find many of the documents that I see a little overusing the 
abbreviations.)


Jari

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art


Re: [Gen-art] re-review of draft-ietf-mipshop-pfmipv6-11.txt

2009-12-11 Thread Francis Dupont
 In your previous mail you wrote:

   Now I see what gave you a pain... A series of unfamiliar abbreviations
   may hamper readability. Please take a look at the following style. The
   key words below are spelled out:
   
= BTW I am familiar with most of these abbrevs (I worked a lot in Mobile
IPv6 area) but it is just a matter of taste: the abuse of abbrevs is
IMHO a bad style for a written text. And this includes the use English
words the first time, introduce abbrevs and use them in place of plain
English after.
Please note it is a matter of taste and I am not against the use of
abbrevs, just against the abuse.

Regards

francis.dup...@fdupont.fr

PS: I apologize for the delay (travel, mail server crash, ...)
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art


Re: [Gen-art] re-review of draft-ietf-mipshop-pfmipv6-11.txt

2009-12-03 Thread Hidetoshi Yokota
Hello Francis,

Now I see what gave you a pain... A series of unfamiliar abbreviations
may hamper readability. Please take a look at the following style. The
key words below are spelled out:

MN - mobile node
P/N-AN - previous/new access network
P/NMAG- previous/new MAG
etc.

If the revised style is acceptable, we will revise the whole document as
such.

 excerpt from Section 4.1 ===
   (a)  The mobile node detects that a handover is imminent and reports
the identifier of itself (MN ID) and the New Access Point
Identifier (New AP ID) [RFC5568] to which the mobile node is
most likely to move.  The MN ID could be the NAI or a Link Layer
Address (LLA), or any other suitable identifier.  This step is
access technology specific.  In some cases, the previous access
network (P-AN) will determine which AP ID the mobile node is
moving to.

   (b)  The previous access network, to which the mobile node is
currently attached, indicates the handover of the mobile node to
the previous mobile access gateway (PMAG).  Detailed definition
and specification of this message are outside the scope of this
document.

   (c)  The previous MAG sends the Handover Initiate (HI) message to the
new mobile access gateway (NMAG).  The HI message MUST have the
P flag set and include the MN ID, the HNP(s) and the address of
the local mobility anchor (LMA) that is currently serving the
mobile node.  If there is a valid (non-zero) MN Link-layer
Identifier (MN LL-ID), that information MUST also be included.
With some link layers, the MN Link-local Address IID (MN LLA-
IID) can also be included (see Section 6.2.3).

   (d)  The new MAG sends the Handover Acknowledge (HAck) message back
to the previous MAG with the P flag set.

   (e)  If it is preferred that the timing of buffering or forwarding
should be later than step (c), the new MAG may optionally
request the previous MAG at a later and appropriate time to
buffer or forward packets by setting U flag [RFC5568] or F flag
in the HI message, respectively.

   (f)  If the F flag is set in the previous step, a bi-directional
tunnel is established between the previous MAG and new MAG and
packets destined for the mobile node are forwarded from the
previous MAG to the new MAG over this tunnel.  After
decapsulation, those packets may be buffered at the new MAG.  If
the connection between the new access network and new MAG has
already been established, those packets may be forwarded towards
the new access network, which then becomes responsible for them
(e.g., buffering or delivering depending on the condition of the
mobile node's attachment); this is access technology specific.

   (g)  The mobile node undergoes handover to the new access network.

   (h)  The mobile node establishes a physical link connection with the
new access network (e.g., radio channel assignment), which in
turn triggers the establishment of a link-layer connection
between the new access network and new MAG if not yet
established.  An IP layer connection setup may be performed at
this time (e.g., PPP IPv6CP) or at a later time (e.g., stateful
or stateless auto address configuration).  This step can be a
substitute for the Unsolicited Neighbor Advertisement (UNA) in
[RFC5568].  If the new MAG acquires a valid new MN LL-ID via the
new access network and a valid old MN LL-ID from the previous
MAG at step (c), these IDs SHOULD be compared to determine
whether the same interface is used before and after handover.
When the connection between the mobile node and new MAG is PPP
and the same interface is used for the handover, the new MAG
SHOULD confirm that the same interface identifier is used for
the mobile node's link-local address (this is transferred from
previous MAG using the MN LLA-IID option at step (c), and sent
to the mobile node during the Configure-Request/Ack exchange).

   (i)  The new MAG starts to forward packets destined for the mobile
node via the new access network.

   (j)  The uplink packets from the mobile node are sent to the new MAG
via the new access network and the new MAG forwards them to the
previous MAG.  The previous MAG then sends the packets to the
LMA that is currently serving the mobile node.

   (k)  The new MAG sends the Proxy Binding Update (PBU) to the LMA,
whose address is provided in (c).  Steps (k) and (l) are not
part of the fast handover procedure, but shown for reference.

   (l)  The LMA sends back the Proxy Binding Acknowledgment (PBA) to the
new MAG.  From this time on, the packets to/from the mobile node