;
> Sheng
>
> > -Original Message-
> > From: forwardingalgori...@ietf.org On
> > Behalf Of 'Toerless Eckert'
> > Sent: Wednesday, May 15, 2024 12:05 AM
> > To: Sheng JIANG
> > Cc: draft-ietf-anima-network-service-auto-deploym...@ietf.org;
> >
t be path-oriented, should be
> also started as an use case of such framework.
>
> How do you think?
>
> Best regards,
>
> Sheng
>
> > -Original Message-
> > From: Anima On Behalf Of Toerless Eckert
> > Sent: Thursday, May 2, 2024 11:21 PM
>
Brian:
Well, we do have the answer that we worked out in our first batch of RFCs,
which is that the ANI with BRSKI, ACP and GRASP provides not only the
secure autonomously established communications fabrics for ASA to
talk to each other, but also that "SDN controller/orchestrars" can use
the ANI
Dear Authors
Thank you for this work. The document sounds and currently intends to target
a full standard specification for arbitrary services management via GRASP. I
think this is an unattainable goal. What i think is attainable is to outline
how to build such GRASP based signaling
who are in AD review)
- Discuss brski-discovery, especially CoAP option
Cheers
Toerless
On Mon, Mar 11, 2024 at 11:01:29PM +0100, Toerless Eckert wrote:
> Given how we will only have limited in-person attendance in Brisbane,
> given how the time may also be badfor remote atte
C8366bis has
> advanced.
>
> Best regard
> Steffen
>
> > -Original Message-
> > From: Anima On Behalf Of Toerless Eckert
> > Sent: Monday, March 11, 2024 10:56 PM
> > To: anima@ietf.org
> > Cc: Sheng JIANG ; mjethanand...@gmail.com;
> >
> Length of time requested 5min
> name of draft(s) discussed draft-ietf-anima-brski-prm-11
> Local/remote remote
>
> Best regards
> Steffen
>
> > -Original Message-
> >
Thanks, added to our notes for IETF119 for the moment.
On Wed, Mar 06, 2024 at 10:29:27AM +, Esko Dijk wrote:
> Hi Toerless,
>
> Yesterday in the design team call you asked if any specifications use the
> "YANG to CBOR" mapping (RFC 9254), apart from us (cBRSKI).
> In the call we forgot to
Given how we will only have limited in-person attendance in Brisbane,
given how the time may also be badfor remote attendance, and given how we
will also have key contributors not attending for especially the constrained
proxy/voucher
drafts, i wanted to put out a doodle poll for a tentative
Agenda is now posted.
https://notes.ietf.org/s/notes-ietf-119-anima
If you're gong to be local in Brisbane, please consider to be note-take, that
would be greatly appreciated!
This is a fairly lightweight agenda, but we have a few core questions
that would be good to discuss in person, in
Hi Rob,
Can you please fix the text of the errata according to below ?!
Thanks
Toerless
-- Current text -
Section 5.4 says:
Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is
REQUIRED. TLS 1.3 (or newer) SHOULD be available.
It should say:
TLS 1.2 [RFC5246] with
ichardson
> Sent: Wednesday, February 14, 2024 19:54
> To: Toerless Eckert
> Cc: rwil...@cisco.com; anima@ietf.org
> Subject: Re: [Anima] Errata 6642: Re: Registrar to MASA connections: SNI
> required
>
>
> Toerless Eckert wrote:
> >> I'm fine with t
Rob:
-- Current text -
Section 5.4 says:
Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is
REQUIRED. TLS 1.3 (or newer) SHOULD be available.
It should say:
TLS 1.2 [RFC5246] with SNI support [RFC6066] is REQUIRED if
TLS 1.3 is not available.
The Server Name
On Wed, Feb 14, 2024 at 01:01:56PM -0500, Michael Richardson wrote:
> tte> Just to double check: in this thread we're only talking registrar to
> tte> MASA (no pledges).
>
> The text I quote from you above, says, "pledge"
Siure, i mean for this thread with subject "Errata 6642" lets only
+1 support adoption (author)
On Fri, Feb 09, 2024 at 04:28:55PM +0800, Sheng JIANG wrote:
> Hi, ANIMAers,
>
> This email starts a two-week adoption call on
> draft-eckert-anima-brski-discovery-01. It ends by 2024/2/23rd.
>
> This draft is not new as normal -01 individual draft. It is coalesced
Toerless Eckert has requested publication of
draft-ietf-anima-grasp-distribution-11 as Experimental on behalf of the ANIMA
working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-anima-grasp-distribution
On Mon, Feb 12, 2024 at 09:01:50AM -0500, Michael Richardson wrote:
>
> Toerless Eckert wrote:
> > agile. But SNI is one such example, where the pledge does need to
> > signal the right info (SNI) to enable "cheaper" cloud registrars, aka:
> > those
Dear Sheng,
On behalf of the co-authors, i would hereby like to ask for adoption of
draft-eckert-anima-brski-discovery.
The draft is not about new, not-yet-adopted work, but instead it is coalescing
discovery options that we originally had started to write into different BRSKI
variation
k technically
it is correct to ask for SNI support on Registrar. But i am not adament to make
a fuzz about it.
Lets just agree on the final text for this errata so Rob can close the book on
it.
Cheers
toerless
On Fri, Feb 02, 2024 at 08:49:06AM -0500, Michael Richardson wrote:
>
> Toe
Thanks a lot to the authors for the update,
Michael: Would be great if you could finish the Shepherd review soon, so this
doc
might still get into the AD queue!
Cheers
Toerless
On Tue, Feb 06, 2024 at 01:25:19AM -0800, internet-dra...@ietf.org wrote:
> Internet-Draft
meeting session request has just been submitted by Toerless Eckert, a
> Chair of the ANIMA Working Group.
>
>
> -
> Working Group Name: Autonomic Networking Integrated Model and Approach
> Area Name: Operations and Ma
rstand why not.
If this is the right fundamental rule, then lets figure out how to make sure we
put the
right instances of this into the right places, like the errata and e.g.:
brski-cloud
Cheers
Toerless
On Wed, Jan 31, 2024 at 09:18:33AM -0500, Michael Richardson wrote:
>
> Toerle
11:39:30PM -0500, Michael Richardson wrote:
>
> Toerless Eckert wrote:
> > I am not sure what to do about this in general, but i think the really
> > important issue is that we ask for support of SNI in BRSKI cloud to
> > support actual cloud deployment (wit
Michael, *:
You asked in another thread for verificiation of errata 6642:
https://www.rfc-editor.org/errata/eid6642
Currently it says:
~~~
Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is
REQUIRED. TLS 1.3 (or newer) SHOULD be available.
It should say:
TLS 1.2 [RFC5246] with
I am not sure what to do about this in general, but i think the really important
issue is that we ask for support of SNI in BRSKI cloud to support actual cloud
deployment (with shared IP address) of registrars, when pledges only have TLS
1.2 - because
RFC8995 did not require it.
So, i did open:
Thanks, Rob
We where actually wondering about the differnt datatracker status unless Alvaro
told me
how to find the reason in the history:
https://datatracker.ietf.org/doc/draft-ietf-anima-jws-voucher/history/
Thanks for holding the document, because this is what we originally asked you
to
FYI:
We have passed JWS on to IESG for review after the authors confirmed to us that
the document(s)
depending on JWS voucher, predominantly BRSKI-PRM is now in a state where we
are sure that
no further fixes on the JWS voucher document is required. JWS voucher itself
went through all
the WG
Toerless Eckert has requested publication of draft-ietf-anima-jws-voucher-09 as
Proposed Standard on behalf of the ANIMA working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-anima-jws-voucher/
___
Anima
Toerless Eckert has requested publication of draft-ietf-anima-brski-ae-09 as
Proposed Standard on behalf of the ANIMA working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-anima-brski-ae/
___
Anima mailing
ski...@ietf.org
Subject: Pre: review of draft-ietf-anima-brski-ae-08
Message-ID:
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
rom: Toerless Eckert
Status: RO
Content-Length: 92164
Lines: 1927
pre-post to authors, final will go to list.
main two iss
Thanks a lot, Michael
Wrt. the process: As a reviewer, keeping everything in a single file is always
easier
than breaking it up into issues. Especially because the more you revisit a
document, the
more you go back and forth and maybe delete comments or change them.
When i sent this as an
Inline
On Mon, Dec 11, 2023 at 10:48:57AM -0500, Michael Richardson wrote:
> RFC8994 says:
>
> 6.8.3.1. Native IPsec
>
>An ACP node that is supporting native IPsec MUST use IPsec in tunnel
>mode, negotiated via IKEv2, and with IPv6 payload (e.g., ESP Next
>Header of 41). It MUST
On Tue, Dec 05, 2023 at 01:05:42PM -0500, Michael Richardson wrote:
>
> > Earlier this year, i did a review of draft-ietf-anima-brski-cloud-05:
> > https://mailarchive.ietf.org/arch/msg/anima/fxFBwoUUUc31eHUcDhdTmWdkFdk
>
> I see that email refers to your review, but it is not the review
Thanks for Cc'ing ANIMA!
Discussions i think on the netmo mailing list, Cc. to iesg. That's what i just
did.
I did not have concerns about not seeing ANIMA mentioned explicitly in the
charter because no other working group is mentioned either, and i think there
is automation work goin on in
Dear BRSKI-cloud authors,
Earlier this year, i did a review of draft-ietf-anima-brski-cloud-05:
https://mailarchive.ietf.org/arch/msg/anima/fxFBwoUUUc31eHUcDhdTmWdkFdk
The acknowledgemeent section of -08 does not mention my name. There is no
changelog in the document explaining whether or not
s. Aka: This would have to be taken when such DTLS centric deplouments where
successful enough to justify such a requirement. And this would be beyond the
scope
of mere discovery work.
Thanks!
Toerless
>
> Regards
>Brian Carpenter
>
> On 22-Nov-23 04:14, Toerless Ecke
Revisiting the constrained BRSKI discovery details, i stumbled across a generic
discovery
issue for which i would like to solicit opinions.
Please also add your thoughts about this to:
https://github.com/anima-wg/brski-discovery/issues/4
(but discuss here first).
Question: How do we want to
Thanks Esko,
inline
On Tue, Nov 21, 2023 at 01:12:45PM +, Esko Dijk wrote:
> A first comment / question here: in IETF 118, it was proposed to focus the
> discovery methods for Constrained BRSKI
> (draft-ietf-anima-constrained-voucher) only on a single mechanism and leave
> further
Dear ANIM-WG
ANIMA will have one 1 hour session, at IETF118
chaired by Sheng Jiang and Toerless Eckert
17:00 - 18:00 (local time CET, 16:00 - 17:00 UTC) Tuesday Session 4, Room
Bohemia I/II/III
The tentative ANIMA-WG agenda has been posted, as always, we are (ab)using the
notes page, so we can
aft draft-eckert-anima-brski-discovery-01.txt has
> been successfully submitted by Toerless Eckert and posted to the
> IETF repository.
>
> Name: draft-eckert-anima-brski-discovery
> Revision: 01
> Title:Discovery for BRSKI variations
> Date: 2023-10-23
> Group:
> (This will be published prior to the IETF meeting.) 5 minutes would be ok,
> 10 minutes better if we have the time ;)
>
> Esko
>
> -Original Message-
> From: Anima On Behalf Of Fries, Steffen
> Sent: Thursday, September 14, 2023 14:58
> To: Toerless Ecke
We're having a range of good and important work threads on github, and as much
as i love
the automatic threading and later easy review of github, as a WG chair i still
have to worry about us complying with IETF rules as well as concerns of ADs and
participants.
If we do not copy these
the WG meeting time request
for
IETF118 as then needed.
Cheers
Toerless - for the chairs
On Wed, Sep 13, 2023 at 04:05:47PM -0700, IETF Meeting Session Request Tool
wrote:
>
>
> A new meeting session request has just been submitted by Toerless Eckert, a
> Chair of the ANIMA W
Thanks, David
I have some more fundamental concerns than the discussions that we had this week
and that you tried to sommarize, so let me try to restate the issue in a way
that
readers with less context detail can hopefully follow.
In BRSKI, the overall sequence of events is high level:
1.
Dear ANIMA-WG
In the weekly BRSKI calls we did discuss on and off the issue of limited HTTP
error codes returned when calling BRSKI endpoint URIs. Especially the point
that it's difficult
to map all error conditions to unique HTTP status codes.
So, i would hereby like to suggest that we
Thanks!
I guess the logic is:
If you can describe a semantic to the order of elements, then its a list/array,
else should be a map/object.
AFAIK, there is no definition of ordering in kvpairs in DNS-SD, so it should be
e.g.:
kvpairmap = ?{ +kvpair }
kvpair = [ key : str , ?( value: str) }
On Sat, Jul 29, 2023 at 10:17:38AM +1200, Brian E Carpenter wrote:
> On 27-Jul-23 01:44, Toerless Eckert wrote:
> > DNS-SD TXT RR's are a sequenze of zero limited strings "key1=value1" ...
> > "keyn=valuen"
> >
> > In my current grash/dsn-sd draft
Esko: I was just checking -07, it looks as if your open review concerns should
have been
successfully answered. Would you mind acknowledging, please ?!
Thanks
Toerless
On Wed, Jul 26, 2023 at 01:58:22PM -0400, Michael Richardson wrote:
>
> Owen Friel \(ofriel\) wrote:
> > Thanks Esko,
DNS-SD TXT RR's are a sequenze of zero limited strings "key1=value1" ...
"keyn=valuen"
In my current grash/dsn-sd draft i have just proposed to encode this in
CBOR with as little as possible changes, e.g.:
[ "key1=value1", ... "keyn=valuen" ]
Thinking that one needs to be able to parse this
Your best opportunity this week to earn a lot of thanks, pls let us chairs know!
Thanks so much!
Toerless - for the chairs.
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Want to throw a different proposal in the room.
See proposal in my slides tomorrow, i think we may want to include more
information,
even when the actual variation is just a single string.
Cheers
toerless
On Tue, Jul 25, 2023 at 05:52:27PM -0400, Michael Richardson wrote:
>
> On 26-Jul-23
Carsten:
The way i see it, the underlying issue seems to be that most IETF specs that
use JSON seem to be happy in specifying their JSON objects without formal
specification of their JSON objects in CDDL.
For example, i walk through the list of drafts/RFCs referencing RFC7515
(JSON Web
.
Cheers
Toerless
On Wed, Jul 19, 2023 at 07:25:22AM +, Yanlei(Ray) wrote:
> Toerless,
>
>
> Toerless Eckert wrote:
> >Ray:
> >
> >Added to agenda. Will still need to check how much time we will have.
> >Consider 10+ minutes guaran
My 2cent as individual contributor:
I like the use of the BASE64URL notation without apostrophes better,
because as you said, it could be pefect javascript (considering
javascript as the ideal template language for JSON).
Then again, we did introduce the pseudovalue "base64encodedvalue=="
in
Thanks, Esko!
It looks as if you are not registered for IETF117... I think to remember
something about PTO.
Are the specific issues you would like to be discussed (even in your absence)
during the WG
meeting, maybe one of the co-authors could lead ?
Cheers
Toerless
On Fri, Jul 07, 2023
Of 蒋胜
> > Sent: Thursday, July 6, 2023 10:33 AM
> > To: anima
> > Cc: anima-chairs ; Toerless Eckert
> > Subject: [Anima] Call for agenda items ANIMA@IETF117@ San Francisco
> >
> >Dear ANIMA WG,
> >
> >The preliminary IETF117 agenda is on the web.
>
Thanks a lot Sheng,
A bit more logistics:
1. The authoritative agenda for the WG meeting is the meetings notes page:
https://notes.ietf.org/notes-ietf-117-anima
We have already created on the notes page a list of WG documents, and even if
you do not want
to have a slot, we instead need for
In the process of discussing shepherd review feedback for BRSKI-PRM draft, the
authors brought up arguments relating to their interpretation of requirements
against required TLS server certificate validation by the client.
Let me try to hopefully correctly restate and provide my thoughts,
if i am
> I am not aware of any IPR against BRSKI-AE.
>
> Hendrik
>
> > Von: Toerless Eckert
> >
> > Dear subject draft authors and ANIMA WG:
> >
> > I am working on the document shepherd for draft-ietf-anima-brski-ae. Here
> > are the IPR
On Wed, Apr 19, 2023 at 04:43:36PM -0400, Michael Richardson wrote:
>
> Toerless Eckert wrote:
> > 2. I would suggest to move RFC7030 to normative references. This would
> make
> > it consistent with lightweight CMP references also being normative, and
> given
Dear authors
Thanks a lot for the work on the document (and as well thanks to all reviewers).
Please fix the following issues and upload a new version.
>From Brian Carpenters review:
1. Michaels recommendation: Please replace URL for reference [BRSKI-AE-overview]
with one pointing to the
Dear subject draft authors and ANIMA WG:
I am working on the document shepherd for draft-ietf-anima-brski-ae. Here are
the IPR question. The chairs must have answers for a) in order to forward this
work (authors may reply to chairs only). If any one happens to know (b), then
please reply to
ts authors. The authors therefore think
> > is ready for WGLC. Please send your comments by April 3rd 2023. If you do
> > not feel this document should advance, please state your reasons why.
> > Toerless Eckert is the assigned document shepherd.
> >
> > Regards,
> >
Thanks Sheng!
We have now also uploaded the agenda on the notes page, so it's easier to
collaboratively edit,
and we will take notes on it during the meeting as we did during the last
meetings as well:
https://notes.ietf.org/notes-ietf-116-anima
Please check if the session you requested is
Infrastructure Certificate and Certificate Revocation List
592 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
593 <https://www.rfc-editor.org/rfc/rfc5280>.
595[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)"
:29:07PM +0100, Toerless Eckert wrote:
> Dear ANIMA WG
>
> The preliminary IETF116 agenda is on the web.
> ANIMA WG will meet at IETF116 for one 2 hour slot:
> Thursday March 30th, 09:30-11:30 (Session I), Room G317, MEETING TIMEZONE
> (Japan).
>
> [ Unfortunately, this
Thanks, Rich, inline
On Wed, Mar 01, 2023 at 12:49:33AM +, Salz, Rich wrote:
> >Yepp. I understand the high level point in the meantime. I wonder how
> >commonly
> available protocol options between registrar and CA allow to support
> this. FullCMC seems to support it (hence also EST if CA
Dear ANIMA WG
This message starts the two-week ANIMA Working Group Last Call to
advance draft-ietf-anima-jws-voucher-06, which replaces the
CMS encoding of RFC8366 ANIMA/BRSKI vouchers with JSON and
JSON Web Signing (JWS, RFC7515). This draft is a reference
for draft-ietf-anima-brski-prm (which
s in the CSR or change them. That said, it is up the the certificate
> policy to nail down the things that the CA needs to do to make sure the
> issued certificate is correct.
>
> Russ
>
>
> > On Feb 27, 2023, at 2:17 PM, Toerless Eckert wrote:
> >
> >
Dear ANIMA WG
The preliminary IETF116 agenda is on the web.
ANIMA WG will meet at IETF116 for one 2 hour slot:
Thursday March 30th, 09:30-11:30 (Session I), Room G317, MEETING TIMEZONE
(Japan).
[ Unfortunately, this means that those of you attending remotely from
Europe will have to wake up at
Just opened an issue on github based on our discussion:
Hope this makes sense.
https://github.com/anima-wg/anima-brski-prm/issues/82
>From todays BRSKI meeting discussion, i learned:
registrar-agents should be supported on mobile devices such as (i guess)
iOS/Android/Windows portable devices -
This is the second and final set of review feedbacks for
draft-ietf-anima-brski-prm-06,
sorry for the long time it took.
I am continuing after where i stopped in the first review.
[major]
I am worried about the non-support for the mechanisms of CSRattr in this spec
and
would like to see
Would like to understand lamps experts insight:
1. If a pledge creates some Certificate Signing Request (CSR - whatever
protocol/mechanism),
and later receives a certificate, and trusts it/the sender (through
whatever means,
like RFC7030 TLS connection):
How reasonable or
Given how we didn't have the time to pass the document on so far, please find
attached my editorial review of the document. I think its in very good
functional
description state, but the lange gould be improved via the suggestions i made
Thanks a lot
Toerless
On Thu, Dec 01, 2022 at
On Thu, Nov 03, 2022 at 10:33:47AM +, Michael Richardson wrote:
> > How would you deal with proxies that are on frequencies where the duty
> cycle
> > is limited by law. For example devices on my 868 home automation
> network needs to maintain
> > a 1%/hour duty cycle.
>
> "by
e presence/absence of a service, and its advertised
> lifetime. All of the current discovery methods support that at least.
> For CoAP discovery at least some "service availability parameter" could be
> defined in general so that it can be used for any types of services/resources
e context of CoAP group communication). No pictures there
> unfortunately.
Ok, will check in detail.
Thanks
Toerless
> Esko
>
> -Original Message-
> From: Toerless Eckert
> Sent: Tuesday, November 1, 2022 16:21
> To: Michael Richardson
> Cc: Esko Dijk ; anima@ietf.org;
.: that an error
would be raised (which seems what we should do).
Whats even all this terminology - forward/reverse proxy... Is there a simple
picture anyhwere in any of the RFC references explaining this ?
Thanks!
Toerless
On Mon, Oct 31, 2022 at 03:30:09PM +0100, Michael Richardson wrote:
> Toerl
Can we make sure that the text does explain why the field is not
inclueded, and explain that the packet MUST be rejected if it was included ?
Seems like:
Field is not included and would cause rejection of the packet if it was
present, because it is inappropriate for the initiator to choose the
ank you,
> Steffen
>
> From: Anima on behalf of Toerless Eckert
>
> Sent: Thursday, October 27, 2022 4:26:30 AM
> To: anima@ietf.org
> Cc: anima-cha...@ietf.org
> Subject: [Anima] ANIMA agenda for IETF115 posted
>
> As usual, i have used notes.ietf.or
if permitting, e.g.: if ouy
discussions
on chartered work do not preempt those slots. But there is still the benefit of
having any slides you may want to produce in the proceedings anyhow!
Cheers
Toerless
On Tue, Oct 18, 2022 at 06:31:42PM +0200, Toerless Eckert wrote:
> Thanks, Rol
As usual, i have used notes.ietf.org for the agenda, please see:
https://notes.ietf.org/s/notes-ietf-115-anima
Pls. check if your request for a slot was correctly honored, if not, please get
back to us chairs immediately.
I have sent a separate email to those with WG drafts for which no slot
Thanks, Roland
It would actually be interesting to see a presentation and feedback in Roll
because that is where the RPL experts could chime in with opinion.
try to present a m
But please put in a request for ANIMA as well, and we will see if it can fit the
agenda. I think it should
Cheers
Dear ANIMA WG
With IETF115 agenda being finalized on friday, ANIMA WG will meet at IETF115
for one 2 hour slot:
Thursday November 10th, 13:00-15:00 (Session II), Mezzanine 10-11, UTC
(this time TZ is easy, UTC = local! ;-)
Please submit your requests for Agenda items in reply to this email, as
Dear authors
Thank you so much for the document. really nice
I have i think almost exclusively NITs for textual quality and hopefully useful
additional
text suggestion to clarify what ultimately is (at least to me) quite a complex
technology.
Maybe i am not the only one who would benefit from
Thanks, Esko
inline
On Wed, Sep 21, 2022 at 10:52:47AM +, Esko Dijk wrote:
> Thanks,
>
> One item I forgot to include which was also on my mind - a security
> consideration. If an autonomous bootstrap method like BRSKI is left
> "always-on" in a mesh network, it means that at any time an
On Thu, Sep 08, 2022 at 12:44:05PM +0200, Hendrik Mahrt wrote:
> > On the other hand, a more typical ISP situation is there is a router with
> > three or four WAN links, each of which is a p2p ethernet. In that case,
> > there is really only one peer on each link, and it makes no sense not to
>
On Wed, Sep 07, 2022 at 05:12:44AM -0400, Michael Richardson wrote:
> My thinking, which may be entirely wrong, is that the idea is to keep at most
> three IPsec tunnels up with potential parents.
I think ACP does not describe anything like this (which is fine, because
optimizations only need to
Hi Hendrik,
The questions you ask are referrring to details of
rfc8994 that where contributed by Pascal Thubert, and i am
not deep enough into RPL details to answer, so Cc'ing ROLL WG to
maybe get more insight. Michael Richardson might also know...
I do remember that i successfully tested
Dear ANIMA WG
This message starts the two-week ANIMA Working Group Last Call
to advance draft-ietf-anima-constrained-join-proxy-04,
"Constrained Join Proxy for Bootstrapping Protocols". The WGLC
ends after September 20th, or when all comments received are discussed.
This document had a prior
On Tue, Aug 30, 2022 at 06:26:41PM -0400, Michael Richardson wrote:
> bc> Right. So I'm not yet convinced we should repurpose the session ID for
> bc> this. If we're going to focus on signing objectives, maybe we need to
> bc> decouple this aspect completely from the session ID?
>
> I
On Sat, Aug 27, 2022 at 09:41:20AM +1200, Brian E Carpenter wrote:
> > The way i see it, whenever i hae to send another periodical instance of my
> > own
> > M_FLOOD(s), then i would use a new session-id, and that would perfectly be
> > valid
> > as a Epoch-ID... except that if i randomnly
On Thu, Aug 25, 2022 at 11:55:13AM -0400, Michael Richardson wrote:
> Ah.
> A trusted third party would rain Epoch IDs down on all nodes, both
> transmitters and
> receivers. They could use signed M_FLOODs.yes, that creates a circular
> problem, but the EpochIDs could be arranged to be a
On Thu, Aug 25, 2022 at 12:05:54PM -0400, Michael Richardson wrote:
> > Light switches could M_FLOOD instructions, such as in old building
> > automation: GROUP_123 on/off. And lights are then preconfigured to
> > belong to a group. Or as you propose, they could M_FLOOD status, as you
Btw.: I have no strong opinions either way, and i am not the one who
put a + in front of objective for the flood-message. Aka would be curious
about the reason Brian wanted to support multiple objectives in it!
Cheers
Toerless
On Fri, Aug 26, 2022 at 09:14:42AM +1200, Brian E Carpenter
Changing subject because i think this is a broader/different
discussion than GRASP signature/extensions
I can not link ICN to the use-cases you describe. I could however easily map
the resilient light-switch use-case to multicast and GRASP:
Light switches could M_FLOOD instructions, such as in
On Wed, Aug 24, 2022 at 08:33:43PM -0400, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > I need to understand epochs a bit better. I wonder whether an epoch
> > boundary should define when session-id repetition becomes OK (even if
> > highly improbable). There's a
On Wed, Aug 24, 2022 at 04:57:21PM -0400, Michael Richardson wrote:
> > What I don’t understand is why the signature then needs to be encoded
> > as part of the objective. Why can’t I sign a combination of objectives
> > that are only valid as that combination?
>
> I think it could
a flood message.
>
> Sheng
>
> On Wed, 24 Aug 2022 at 07:02, Brian E Carpenter
> wrote:
>
> > On 23-Aug-22 21:56, Toerless Eckert wrote:
> >
> > > Agreed. My opininion is that the mandatory-to-verify is not at the
> > > level of the flood-message,
How about any of this in array context ?
On Tue, Aug 23, 2022 at 01:54:44PM +0200, Carsten Bormann wrote:
> On 2022-08-23, at 13:27, Derek Atkins wrote:
> >
> >tcp-header = {seq: uint, ack: uint, * $$tcp-option}
>
> Right. For the full set of extensibility, today we’d probably
1 - 100 of 551 matches
Mail list logo
