Subject: [Seamoby] Re: I-D ACTION:draft-ietf-seamoby-mobility-terminology-03.txt

From: Jukka MJ Manner <[email-masked]>
Date: Sat, 5 Apr 2003 12:50:03 +0300 (EEST)

Hi Randy,

thank you for this very thorough review - it was awful to read how many 
mistakes the draft has...:) All points noted and will be dealt with in the 
future version. Thank you.

Charlie, can you comment on the Section 2 issues and definitions?

Regards,
Jukka

On Fri, 4 Apr 2003, Randy Presuhn wrote:

> Hi -
> 
> A couple of nits jumped out at me from
> draft-ietf-seamoby-mobility-terminology-03.txt,
> please ignore if you think I'm hallucinating.
> 
> Section 1, first paragraph:
>     "could like take" -> "could take"
> 
> Section 1, second paragraph:
>     "terminology, for" -> "terminology.  For"
> 
> Section 2, "Bandwidth" should be expressed as information carrying
>     capacity PER UNIT TIME.  Without the time dimension, it's not
>     bandwidth.
> 
> Section 2, "Bandwidth Utilization" neglects link overhead.  The current
>     definition sounds closer to "goodput".
> 
> Section 2, "Channel Access Protocol" the second sentence seems to conflict
>     with the previous definition.  The phrase "uncontested access to the
>     medium" doesn't seem to be quite right for FDMA or CDMA, for example.
>     Same comment applies to the MAC definition.  Perhaps the distinction
>     between "channel" and "medium" should be more rigorously observed.
> 
> Section 2, "Fairness" sounds like it means to say something like "fairly
>     available" instead of "fairly equal"
> 
> Secton 2, "Mobility Factor": so the units would be moves per initiation?
>     (rather than something like pdu, exchange, or transaction)  What does
>     this mean for connectionless protocols like SNMP?
> 
> Section 2, "Neighbor": "forwarding node" -> "forwarding node."
> 
> Section 2, "Payload": "Note," -> "Note"
> 
> Section 3, first paragraph: "a set of nodes form" -> "a set of nodes forms"
> 
> Section 3, first paragraph: "The Figure 1" -> "Figure 1"
> 
> Section 3, second paragraph: "i.e." -> "e.g."
> 
> Section 3, second paragraph: "ANR" is introduced without expansion
> 
> Section 4.1: the distinction between "horizontal handover" and
>      "layer 2 handover" isn't clear.  An example illustrating the
>      difference might be useful.
> 
> Section 4.2: The intent here is to characterize all handovers
>      in five dimensions (a-e)?  The use of "may be" in (c) where
>      the others use "is" seems odd.
> 
> Section 4.2 (c): so "mutual assistance" isn't possible?  :-)
> 
> Section 4.4, "Goodput": this is an unusual way of defining it.
>      This definition would count bandwidth used by packets dropped
>      due to CRC errors as "goodput".  Is that really the intent?
> 
> Section 4.5: "UTRAN FDD" used without expansion.
> 
> Section 4.5: "the splitting" -> "The splitting"
> 
> Section 4.6:  (bottom of page 18)  Where's the rest of the sentence
>      beginning "The term"  ?  :-)
> 
> Section 4.6, "Active State": "when" -> "When"
> 
> Section 4.6, "Time-slotted Dormant Mode": is the extra indentation
>      deliberate?  The following text refers to three states, which would
>      suggest that it is, but the layout looks odd nonetheless.  I'd suggest
>      moving it into the "additional defintions" that immediately follow.
> 
> Section 4.5, "Paging" and "Location updating": "a procedure" -> "A procedure"
> 
> Section 4.8: "to which MN is currently attached to" ->
>              "to which MN is currently attached"
> 
> Section 4.9: "means, the", "means the"
> 
> Section 4.9, last paragraph: "LMM messages itself are not" ->
>      "LMM messages are not"
> 
> Section 4.9, last paragraph: "although," -> "although"
> 
> There's no IPR section...  No trademarks, etc. in this area?
> 
> Section 10: if this is planned for eventual RFC publication,
>    this should be split into normative and informative references
> 
> Section 10: the format for entries should follow that used in
>      <draft-rfc-editor-rfc2223bis-04.txt> (Note the order of
>      names and initials in lists follows common bibliographic
>      practice, strange though it may be.)
> 
> Section 11: there's a superfluous ")" in one of the email addresses.
> 
> Section 12.a.1:  "GSM", "EMA", "WLAN", "PLMN". "UMTS" aren't expanded
> 
> Section 12.a.2: "TDMA", "W-CDMA", "CDMA" aren't expanded
> 
> Section 12.a.3: "RNC" that isn't Republican National Committee, is it?
> 
> Section 12.a.4: GPRS? GGSN?
> 
> Section 12.a.4: "components (see Figure 1."  -> "components.  (See Figure 1.)"
> 
> 
> Randy
> 
> 
> 

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 22 Apr 2003 14:38:26 -0700

Hello Jukka and Randy,

A bit late, but...

Does it really say "Universty of elsinki"?

> >     capacity PER UNIT TIME.  Without the time dimension, it's not

Correct!

> >     definition sounds closer to "goodput".

A better definition would be:

       The actual rate of information transfer achieved over a link, expressed
       as a percent of the available bandwidth on that link.
 
> >     between "channel" and "medium" should be more rigorously observed.

How about:
       A protocol for mediating access to, and possibly allocation of,
       the various channels available within the physical communications
       medium.  Nodes participating in the channel access protocol agree
       to communicate only when they have uncontested access to one of
       the channels, so that there will be no interference.

> >     available" instead of "fairly equal"

Correct.

> >     this mean for connectionless protocols like SNMP?

The definition is as I understand it to be commonly
used, but it does make the mobility factor to be
application dependent.  I guess the terminology could
be replaced or deleted, but it is often used, and is
meaningful so I hope it can be kept even if not very
precise by this criterion.  Higher "mobility factor"
is seen to correlate with more  benefit from better
handovers.  Higher.  More.  Better.  Yes.

No, I haven't joined the marketing dept.

> > Section 2, "Payload": "Note," -> "Note"

These are fine with me!

Regards,
Charlie P.