> The JSON Compact Serialization is examplained in section 3.1 or section
7.1
examplained?? A great word, but not in my dictionary.
Mainly I can't understand this draft because it's way outside my expertise, but
it seems necessary so I would support adoption.
Regards
Brian
On 30-Jun-21 12:
1) I've already supported adoption.
2)
> (2) Up to the point where an AD or other higher power might have objections,
> i really would like to see this document marked as an Update to RFC8366 so
> that we have a breadcrump trail from RFC8366 to this document (personally
> i am never quite sure wh
> >I am not sure whether we can get
> > enough reviewers to guarantee the quality of this type of format
> > definition.
I think we have a way to do that, which is to ask both Gen-ART and the
Security area for early reviews, right after adoption. This is a problem
for many WGs when they touch a se
below..
On 07-Jul-21 05:15, Michael Richardson wrote:
>
> In section 5.1 of RFC8995, we say:
>
>> Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is
>> REQUIRED on the Pledge side. TLS 1.3 (or newer) SHOULD be available
>> on the Registrar server interface, and the Registrar cl
I've just come across Jeff Mogul's keynote speech about self-driving (i.e.
autonomic) networks from a couple of years ago. Well worth reading before
designing your own autonomic network:
https://conferences.sigcomm.org/sigcomm/2018/files/slides/selfdn/keynote.pdf
Regards
Brian
_
On 11-Jul-21 05:06, Alan DeKok wrote:
> On Jul 10, 2021, at 12:44 PM, Michael Richardson
> wrote:
>> Alan DeKok wrote:
>>> Networks are generally organized by configuration, not by state.
>>> i.e. the "state" of the network, such as it is, is buried inside a
>>> random grab-bag collection of co
Hi,
About draft-ietf-anima-asa-guidelines:
Although we probably want to produce one more version, I think the authors of
this draft feel it is as complete as seems possible at present. So is it
possible to plan a WG Last Call as soon as the next version comes out?
If so, I would suggest that w
Recently I rediscovered something that we included in RFC 8990:
"2.8.3. Message Size
GRASP nodes MUST be able to receive unicast messages of at least
GRASP_DEF_MAX_SIZE bytes. GRASP nodes MUST NOT send unicast messages longer
than GRASP_DEF_MAX_SIZE bytes unless a longer size is explicitly allo
On 27-Jul-21 14:32, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > In other words, the method of bulk transfer described in
> > draft-ietf-anima-grasp-distribution at Section 4.3 "Bulk Information
> > Transfer" could be improved by first
Hi,
One quick comment on the draft.
> An example of discovery message using GRASP would be the following
> (in this example, the fog monitoring controller is identified by
> its IPv6 address: 2001:DB8::::::):
>
> [M_DISCOVERY, 13948745, h'20010db81
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
worked out whether it can actually be
implemented yet.)
Regards
Brian
>
>
> Rgds,
> Yizhou
>
>
> -Original Message-
> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
> Sent: Wednesday, July 28, 2021 4:14 AM
> To: Liyizhou ; anima@ietf.o
On 03-Aug-21 07:55, Michael Richardson wrote:
>
> Fries, Steffen wrote:
> > Based on the discussion in the ANIMA WG last week, I would like to
> > proceed with the discussion on the author's proposal to split the
> > current BRSKI-AE draft
> >
> (https://datatracker.ietf.org/doc/
I am wondering whether we can realistically develop a generic solution
for service deployment. There can be such a variety of services. Can they
really all be described in a single framework? Is there a risk that we
end up with such a general solution that it cannot describe the details
of each ser
I was writing loosely; it's something like RFC8200+RFC4861+RFC4862, which every
o/s of significance has supported for >10 years.
Regards
Brian
On 06-Aug-21 10:25, Toerless Eckert wrote:
> I would not say "standard dual stack" because i think the requirements
> can be even less IPv6 than what
On 21-Aug-21 13:06, Michael Richardson wrote:
>
> Peter van der Stok wrote:
> > What about?
>
> > PRVR = Pledge-Registrar Voucher Request
> > RMVR = Registrar-Masa Voucher Request
>
> I don't object, but remember that the PRVR is also carried across the
> BRSKI-MASA link (inside the
Hi,
When thinking about next steps for draft-ietf-anima-grasp-distribution, I began
to think about the fact that GRASP (RFC8990) defines a default maximum message
size. For distribution of significant amounts of data, this could be an issue.
The RFC says this:
"GRASP nodes MUST be able to recei
Hi,
Following up on my previous message, here are some thoughts about how GRASP
could manage itself. It will be a lame autonomic protocol if it can't manage
itself ;-).
One mechanism is that a "GRASP manager" ASA in an autonomic node associated
with the NOC could send out configuration message
I agree with Michael, this side discussion belongs on the list:
On 23-Aug-21 03:54, Michael Richardson wrote:
>
> {feel free to reply to the list, or tell me to}
>
> Brian E Carpenter wrote:
> >> Toerless Eckert wrote:
> >> > One of things i feel
One point in line:
On 22-Aug-21 10:43, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > (1) Flooding (M_FLOOD) messages. These are UDP multicasts, so in effect
> > all nodes must agree on the same maximum size. To send messages above
> > the pr
On 23-Aug-21 12:26, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> >> Brian E Carpenter wrote:
> >> > (1) Flooding (M_FLOOD) messages. These are UDP multicasts, so in
> effect
> >> > all nodes must agree on the same maximum s
ther "I didn't understand
that".)
Regards
Brian
>
> Regards,
>
> Sheng
>
>> -Original Message-
>> From: Anima On Behalf Of Brian E Carpenter
>> Sent: Saturday, August 21, 2021 1:17 PM
>> To: Anima WG
>> Subject: [Anima] Ho
Hi,
Sorry this version took a long time. There is one small change, a note about
the maximum size of a GRASP objective.
I believe this is ready for WG Last Call.
Regards
Brian
On 13-Sep-21 17:02, internet-dra...@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Interne
ories.
Title : GRASP Configuration Management Objective
Author : Brian E. Carpenter
Filename: draft-carpenter-anima-grasp-config-00.txt
Pages : 5
Date: 2021-09-21
Abstract:
This document specifies a tech
This is the only bit I'm competent to comment on:
On 23-Sep-21 09:20, Michael Richardson wrote:
...
> 4) I also noticed that there is a race condition between seeing the GRASP
>AN_ACP and setting up the policy.
>
>Node A says, "AN_ACP", "I'm here".
>Node B sees it, and initiates to No
On 30-Sep-21 07:04, Michael Richardson wrote:
> On 2021-07-04 6:13 p.m., Michael Richardson wrote:
>> Hi, I have converted RFC8366.xml to Markdown, and switched to the latest MT
>> makefile, and after a bit of small massage to remove "8366" from the page,
>> and point to RFCs which are published, t
Michael,
On 01-Oct-21 06:43, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > Where's the "Changes from RFC8366" section? We need that, for sure.
> > What differences are there, anyway? I don't see anything significant
> > in
I *really* don't understand this stuff, but how long could the rollover
take, for a reasonably large IoT network (presumably thousands of
devices)? Are we talking about a few seconds when no new sessions could
start, or what?
That said, I don't see that you have much choice.
Regards
Brian
On
Hi,
I've looked at this from the GRASP point of view and it all seems fine.
It's perhaps worth noting that GRASP DULL discovery is quite independent
of both CoAP and DTLS. As far as I know, DTLS still can't protect
multicast, so there is no alternative to DULL.
(Something the WG should perhaps co
I'm not sure I've seen a reminder about this very important deadline on the
ANIMA list.
One week to deadline:
https://datatracker.ietf.org/nomcom/2021/nominate/
Brian
Forwarded Message
Subject:Want to be on the IESG?
Date: Fri, 1 Oct 2021 14:18:29 +
From: S
On 06-Oct-21 05:24, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > I *really* don't understand this stuff, but how long could the rollover
> > take, for a reasonably large IoT network (presumably thousands of
> > devices)? Are we talking ab
Esko,
> Also, the document has had little review from the WG so far I could see.
True. Maybe we should also ask for an early review by the Security Area? This
is a rather specialised topic, and I'm not sure this WG has many people with
the skills needed for an independent review.
Regards
Br
I am not aware of any IPR relevant to this draft.
(Co-authors, we should all reply on this point.)
There is no real implementation report for this draft,
but I did work on a very simple version of the ASA
life cycle aspect earlier this year:
https://mailarchive.ietf.org/arch/msg/anima/u1TCJQ0PpOJ
[Repeat with address correction.]
I am not aware of any IPR relevant to this draft.
(Co-authors, we should all reply on this point.)
There is no real implementation report for this draft,
but I did work on a very simple version of the ASA
life cycle aspect earlier this year:
https://mailarchive.
Hi everybody,
Two new items for your reading list:
1) There is a new full length article about ANIMA: "Autonomic Networking Gets
Serious", Internet Protocol Journal 24(3), pp2-18, October 2021:
https://ipj.dreamhosters.com/wp-content/uploads/2021/10/243-ipj.pdf
2) There is a new GRASP tutorial
Hi,
This is an interesting draft and I think the topic is important. Can you please
compare with draft-carpenter-anima-l2acp-scenarios-02? Unfortunately we did not
get much response to that draft 2 years ago.
I don't really understand this statement:
The DULL instance of GRASP is used to dis
The RFC Editor clearly used their own glossary:
https://www.rfc-editor.org/materials/abbrev.expansion.txt
A miss at AUTH48, I fear.
Regards
Brian Carpenter
On 20-Oct-21 16:29, Michael Richardson wrote:
>
> please mark as verified, wait for revision.
>
> RFC Errata System wrote:
> > Th
I want to be very clear that we do not currently have a design for "unsolicited
synchronization" in GRASP that works.
https://mailarchive.ietf.org/arch/msg/anima/31UnJbFe45FZF7u_YQHtJLe9Xv8/
Regards
Brian
On 27-Oct-21 03:04, duzongp...@foxmail.com wrote:
Hi, Yizhou
I have read the dr
How big is the data likely to be, and what is the approximate rate of refreshes?
If these values are low (e.g. 2 kB data once per minute), a GRASP flood would
be sufficient.
If you want an acknowledgment, a flood is not suitable. GRASP synch is acknowledged
implicitly by TCP. If you want any i
Behalf Of Brian E Carpenter
Sent: Wednesday, October 27, 2021 4:55 AM
To: duzongp...@foxmail.com; Liyizhou ; anima@ietf.org
Cc: Xun Xiao
Subject: Re: [Anima] unsolicited synchronizaiton in
draft-yizhou-anima-ip-to-access-control-groups-01.txt
I want to be very clear that we do not currently have a
Just one comment here:
But quite a number of them feel not so comfortable and hard (or not so willing)
to understand to build ACP in ipv6
They do not need to understand IPv6 or do anything except check that the IPv6
stack is enabled in all devices. The ACP will deploy itself without requiri
--
From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Brian E Carpenter
Sent: Thursday, October 28, 2021 11:08 AM
To: Liyizhou ; duzongp...@foxmail.com; anima@ietf.org
Cc: Xun Xiao
Subject: Re: [Anima] unsolicited synchronizaiton in
draft-yizhou-anima-ip-to-access-control-groups-01.txt
unic
.
Regards
Brian
Best Regards
Yujing Zhou
-Original Message-
From: Brian E Carpenter
Sent: 2021年10月28日 10:54
To: zhouyujing (A) ; duzongp...@foxmail.com;
anima@ietf.org
Subject: Re: [Anima] Discussion regarding
draft-dang-anima-network-service-auto-deployment
How big is the
Brian,
Thanks for your reply, allowing me to think about my draft more clearly.
Please see inlines with [yj]. Thanks.
Best Regards
Yujing Zhou
-Original Message-
From: Brian E Carpenter
Sent: 2021年10月29日 11:31
To: zhouyujing (A) ; duzongp...@foxmail.com;
anima@iet
As a reminder to myself: we need to add a point to the security considerations:
https://mailarchive.ietf.org/arch/msg/anima/8TLhWV0NcSOQhKihe-tc5Co1_6g/
Regards
Brian
On 16-Oct-21 15:53, Toerless Eckert wrote:
Dear ANIMA WG
This message starts the two-week ANIMA Working Group Last Call to
Updated as requested by the document shepherd.
Regards
Brian
On 07-Nov-21 13:44, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and
Approach WG of the IET
I agree with Med that the description of the use case is too abstract. I always
try to look at use cases as a programmer: what would I put in my program to
implement this?
So I think the next version should tackle this, possibly as an appendix. Give several specific examples of [restype, resval
I think that the goal of this document is to somehow gateway DNS-SD
requests/replies into GRASP M_FLOOD messages. But, I'm having to reverse
engineer that.
They don't need to be floods. My toy implementation uses GRASP negotiation
to proxy a DNS-SD lookup.
https://github.com/becarpenter/graspy
Thanks Rob, that's a very helpful review. We'll work on an update.
Regards
Brian
On 19-Nov-21 07:27, Rob Wilton (rwilton) wrote:
Hi Authors, ANIMA, Toerless,
My AD review of draft-ietf-anima-asa-guidelines-03 is inline. I have also
attached a copy of my review because the IETF mailer like
Hi Rob, thanks for such a careful review. The -04 version posted a few seconds
ago should respond to your points, but we have inserted comments below.
On 19-Nov-21 07:27, Rob Wilton (rwilton) wrote:
Hi Authors, ANIMA, Toerless,
My AD review of draft-ietf-anima-asa-guidelines-03 is inline. I h
ionable.
-Original Message-
From: Brian E Carpenter
Sent: 24 November 2021 02:56
To: Rob Wilton (rwilton) ; anima@ietf.org; draft-ietf-
anima-asa-guidelines@ietf.org; Toerless Eckert
Subject: Re: AD review of draft-ietf-anima-asa-guidelines-03
Hi Rob, thanks for such a careful review.
On 01-Dec-21 01:55, Esko Dijk wrote:
While reviewing latest updates; one other issue came up: the draft (re latest
in Github) currently mentions DNS-SD as a means for a Pledge to discover a Join
Proxy.
But for DNS-SD discovery I believe a service name is needed; see RFC 6763 Section 7. But th
ssignee: Peter van der Stok
Contact: Peter van der Stok
Description: service name of Registrar server to Join Proxy
Reference [this document]
Port Number: to be discovered.
Known Unauthorized: Uses BRSKI porotocol
Agreed?
greetings,
Peter
Brian E Carpenter schreef op 2021-11-30 20:42:
O
;DULL") side.
Brian E Carpenter wrote:
I think there's another reason for deferring it. We have a pending proposal
in draft-eckert-anima-grasp-dnssd for how DNS-SD will integrate in an
autonomic environment. It seems wise to have more clarity about that before
defining how DNS-SD w
Original Message-----
From: Anima On Behalf Of Brian E Carpenter
Sent: Thursday, December 2, 2021 20:23
To: Michael Richardson
Cc: anima@ietf.org
Subject: Re: [Anima] Constrained-join-proxy: use of DNS-SD discovery of a Join
Proxy
On 03-Dec-21 07:01, Michael Richardson wrote:
* While
Hi Thomas,
Thanks for the careful reading and review. I think we can deal
with all your comments without difficulty. Just two possible
discussion points in line below.
Regards
Brian
On 07-Dec-21 03:58, Thomas Fossati via Datatracker wrote:
Reviewer: Thomas Fossati
Review result: Ready with
This is necessary work and I support adoption (and rapid progress).
Regards
Brian
On 06-Dec-21 19:57, Sheng Jiang wrote:
Hi, all ANIMAer,
This message starts a two-week adoption call for
draft-richardson-anima-rfc8366bis, which we have traced a few discussion and
think the WG is intereste
Thanks Menachem.
There are several diagrams in the IPJ article that we cited. We will think
about whether a version of one of them would help, or whether the reference is
sufficient.
The "Note: This section is to be further developed..." will be removed. Somehow
we missed that during WGLC.
R
Hi Martin,
Thanks for the careful review. I've inserted a few comments in line
below, but we will take care of all your points in the next version.
Regards
Brian
On 13-Dec-21 22:36, Martin Dürst via Datatracker wrote:
Reviewer: Martin Dürst
Review result: Ready with Issues
I'm not an exper
So, congratulations on this RFC. Should ANIMA consider an incompatible update
to RFC8992 to use these new CBOR tags instead of the existing ad hoc solution?
I don't think we have an installed base to worry about, and the difference for
an implementor is not very big.
Regards
Brian
On 14-De
On 15-Dec-21 07:43, Michael Richardson wrote:
Brian E Carpenter wrote:
> So, congratulations on this RFC. Should ANIMA consider an incompatible
> update to RFC8992 to use these new CBOR tags instead of the existing ad
> hoc solution?
Maybe. I'm not sure.
I
On 18-Dec-21 10:42, Michael Richardson wrote:
Toerless Eckert wrote:
> 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.
> A
Hi,
This version is intended to cover the technical and editorial clarifications
raised in the three Last Call reviews that we received.
The main changes:
* Clarified NETCONF wording.
* Removed on advice from IETF Trust
* Noted resource limits in constrained nodes
* Strengthened text on data i
Thanks Warren, some personal responses in line...
On 18-Jan-22 04:16, Warren Kumari via Datatracker wrote:
...
I do have a few (non-blocking) comments:
Introduction:
O: "The net result should be significant improvement of operational metrics."
P: "The net result should be significant improvemen
Thanks John. In line...
On 18-Jan-22 10:48, John Scudder via Datatracker wrote:
Thanks for this document, which was overall informative and easy to read. I do
have a couple small comments.
1. While most terminology is clearly defined, I didn’t find any
definition of
“the decoupled mode” fi
Hi Éric, thnaks for the comments. In line...
On 19-Jan-22 06:02, Éric Vyncke via Datatracker wrote:
-- Section 1 --
Should "ANIMA" be expanded at first use ? Or should it be replaced by "ANIMA
WG" ?
Good catch. I think that both occurrences in the text should just be
"Autonomic Networking" ra
Roman,
Thanks for the review, responses in line.
On 19-Jan-22 15:14, Roman Danyliw via Datatracker wrote:
...
--
DISCUSS:
--
** Section 3.1 and 3.2.
(a) (Se
Hi Ben,
...
--
DISCUSS:
--
It looks like the indentation in the example MAIN PROGRAM in Appendix C
is incorrect, or at least confusing, in the "do forever" loo
Thanks Benno, we'll pick up these points in the next version.
Regards
Brian Carpenter
On 22-Jan-22 07:46, Benno Overeinder via Datatracker wrote:
Reviewer: Benno Overeinder
Review result: Ready with Nits
Intdir Review draft-ietf-anima-asa-guidelines-05
I am an assigned INT directorate revi
Hi,
This version aims to respond to all IESG comments, including the two DISCUSS
comments.
Regards
Brian Carpenter
On 27-Jan-22 15:10, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic
This lacks either an Obsoletes: or Updates: RFC8366 in the header, a
corresponding statement in the Abstract, and an explanation in the text of how
it relates to RFC8366.
I see that the YANG includes this:
This version of this YANG module is part of RFC 8366
Regards
Brian
On 01-Feb-22 13:
This version just fixes three minor editorial issues following the IESG ballot.
Regards
Brian Carpenter
On 02-Feb-22 10:38, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking I
Hi,
I can reply fairly quickly, since I studied these two drafts before,
and prototyped the draft-eckert-anima-grasp-dnssd mechanism.
I haven't exercised that code recently, but it can be found at:
https://github.com/becarpenter/graspy/blob/master/GetDNSSD2.py
https://github.com/becarpenter/grasp
any JSON we want
to all autonomic nodes".
Regards
Brian
Cheers
Toerless
On Sat, Mar 05, 2022 at 02:03:37PM +1300, Brian E Carpenter wrote:
Hi,
I can reply fairly quickly, since I studied these two drafts before,
and prototyped the draft-eckert-anima-grasp-dnssd mechanism.
I have
Hi,
I have a few questions about this draft.
1) Format of objective-value:
objective-value = n-s-deployment-value ; An n-s-deployment-value is defined as
Figure-1.
n-s-deployment-value
+ service-information
+ source-ip-address
+ destination-ip-address
+ servic
On 10-Mar-22 21:52, Toerless Eckert wrote:
[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 problem is as old as distributed computing. I remember the difficulty
of restarti
FYI if you are using or studying my grasp.py code.
I just pushed a new version to GitHub which fixes a serious issue with discovery
responses using the Divert option (O_DIVERT). Previously the code did not conform to
RFC8990 on the wire, and now it does, so this fix is essential and anyone usin
On 03-Apr-22 06:12, Fred Baker wrote:
Gee, I thought we had learned from the OSI debacle that options are places in
which protocols break!
Well, where interoperability breaks, for sure. But sometimes the real world is
complicated enough that there must be choices available.
Sent using a ma
Hi Jürgen,
On 05-Apr-22 20:36, Jürgen Schönwälder wrote:
...
Pvds==>
Now I am confused. I expected you to require more text here.
Something seems to be missing in the description of the base line scenario,
and I need more info to understand what the missing pieces are.
I think it is rather o
DNS-SD Compatible Service Discovery in GRASP
Presenter: Toerless Eckert
Time: 5 minutes
Draft: https://datatracker.ietf.org/doc/draft-eckert-anima-grasp-dnssd/03/ (was
-02 at IETF112)
The document is quite stable and any review is appreciated.
10 Autoconfiguration of infrastructure services
On 10-Apr-22 05:37, Toerless Eckert wrote:
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/
On 12-Apr-22 04:44, Michael Richardson wrote:
Toerless Eckert wrote:
> The main difference is therefore really the replacement of mDNS
> encoding/transport of the service announcements with GRASP
> encoding/transport and we heard from Stuart Cheshire that he agrees and
> sup
On 13-Apr-22 03:00, Toerless Eckert wrote:
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
5
Toerless,
I am asking because if/where there are gaps in supported discovery mechanisms,
we might be able to suggest GRASP without ACP. Which would be somewhat of
another
draft..
The only standards-track requirement for that is that GRASP can run over a
secure
substrate. Been there, done tha
On 27-Apr-22 09:01, Toerless Eckert wrote:
On Tue, Apr 26, 2022 at 04:07:13PM +1200, Brian E Carpenter wrote:
Toerless,
I am asking because if/where there are gaps in supported discovery mechanisms,
we might be able to suggest GRASP without ACP. Which would be somewhat of
another
draft
On 26-Apr-22 19:02, Peter van der Stok wrote:
HI,
To add to the discussion, below the text that I adapted for Graps discovery in
contrsined-join-proxy draft.
Comments are welcome, Corrections are encouraged.
Are you intending to define a new GRASP objective "AN_REGISTRAR"? If so, you must be
On 03-May-22 05:22, Michael Richardson wrote:
Toerless Eckert 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 shoul
Toerless,
Needless to say, I like this:
And a small GRASP daemon using the same DTLS as BRSKI is equally simple to
develop
(i claim) as a proxy daemon. Certainly a completely different ballpark than
trying to get network layer IP multicast
However, in fairness, the part of GRASP tha
On 06-May-22 05:37, Michael Richardson wrote:
Toerless Eckert wrote:
> Here is what i think, please reject points if you have arguments
against them,
> otherwise i'd assume you agree ;-):
> 1. "AN_join_registrar" and "AN_Proxy" where defined in RFC8995 for use
with ANI.
Yes. Except that if we do not adopt my proposed draft(s) that formally introduce
the SRV.* notion, i am not sure how long i want to explicitly explain that name
choice ;-)
Was there an adoption call?
Regards
Brian
On 09-May-22 05:12, Toerless Eckert wrote:
On Sat, May 07, 2022 at 06:32:57
I see that [I-D.richardson-lamps-rfc7030-csrattrs] is given as an Informative
reference. Is that OK? It looks to me like it might be essential reading, and
RFC7030 itself [EST] is a normative reference.
Regards
Brian Carpenter
On 25-May-22 07:52, internet-dra...@ietf.org wrote:
A New Inte
Hi,
The question of a registry for the value field of a GRASP objective never came
up before the GRASP RFC was published, as far as I remember. What we actually
have in the IANA Considerations is:
"To assist expert review of a new objective, the specification should include a
precise descript
On 27-Jun-22 12:58, Michael Richardson wrote:
Brian E Carpenter wrote:
> "To assist expert review of a new objective, the specification should
> include a precise description of the format of the new objective, with
> sufficient explanation of its semantics to all
Hi,
Just trying to check my understanding. In section 5.5.1 we have:
In
addition, the registrar-agent MUST know the product-serial-
number(s) of the pledge(s) to be bootstrapped. The registrar-
agent MAY be provided with the product-serial-number in different
ways
On 13-Jul-22 09:51, Michael Richardson wrote:
Brian E Carpenter wrote:
> Just trying to check my understanding. In section 5.5.1 we have:
I'm behind on their latest changes, but I'll catch up.
> In 5.4.2 we have:
>> The registrar-agent MAY use
mDNS.
Regards
Brian Carpenter
On 14-Jul-22 06:35, Michael Richardson wrote:
Brian E Carpenter wrote:
>> > In any case, isn't the list of pledges itself a point of attack for
>> > someone attempting to install a rogue device? So the security of the
>> &
Hi,
I have a few questions and comments on this draft. Please consider them at the
same time as any discussion in the meeting at IETF 114.
1. Introduction
...
From the network perspective, this kind of service has a source IP address and a destination IP address.
Are these always unicast
Please delete the previous message, I hit send by mistake!! More later...
Regards
Brian Carpenter
On 18-Jul-22 15:37, Brian E Carpenter wrote:
Hi,
I have a few questions and comments on this draft. Please consider them at the
same time as any discussion in the meeting at IETF 114.
1
Hi,
I have a few questions and comments on this draft. Please consider them at the
same time as any discussion in the meeting at IETF 114.
1. Introduction
...
From the network perspective, this kind of service has a source IP address and a destination IP address.
Are these always unicast
By the way, the draft I mentioned below, draft-ietf-core-yang-cbor, is now
RFC9254!
This should make it rather easy to include YANG in GRASP objective values.
Regards
Brian
On 18-Jul-22 15:59, Brian E Carpenter wrote:
Hi,
I have a few questions and comments on this draft. Please consider
1 - 100 of 846 matches
Mail list logo
