I support adoption of this draft.
The first item of work once adopted should be to clarify the relationship of
this draft to the confusing PLC landscape. Section 3 mentions IEEE 1901 and
G.9904, but the rest of the text doesn’t seem to discuss these forms of PLC any
further. This is an editor
On Feb 7, 2019, at 11:58, Yasuyuki Tanaka wrote:
>
> If you receive a fragment having a fragment_tag which you've already seen and
> the fragment_tag is not associated with any entry in the VRB table, you can
> consider it as a duplicate or late-arriving fragment. Then, you can drop the
> rece
On Feb 6, 2019, at 15:49, Martine Lenders wrote:
>
> However, I'm unsure how I can determine when it is safe to remove a VRB entry
> at least for the minimal forwarding case (even for a successfully transmitted
> datagram). As far as I have seen not even the original VRB draft [4] mentions
> a
On Feb 7, 2019, at 12:36, Yasuyuki Tanaka wrote:
>
> Since datagram_tag is expected to be incremented (by one) as RFC4944
> specifies, holding the last datagram_tag per peer may be enough, although
> this kind of thing could be "implementation-specific":
Right. We don’t want to blackhole data
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF104. Remember that there is still quite some potential for
changes.
cose/teep and lpwan/t2trg are some annoying conflicts that meet the eye.
I also don't like that I'll have to miss the cacao BOF (vs. core),
dinrg/suit,
Here is my usual eclectic condensed agenda based on the FINAL AGENDA
for IETF104. Remember that, even though this will now go to the
printers, there is still some potential for changes.
The somewhat annoying coflicts cose/teep and lpwan/t2trg remain.
I also don't like that I'll have to miss the c
On May 12, 2019, at 15:54, Barry Leiba via Datatracker wrote:
>
> Why is DTL the length *minus 1*? Doesn’t that invite mistakes? Is there a
> reason not to make it the length, and to say that 0 is not a valid value?
Fundamentally, a small integer encoded into a bitfield is best encoded as a
v
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF105. Remember that there is still quite some potential for
changes.
Conflicts that meet the eye: COSE/TEEP again!
ROLL/SUIT/DINRG and 6TISCH/ACE are maybe slightly less annoying.
(The poor TEEP people get to both start
Here is my usual eclectic condensed agenda based on the FINAL AGENDA
for IETF105. Remember that, even though this will now go to the
printers, there is still some potential for changes.
Conflicts that meet the eye: COSE/TEEP stays;
ROLL/SUIT/DINRG and 6TISCH/ACE are maybe slightly less annoying.
RFC 6775/8505 on a new (greenfield) foo (as in IP over foo) is pretty much a
no-brainer, if that foo has points where the 6LBR functionality is naturally
centralized.
Not so easy for brownfield, i.e., in networks where classic ND is already used
in some hosts and some routers. “Efficient ND” (
On Jul 8, 2019, at 14:41, Pascal Thubert (pthubert) wrote:
>
>> What sort of device is a "L3AP"? In RFC 8200 we don't have that sort of
>> device
>> defined, we just have links, hosts, routers and nodes (IPv6 host or router).
>
> Like a L3-switch but wireless. An AP is a bridge that is proactiv
I am not personally aware of any patent claims that would read on this
specification.
Grüße, Carsten
> On Jul 17, 2019, at 17:32, Carles Gomez Montenegro
> wrote:
>
> (Note: CC'ing the 6Lo WG list.)
>
> Dear authors,
>
> In preparation for the shepherd writeup of the minimal fragment forwar
On Jul 19, 2019, at 17:08, Pascal Thubert (pthubert) wrote:
>
> Actually we use the term Low Power Lossy Network beyond 6lo, e.g., in ROLL.
> I'd rather keep the term but certainly expand it on first use.
I’d rather get rid of it.
Grüße, Carsten
___
On Jul 19, 2019, at 17:33, Carsten Bormann wrote:
>
> On Jul 19, 2019, at 17:08, Pascal Thubert (pthubert)
> wrote:
>>
>> Actually we use the term Low Power Lossy Network beyond 6lo, e.g., in ROLL.
>> I'd rather keep the term but certainly expand it on first us
On Jul 19, 2019, at 17:08, Pascal Thubert (pthubert) wrote:
>
> Based on your 2 suggestions combined, the title becomes "6LoWPAN Fragment
> Forwarding"
Sounds good.
Grüße, Carsten
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listin
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF106. Remember that there is still quite some potential for
changes.
Conflicts that meet the eye:
LAKE/SUIT (already noted by Russ), BOF on top (thing security): TMRID.
ACE/RATS are also both security technologies that i
Here is my usual eclectic condensed agenda based on the FINAL AGENDA
for IETF106. Remember that, occasionally, futher agenda changes do
happen.
Quite a bit has been moved around from the draft agenda.
LAKE no longer conflicts with SUIT, TMRID is now on top of ROLL and
TEEP which is maybe a bit le
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF107. Remember that there is still quite some potential for
changes.
Conflicts that meet the eye: ROLL vs. COSE/TEEP, LPWAN vs. RATS, and
LAKE vs. RATS, WPACK vs. ACE. The latter two might be a bigger
problem, while the
Here is my usual eclectic condensed agenda based on the FINAL AGENDA
for IETF107. Remember that, occasionally, futher agenda changes do
happen.
Not much change from the DRAFT AGENDA. SUIT has moved to Friday, now
on top of 6lo. The other security/not-so-much-security conflicts in
the IoT space
Congratulations!
After area-context header compression, RFC 6282 in 2011, this is another
milestone of header compression to bring IP to constrained environments.
Looking forward towards many things being built on top of this!
Grüße, Carsten
> On 2020-04-16, at 04:39, rfc-edi...@rfc-editor.o
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF108. Remember that there is still quite some potential for
changes.
Conflicts that meet the eye: LAKE/SUIT (!). ACE/RATS. (I think
6LO/COSE can be ignored.) HACKATHON is on top of CORE, but I don't
know what that slot
Here is my usual eclectic condensed agenda based on the FINAL AGENDA
for IETF108. Remember that, occasionally, further agenda changes do
happen.
There has been no change from the DRAFT AGENDA in the Conflicts I
noted: LAKE/SUIT (!). ACE/RATS. (I think 6LO/COSE can be ignored.)
The only significa
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF109. Remember that there is still quite some potential for
changes.
The conflicts that meet the eye this time seem to impact generalists only.
Great scheduling job!
All times *on my agenda* are in UTC (the default page
Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA
for IETF109. Remember that further agenda changes can still happen.
Very little has changed with respect to the draft agenda. WEBTRANS
does meet, and CFRG and IRTFOPEN have been moved around (CFRG now on
top of CORE, unfortun
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF110. Remember that there is still quite some potential for
changes.
The IoT-relevant conflicts that meet the eye this time are LAKE/RATS,
IOTOPS/COSE, CORE/DANISH, in order from hurtful to disastrous
(ROLL/SUIT and LPWA
Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA
for IETF110. Remember that further agenda changes can still happen.
A number of changes have been made with respect to the draft agenda.
CBOR has moved to Monday into what was ASDF's slot, and ASDF is now on
top of IOTOPS (ug
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF111. Remember that there is still quite some potential for
changes.
The IoT-relevant conflicts that most meet the eye this time are
LAKE/RATS, IOTOPS/RATS (and there is likely to be an IoT-relevant
discussion at tsvwg,
Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA
for IETF111. Remember that further agenda changes can still happen.
A number of changes have been made with respect to the draft agenda.
Most notably, IOTOPS has moved on top of SECDISPATCH (was on top of
RATS), but LAKE stay
On 2021-09-06, at 05:40, Dale R. Worley wrote:
>
> I remember filing this erratum, and at the time, someone pointed out how
> the 255 hop-limit is used, etc. as Kerry describes. I'm surprised that
> the erratum hasn't been closed previously.
I agree with Dale that the errata report should be cl
On 2021-10-06, at 14:45, Carles Gomez Montenegro wrote:
>
> We encourage the WG to read the document and provide comments on the
> mailing list.
May not get to it immediately.
I’d like to point out that we did something rather similar in
draft-ietf-roll-ccast, the MLAOs (Section 5.1):
https:/
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF112. Remember that there is still quite some potential for
changes.
The IoT-relevant conflicts that most meet the eye this time are
ASDF/LAKE/RATS and IOTOPS/COSE.
All times are in UTC.
Note that the first week in Novem
Is it time for an adoption call?
(15 days before I-D deadline, so a 14-day adoption call would need to be issued
quickly; 7-day adoption calls are fine, though.)
Grüße, Carsten
> On 2021-10-09, at 13:53, Pascal Thubert (pthubert)
> wrote:
>
> Dear chairs and ADs
>
> The IANA section correct
Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA
for IETF112. Remember that further agenda changes can still happen.
COSE no longer is on IOTOPS; MADINAS, ADD, INTAREA, UTA, and OPENPGP
have moved around a bit. The conspicuous conflict of ASDF/LAKE/RATS
remains.
All times
On 2021-12-14, at 10:09, Luigi Iannone wrote:
>
> While we believe that the document is becoming mature, we still welcome any
> feedback people can send us.
I haven’t read the new version, but I stick with the observation that the
problem/opportunity addressed is already solved with 6lo header
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF113. Remember that there is still quite some potential for
changes.
The IoT-relevant conflicts that most meet the eye this time are
LPWAN/ACE (probably little actual overlap) and DRIP/ROLL/RATS
(probably a little more o
Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA
for IETF113. Remember that further agenda changes can still happen.
The IoT-relevant conflicts that most meet the eye this time are
LPWAN/ACE (probably little actual overlap) and DRIP/ROLL/RATS
(probably a little more overlap
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF114. Remember that there is still significant potential for
changes.
The IoT-relevant conflicts that most meet the eye this time are
ROLL/SUIT (probably little actual overlap) and CBOR/LAKE (probably a
lot of overlap).
Here is my usual eclectic condensed agenda based on the FINAL AGENDA
for IETF114. Remember that further agenda changes can still happen.
ROLL is now on top of COSE and no longer SUIT (both probably with
little actual overlap), LAKE is now on top of LPWAN and no longer CBOR
(probably much less ove
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF115. Remember that there is still significant potential for
changes.
All times are in UTC, as will be the physical meeting.
Grüße, Carsten
SATURDAY, November 5, 2022
0930-2100 Hackathon - Admiral 1
1030-1100 Hacka
Here is my usual eclectic condensed agenda based on the FINAL AGENDA
for IETF115. Remember that further agenda changes can still happen.
As usual, there are tons of subtle conflicts; e.g., having TIGRESS,
MADINAS, and SECDISPATCH in one slot will be hard for security and
privacy minded people ev
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF116. Remember that there is still significant potential for
changes.
Notable conflicts include:
dispatch vs. rats
CORE vs. SCITT
drip vs. roll
IOTOPS vs. TEEP
All times are in UTC; the physical meeting will be on JST +
Here is my usual eclectic condensed agenda based on the FINAL AGENDA
for IETF116. Remember that further agenda changes can still happen.
Some conflicts in the draft agenda have been resolved, some of the
more subtle ones remain, including:
dispatch vs. rats
CORE vs. SCITT
drip vs. roll
The ACE v
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF117. I'm sorry this took a little longer but the format in
which the input was provided by the Secretariat had changed, so some
assembly was required. Remember that there is still significant
potential for changes.
The
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF118. Remember that there is still significant potential for
changes.
I personally don't like the SCHC/IOTOPS conflict; I also don't like
the TIGRESS/ACE/JOSE cluster.
Apart from that, this agenda works reasonably well.
Here is my usual eclectic condensed agenda based on the FINAL AGENDA
for IETF118. Remember that there is still potential for changes.
Not much has changed apart from a couple of room changes: DNSSD has
been moved from Friday to Thursday, and a couple of "break sessions"
have been created.
I stil
Here is my usual eclectic condensed agenda based on the FINAL AGENDA
for IETF118. Remember that there is still potential for changes.
Not much has changed apart from a couple of room changes: DNSSD has
been moved from Friday to Thursday, and a couple of "break sessions"
have been created.
I stil
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF119. Remember that there is still significant potential for
changes.
CFRG vs. COSE is a bit suboptimal for the crypto expertise that might
be present in the COSE room. INTAREA vs. WITAREA is a bit surprising
to me; the
Here is my usual eclectic condensed agenda based on the FINAL AGENDA
for IETF119. Remember that there is still potential for changes.
CFRG vs. COSE still is a bit suboptimal for the crypto expertise that
might be present in the COSE room. WITAREA is now on LAKE.
CBOR got moved to Friday and has
RFC 4944 does what (AFAIK) all 802-derived IP-over-foos do when creating IP
addresses from MAC addresses/EUIs:
The Interface Identifier is then formed from the EUI-64 by
complementing the "Universal/Local" (U/L) bit,
(Section 4 of RFC 2464).
The text cited from IEEE talks about EUIs.
EUI
On 2024-04-28, at 16:38, Esko Dijk wrote:
>
> Just noting that the naming in RFC 4944 may confuse some readers: both bits
> are now named "U/L bit". The complemented bit could have been named "L/U
> bit" instead; or "the bit in the U/L bit position". Also the RFC 2464
> reference URL to the "
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF120. Remember that there is still significant potential for
changes.
All times are in UTC; the physical meeting will be on PDT == -0700.
The times listed as 2400 plus are the next day in UTC!
Grüße, Carsten
SATURDAY,
Here is my usual eclectic condensed agenda based on the FINAL AGENDA
for IETF120. Remember that there is still potential for changes.
All times are in UTC; the physical meeting will be on PDT == -0700.
The times listed as 2400 plus are the next day in UTC!
Grüße, Carsten
SATURDAY, July 20, 20
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF96. Remember that there is still quite some potential for
changes.
Apart from COSE on PLUS (ouch), and the maybe more personal conflicts
of ACE on QUIC and 6LO on ARTAREA, I'm not seeing a lot of hurt this
time. Moves d
Hi Alex,
I think we were experiencing a tools.ietf.org outage.
Works for me now.
Grüße, Carsten
Alexandru Petrescu wrote:
> Le 11/06/2015 à 15:38, Carsten Bormann a écrit :
> [...]
>
>> May I remind people that there is a repository of 6LoWPAN packet dumps at
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF97. Remember that there is still quite some potential for
changes.
IoT is starting a bit late at IETF97; only two meetings of cluster WGs
on Mon/Tue (but then of course we start big with the Sunday
icnrg/t2trg joint meet
Constrained Node/Network Cluster @ IETF97: FINAL AGENDA
To: 6lo@ietf.org, 6ti...@ietf.org, lp-...@ietf.org, l...@ietf.org, r...@ietf.org
To: a...@ietf.org, c...@ietf.org, c...@ietf.org, dtls-...@ietf.org,
t2...@irtf.org
Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA
for IE
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF98. Remember that there is still quite some potential for
changes.
ACE/HOMENET/DISPATCH is a bit of a triple whammy. WUGH on LWIG will
pull many constrained networks people off the github discussion. I'm
not seeing any
On 27 Feb 2017, at 14:56, Pascal Thubert (pthubert) wrote:
>
> [Pascal] I expect that this could happen with an update of RFC 6282, but with
> the current spec you cannot since RFC6282 defines the chain all the way to
> the payload or at least the end of the compressed piece.
>
Well, yes. 62
Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA
for IETF98. Remember that agenda definitions are never really
"FINAL"... "While this is considered the final agenda for printing,
changes may be made to the agenda up until and during the
meeting. Updates will be reflected on
I just submitted draft-bormann-t2trg-sworn-00.txt, which describes a secure way
for applications to wake sleepy nodes.
For 6lo, it may be of interest as a way to expose a MAC layer feature to the
application layer in a secure way.
For CoRE, it shows an unusual way to use the CoAP protocol.
For
> The major rationale IMO for this draft is that it doesn't require
> intermediary nodes to reassemble!
As I said in the WG meeting (and pointed out in the 6LoWPAN book), this has not
really been necessary even in the original 6LoWPAN. However, to make “virtual
reassembly buffers” work in mul
>>> The major rationale IMO for this draft is that it doesn't require
>>> intermediary nodes to reassemble!
>>
>> As I said in the WG meeting (and pointed out in the 6LoWPAN book), this has
>> not really been necessary even in the original 6LoWPAN. However, to make
>> “virtual reassembly buffe
On Apr 6, 2017, at 10:57, Rahul Jadhav wrote:
>
> Fragmentation at 6lo layer as it is today is almost unusable for a moderately
> sized network with lower MTUs such as 127B.
Hi Rahul,
please explain some more.
What kind of problem do you experience?
Is the load on your network predominantly
using reception
> from different peers is hurting the end to end msg transmission badly. The
> failure rate and thus the retransmission rate at app is very high,, so much
> that we had to adopt a proprietary compressed PANA signalling mechanism to
> improve convergence time.
>
Thank you. Pascal, for seeing this through — this gives us a much better way to
encapsulate RPL-routed traffic (and in particular the source routing in
Non-Storing Mode) in all kinds of 6Lo-style networks.
Now let’s get the information out on implementation efforts.
Grüße, Carsten
> On Apr 12
Hi Benjamin,
Just speculating here:
In RPL itself, you could use "IP addresses" made up from MAC addresses as IIDs.
For the RPL-routed traffic, you could use 6LoRH-style encapsulation (RFC 8138),
which also would fit a mesh-under approach very well.
So I think the total amount of messages that h
Congratulations!
It seems the first wave of 6lo adaptation layers is now complete:
RFC 7428 (was draft-ietf-6lo-lowpanz)
Transmission of IPv6 Packets over ITU-T G.9959 Networks
RFC 7668 (was draft-ietf-6lo-btle)
IPv6 over BLUETOOTH(R) Low Energy
RFC 8105 (was draft-ietf-6lo-dect-ule)
Transmi
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF99. Remember that there is still quite some potential for
changes.
ACE people are going to miss DISPATCH (ARTAREA) again -- not sure if
there would have been be any discussions relevant to Constrained
Nodes/Networks in A
Here is my usual eclectic condensed agenda, now based on the "FINAL"
AGENDA for IETF99. Compared to the last week's draft agenda, dnssd
and acme were moved. (It is likely that there still will be some more
changes after this "FINAL" agenda.)
ACE people are going to miss DISPATCH (ARTAREA) again
On Jul 12, 2017, at 23:27, Gabriel Montenegro
wrote:
>
> There were zero comments on this LC.
Right. I didn’t have the cycles to look at this, and won’t before early August.
More importantly, I believe we need feedback from implementers about this.
Grüße, Carsten
__
We need to do at least the first two of three things:
(1) Write up how fragment forwarding works today (those implementation
techniques are currently not documented in a way that is very accessible to new
implementers).
(2) Look at the timing considerations governing burst packet transmission t
> On Jul 20, 2017, at 09:45, Behcet Sarikaya wrote:
>
> Hi Pascal,
>
> Is fragmentation an issue in lpwan also?
Definitely, and there is a draft for that:
LPWAN Static Context Header Compression (SCHC) and fragmentation for
IPv6 and UDP
draft-iet
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF100. Remember that there is still quite some potential for
changes.
The CBOR/SUIT conflict needs to be fixed. Also, maybe CORE and 6TISCH
are going to swap so we have more time between the two CORE meetings.
All times
(Sorry for the resend; the previous version missed out on all meetings
in the room "VIP A", and I didn't see those conflicts either.)
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF100. Remember that there is still quite some potential for
changes.
The CBOR/SUIT conf
Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA
for IETF100. Remember that "FINAL" means this will be the basis for
printed agenda sheets, there is still some potential for changes after
that.
The CBOR/SUIT conflict has been fixed, but now there is overlap
between 6TISCH an
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF101. Remember that there is still quite some potential for
changes.
The painful ones (not necessarily fixable) this time include:
DINRG vs. ACE, CBOR vs. TEEP, ROLL vs. SUIT vs. OCF/WoT; also CORE
vs. ANIMA, CORE vs. QUI
On Feb 21, 2018, at 10:07, Jürgen Schönwälder
wrote:
>
> - What is the 'legacy 6LoWPAN ND specification'? I found out later
legacy | ˈlɛɡəsi |
noun (plural legacies)
an amount of money or property left to someone in a will.
• a thing handed down by a predecessor: the legacy of cen
Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA
for IETF101. Remember that "FINAL" means this will be the basis for
printed agenda sheets, there is still some potential for changes after
that.
SUIT is now on top of CORE (!??).
(Also, ICE has moved.) The painful ones this
On Feb 22, 2018, at 10:06, Pascal Thubert (pthubert) wrote:
>
> ROLL has the concept of a leaf, that is a 6LN that is not aware of RPL but
> needs routing handled for it.
This terminology is confusing.
In RPL, a Leaf Node is a RPL router that does not forward (RFC 6550 Section
8.5).
We also
On Feb 26, 2018, at 18:22, Pascal Thubert (pthubert) wrote:
>
> Yes Carsten,
>
> I agree there's a confusion that we need to clean up on the ROLL side. My
> definition of leaf echoes yours from RFC 6550. A leaf still understands RPL.
> But over time people started using the term as a plain host
Hi Pascal,
> On Feb 26, 2018, at 19:00, Pascal Thubert (pthubert)
> wrote:
>
> For backwards compatibility we need to be able to live without 6CIO.
Please explain.
> Still 6CIO seems to be a good mechanism to generalize and that’s why we used
> it.
Yes.
> So should we keep the CIO mechani
Hi Hudson,
interesting research!
Kudos for making this available while it is still officially stuck in some
lengthy review process.
I can’t say I have processed all the details in the paper, but I would like to
point to one need that we have in maintaining a protocol that has been around
for
On May 16, 2018, at 07:15, Hudson Randal Ayers wrote:
>
> 6LoWPAN as a whole may be too focused on radio energy savings, at the
> expense of code size and complexity.
I would maintain that we hit exactly the sweet spot here, at least with respect
to RFC 6282 (6LoWPAN header compression).
> W
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF102. Remember that there is still quite some potential for
changes.
ACE vs. DISPATCH seems to become a common occurrance; at this rate,
I'll probably never see a DISPATCH meeting again. CBOR vs. 6LO is
maybe just a pers
I forgot to send the update of my usual eclectic condensed agenda
based on the "FINAL" AGENDA for IETF102. Remember that "FINAL" means
this will be the basis for printed agenda sheets, there is still some
potential for changes after that.
The only change from the previous draft agenda (apart from
On Aug 2, 2018, at 00:38, Michael Richardson wrote:
>
> As for the document. I want to suggest that the WG adopt it.
Hmm. While the document has some interesting observations, I don’t think we
should adopt any one of its conclusions. The interop problems we are seeing in
the research implem
Hi Philip,
I think we have strong agreement that code space is at a premium. (There are
lots of people who’d rather sell bigger micros than enable the smaller ones,
but the point of the whole constrained node network activity is to expand the
Internet to less capable platforms.)
There are als
On Aug 22, 2018, at 21:52, Antonino Masaracchia
wrote:
>
> [Please accept our apologies if you receive multiple copies of this email]
Unfortunately, no, apologies *not* accepted.
I have 10 announcements for this conference (the 2018 version!) in my inbox
that I haven’t deleted yet, 2 of these
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF103. Remember that there is still quite some potential for
changes.
cbor/teep and 6tisch/suit are annoying but probably livable.
No qirg for core goers...
All times are ICT (Indochina Time) == UTC +7 hours. There is no
Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA
for IETF103. A few changes from the DRAFT AGENDA. I waited a bit
with sending this as a few more side meetings have become known, as
well. Of course, "FINAL" doesn't mean final.
cbor/teep and 6tisch/ace (was suit) are annoyi
Here is my usual eclectic condensed agenda based on the FINAL AGENDA
for IETF121. Remember that there is still potential for changes.
ACE on RATS staid in as a conflict that probably isn't in
practice. Similar for ASDF vs. DEEPSPACE.
SCONE no longer is across CORE, but now T2TRG.
And the new IA
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF121. Remember that there is still significant potential for
changes.
ACE on RATS maybe should be a conflict, but probably isn't in
practice. I'm miffed about CORE vs. SCONE, but might be the only one.
Similar for ASDF
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF122 (Updated 2025-02-15 03:46:26 +0700). Remember that there
is still significant potential for changes.
Notable conflicts include CBOR vs. SPICE, JOSE vs. SCITT.
All times are in UTC; the physical meeting will be on UT
Here is my usual eclectic condensed agenda based on the FINAL AGENDA
for IETF122 (Updated 2025-02-22 04:58:52 +0700). Remember that there
is still potential for changes.
The conflict JOSE vs. SCITT remains.
All times are in UTC; the physical meeting will be on UTC+0700.
Grüße, Carsten
SATURD
Here is my usual eclectic condensed agenda based on the DRAFT AGENDA
for IETF123 (Updated 2025-06-20 19:47:20 CEST +0200).
Remember that there is still significant potential for changes.
Notable unfortunate overlaps include Monday morning's DISPATCH WG,
which overlaps with the GEN area PROCON WG
95 matches
Mail list logo
