Hi Lloyd:
There is some history in the ML about UDP checksum compression and
ISA100.11a.
On 3/3 I wrote:
"
Per RFC 4944:
"The UDP header's checksum field is not compressed and is therefore
carried in full."
The UDP checksum is not the only way to protect the IP pseudo header,
the UDP header and the payload.
ISA 100.11a is defining a transport-level security that does all this
and more, since it has a larger signature and provides mutual
authentication at the same time.
Also, the ISA100.11a transport-level security is usually
hardware-assisted, so it requires little power or CPU time on the field
device, whereas UDP checksum will be a costly CPU operation.
So ISA100.11a is an example where the UDP checksum could and actually
should be compressed over the LoWPAN, leaving it up to be reconstructed
by a backbone router should the packet go any further than the LOWPAN
itself.
Since bit 3 in the HC-UDP header is reserved anyway, it makes sense to
standardize it to mean that the UDP checksum is compressed, provided
that the headers and payload are equally or better protected than if the
checksum was used.
"
Then followed a thread entitled:
"[6lowpan] Compressing the UDP checksum"
In short, there was a general agreement that this was doable under
circumstances; In particular, the current draft under review of
ISA100.11a transport section (under review) has the following text:
"
1.4.3 Eliding the UDP checksum
ISA100.11a uses both HC1 and HC2, and extends the UDP common compressed
header encoding to compress the UDP upper layer checksum by relying on
the Transport layer security to provide the same service, and more.
For that purpose, the Transport layer builds an ISA100.11a pseudo-header
by concatenating the UDP pseudo-header for IPv6 as described in the
previous section, the source UDP port and the destination UDP port:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upper-Layer Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source UDP port | Destination UDP port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ISA100.11a pseudo-header is filled and placed before the UDP payload
for the crypto process. If encryption is performed on the message, the
pseudo-header is not encrypted, but the pseudo-header is part of the MIC
in any case.
Once the crypto process is completed, the pseudo-header is removed from
the message, and the IP and UDP headers are put in its place for
transmission. On the receiving side, the transport layer will restore
the pseudo-header based on the received packet prior to the crypto
process to validate that none of the protected fields was tempered with.
When HC2 is applied, bit 3 in the UDP common compressed header encoding,
which is reserved in RFC 4944, is set to express whether the checksum is
elided. When so, the 8 bytes of UDP header can be compressed down to a
single byte that contains the partially compressed ports, using 4 bits
each.
Note 1: When the packet is not protected by the Transport layer
security, the UDP checksum can not be compressed and must be carried in
full as prescribed by RFC 4944. If Transport Layer Security is active
for a given packet, then the UDP checksum might be elided as prescribed
above.
Note 2: If the UDP upper layer checksum field is elided, it is up to
the other endpoint across the DLL subnet to recompute the UDP checksum
as part of the 6LoWPAN expansion, if necessary. This is required in
particular for a middlebox such as a backbone router that forwards the
uncompressed packet as opposed to terminating the transport.
Note 3: If the UDP checksum is not elided and security is applied, then
the UDP checksum must be computed after the security operation is
complete and the security fields are filled. The UDP payload that is
used for the UDP checksum includes all data from the UDP header on,
including the security fields, application data and MIC fields, whether
the application data is encrypted or not.
"
This proposal provides better guarantees than the UDP checksum alone.
Part of it because the security signature is longer and the UDP
checksum, and part of it because that security authenticates the data as
well.
Would you agree that compressing the UDP checksum is valid in this case?
Pascal
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Lloyd Wood
>Sent: lundi 9 juin 2008 21:28
>To: Mark Townsley (townsley)
>Cc: Geoff Mulligan; [EMAIL PROTECTED]; Jay Werb; Polyzois,Christos A;
Chernoguzov,Alexander (PA35);
>6lowpan@ietf.org
>Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements(was
RE: New charter for 6lowpan)
>
>
>On 9 Jun 2008, at 17:34, Mark Townsley wrote:
>
>> Geoff Mulligan wrote:
>>> Mark,
>>> this is interesting news. This can save another byte and if there
>>> would be no large push against this then compressing out another
byte
>>> would be good.
>>>
>> I can't promise anything, but 6lowpan certainly isn't the only place
>> where the UDP checksum mandate in IPv6 is seen as unworkable. Pretty
>> much any UDP-based tunneling protocol running on a router in
>> hardware at
>> high scale or speeds is running into the same problem.
>
>The pseudo-header checksum is the only thing preventing misdelivery;
>the header gets checked once at the endpoint (IPv6) as opposed to
>being checked and recomputed at every hop (IPv4).
>
>I'm not convinced that the IPv6 design choices here were right - I'd
>have gone for a header checksum across immutable fields, skipping TTL,
>CoS and the like, that wouldn't require recomputing, and which would
>have constrained misdelivery to a single link, rather than the path -
>this would be more useful for resends and diagnostics, while
>increasing the pain for NAT. Here, IPv6 assumes a tight application/
>application control loop and path where the cost of resending a packet
>across the entire path is low.
>
>That raw IPv6 header tunnelling sans UDP header (or GRE sans optional
>checksum or MPLS) lacks any self-checking mechanism for reliability
>should be of some concern.
>
>RFC2460 p28 section 8.1 Upper-Layer Checksums:
>
>[..]
>o Unlike IPv4, when UDP packets are originated by an IPv6 node, the
>UDP checksum is not optional. That is, whenever originating a UDP
>packet, an IPv6 node must compute a UDP checksum over the packet and
>the pseudo-header, and, if that computation yields a result of zero,
>it must be changed to hex FFFF for placement in the UDP header. IPv6
>receivers must discard UDP packets containing a zero checksum, and
>should log the error. ^^^^
>[..]
>
>That 'must' is clear and unambiguous. The side-effects mean that this
>should NOT be thought of as an optimization.
>L.
>
>> I know of
>> implementations today that zero out the UDP checksum, and IMHO a good
>> implementation that is "liberal in what it accepts" would not drop
the
>> packet with a zero UDP checksum arriving over IPv6 (in fact, its
>> annoying that one would even have to differentiate between IPv4 and
>> IPv6
>> at all here if you ask me).
>>> This is currently in the HC1g draft and would allow consistency
>>> between
>>> 6lowpan and SP100.
>>>
>> I suppose that isn't a bad thing.
>>
>> - Mark
>>> geoff
>>>
>>> On Mon, 2008-06-09 at 17:25 +0200, Mark Townsley wrote:
>>>
>>>> Geoff Mulligan wrote:
>>>>
>>>>> Aren't both abstractions equally valid? I think that the biggest
>>>>> issue
>>>>> with a mesh under is that there is no one standard for it.
>>>>> ISA100 is
>>>>> one; I have done another using AODVtiny; I think Jennic has one
>>>>> using
>>>>> their mesh protocol and there are others. If IEEE had defined a
>>>>> multi-hop L2 mesh then we could point at that and define a
>>>>> solution for
>>>>> ND and bootstrapping and security and ... for it.
>>>>>
>>>>> The WG decided a couple of meetings ago that we would focus on
>>>>> solutions
>>>>> for the Route Over abstraction. [If while we are doing this we
>>>>> can keep
>>>>> in mind some of the issues w.r.t. mesh under that's good.]
>>>>>
>>>>> Somewhat independent from this is the HC1G draft that is
>>>>> important to
>>>>> deal with since we do need a way to efficiently handle non-local
>>>>> addresses. So as to remove the mesh under vs. route over issues
>>>>> from
>>>>> the HC1G draft I would like to see the draft updated to remove
>>>>> the UDP
>>>>> checksum optimization.
>>>>>
>>>>>
>>>> I'm more optimistic about keeping the UDP checksum optimization.
>>>> There
>>>> are other forces at work which may relax the UDP checksum
>>>> requirement in
>>>> IPv6 in certain cases. So as long as you have well thought out
>>>> reasoning, I wouldn't be afraid of keeping it in.
>>>>
>>>> - Mark
>>>>
>>>>> I would like to ask the WG if we should consider taking
>>>>> draft-hui-6lowpan-hc-00.txt on a a WG document, with the change of
>>>>> removing the UDP checksum compression.
>>>>>
>>>>> geoff
>>>>>
>>>>> On Thu, 2008-05-22 at 09:14 -0700, Jonathan Hui wrote:
>>>>>
>>>>>
>>>>>> Hi Pascal,
>>>>>>
>>>>>> So let's drop the mesh-under/route-over terminology for a
>>>>>> second, I
>>>>>> think they are confusing since everyone seems to have a different
>>>>>> definition for those terms.
>>>>>>
>>>>>> What I am mainly concerned about is the kind of IP Link
>>>>>> abstraction
>>>>>> 6LoWPAN provides: (i) an IP Link is formed by multiple L2 hops
>>>>>> (e.g.
>>>>>> 802.15.4 and possible others through a BbR), what I've been
>>>>>> calling
>>>>>> mesh-under (ii) an IP Link is defined by a single L2 hop (e.g.
the
>>>>>> radio range of 802.15.4), what I've been calling route-over. My
>>>>>> point
>>>>>> to Mark's concern was that solutions to some work items within
>>>>>> 6LoWPAN
>>>>>> will be different depending on our IP Link abstraction. From
>>>>>> what I
>>>>>> understand, ISA100.11a has chosen option (i). But to your point
>>>>>> below,
>>>>>> using IP routing to provide connectivity between nodes within
>>>>>> the same
>>>>>> IP Link doesn't seem right to me, so it'd be great if you could
>>>>>> help
>>>>>> me see a path to get there.
>>>>>>
>>>>>> A lot of this confusion can be cleaned up within the 6LoWPAN
>>>>>> architecture document. But I think Mark's concern still stands:
>>>>>> whether or not we're focused on one or both of these IP Link
>>>>>> abstractions.
>>>>>>
>>>>>> --
>>>>>> Jonathan Hui
>>>>>>
>>>>>> On May 22, 2008, at 12:47 AM, Pascal Thubert (pthubert) wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi:
>>>>>>>
>>>>>>> My understanding is that defining how mesh-under computes its
>>>>>>> routes
>>>>>>> is
>>>>>>> out of scope for the IETF overall. I'm not even sure we need to
>>>>>>> document
>>>>>>> requirements in that space. It's good that we push some
>>>>>>> requirements
>>>>>>> to
>>>>>>> ROLL on route-over, and that's certainly the right time to do
so.
>>>>>>>
>>>>>>> To Jonathan: I do not completely agree that ISA100 is mesh
>>>>>>> under. The
>>>>>>> routing is not specified and left to the system manager
>>>>>>> implementation.
>>>>>>> My personal hope is to promote a ROLL solution in ISA100.11a
next
>>>>>>> release. See
>>>>>>> http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req .
>>>>>>>
>>>>>>> So the current release of ISA100.11a is at the same level as
>>>>>>> 6LoWPAN
>>>>>>> on
>>>>>>> the matter of routing.
>>>>>>>
>>>>>>> In a same fashion, ISA does not define the backbone operation,
>>>>>>> the
>>>>>>> fragment recovery mechanism or the Explicit Congestion
>>>>>>> Notification.
>>>>>>> For
>>>>>>> all those features, there's a hope at ISA that the IETF will
>>>>>>> come up
>>>>>>> with more generic solutions that they can apply. But time is
>>>>>>> running
>>>>>>> out.
>>>>>>>
>>>>>>> 6LoWPAN hasn't produced anything for the last 6 months. At this
>>>>>>> rate,
>>>>>>> ISA will have to define everything on its own and hopefully
>>>>>>> publish an
>>>>>>> informational to this group.
>>>>>>>
>>>>>>> At the moment, the first draft of ISA100.11a is in letter
>>>>>>> ballot. The
>>>>>>> current draft mostly applies 6loWPAN formats over ISA100.11a
DLL,
>>>>>>> which
>>>>>>> is an evolution from 802.15.4. But the formats are not exactly
>>>>>>> 6LoWPAN
>>>>>>> so ISA is using NaLP headers starting with b'00'.
>>>>>>>
>>>>>>> What ISA needs from 6LoWPAN in very short term is in that order:
>>>>>>> - promote Jonathan's draft as a convergence specification so
>>>>>>> ISA can
>>>>>>> at
>>>>>>> least use standard HC headers.
>>>>>>> This enables: non-Link-Local-Address compression
>>>>>>> Hops limit compression
>>>>>>> UDP checksum compression
>>>>>>> Better placement of HC2
>>>>>>> Which are all mandatory for ISA100.11a
>>>>>>> - better define the NaLPs.
>>>>>>> There should be a way to indicate to a 6LoWPAN node whether a
>>>>>>> NaLP
>>>>>>> can
>>>>>>> be skipped and what its length is.
>>>>>>> - define IP ECN bits in a 6LoWPAN header for use by
>>>>>>> intermediate nodes
>>>>>>> to report congestion.
>>>>>>> - specify a fragment flow control and recovery protocol at the
>>>>>>> 6LoWPAN
>>>>>>> Shim layer
>>>>>>> There is no rocket science in any of this and it all could/
>>>>>>> should be
>>>>>>> carried out swiftly.
>>>>>>>
>>>>>>> What ISA needs in longer term:
>>>>>>> - define backbone operation when the backbone federates multiple
>>>>>>> LoWPANs
>>>>>>> into a single link (or subnet, TBD).
>>>>>>> This is more theoretical work for us. Related to proxy ND, a new
>>>>>>> registration protocols, multilink subnet, etc...
>>>>>>>
>>>>>>> Pascal
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: [EMAIL PROTECTED] [mailto:6lowpan-
>>>>>>>> [EMAIL PROTECTED] On
>>>>>>>>
>>>>>>>>
>>>>>>> Behalf Of Jonathan Hui
>>>>>>>
>>>>>>>
>>>>>>>> Sent: jeudi 22 mai 2008 00:20
>>>>>>>> To: Mark Townsley (townsley)
>>>>>>>> Cc: 6lowpan@ietf.org
>>>>>>>> Subject: Re: [6lowpan] New charter for 6lowpan
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Mark:
>>>>>>>>
>>>>>>>> On May 20, 2008, at 8:24 AM, Mark Townsley wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>> - To your point on ND, this is precisely why the
>>>>>>>>>> architecture draft
>>>>>>>>>> is so important. We haven't given it as much attention
>>>>>>>>>> lately, but
>>>>>>>>>> it will help resolve the question your raise and many other
>>>>>>>>>> questions in the future. For example, the architecture draft
>>>>>>>>>> identifies two modes of operation: mesh-under and route-
>>>>>>>>>> over. Both
>>>>>>>>>> of which may require different ND mechanisms. This doesn't
>>>>>>>>>> apply to
>>>>>>>>>> just ND, but may apply questions of fragmentation, header
>>>>>>>>>> compression, security, etc.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> I worry about the under/over debate. It seems that with all
the
>>>>>>>>> effort and enthusiasm in ROLL, we might be well-served at the
>>>>>>>>> moment
>>>>>>>>> by focusing on helping them be successful with route-over than
>>>>>>>>> spending too much of our time on route-under.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> I worry too, especially since it will pull the WG in different
>>>>>>>> directions. I'm with you on the preference for route-over, but
>>>>>>>> others
>>>>>>>> in this group feel strongly about mesh-under as well,
especially
>>>>>>>> since
>>>>>>>> ISA100.11a seems to have adopted a mesh-under approach. I've
>>>>>>>> personally been focused on developing route-over solutions
while
>>>>>>>> being
>>>>>>>> conscious of supporting mesh-under when possible (evident with
>>>>>>>> 6lowpan-
>>>>>>>> hc). However, things will start to diverge when we start to
talk
>>>>>>>> about
>>>>>>>> bootstrapping, ND, etc. So we should make a conscious decision
>>>>>>>> of
>>>>>>>> whether we're supporting one or both.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jonathan Hui
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>> - I hesitate a bit that we suggest possible solutions to ND
>>>>>>>>>> in the
>>>>>>>>>> charter ("reusing the 802.15.4 network structure (use the
>>>>>>>>>> coordinators)") especially since the definition of such link
>>>>>>>>>> mechanisms are still in motion within the IEEE. It seems more
>>>>>>>>>> productive to me if we can develop mechanisms that are less
>>>>>>>>>> dependent on the specific structure of 802.15.4 mechanisms.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> I agree that we should develop mechanisms that could work
>>>>>>>>> generically whenever possible.
>>>>>>>>>
>>>>>>>>> - Mark
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Rest of the charter looks good to me.
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jonathan Hui
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Pascal Thubert (pthubert) wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi Mark:
>>>>>>>>>>>>
>>>>>>>>>>>> I think we need a work item (usually implicit) around the
>>>>>>>>>>>> concept
>>>>>>>>>>>> of
>>>>>>>>>>>> improving existing WG RFCs. RFC 4944 can be improved in
>>>>>>>>>>>> several
>>>>>>>>>>>> aspects:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> - A major one is a better fit with ISA100.11a. Getting
>>>>>>>>>>>> ISA100.11a
>>>>>>>>>>>> to
>>>>>>>>>>>> conform to 6LoWPAN would be a major win, but is certainly
>>>>>>>>>>>> not a
>>>>>>>>>>>> given.
>>>>>>>>>>>> At the moment, the ISA100.11a documents expose
>>>>>>>>>>>> discrepencies with
>>>>>>>>>>>> RFC
>>>>>>>>>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-
>>>>>>>>>>>> hc
>>>>>>>>>>>> resolve
>>>>>>>>>>>> for the most part.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> Are the resolutions backwards compatible with RFC 4944? I'm
>>>>>>>>>>> eager
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> to
>>>>>>>
>>>>>>>
>>>>>>>>>>> improve RFC 4944, but not eager to endorse changes that
>>>>>>>>>>> inhibit
>>>>>>>>>>> interoperability.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> - The issue of fragmentation. Applying RFC 4944 over a
>>>>>>>>>>>> multihop
>>>>>>>>>>>> radio
>>>>>>>>>>>> mesh exposes the network to congestion collapse, as
>>>>>>>>>>>> described in
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>
http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec
>>>>>>>
>>>>>>>
>>>>>>>>>>>> overy . I think that the WG should dedicate some
>>>>>>>>>>>> bandwitdth to
>>>>>>>>>>>> provide
>>>>>>>>>>>> additional functions that would improve the LoWPAN
>>>>>>>>>>>> operation WRT
>>>>>>>>>>>> flow
>>>>>>>>>>>> control and recovery of fragments.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> Fragmentation, OK, but why is flow control a network layer
>>>>>>>>>>> issue
>>>>>>>>>>> rather
>>>>>>>>>>> than a transport layer issue?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Another aspect of ISA100.11a is the concept of a backbone
>>>>>>>>>>>> router.
>>>>>>>>>>>> It
>>>>>>>>>>>> would be appropriate that the IETF comes up with a
>>>>>>>>>>>> proposal to
>>>>>>>>>>>> implement
>>>>>>>>>>>> the concept in the IPv6 world. This partially falls under
>>>>>>>>>>>> the
>>>>>>>>>>>> first work
>>>>>>>>>>>> item on ND but might also include ND proxy over the
backbone
>>>>>>>>>>>> which is a
>>>>>>>>>>>> stretch to the work item. More in
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>
http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router
>>>>>>>
>>>>>>>
>>>>>>>>>>>> .
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> Well, don't we need to define what ND looks like on a lowpan
>>>>>>>>>>> before we
>>>>>>>>>>> decide whether it needs to be proxied or not?
>>>>>>>>>>>
>>>>>>>>>>> - Mark
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>
>>>>>>>>>>>> Pascal
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
>>>>>>>>>>>>> ]
>>>>>>>>>>>>> On
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> Behalf Of Mark Townsley
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> (townsley)
>>>>>>>>>>>>> Sent: jeudi 15 mai 2008 23:02
>>>>>>>>>>>>> To: 6lowpan@ietf.org
>>>>>>>>>>>>> Subject: [6lowpan] New charter for 6lowpan
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'd like to ask the group one final time for comments on
>>>>>>>>>>>>> the
>>>>>>>>>>>>> proposed
>>>>>>>>>>>>> new charter. I've also asked the ROLL WG chairs to
comment.
>>>>>>>>>>>>>
>>>>>>>>>>>>> As I said before, soon after the format document was
>>>>>>>>>>>>> published,
>>>>>>>>>>>>> there
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> is
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> nothing stopping the WG from discussing and working on
>>>>>>>>>>>>> new and
>>>>>>>>>>>>> existing
>>>>>>>>>>>>> items at this time. In fact, activity helps us to decide
>>>>>>>>>>>>> what
>>>>>>>>>>>>> should be
>>>>>>>>>>>>> in and out of the charter. Please do not construe not
>>>>>>>>>>>>> having a
>>>>>>>>>>>>> charter
>>>>>>>>>>>>> in place as a reason not to update drafts, or discuss
>>>>>>>>>>>>> topics
>>>>>>>>>>>>> that need
>>>>>>>>>>>>> to be discussed. Just as when we have BoF's and mailing
>>>>>>>>>>>>> lists
>>>>>>>>>>>>> before
>>>>>>>>>>>>> creating a new WG, it is good to have WG meetings and on-
>>>>>>>>>>>>> lists
>>>>>>>>>>>>> discussions when creating new WG charters.
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Mark
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 6lowpan mailing list
>>>>>>>>>>> 6lowpan@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 6lowpan mailing list
>>>>>>>> 6lowpan@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan
>>>>>>>>
>>>>>>>>
>>>>>> _______________________________________________
>>>>>> 6lowpan mailing list
>>>>>> 6lowpan@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> 6lowpan mailing list
>>>>> 6lowpan@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/6lowpan
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> Roll mailing list
>> [EMAIL PROTECTED]
>> https://www.ietf.org/mailman/listinfo/roll
>
>DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/
>
><http://info.surrey.ac.uk/Personal/L.Wood/><[EMAIL PROTECTED]>
>
>
>
>
>_______________________________________________
>Roll mailing list
>[EMAIL PROTECTED]
>https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
