This emails starts a two week call for adoption for
draft-richardson-anima-jose-voucher
The adoption call does end when Jun 14 has passed for everyone on planet earth.
Justification:
This draft is a core normative dependency for the ANIMA WG document
draft-ietf-anima-brski-async-enroll (BRSKI-AE
[apologies for mixing up june with july. resending to be formally correct.
Thanks Bill!]
This emails starts a two week call for adoption for
draft-richardson-anima-jose-voucher
The adoption call does end when July 14 has passed for everyone on planet earth.
Justification:
This draft is a core
Hi Rob,
Hadn't seen a reply from you to email below.
Also adding Benoit this time around as he was the one who wrote that URL,
not sure hough if he can still trigger to get it updated given his
lack of AD powers now...
Cheers
Toerless
On Mon, May 24, 2021 at 11:12:10PM +0200, Toe
quot; which just two sentences:
This document adds the new JOSE (JWS ?) signature option to vouchers.
This document adds privacy considerations for transporting vouchers.
>
> 170 5. Security Considerations
>
> 172 The issues of how [RFC8366] vouchers are used in a [RFC8995] sys
[Changing subject so it's easier for me to count adoption replies later]
a) Just because this draft does not extend ONE part of rfc8366 (YANG), it does
extend the second
normative part of rfc8366, which is the encoding: rfc8366 only has CMS, with
this update
draft, voucher can have CMS or JOSE.
Hi ANIMA,
What to do when you submitted your draft next week and before IETF111 starts ?
Boredom anxiety ? Try the hackathon!
The BRSKI team has worked over the last months to put together a plan for the
Hackathon to test
BRSKI implementation interop. Feel encouraged to join the effort, or just
t; > From: Rob Wilton (rwilton)
> > Sent: 06 July 2021 09:15
> > To: Toerless Eckert
> > Cc: anima@ietf.org; benoit.cla...@huawei.com
> > Subject: RE: Rob/Benoit: Re: Rob: Can you please (ANIMA marketing...)
> >
> > Hi Toerless,
> >
> > Sorry f
Dear SACM WG, SACM chairs.
When we designed the ANIMA WG solution, we did go to SACM several times
to report and seek input from SACM WG members on the solution.
In May 2021 ANIMA WG finished its charter round 1 (ANI)
consisting of RFC8366,RFC8368,RFC8990,RFC8991,RFC8992,RFC8993,RFC8994,RFC8995.
better now.
What is the worst that can happen ? We could figure out later that we wanted
to
merge the JOSE voucher work back into rfc8366bis. So what ?! No harm done!
Cheers
Toerless
On Thu, Jul 01, 2021 at 06:33:35PM +0200, Toerless Eckert wrote:
> [apologies for mixing up june wi
No need for a that only differ by name, or further pre-WG-adoption version.
Cheers
Toerless
On Fri, Jul 16, 2021 at 12:49:07PM -0400, Michael Richardson wrote:
>
> Toerless Eckert wrote:
> > Please attempt to solve as many as possible of the textual details
> brought
&g
Wrt to the discussion today at he Hackathon, i am trying to figure out
how the header hierarchy for constrained voucher would work:
We use a CoAP session.
As a payload of CoAP, we indicate a COSE message, so
somewhere in a CoAP header we have a (hopefully ?) binary field for
the message type, and
Dear ANIMA WG
The constrained BRSKI team is actively working on their impleemntations, also
in the hackathon (see hackathon wiki for daily time and meeting coordinates).
Today we ran into the issue that the implementations need early allocations
codepoints so as to not run into implementation/in
Working on IETF111 chair slides i just stumbled over one process step:
a) Dear authors of draft-richardson-anima-jose-voucher and ANIMA WG:
This is the IPR poll for draft-richardson-anima-jose-voucher
We need for each of you authors to make an IPR statement about the draft.
As applicable, for e
formats
> aren't defined it will also work in practice.
> For example my servers should also accept content-format 18 just as TBD3.
> So all in all I would say leaving out the 'content type' parameter always
> will just work and it will only be needed once a new content
On Thu, Jul 22, 2021 at 02:47:33AM +0200, Carsten Bormann wrote:
> >
> >> Now, there is in the COSE header also a parameter paramaeter called
> >> "content type"
> >
> > In my implementation I don't use the 'content type' header in COSE because
> > it is duplicate.
>
> It is not: the REST-leve
't know what purpose it serves and if we wanted it to serve a purpose
it
sounds as if we would need to assign more useless code points.
Cheers
Toerless
On Thu, Jul 22, 2021 at 04:55:59PM -0400, Michael Richardson wrote:
>
> Toerless Eckert wrote:
> > So: if we wanted t
Dear draft-ietf-anima-voucher-delegation authors,
I have not seen a slot request for subject draft. I will list it for the
time being as to be reported during Chair slides, but you are more than welcome
to request a slot.
Cheers
Toerless
___
Anima
On Fri, Jul 23, 2021 at 03:15:09AM +0200, Carsten Bormann wrote:
> > Overthinking is a result of underspecification in the COSE RFC/bis-draft.
>
> This is not underspecification; this is leaving decisions to the protocol
> using COSE.
Underexplained how/why to make specific decisions based on un
On Fri, Jul 23, 2021 at 08:38:31AM -0400, Michael Richardson wrote:
> > My sugestion for the constrained voucher text is:
>
> > Constrained vouchers (application-type/voucher-cose+cbor, TBD3)
> > SHOULD NOT use the COSE header "content type" field because the
> > encoding is neve
Thanks. dded as note to chair slides
On Fri, Jul 23, 2021 at 08:40:56AM -0400, Michael Richardson wrote:
>
> Toerless Eckert wrote:
> > I have not seen a slot request for subject draft. I will list it for
> > the time being as to be reported during Chair slides
On Fri, Jul 23, 2021 at 08:39:59AM -0400, Michael Richardson wrote:
>
> Carsten Bormann wrote:
> > Are you also saying that they should/should not use “countersignature”?
> > Maybe a single sentence that explains that there are no header
> > parameters in use expect those that you spe
Unfortunately, i have to pile on instead of just answering:
I can not remember that we ever constructed a case where his
field was necessary when we wrote rfc8366. At least, we did
not document it e.g. in the examples. Such an example, explanation
would now be very helpfull in answering your ques
Dear WGs
For those of you here on the list who are new to ANIMA and
would be interested in an overview and status report of ANIMA,
i will be giving those this week because of us finishing
ouur charer round 1 work before this IETF:
First and last session of the week:
Monday session 1 in SACM WG
into rfc8366bis
so readers can understand why this differentiation by KeyIdentifier
may be useful to have.
Cheers
Toerless
On Fri, Jul 23, 2021 at 10:00:40PM +, Max Pritikin (pritikin) wrote:
> Inline,
>
> > On Jul 23, 2021, at 11:34 AM, Toerless Eckert wrote:
> >
> >
ers can understand why this differentiation by KeyIdentifier
> may be useful to have.
>
> Cheers
>Toerless
>
> On Fri, Jul 23, 2021 at 10:00:40PM +, Max Pritikin (pritikin) wrote:
> Inline,
>
> On Jul 23, 2021, at 11:34 AM, Toerless Eckert
> mailto:t...@cs.
This goes back to your observation from the content-type discussion:
"Data items not mentioned SHOULD be ignored."
BUT: Vendors (running MASA) could be very curious. Lightbulbs enrolling
may want to encode in some opague data of the VR (such as the cert)
information spoofed about the environment,
Dear WG
The authors asked me to reorder agenda items on thursday, pls. check
when you need to speak, updated agenda on CodiMD:
https://codimd.ietf.org/notes-ietf-111-anima?view
and below
Also, i am not seeing slides for #6 (RFC8366bis) #7 (constrained
voucher/hackathon).
No slides is fine, if
I am pretty sure something on your side failed because i did
never reject any uploaded slides. But the 15 minutes prep before
the session was very good. Will have to remember to ask anyone
planing to be active (presenting etc) to join 15 mins before
the WG meeting next time.
Lets use the BRSKI wee
Michael, *:
Wrt to the erratas:
https://www.rfc-editor.org/errata_search.php?rfc=8995&rec_status=0
I do agree that support for rfc6066 SNI would be great to have.
I do not know if/what difference to implementations it would make
if an errata is "validated" or if it is just assessed as
"hold for
I would not say "standard dual stack" because i think the requirements
can be even less IPv6 than what i consider to be standard dual stack
with our existing ANIMA RFCs:
A) The networks data-plane can be almost (*) solely IPv4 if that is the
(enterprise, industrial,...) network stack desired in a
On Thu, Aug 05, 2021 at 05:57:25PM -0400, Michael Richardson wrote:
> Toerless Eckert wrote:
> > Wrt to the erratas:
> > https://www.rfc-editor.org/errata_search.php?rfc=8995&rec_status=0
> > I do agree that support for rfc6066 SNI would be great to have.
&
FYI.
-Original Message-
From: ietf [mailto:ietf-boun...@ietf.org] On Behalf Of NomCom Chair 2021
Sent: Monday, August 30, 2021 10:04 PM
To: IETF Announcement List
Cc: i...@ietf.org
Subject: NomCom 2021-2022 Call for Nominations
Finally! The moment we've all been waiting for:
C A L L
I am fine with this recommendation.
Cheers
Toerless
On Thu, Aug 26, 2021 at 10:24:32AM -0400, Michael Richardson wrote:
>
> In issue
> https://github.com/anima-wg/constrained-voucher/pull/130/files#diff-b1a883ba872bd532268c7ac5ad10aeea2e77bba494569031f1e5d392b5f7cd91R666-R667
>
> Carsten a
The authors have
addressed all known comments and think the document is ready for WGLC.
Please send your comments by Nov 1st, 2021 (any time zone). (**)
If you do not feel this document should advance, please state your reasons why.
Toerless Eckert is the assigned document shepherd.
Thanks a lo
Dear authors of
draft-ietf-anima-brski-cloud
draft-ietf-anima-constrained-join-proxy
draft-ietf-anima-jws-vouc...@ietf.org
I see you progressed the wor on your document since last IETF, but i did not
find any request for a slot at IETF112. If this is an error on my side (email
mes
Initial IETF112 ANIMA agenda uploaded. Master is on hedgedoc:
https://codimd.ietf.org/notes-ietf-112-anima
I send reminder to those WG document authors that updated their
work but didn't send rquests for slots.
For everybody, please propose your slides (if any, none needed, talking faces
are gr
Hi folks
Special recognition promised to whoever is willing to be the notes taker for
the ANIMA WG meeting!
Pls. let us chairs know!
Thanks
Toerless
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
the authors for all the work inested into this so far!
Cheers
Toerless (as co-chair)
On Sat, Oct 16, 2021 at 04:53:43AM +0200, Toerless Eckert wrote:
> Dear ANIMA WG
>
> This message starts the two-week ANIMA Working Group Last Call to advance
>
> Guidelines for Autonomic
Dear ANIMA-WG
draft-ietf-anima-grasp-distribution authors already told the WG in July, that
this draft is ready for last call. I would like to see if one (or more ;-) of
you WG members would like to volunteer becoming Shepherd for this document
to start guiding it through WGLC. Ideally one of you
Dear ANIMA WG
To move the discussion from IETF112 meeting to the mailing list:
a) To be able for other drafts to extend the RFC8366 voucher YANG data model,
we need
to fix up the RFC8366 voucher model. This is the smallest possible RFC8366bis
scope.
b) We can make the scope bigger by also addi
The authors of draft-dang-anima-network-service-auto-deployment have asked
ANIMA WG for
adoption of the work.
Given how we are probably all still exhausted from IETF112, let me give this
one a bit more time:
This emails starts a three week call for adoption for
draft-dang-anima-network-service
tc.pp: aka: answering all the question to round up such an
example is the easiest way to determine if there are just minor
or any mayor gaps in the proposed approach.
Thanks!
Toerless
On Tue, Nov 16, 2021 at 03:17:27AM +0100, Toerless Eckert wrote:
> The authors of draft-dang-anima-ne
On Tue, Dec 14, 2021 at 03:28:52PM -0500, Michael Richardson wrote:
> But, no point in advertising in GRASP (over an ACP) an objective that only be
> satisfied by going to the dataplane to do IPv4.
ASA would use the ACP (IPv6) to coordinate amongst each other for
some autonomic function, BUT: The
Dear ANIMA WG members,
I have refreshed the two drafts to complete a solution for a real standalone
ACP:
a) use DNS-SD service compatible service discovery in ANIMA/ACP via GRASP:
https://datatracker.ietf.org/doc/draft-eckert-anima-grasp-dnssd/
b) Use service discovery for ANIMA/ACP to autoco
l the same, I think this approach to integrating GRASP-based service
> management with DNSSD and with legacy NOC services is very interesting
> and seems to be something ANIMA should consider carefully.
>
> Could the authors deal with the various TBDs in both documents?
>
> Regar
[adding anima]
One should not be surprised to see a lot of outages to be related to
loss of connectivity and/or control due to non-understood circular dependencies.
This is certainly true for several of the big outages reported, such as
some complex mutual automation control failure in Google a fe
Please see https://notes.ietf.org/notes-ietf-113-anima
We are happily accepting notes takers!
I added slots for all requests i received. If you did send a request but do not
see a slot, please contact us cahirs.
(also if you see any other bugs)
Please upload/propose slides when you have written
https://datatracker.ietf.org/meeting/113/materials/minutes-113-anima-01
If you have suggestions for fixes, pls. just edit into notes.ietf.org source:
https://notes.ietf.org/notes-ietf-113-anima
And let us chair know, we will then re-import the notes.
Cheers
Toerless
___
Hi Rob
This request here somehow fell through the cracks. Pls. approve.
Thanks
Toerless
In-Reply-To:
On Tue, Jul 27, 2021 at 03:02:45PM -0400, Warren Kumari wrote:
> This sounds fine to me, but actual approval should come from Rob.
> W
>
> On Thu, Jul 22, 2021 at 7:35 PM wrote:
> >
> > D
> 6.5.1. Discovery
>
>The Pledge discovers an IP address and port number that connects to
>the Registrar (possibly via a Join Proxy), and it establishes a DTLS
>connection.
This is very terse and possibly not completely correct.
How about:
The Pledge discovers an IP address a
ut the modified BRSKI in this solution without
having a proper name for it. Could we / should we not call it cBRSKI, C-BRSKI,
CBRSKI
or anything similarily compact ? And of course put it in the title - (cBRSKI)
instead of (BRSKI).
4. Wrt to 6.5.1
> Toerless Eckert wrote:
>
Malisa,
Thanks a lot for the review.
Just quick feedback on one of your points
On Fri, Apr 08, 2022 at 06:23:38AM -0700, Mališa Vučinić via Datatracker wrote:
> Interoperability-wise, the operation of a Stateful Join Proxy does not seem to
> necessitate a standardization effort as the processing
s therefore think is ready for WGLC.
Please send your comments by April 25th 2022.
If you do not feel this document should advance, please state your reasons why.
Toerless Eckert is now the document shepherd.
Cheers
Toerless
(*) rounded up to the next
On Sat, Apr 09, 2022 at 02:45:20PM +1200, Brian E Carpenter wrote:
> > Toerless askes for WG adoption of both drafts.
>
> I haven't re-reviewed these recently but I did study them quite a while ago
> and verified (by implementing it) that the GRASP/DNSSD interface works
> quite well. I agree with
Note: I am writing this as a problem against only the join-proxy draft, but i
think
there may also be text affected in constrained-voucher. I just have not checked
specifically which text.
draft-ietf-anima-constrained-join-proxy:
1. GRASP discovery
514 6.1.2. GRASP discovery
516Th
Thanks Brian, inline
On Wed, Apr 13, 2022 at 08:45:39AM +1200, Brian E Carpenter wrote:
> If RFC8990 has a weakness, it is indeed that only the initial registration
> of a GRASP objective requires a specification and expert review. Personally
> I think this is a good thing, since it allows for fle
On Wed, Apr 13, 2022 at 01:19:21PM -0400, Michael Richardson wrote:
(1)
> Yes, you are right, we need to have a new objective to announce.
> I guess that we don't really think about the constrained-join-proxy really
> being used in an ACP context, but we really should that right.
I don't think t
lly the question where/how those constrained vouchers would be used in
mesh networks and what
gaps those mesh networks might have.
6TISCH for example seems like not having something useful for discovery right
now if i correctly
extrapolate MichaelR's last reply here.
CHeers
Toerless
Line numbers are from ID-Nits
3 anima Working GroupM. Richardson
3 Internet-Draft Sandelman Software Works
4 Intended status: Standards Track P. van der Stok
5 Expires: 16 Octob
ry
> > right now if i correctly
> > extrapolate MichaelR's last reply here.
> >
> > CHeers
> > Toerless
> >
> > >
> > > Regards
> > > Brian
> > >
> > > On 26-Apr-22 12:16, Toerless Eckert wrote:
> &
Sorry for cross-posting, but this is one of those (set of) question(s) that
likeley need it.
RFC7390 (and its -bis draft) define CoAP discovery via ASM IP Multicast
request/reply
on ff0x::fd, with link-local (ff02::fd) for LANs and ff05::fd (Admin Scope) for
L3 networks.
I am wondering what in
In ANIMA, we do have a bootstrp service (RFC8995), which has two service
points, registrar and proxy. We primarily use GRASP and not DNS-SD
for its "original" instance (with RFC8994), but we also defined service
names brski-proxy / brski-registrar.
Now we're working on variations of this service,
e detail. The following changes are necessary
>with respect to figure 10 of [RFC8995]: * The transport-proto is
>IPPROTO_UDP * the objective is AN_JOIN_PROXY * the objective name is
>empty The constrained Join Proxy announces itself using ACP instance
>of GRASP using M_FLOOD messages. Autonomic Network Registrars MUST
>support GRASP discove
On Mon, May 02, 2022 at 01:22:33PM -0400, Michael Richardson wrote:
> I am saying that the existing GRASP M_FLOOD specified in RFC8995,
>
> and I'm saying that we'd have:
>$transport-proto /= IPPROTO_UDP ; ...
Agreed.
> GRASP DULL is easy.
> In some sense, for IoT networks, there is *only*
emporal epistemologist
> www.strayalpha.com
>
> > On May 1, 2022, at 8:15 AM, Toerless Eckert wrote:
> >
> > In ANIMA, we do have a bootstrp service (RFC8995), which has two service
> > points, registrar and proxy. We primarily use GRASP and not DNS-SD
> > for
On Tue, May 03, 2022 at 11:50:10AM -0700, Stuart Cheshire wrote:
> > I guess this could happen when we come up with different
> > protocols all running on top of coap (given how the service instance
> > port number is only bound to the coap layer).
>
> That would be a bad design.
>
> The service
Oops, sorry, yes, the service names use -, the . is the coap level discovery
naming.
No idea yet, whether there is an actual need for that difference (still getting
up to
speed with coap).
On Tue, May 03, 2022 at 03:54:01PM -0700, Stuart Cheshire wrote:
> On 3 May 2022, at 12:39, Toerl
Thanks, Tim, but i don't see rfc8552 updating or even mentioning rfc6763,
so i do not understand how it would be applicable to DNS-SD
Cheers
Toerless
On Tue, May 03, 2022 at 07:44:51PM -0400, Tim Wicinski wrote:
> On Tue, May 3, 2022 at 7:31 PM Toerless Eckert wrote:
>
> >
On Mon, May 02, 2022 at 01:22:33PM -0400, Michael Richardson wrote:
> > How about cert renewal, did you folks discuss if this would ever be
> something
> > pledges would want to do through the proxy ? In the case of ACP we did
>
> Nope, never. Just like in BRSKI.
Just for the fun of it i
On Thu, May 05, 2022 at 01:16:12PM -0400, Michael Richardson wrote:
> Toerless Eckert wrote:
> > Just for the fun of it i just registered service-name est-coaps against
> RFC9148 with IANA
> > yesterday, like Jack registered "est" against RFC7030 a decade
>
Carsten:
Thanks for the insight , some comments and Q..
All the coap(related) RFCs still leave open the question what, if any,
option there is to zero-touch discover (and ideally set up) discovery
in mesh networks, or for that matter any other L3 networks with lets
say two or more router hops.
On Sat, May 07, 2022 at 06:32:57PM -0400, Michael Richardson wrote:
>
> Toerless Eckert wrote:
> >> I'm not sure that I agree with the name "est-coaps", as I think it's
> still
> >> "est" with a transport of CoAP/UDP.
>
>
nd how to use those – e.g. as we do for GRASP in BRSKI.
> Similar details could be added for some of the other alternatives, perhaps.
>
> Esko
>
>
> From: Ted Lemon
> Sent: Wednesday, May 18, 2022 02:01
> To: Toerless Eckert
> Cc: Esko Dijk ; dn...@ietf.org
> S
Dear ANIMA WG
FYI:
I am going to ask the IETF secretariat to close down the two old
"sub" mailing lists that we had created shortly after creation of the
ANIMA WG to reduce the "load" on the main ANIMA mailing list for
BRSKI and GRASP specific work. The last messages to these lists where
from 201
FYI:
Zulip is the new tool to be used instead of jabber for the IETF,
starting to be officially used @IETF114.
Service is via web: zulip.ietf.org or via downloadable app from www.zulip.com.
Login is via datatracker account, so no separate accounts needed/possible.
The channels on zulip (called
Hi Rob,
We just had another meeting of the design team and feel it is necessary to do
some
move of text about discovery from join-proxy to constrained-voucher (including
change of announcements) to make it more correct. I also have an even larger
WG-last
call review i have been working on i need
Can we delay this iot-ops review for a moment ?
I also had put into github as well as in before to the anima list what i think
would be a mayor design improvement for the join-proxy:
https://github.com/anima-wg/constrained-join-proxy/issues/21
Aka: Right now, if we come up with a different link-
Dear ANIMA WG
Just as another encouragemenet to submit your agenda requests:
https://datatracker.ietf.org/meeting/114/important-dates/
2022-07-13 Wednesday Draft Working Group agendas due by UTC 23:59
Upload using the Meeting Materials Management Tool.
Cheers
Toerless
On Th
Thanks, sheng, please consider me putting in a request for 5 minutes
asking WG for call for adoption of the DNS drafts;
draft-eckert-anima-services-dns-autoconfig
draft-eckert-anima-grasp-dnssd
5 minutes for both together.
On Fri, Jul 15, 2022 at 7:28 AM Sheng Jiang wrote:
>
> Hi, all,
>
> The
Dear Colleagues. Let me know who of you would be happy to help with note taking
tomorrow, so we do not have to waste time figuring that out in the session!
Thanks,
Toerless
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/
Minutes, Michael Richardson
>
> draft-richardson-emu-eap-onboarding, 5~10 Minutes, Michael Richardson
> draft-eckert-anima-services-dns-autoconfig
> & draft-eckert-anima-grasp-dnssd, 5 Minutes, Toerless Eckert
>
> Sheng
>
> On Sat, 16 Jul 2022 at 08:54, Sheng Jiang
Dear WG draft authors.
I saw uploaded slides from Michael for constrainned-proxy, but none for
constrained-voucher, so for now i have designated the 10 minute slot for
constrained-proxy, but if you want another slot for constrained proxy, let me
know, otherwise i'll see that we summarize any work
Dear subject draft authors,
I have not seen a slot request or uploaded meeting materials for subject draft.
Given how this is a working group draft and did receive an update since last
IETF,
please provide some summary of the work, which i will happily add to notes
during
chair slot. Otherwise,
Dear subject draft authors,
I have not seen a slot request or uploaded meeting materials for subject draft.
Given how this i
Dear subject draft authors,
I have not seen a slot request or uploaded meeting materials for subject draft.
Given how this is a working group draft and did receive any work since IETF113,
its probably easiest to add a status update during the chairs slot. Pls.
check what i already whipped up on th
Thats fine, i will simply add the voucher as being updated on that slot.
On Sun, Jul 24, 2022 at 04:38:06PM -0400, Michael Richardson wrote:
> Toerless Eckert wrote:
> > I saw uploaded slides from Michael for constrainned-proxy, but none for
> > constrained-voucher, so
Dear presenters / slide creators for the following drafts:
draft-ietf-anima-jws-voucher
draft-ietf-anima-grasp-distribution
draft-richardson-emu-eap-onboarding
draft-eckert-anima-services-dns-autoconfig
We have not yet received slides for your allocated slot.
Please upload the slides to
Let me rephrase to make clear i understand.
We've got (A) BRSKI, and (B) and (C) two "independent" amendmentds
driven as independent RFCs. And neither (B) has (C) as reference,
nor vice versa, but both refer only to (A).
When a user wants to build product incorporating (A), (B), (C),
i am sure th
For all on the list who may not know all those "status upgrade" aspects, some
details:
The status of an IETF standards track document is NOT in the document itself.
The document itself just says "Standards Track".
But you can see it on the datatracker page:
https://datatracker.ietf.org/doc/
Thanks for the pointer. Interesting, but frustrating read explain as much of
the important solution details as ACP drafts did when they where only 30 pages
long ;-)).
I am professionally pessimistic about the performance characteristics of
distributed set
reconcilliation via Invertible Bloom Loo
[ Sorry for cross-post but given how this is about ANIMA GRASP, a CBOR
protocol, i think its the best/fastest way to converge. ]
In GRASP (RFC8990] we define the GRASP message structure as follows:
message-structure = [MESSAGE_TYPE, session-id, ?initiator, *grasp-option]
MESSAGE_TYPE = 0..255
On Fri, Aug 19, 2022 at 08:56:35PM +0200, Carsten Bormann wrote:
> > EXTENSION_TYPE = 0..255
>
> There is no reason to limit this to 255.
Agreed. I just copied from MESSAGE_TYPE in GRASP.
> ➔ EXTENSION_TYPE = uint
>
> (Do you plan to creat a registry for these?
Probably we should. Typical subd
On Sat, Aug 20, 2022 at 04:21:06PM -0400, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > We would prefer that this doesn't invalidate existing (unsigned) GRASP
> > code. That could be done by appending an optional signature to the
> > existing M_FLOOD message format. An al
On Sat, Aug 20, 2022 at 10:01:37AM +1200, Brian E Carpenter wrote:
> Ditto, but referring to CDDL details. Off list, I suggested:
>
>grasp-option = numeric-option / objective
>numeric-option = option .within option-structure
>option-structure = [0..255, any]
>
> and then
>
>optio
On Tue, Aug 23, 2022 at 10:57:44AM +1200, Brian E Carpenter wrote:
> > In my reading of rfc8990 CDDL, an M_FLOOD message with an appended
> > signature would NOT be parsed as an rfc8990 flood-message CDDL name,
> > which in my book means it wouldnot be an rfc8990 flood message. Aka:
> > i do not se
On Mon, Aug 22, 2022 at 08:43:57PM +0200, Carsten Bormann wrote:
> Grasp-option really is the lower layer of extensibility, which allows you to
> create new messages that then conform to message-structure. These should
> provide maximum flexibility.
>
> (Message should be/employ a socket, to ma
On Mon, Aug 22, 2022 at 08:43:57PM +0200, Carsten Bormann wrote:
[... snip...]
> > 2) Still want to understand .within correctly i think it does not doe
> > not work as you hope above.
> >
> > Carsten claimed offlist, that in your above syntax, grasp-option would
> > match some option that is not
Thanks, Derek
inline
On Tue, Aug 23, 2022 at 07:27:40AM -0400, Derek Atkins wrote:
> On Tue, August 23, 2022 6:30 am, Toerless Eckert wrote:
> > On Mon, Aug 22, 2022 at 08:43:57PM +0200, Carsten Bormann wrote:
> >> Grasp-option really is the lower layer of extensibility, which
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 say:
gt; define 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
1 - 100 of 701 matches
Mail list logo
