Subject: [6lowpan] New new charter text (resend)

From: Geoff Mulligan <[email-masked]>
Date: Fri, 13 Jun 2008 12:17:42 -0600

Folks, 
 [ I don't know whats up with the formatting so I'm resending this
message. ]

 I think that our charter will be discussed on the next IESG telechat,
next Thursday!  We need to get the text correct and to Mark WELL BEFORE
the Thursday.

JP has suggested a change to the wording for the Arch Doc draft item.

Please send a message indicating your thoughts about the change.

While I thought that we did have consensus around this particular item I
would like to make sure that we do.

Should we remove the text about mesh-under and route-over?

Should we leave the text as it is?

        geoff 

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 16 Jun 2008 10:52:14 +0200

Hi Geoff

I do agree with JP.

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Geoff Mulligan
>Sent: vendredi 13 juin 2008 20:18
>To: 6lowpan
>Subject: [6lowpan] New new charter text (resend)
>
>Folks,

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 16 Jun 2008 10:06:41 -0700

Hi Geoff,

Other folks and myself already respond to the following question
before in the mailing list.

> Should we remove the text about mesh-under and route-over?

IMHO, the answer is no.

The discussion of mesh-under and route-over concepts with respect to
IPv6-over-802.15.4 network is important for folks to understand the
over-all picture.

> Should we leave the text as it is?

Yes, please.

Thanks.
-Samita

---

From: JP Vasseur <[email-masked]>
Date: Mon, 16 Jun 2008 19:43:28 +0200

So at least can we agree to
(1) Have "some" high level text in the architecture ID
(2) A separate ID dealing with the subject and used to draw a consensus.

> Hi Geoff,

Other folks and myself already respond to the following
> question

IMHO, the answer is no.

The discussion of
> mesh-under and route-over concepts with respect to
IPv6-over-802.15.4 network
> is important for folks to understand the
over-all picture.

> the text as it is?

Yes,
> please.

Thanks.
-Samita
6low
> pan mailing 
> list
[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 16 Jun 2008 21:22:10 +0200

> (2) A separate ID dealing with the subject and used to draw a  

(Assuming you mean on the question of L2 forwarding yes [mesh-under]  
or no [route-over]:)

As I said, I'm not sure we are even getting any closer to a consensus.
Why should the WG try to make that decision?  Why now?  (This is not  
just a rethorical question!)

Gruesse, Carsten

---

From: JP Vasseur <[email-masked]>
Date: Tue, 17 Jun 2008 16:55:34 +0200

Hi Carsten,

> just a rethorical question!)

Just because it may not be a bad idea to close on this if you do not want
this topic to pop again in a few month but if you think that this is not
necessary, fine ...

JP.

---

From: Geoff Mulligan <[email-masked]>
Date: Tue, 17 Jun 2008 14:16:32 -0600

So then can we agree that the charter text can stand as it was sent out
on 13 June.

Anyone not agreeing?

	geoff

---

From: JP Vasseur <[email-masked]>
Date: Wed, 18 Jun 2008 11:58:40 +0200

Hi Geoff,

> So then can we agree that the charter text can stand as it was sent out

Well I do not see a consensus here ... Looking at the emails on the subject,
2 in favor, 2 opposed.

My proposal.

Original text:
3. Produce "6LoWPAN Architecture" to describe the design and
implementation of 6LoWPAN networks.  This document will cover the
concepts of "Mesh Under" and "Route Over", 802.15.4 design issues such
as operation with sleeping nodes, network components (both battery-
and line-powered), addressing, and IPv4/IPv6 network connections.
As a spin-off from that document, "6LoWPAN Routing Requirements" will
describe 6LoWPAN-specific requirements on routing protocols used in
6LoWPANs, addressing both the "route-over" and "mesh-under" approach.
Both documents will be informational.

I see that some people want to see the concept of mesh-under and route over
covered in the architecture document, fine (although it looks pretty
straightforward).

The text I'm disagreeing with is:

" As a spin-off from that document, "6LoWPAN Routing Requirements" will
describe 6LoWPAN-specific requirements on routing protocols used in
6LoWPANs, addressing both the "route-over" and "mesh-under" approach.
Both documents will be informational."

Why a spin-off ? Make it a separate ID in the first place. Requirements
should NOT be discussed in architecture ID. Furthermore, I would slightly
reword, remove "addressing both the "route-over" and "mesh-under" approach.
And mention that the document will be owned by 6owpan and reviewed by ROLL.

Does it make sense ?

Thanks.

JP.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 18 Jun 2008 13:16:55 +0200

> Why a spin-off ?

Sorry, this was poor wording on my part.

> Make it a separate ID in the first place.

That is what is intended.

s/As a spin-off from that document/As a separate I-D/
Give that number 4, and move 4 and 5 to 5 and 6.
Add "This document will be informational." at the end of 3, and change  
"Both documents will be informational." to "This document will be  
informational." at the end of 4 new.

> Requirements
> should NOT be discussed in architecture ID.

Fine. (Hope that is fixed by the change above.)
[As a side note, there are things that are called "architectural  
requirements" (1).]

> Furthermore, I would slightly

I think this is implicit, so the verbiage is just redundant  
specificity, but I would like to keep it in order to not rehash this  
discussion every month.

> And mention that the document will be owned by 6owpan and reviewed  

Saying that explicitly won't hurt; I agree.

Add
"This document will be owned by the 6LOWPAN WG and developed in close  
cooperation with the ROLL WG." after "approach".

Are we done now?

Gruesse, Carsten

(1) See, e.g., http://www.ibm.com/developerworks/rational/library/4706.html 
  for a systematic approach to architectural requirements.