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,
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 the di
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
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
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:
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 about a
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
--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. The -04 vers
-
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 reviewing latest up
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
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
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.
>
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
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,
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.
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
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
] On 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
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
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
,
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@ietf.org
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
[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
unicast unsolici
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
there.
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
;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 works
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:
On 01-Dec-21 01:55
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.
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
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 will
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
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
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 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
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
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
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
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 haven't exercised that c
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
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
+
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
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
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
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
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"
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)
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”
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"
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
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
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/DNSSD
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
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 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
>
On 23-Sep-23 06:42, Michael Richardson wrote:
Toerless Eckert wrote:
> So, i am always happy in taking recommendations how to best rectify this
type of issue.
> I am of course always a believer in better tooling, but i wouldn't know
if/how we would
> best copy e.g. relevant
On 25-Sep-23 07:10, Michael Richardson wrote:
Brian E Carpenter wrote:
> Certainly, but that depends on humans. We also need filters for github
> messages, because if you are subscribed to a repo, you tend to get a
> lot of trivia as well as substantive di
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
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
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
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
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
>>
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
.
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
>> > lis
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
Hi,
I think this draft by Kathie Nichols, Van Jacobson and Randy King might be of
some interest to ANIMA. That may not be obvious at first sight, but it's about
a network domain with well defined and secure membership, and is heavily based
on IPv6 link-local multicast.
It has one significant
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
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
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 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
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
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
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.
On 25-Aug-22 08:57, Michael Richardson wrote:
Carsten Bormann wrote:
> That is getting closer to my question “what does it mean for
> (something) to be signed”?
> Apparently, this is a statement from an initiator, valid within the
> session-id, optionally scoped to the
On 23-Aug-22 22:35, Toerless Eckert wrote:
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
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, but at the objective definition level.
If that's the case, we are on the wrong track. Should we be discussing
signing GRASP objectives, rather than
On 26-Aug-22 21:26, Toerless Eckert wrote:
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
:42AM +1200, Brian E Carpenter wrote:
On 26-Aug-22 08:59, Michael Richardson wrote:
Brian E Carpenter wrote:
> (b) but it could be implemented *on top* of the current
> definition of GRASP, if the floods in question were issued with a loop
> count of 1 (so they wo
On 30-Aug-22 00:13, Toerless Eckert wrote:
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
On 20-Aug-22 06:56, Carsten Bormann wrote:
In GRASP (RFC8990] we define the GRASP message structure as follows:
message-structure = [MESSAGE_TYPE, session-id, ?initiator, *grasp-option]
MESSAGE_TYPE = 0..255
session-id = 0..4294967295 ; up to 32 bits
grasp-option = any
Then we've defined a
On 20-Aug-22 09:15, Carsten Bormann wrote:
On 2022-08-19, at 23:05, Brian E Carpenter wrote:
EXTENSION_TYPE = 0..255
There is no reason to limit this to 255.
➔ EXTENSION_TYPE = uint
(Do you plan to creat a registry for these?
The 'extension_type' terminology is confusing, because
Hi ANIMA,
Some background on the new discussion:
A few of us have been discussing the need to cryptographically sign
GRASP multicasts (especially M_FLOOD messages) and this has shown
up a gap in RFC8990 (the GRASP spec). We're currently thinking that
this topic will need a draft (or maybe two
On 22-Aug-22 18:56, Toerless Eckert wrote:
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 sig
Just a couple of comments in line:
On 22-Aug-22 21:09, Toerless Eckert wrote:
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
On 23-Aug-22 06:43, Carsten Bormann wrote:
Aka: grasp-option can not represent the purely numeric ttl anymore.
That's actually a bug in the changes I was proposing. It will be
fixed but I doubt that the cbor list cares.
We could do a one-off fix for ttl by channging message-structure, but
On 26-Aug-22 03:58, Michael Richardson wrote:
Toerless Eckert wrote:
> Could as well simply be a function which buffers flood-messages over a
> period of e.g.: 60 seconds and coalesces them together, so it's
> transparent to the originators (loose coupling).
> So, now i
On 26-Aug-22 08:59, Michael Richardson wrote:
Brian E Carpenter wrote:
> (b) but it could be implemented *on top* of the current
> definition of GRASP, if the floods in question were issued with a loop
> count of 1 (so they would never be relayed pe
Hi,
I'm still not fully understanding the notation used in Figure 2 at:
https://www.ietf.org/archive/id/draft-ietf-anima-network-service-auto-deployment-03.html#section-5-8
There is an expansion of service-information in CDDL just below the figure, but
if you want conforming implementations, I
---
Best Regards
Yujing Zhou
-Original Message-
From: Brian E Carpenter
Sent: 2022年10月25日 8:46
To: anima@ietf.org
Subject: Re: [Anima] I-D Action:
draft-ietf-anima-network-service-auto-deployment-03.txt
Hi,
I'm still not fully understanding the notation used in Figure 2 at:
https
On 31-Oct-22 22:24, Esko Dijk wrote:
cases where the Registrar would configure another resource (e.g. /j or
> /join or whatever) and in such case a Uri-Path option would be needed.
Okay, but I'd like to not do that :-)
Okay, I see your point - let's go for the '/' resource option and see
nt: RFC8141.
Regards
Brian Carpenter
On 02-Nov-22 08:58, Brian E Carpenter wrote:
On 31-Oct-22 22:24, Esko Dijk wrote:
cases where the Registrar would configure another resource (e.g. /j or
> /join or whatever) and in such case a Uri-Path option would be needed.
Okay, but I'd like
M_FLOOD includes a TTL.
"The message MUST contain a time-to-live (ttl) for the validity of the
contents, given as a positive integer value in milliseconds. There is
no default; zero indicates an indefinite lifetime."
In any case, floods must be ignored after their TTL expires, obviously.
I see
On 13-Dec-22 23:53, Esko Dijk wrote:
Hello Bill,
You mention "the advantages of using native CBOR encoding". So this refers to
the CBOR encoding of (DNS) service properties, which would avoid parsing of the old DNS
format.
As I understand there's a wish of people to avoid having a DNS data
IMHO, our first step should be to read [ITU-T Y.Suppl 71]. To my surprise, that's
open access: https://www.itu.int/ITU-T/recommendations/rec.aspx?id=15041=en
The second step could be an FYI response listing our framework documents,
existing standards, and ongoing work. Only needs a page. From
vices needed to bootstrap the system (NTP, logging,
Radius, central DNS server, ... ) and not that every ACP-node starts
advertising a bunch of services. (As that wouldn't scale.)
Agreed.
Brian
Regards
Esko
-----Original Message-
From: Brian E Carpenter
Sent: Tuesday, November
Hi,
Summary:
This draft is very clear and almost ready, but I think it needs one more
editing pass. I have some minor substantive comments followed by some nits.
Substantive comments:
=
Abstract
This is a bit short. I think it should provide a little context
On 22-Nov-22 23:57, Esko Dijk wrote:
Hi all,
From a DNS/DNS-SD background and interest I started looking into
draft-eckert-anima-grasp-dnssd-04. Also saw some earlier list discussion on
this topic (GRASP + DNS-SD).
It looks like the draft mainly aims to provide a “multi-hop mDNS like
On 02-Nov-22 20:16, Michael Richardson wrote:
https://github.com/anima-wg/constrained-join-proxy/pull/44
## GRASP Discovery Registry
IANA is asked to extend the registration of the "AN\_join\_registrar" (without quotes) in
the "GRASP Objective Names" table in the Grasp Parameter registry.
501 - 600 of 617 matches
Mail list logo
