On Jan 27, 2012, at 08:10, <[email protected]> wrote:
> Hi,
>
> Just to inform that our draft “Transmission of IPv6 Packets over Bluetooth
> Low Energy” was updated some weeks ago based on the WGLC comments. Version 5
> is available at:
> https://datatracker.ietf.org/doc/draft-ietf-6lowpan-btle/.
Thanks, Johanna.
<with chair hat>
This draft passed WGLC on 2012-01-05.
While trying to write the proto writeup as a prerequisite for asking for
publication as a Standards-Track, I found a number of (in part not entirely
trivial) editorial issues that I'm sending directly to the authors.
I also have a couple of technical observations that I believe need to be
addressed before we can go ahead.
1)
A
device MAY also derive the IID of the other endpoint of a L2CAP
connection from the Link Layer connection establishment messages.
-So how do we get consistency here?
-It is not acceptable if endpoints derive the wrong address -- among
-many problems, pseudoheader-based checksums will simply fail.
2)
When a BT-LE slave transmits an IPv6 packet to a remote destination
using global IPv6 addresses, the slave MUST elide the IPv6 source
address.
-To be able to compress a global prefix, it must have acquired a
-context. How do you make sure that is the case, to enable fulfilling
-that MUST?
3)
The 6LBR/master can infer the elided IPv6 source address
since 1) the master/6LBR has previously assigned the prefix to the
slaves;
-In IPv6, there may be more than one prefix.
-That's why RFC 6282 has a context identifier.
4)
If a context is defined for the prefix of the IPv6 source address,
the master/6LBR MUST elide that prefix as well.
-In summary, we use RFC 6282, but extend it to make, in some of the
-cases, compression mandatory?
-The intro to this section should say that.
Summarizing my observations:
a) Whenever the spec leaves a choice, it must either
-- explain why this choice does not cause interoperability problems, or
-- make sure that peers make the same choice.
b) Whenever the spec constrains an existing spec, it must
-- explain why the constrained behavior is always indeed possible at all,
-- make sure that both peers operate the constraint in the same way.
I don't see a way around generating a -06 that addresses these issues, before I
can do the proto writeup -- if we don't fix these items now, they will be much
more work to fix in the IESG phase.
Grüße, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
