Re: [Anima] [Technical Errata Reported] RFC8995 (6649)

Greetings, This errata reports a problem with Section 5.4/RFC 8995. Upon further review, we believe it should point to Section 5.5.4./RFC 8995. We have updated accordingly. Please let us know any concerns. Thank you. RFC Editor/cs > On Jul 26, 2021, at 7:29 PM, RFC Errata System > w

Re: [Anima] unsolicited syn messages and selective flooding in grasp

Hi Yizhou, GRASP synchronization is a request/response protocol, so with no request, there can be no response. How does the ASA that sends an unsolicited M_SYNCH know where to send it, and how would the remote ASA tell GRASP that it wanted the result? The answer is that it's impossible, so you

Re: [Anima] Rob/Warren: Early allocation request for draft-ietf-anima-constrained-voucher (according to RFC7120)

This sounds fine to me, but actual approval should come from Rob. W On Thu, Jul 22, 2021 at 7:35 PM wrote: > > 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-constraine

Re: [Anima] x5bag in pledge->registrar

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,

Re: [Anima] Registrar certificate EKU bits

Peter van der Stok wrote: > A section describing certificate requirements (grouping them all) is > necessary for constrained voucher and BRSKI RFC. > Suggestion: a new document? Maybe. What does the WG think? Existing documents that already deal with 90% of the certificate issues:

[Anima] unsolicited syn messages and selective flooding in grasp

Hi, When reading RFC8990 and draft-ietf-anima-grasp-distribution, I found RFC8990 allows Flood Synchronization Message (section 2.8.11) to be *unsolicited* but Synchronization Message does not allow so. I guess that's why unsolicited_synch-message is defined in section 5.1 in draft-ietf-anima-

Re: [Anima] New Version Notification for draft-dang-anima-network-service-auto-deployment-00.txt

Hi, Thanks for your kind reminder and suggestion. I have studied GRASP Objective allocations in RFC8994 which is very helpful for me. The GRASP objective between Network Initiator and SPE is an example as follows. The formal definition of the objective in CDDL (see "Concise Data Definition L

Re: [Anima] draft-bernardos-anima-fog-monitoring-04

The flag bits are simply part of the objective option, so they are always included in the discovery message (see https://www.rfc-editor.org/rfc/rfc8990.html#name-format-of-objective-options). It MAY also be present in the response. It could be used for a consistency check or used actively in Dry Ru

Re: [Anima] x5bag in pledge->registrar

Fully agree peter Michael Richardson schreef op 2021-07-27 04:15: In the hackathon work a Registrar implementor noticed an x5bag on the BRSKI-EST link (Pledge->Registrar) I think that the DTLS Client Certificate (and chain) is always better. But, I guess we should say something about why the R

Re: [Anima] Registrar certificate EKU bits

To be quite honest: A section describing certificate requirements (grouping them all) is necessary for constrained voucher and BRSKI RFC. Suggestion: a new document? Peter Michael Richardson schreef op 2021-07-27 04:18: Esko Dijk wrote: If the EKU is present, it will restrict the allowed u

Re: [Anima] draft-bernardos-anima-fog-monitoring-04

Hi, I am also studying the GRASP objective definition recently. I have one question: why does F_SYNCH_bits appear in the discovery process? Best wishes, Joanna -Original Message- From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: 2021年7月27日 12:41 To: Anima W