Time for me to update the coaping gem…
Well, yeah, the warning message.
Grüße, Carsten
$ gem install coaping
Fetching coaping-0.0.1.gem
Successfully installed coaping-0.0.1
$ coaping coap.me
Trying 20 times with coap.me at port 5683, waiting 1.0 second max:
/Volumes/nar/Users/cabo-rescue/lib/ru
On 2021-07-22, at 09:45, Carsten Bormann wrote:
>
> Time for me to update the coaping gem…
Done:
VERSIONS:
• 0.0.2 - July 22, 2021 (5 KB)
• 0.0.1 - November 19, 2012 (4.5 KB)
Grüße, Carsten
___
Anima mailing list
Anima@ietf.org
https
Hi,
Maybe not exactly what people are looking for, but below is a link to the
thin-ICE presentation from the T2TRG 2019 session in Singapore.
https://github.com/t2trg/2019-11-singapore/blob/master/slides/44-thin-ICE-151119-Singapore.pdf
Regards,
Christer
-Original Message-
From: cor
> It is not: the REST-level (here CoAP) Content-Type is the media-type of the
> whole thing
Thanks, I overlooked this aspect. That implies that the parameter should,
instead of 'TBD3' what I thought, describe 'voucher in cbor' for which there is
no CoAP cf defined. I assume that the number would
On 2021-07-22, at 10:23, Esko Dijk wrote:
>
> be liberal in what it accepts
Well, Postel’s principle doesn’t apply to wanton extension of the protocol (~
somebody might decide to do something different from the standard, so I’ll
implement my idea of what that could be). If it says you need to
> On 2021-07-21, at 21:36, Michael Richardson wrote:
>
> Signed PGP part
>
> Esko Dijk wrote:
>> There is already a "CoAP ping" described in RFC 7252 that can be
>> used. It does not access any resource, just the CoAP server endpoint at
>> CoAP message layer. As a side effect of this ping you
Hi,
To add my few words,
I am a proponent to explicitly state that the payload is a voucher and
its signature production.
Actually, my code decides what routines to invoke on the basis of that
information.
Peter
Carsten Bormann schreef op 2021-07-22 10:39:
On 2021-07-22, at 10:23, Esko Dij
Michael,
On 2021-07-21, Michael Richardson wrote:
> Esko Dijk wrote:
> > There is already a "CoAP ping" described in RFC 7252 that can be
> > used. It does not access any resource, just the CoAP server endpoint at
> > CoAP message layer. As a side effect of this ping your DTLS stack
> Well, Postel’s principle doesn’t apply to wanton extension of the protocol (~
> somebody might decide to do something different from the standard, so I’ll
> implement my idea of what that could be).
> If it says you need to have X, allowing Y just to get clients to rely on that
> and make li
PS created issue https://github.com/anima-wg/constrained-voucher/issues/143 to
add the COSE 'content type' header parameter requirement to the draft. (Authors
still need to discuss it)
-Original Message-
From: Carsten Bormann
Sent: Thursday, July 22, 2021 10:39
To: Esko Dijk
Cc: draft
> Yes I read the IETF specs and then implement my idea of what these are trying
> to say. It helps if more people are looking at it, as we do in this case :)
> to avoid interpretation errors.
> From what I read, a COSE_Sign1 object can be adequately described by cf=18 so
> that's what I implem
Carsten Bormann wrote:
>> I don't think you should hide the example in the appendix.
>>
>> Rather, I think that you should make it the core of the document,
>> explaining each bit of arcana.
> That sounds like a great project for long winter evenings at the
> fireside. (
Toerless Eckert wrote:
> So: if we wanted to support the COSE content-type field semantically
> correctly, we should ask for another registry entry:
> application/voucher-cbor TBD4
I don't understand what that would be for.
We already are registering application/voucher-cose+cbor i
Esko Dijk wrote:
> object is a Voucher/VR. So to be compliant to the draft I can remove
> support for cf=18 as soon as TBD3 is allocated. I still don't see how
> cf=18 could be 'wanton extension of the protocol' as it is just using
> CoAP/COSE defined mechanisms that apparently ar
On 2021-07-22, at 22:55, Michael Richardson wrote:
>
> Signed PGP part
>
> Toerless Eckert wrote:
>> So: if we wanted to support the COSE content-type field semantically
>> correctly, we should ask for another registry entry:
>
>> application/voucher-cbor TBD4
>
> I don't understand what that wou
Dear Rob, Warren,
As chairs of the ANIMA WG, we hereby request your AD approval
for early allocation of code points from IANA according to RFC7120
for draft-ietf-anima-constrained-voucher.
This is similar to the early registration request we did for what
is now RFC8366 (voucher), where we reques
Overthinking is a result of underspecification in the COSE RFC/bis-draft.
I simply would like for the constrained voucher document to make a statement
about the use of the COSE content type field. I have no strong opinions by now
as to what it should say, but i would like our RFCs not to be unders
Steffen, Michael:
Thursday for BRSKI-AE is fine. I will assume
the split-out JWS voucher draft (Michael wants to publish it as
draft-ietf-anima-jws-voucher-00)
should then also be discussed.
Right now i will account that as one slot. But feel
free to suggest different speaker/slides for both dr
> 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. I am trying to get you to make those decisions.
> Constrained vouchers (application-type/voucher-cose+cbor, TBD3) SHOULD NOT
> use
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
RFC Errata System wrote:
> --
> Type: Technical Reported by: Aman Mangal
> Section: 5.2
> Original Text
> -
>{ "ietf-voucher:voucher": { "created-on": "2016-10-07T19:31:42Z",
> "expires-on": "2016-10-21T19:31:42Z",
Hi Brian and All,
I have an interest on draft-ietf-anima-asa-guidelines. Would you like to pay
attention to draft-dang-anima-network-service-auto-deployment-00?
To achieve the objective of network service auto-deployment, the autonomic
networks ecosystem must design a new ASAs and corresponding
Hi Micheal,
>Probably, just don't be so specific about the values.
>I think that "object-value" can be any amount of CDDL that want to write.
>You could use a map for "service-identification"
>Since it's all encoded in CBOR, you can't have a 3-bit value, only a 1-byte
>value.
A New GRASP Objecti
Dear ANIMA WG
I uploaded the tentative agenda for ANIMA @ IETF111 for Mon and Thu:
https://datatracker.ietf.org/meeting/111/materials/agenda-111-anima-01.txt
I assigned slots for all the requests i received.
If you submitted a request, PLEASE CHECK IF YOU ARE ON THE AGENDA.
If not, please compl
Hi Toerless,
Thank you for posting the agenda.
For Monday session, the time allocation should start from 21:30? The current
time slot looks like starting from 22:30 UTC.
Rgds,
Yizhou
-Original Message-
From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of t...@cs.fau.de
Sent: Frid
Hi Toerless,
Just to clarify the relations of the drafts, draft-ietf-anima-jws-voucher-00
and draft-ietf-anima-brski-async-enroll-03 are two independent drafts. BRSKI-AE
utilizes the JWS-voucher and normatively refers to it.
The split I was referring to relates to the two use cases in BRSKI-AE,
27 matches
Mail list logo
