Subject: [6lowpan] Problem Statement Comments

From: "Timothy J. Salo" <[email-masked]>
Date: Mon, 06 Nov 2006 18:38:46 -0600

I read the Problem draft again, and therefore have some (admittedly
belated) comments.

Section 4.1, "IP Connectivity"

   If I were writing this section, I would focus on what we probably
   agree are our primary objectives. (I would probably also try to
   avoid specifying the solution in a requirements document).  I might
   write something like:

     The principal motivation for this work is to seamlessly
     interconnect 802.15.4 networks with IPv4 and IPv6 networks,
     including the Internet.

   I don't think this statement is made clearly and directly in
   this document, (or the charter, the last time I looked).

   The current text of this section, for the most part seems to focus
   more on why IPv6 was chosen as the solution, rather than on a
   strong statement that our objective is to interconnect 802.15.4
   networks with IP networks.  (Yes, the _last_ of the four bullets
   sort of implies this, but it feels like what should be the primary
   message was tacked on the end of some IPv6 justifications.)

Section 3. "Assumptions", Bullet 5.

   While it isn't politically correct to say so, I believe that
   there will be a device between IP networks and 802.15.4 networks
   that meets most reasonable definitions of a "gateway".  Nonetheless,
   it is true that the use of the IPv6-like protocols that are being
   discussed make the operation of this not-really-a-gateway fairly
   straight-forward and transparent.

Section 5. "Goals", Bullet 2.

   This would be a nice place to explain in a sentence or two why
   a stateless header compression technology is needed, and why
   ROHC isn't applicable.

- - - - - - - - - - -

A bunch of nits and diction complaints follow.

"Abstract"

   The abstract claims that "Additional goals may be found necessary
   over time and may be added to this document."  I don't understand
   how this document is going to be modified over time, particularly
   after it is an RFC.

1. "Introduction", First Paragraph

   It might make sense to include "limited computational power and
   limited memory" in this list.  While this is (sort of) implied by
   low cost and low power, these limitations are so fundamental to the
   work of the group that it might not hurt to be explicit about them
   in the first paragraph.

1. "Introduction", Second Paragraph

   I don't understand the term "IP and IPv6".  Assuming this isn't
   an editorial comment on IPv6, is this supposed to read "IPv4 and
   IPv6"?

   I'm not sure I like the phrase "enabling IP communications between
   devices in a LoWPAN" because I assume that our real interest is
   to enable IP communications between devices attached to 802.15.4
   networks and IP devices on _other_ networks, (as well as intra-
   802.15.4 communications).

   Have we identified any items that are not "necessarily appropriate
   tasks for the IETF"?  The purpose of this sentence is not clear
   to me.  Could this sentence be deleted?

2. "Overview", First Paragraph

   Yes, I know the 802.15.4 spec uses the term "relaxed throughput",
   but it still seems a bit affected to me.  "Limited bandwidth"
   seems a bit more direct, (but I warned earlier that this is the
   diction section...)

2. "Overview", Sixth Bullet

   "Limited processing power, limited memory, etc." might read better
   than "low processing, low memory, etc."  I might also delete the
   last sentence -- it doesn't really add much.

2. "Overview", Ninth Bullet

   This bullet seems to munge two ideas together: that connectivity
   may be unreliable and that devices may be be unreliable.  The
   bullet might read better if the ideas were stated separately,
   or maybe if the bullet focused on connectivity rather than devices.

2. "Overview", Tenth Bullet

   Perhaps, "In many environments, devices connected to a LoWPAN
   may sleep for long periods of time in order to conserve energy,
   and are unable to communicate during these sleep periods."

3. "Assumptions", Bullets

   I  might focus on the assumption that using IP technologies will
   simplify the interconnection of 802.15.4 networks and IP networks.
   This is sort of what the last paragraph says, my quibbles about
   the claim that a gateway won't exist notwithstanding.

   I don't really understand what the first bullet is trying to say.
   Perhaps, it would be more clear if a few examples were provided.

   I have some question about how applicable the fourth bullet is.
   Will I be able to ping a LoWPAN device?  Send it an SNMP GET?
   (This is where I will say that it would make a lot more sense
   for the we-can't-call-it-a-gateway to respond to these requests
   for the LoWPAN device.)

Section 4.2, "Topologies", Fourth Bullet

   The notion that many LoWPAN devices will sleep much of the time
   is a very important idea.  I would either make this the focus of
   the bullet, (e.g., move this sentence to the beginning of the
   bullet) or add a separate bullet that mentions it.

Section 4.2, "Topologies", Last Paragraph

   This is a very important paragraph.  Many of my comments try to
   emphasize the idea that we want to seamlessly integrate 802.15.4
   networks with IP networks.  However, this idea currently seems
   to be buried in this discussion of topologies.

Section 5, "Goals", Fourth Bullet

   "Ad hoc" is two words.  (OK, OK, this is pretty minor, but
   ad hoc networks are so closely related to this work that we at
   least ought to spell their name correctly...)

Section 5, "Goals", Seventh Bullet

   This is a very interesting topic.  I don't know whether we want
   to suggest changes to verbose higher-layer protocols or simply
   say "don't do that".  (When reviewing a specification document
   for a system that was going to operate in a wireless environment,
   I finally gave up and simply said, "just globally replace all
    instances of "XML good" with "XML bad".)

-tjs

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

---

From: Geoff Mulligan <[email-masked]>
Date: Mon, 06 Nov 2006 18:27:50 -0700

Timothy,
  The WG last call on the problem statement document has long since
closed.  That said, I think that a few of the editorial nits that you
point out could and should be addressed, though we need input from the
rest of the group as to which of your comments should be "fixed".

	geoff

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 8 Nov 2006 10:06:08 -0800

Tim,

I agree with Geoff's comments; we are a bit late with making major  
changes here.
Let me go through your comments point by point.
(Chair hat off.)

>   message was tacked on the end of some IPv6 justifications.)

IPv6 really needs to be motivated in the problem document.
Re IPv4: we have a clear charter to look at IPv6.
I don't think the proposed direction of change would lead to  
consensus quickly.

>   that meets most reasonable definitions of a "gateway".

In the original, 1974 sense: Yes (we now use the term router).

> Nonetheless,

Routers today do have more functionality than they had in 1974.  This  
does not make them mysterious gateway devices, just function-ful  
routers.
We do want to avoid the "gateway" in the sense that every application  
upgrade requires changes to the gateway.
I think this is what bullet 5 says.

>   a stateless header compression technology is needed, and why

Now you are in solution space.
The requirement is:
1) header compression
2) limited memory requirements.
In solution space, this leads to stateless HC as the immediate  
solution, with future enhancements possibly using stateful for things  
like TCP (which may or may not look similar to current ROHC profiles).

Good catch.
I propose we strike this sentence now.

>   work of the group that it might not hurt to be explicit about them

The intro need not necessary spell out the entire situation, but I  
agree that it would be good to add this.
Note that the sentence is about "IEEE 802.15.4 devices", though,  
which is really a statement about the radio, while your comment is  
about the device as a whole.  So this would be a new sentence about  
the expected characteristics of the devices.

>   I don't understand the term "IP and IPv6".

This does sound strange.

> Assuming this isn't

No.  This was meant to say "IP in general and IPv6 in particular".

>   802.15.4 communications).

So, maybe replace "between" with "with"?

>   to me.  Could this sentence be deleted?

The sentence could be improved.  The intention is to say that not all  
that needs to be done for "enabling..." can be done in the IETF, so  
we need to focus on the problems the IETF can work on.

>   Yes, I know the 802.15.4 spec uses the term "relaxed throughput",

No, not the throughput is relaxed, the requirements are.
Sentence can stay as is.

>   last sentence -- it doesn't really add much.

I find it useful to remind readers that Moore's law does apply.

>   or maybe if the bullet focused on connectivity rather than devices.

In the old Internet, the assumption was that devices were allowed to  
fail, but shouldn't too often.
In a LowPAN, the tradeoffs shift towards unreliable devices -- for  
the purposes of LowPAN, it does not make a big difference whether  
somebody steps on it or it just loses connectivity.

>   and are unable to communicate during these sleep periods."

Good new text.

>   Perhaps, it would be more clear if a few examples were provided.

It is trying to say that IP is already available in most  
environments, so it helps to use it.

>   for the we-can't-call-it-a-gateway to respond to these requests

The intention is that the LowPAN devices are IP nodes, with all that  
implies.  A "gateway" that "helpfully" generates fake ICMP replies is  
not always going to help.  (But, yes, optimizations are possible.)

>   bullet) or add a separate bullet that mentions it.

I read this bullet as saying exactly that.

>   networks with IP networks.

Actually, we integrate them *into* IP networks.
(This is a BIG difference.)

> However, this idea currently seems

Yes, again, if we had lots of time and editorial manpower, we could  
make this a better document.
But the consensus of the WG is appropriately caught.

>   "Ad hoc" is two words.

I'd prefer Ad-hoc (still two words) in the adjective position.

> (OK, OK, this is pretty minor, but

True, this is not something the format document can do on its own.
Further work will be required, and this may take both forms  
(simplifying or replacing existing protocols).
I agree this bullet is rather nebulous, but so is our understanding  
of our goals in this space.

In summary, I think there is some good editorial input here (thanks  
Tim!), but I don't see any reason to reopen discussion on existing  
consensus.
Depending on how we proceed with the most recent input on the format  
document, we may have time to incorporate that input.

(Chair hat on.)
I would prefer to do this in a way that does not require a new WGLC  
(i.e., editorial only).

Gruesse, Carsten

---

From: "Soohong Daniel Park" <[email-masked]>
Date: Thu, 9 Nov 2006 03:46:08 +0900

> I would prefer to do this in a way that does not require a new WGLC

Don't need to solicit a new WGLC. IESG will solicit IETF LC on the
IETF announcement, then we will be able to speak up if some issues
happen in our mind.

So, I agree with chairs' opinion at this stage.

Thanks,

-- 

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

---

From: "Schumacher Christian Peter Pii" <[email-masked]>
Date: Wed, 8 Nov 2006 22:26:59 +0100

6lowpanners.

I've made an editorial update of the problem document based on
post-Last-Call comments and put the it on the wiki (6lowpan.tzi.org). 

I would to like emphasize that this is only an editorial update and
hopefully shouldn't void conesensus.

Regards
Christian

-----Original Message-----
From: Soohong Daniel Park [mailto:[email-masked]] 
Sent: 8. november 2006 19:46
To: Carsten Bormann
Cc: [email-masked]
Subject: Re: [6lowpan] Problem Statement Comments

Thanks,

--

---

From: "Timothy J. Salo" <[email-masked]>
Date: Wed, 08 Nov 2006 18:11:51 -0600

> I'd prefer Ad-hoc (still two words) in the adjective position.

I also prefer a few things that are considered incorrect, at least
by standard American English, (e.g., I really think that punctuation
should generally follow the closing quote mark, rather than precede
it). However, I believe that it can quite reasonably be argued
"ad-hoc" is, in fact, wrong.

o	It conflicts with common [American] usage.

o	It conflicts with common IETF and research community
	usage, (although I believe that we have a least one RFC
	that presents a unique opinion about which bit is "bit 0",
	so maybe this isn't a strong argument...)

o	While I really like hyphens, I don't believe that
	introducing a hyphen in "ad hoc" reduces ambiguity,
	(which I think is the primary motivation for using
	hyphens in compound adjectives).

o	I don't carry a good dictionary when I travel, but I am
	pretty sure that current dictionaries say "ad hoc".
	I also understand that the dictionary punctuation takes
	precedence over more generation hyphenation rules.

o	I also don't carry a style manual when I travel, but I
	think that [American] hyphenation rules include a special
	clause for things like "ad hoc", (which says that they
	don't get hyphenated.

More than you every wanted to know,

-tjs

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 8 Nov 2006 16:26:14 -0800

The RFC editor will sort this one out.

Gruesse, Carsten