[Anima] Re: pls comment: “Lightweight GeneRic Autonomic Signaling Protocol”(draft-zhu-anima-lightweight-grasp-00)

Hi Longwei, I have a few questions: #1: 3.1. Reliable transmission for confirmable LW-GRASP messages ... If the LW-GRASP confirmable message does not get an acknowledgment within the retransmission timeout, then the message MUST be retransmitted, but there is no need to regenerate the

[Anima] Re: draft-ietf-anima-network-service-auto-deployment-06 comments

On 16-May-24 18:58, Sheng JIANG wrote: Hi, Toerless, Thanks for your further suggestion. It is fair to have a specific resource deployment as a proof example alongside the framework document. Storage could be one. Actually, I am thinking computing resource may be even more straight forward as

[Anima] GRASP, NETCONF and YANG

Seeing Toerless's comments on draft-ietf-anima-network-service-auto-deployment reminded me of what I think is the largest unsolved issue in the GRASP model. How does GRASP interwork with the NETCONF/YANG approach to network management? I don't really know how to answer this, but if ANIMA

[Anima] Lightweight GRASP

I think it would be good to see a first draft on this, with some ideas about UDP and COAP instead of TCP. Regards Brian ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adoption call on draft-eckert-anima-brski-discovery-01 by 2024/2/23rd

I fully support adoption of this draft. It's a very useful consolidation of information that is otherwise widely spread and hard to visualize. We should pay attention later to clearly identify which sections are informative references to other documents, and which sections are new normative

Re: [Anima] copying from github to WG mailing list ?

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

Re: [Anima] copying from github to WG mailing list ?

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

Re: [Anima] Esko: Re: Moving draft-ietf-anima-brski-cloud-06 forward

. Professional copy editors are paid to do it. Brian -Original Message- From: Brian E Carpenter Sent: Wednesday, August 9, 2023 22:40 To: Esko Dijk ; Toerless Eckert ; Michael Richardson Cc: anima@ietf.org Subject: Re: [Anima] Esko: Re: Moving draft-ietf-anima-brski-cloud-06 forward (we

Re: [Anima] Esko: Re: Moving draft-ietf-anima-brski-cloud-06 forward

(we can apply the lazy-fix policy and let IESG find them ;-) ) A bit off topic, but that is *not* the IESG's job. Unfortunately the IESG often wastes time on this rather than sending it on to the RFC Editor, whose job it is. I believe it's better for everybody if this is done by the authors.

Re: [Anima] New Version of draft-eckert-anima-grasp-dnssd

On 02-Aug-23 14:22, Toerless Eckert wrote: On Sat, Jul 29, 2023 at 10:17:38AM +1200, Brian E Carpenter wrote: On 27-Jul-23 01:44, Toerless Eckert wrote: DNS-SD TXT RR's are a sequenze of zero limited strings "key1=value1" ... "keyn=valuen" In my current grash/dsn-

Re: [Anima] New Version of draft-eckert-anima-grasp-dnssd

On 27-Jul-23 01:44, Toerless Eckert wrote: DNS-SD TXT RR's are a sequenze of zero limited strings "key1=value1" ... "keyn=valuen" In my current grash/dsn-sd draft i have just proposed to encode this in CBOR with as little as possible changes, e.g.: [ "key1=value1", ... "keyn=valuen" ] You

Re: [Anima] New Version of draft-eckert-anima-grasp-dnssd

On 26-Jul-23 09:06, Michael Richardson wrote: Brian E Carpenter wrote: > That makes sense, but it probably needs to be normatively specified, > which would avoid any need to change RFC 8995, except perhaps an > erratum to delete that "(list of)" wart. I di

Re: [Anima] New Version of draft-eckert-anima-grasp-dnssd

On 26-Jul-23 01:07, Michael Richardson wrote: Brian E Carpenter wrote: > Yes, but you can map them in CBOR just as > draft-eckert-anima-grasp-dnssd already describes. (Think JSON but code > CBOR.) My only real concern is how to extend the

Re: [Anima] New Version of draft-eckert-anima-grasp-dnssd

: Michael Richardson Sent: Monday, July 17, 2023 11:47 PM To: Brian E Carpenter Cc: Fries, Steffen (T CST) ; anima@ietf.org Subject: Re: [Anima] New Version of draft-eckert-anima-grasp-dnssd Brian E Carpenter wrote: > I can't answer that, but note that the AN_Proxy and AN_join_regist

Re: [Anima] New Version of draft-eckert-anima-grasp-dnssd

Steffen, On 18-Jul-23 00:46, Fries, Steffen wrote: Hi, I've read the latest version of draft-eckert-anima-grasp-dnssd-05 (https://datatracker.ietf.org/doc/draft-eckert-anima-grasp-dnssd/ ), which has been updated just

Re: [Anima] Moving draft-ietf-anima-brski-cloud-06 forward

Hi Sheng, I checked, and all the points in my review last November are covered. Thank you to the authors. Now draft-ietf-lamps-rfc7030-csrattrs is a downref, which needs to be mentioned in the shepherd's write-up. Regards Brian On 16-Jun-23 15:16, Sheng Jiang wrote: Hi, Brian, Esko &

Re: [Anima] northbound/southbound U interface (Re: New Version Notification for draft-richardson-anima-registrar-considerations-07.txt)

The private keys from the Southbound interfaces SHOULD NOT be made available on the Northbound interfaces. This new sentence reads slightly strangely, since private keys must never be available anywhere! Sow what exactly SHOULD NOT be available to the North? Regards Brian On 15-May-23

Re: [Anima] Expressing RFC 9316 Intent Examples in ASSL

Hi Bill, Interesting work. A few questions: 1) Is ASSL in active use? A quick search suggests it has been fairly quiet in recent years. 2) Java as the target language seems distinctly old-fashioned. I quickly found a Java to Python converter (https://www.javainuse.com/java2py). Have you

Re: [Anima] WGLC for draft-ietf-anima-brski-ae-04, ends April 3rd, 2023

I have insufficient security expertise to review the details of this draft, but it seems to be complete and well written. Section 4.2 "Message Exchange" refers to a diagram stored on GitHub in PNG format. It's a nice diagram, but I think that it's a bad idea to embed a GitHub URL in an RFC.

Re: [Anima] Shepherd review of draft-ietf-anima-brski-prm

On 09-Mar-23 05:30, Matthias Kovatsch wrote: Dear Anima WG, co-chairs, and authors I started my shepherd review of draft-ietf-anima-brski-prm. I currently see the need for some restructuring to make the draft clearer to the reader and easier to implement. Hence my review is done as

Re: [Anima] how should join proxy react to multiple registrars

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

Re: [Anima] ANI Autoconfiguration via DNS

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

Re: [Anima] FW: New Liaison Statement, "LS on the initiation of the new work item Y.AN-Arch-fw: "Architecture Framework for Autonomous Networks""

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

Re: [Anima] DNS-SD in GRASP - draft-eckert-anima-grasp-dnssd-04

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

Re: [Anima] DNS-SD in GRASP - draft-eckert-anima-grasp-dnssd-04

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

Re: [Anima] WGLC for draft-ietf-anima-brski-cloud-05, ends Nov. 28th, 2022

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

Re: [Anima] constrained-join-proxy registration of BRSKI_JP

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.

Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP

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

Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP

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

Re: [Anima] I-D Action: draft-ietf-anima-network-service-auto-deployment-03.txt

--- 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

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://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

Re: [Anima] session-id as epoch-id (was: Re: Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts])

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

Re: [Anima] session-id as epoch-id (was: Re: Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts])

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

Re: [Anima] Consolidated floods [was Signing GRASP objectives]

: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

Re: [Anima] Consolidated floods [was Signing GRASP objectives]

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

[Anima] Consolidated floods [was Signing GRASP objectives]

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

Re: [Anima] Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]

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

[Anima] Signing GRASP objectives [Was: Extending GRASP messages and signing GRASP multicasts]

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

Re: [Anima] [Cbor] GRASP packet header extensions (CBOR question)

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

Re: [Anima] [Cbor] GRASP packet header extensions (CBOR question)

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

Re: [Anima] [Cbor] GRASP packet header extensions (CBOR question)

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

Re: [Anima] Extending GRASP messages and signing GRASP multicasts

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

Re: [Anima] [Cbor] GRASP packet header extensions (CBOR question)

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

[Anima] Extending GRASP messages and signing GRASP multicasts

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

Re: [Anima] [Cbor] GRASP packet header extensions (CBOR question)

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

[Anima] Defined-Trust Transport for Limited Domains

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

Re: [Anima] I-D Action: draft-ietf-anima-network-service-auto-deployment-02.txt

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

Re: [Anima] I-D Action: draft-ietf-anima-network-service-auto-deployment-02.txt

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

Re: [Anima] I-D Action: draft-ietf-anima-network-service-auto-deployment-02.txt

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

Re: [Anima] I-D Action: draft-ietf-anima-network-service-auto-deployment-02.txt

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

Re: [Anima] I-D Action: draft-ietf-anima-brski-prm-04.txt

. 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

Re: [Anima] I-D Action: draft-ietf-anima-brski-prm-04.txt

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 >>

Re: [Anima] I-D Action: draft-ietf-anima-brski-prm-04.txt

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

Re: [Anima] some questions about GRASP objective-values and discovery

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

Re: [Anima] some questions about GRASP objective-values and discovery

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

Re: [Anima] I-D Action: draft-ietf-anima-brski-cloud-04.txt

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

Re: [Anima] FYI: est-coaps registered (was: Re: Discovery of proxy/registrar insufficient (GRASP and) more).

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

Re: [Anima] Discovery of proxy/registrar insufficient (GRASP and more).

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.

Re: [Anima] Discovery of proxy/registrar insufficient (GRASP and more).

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

Re: [Anima] Discovery of proxy/registrar insufficient (GRASP and more).

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

Re: [Anima] Discovery of proxy/registrar insufficient (GRASP and more).

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

Re: [Anima] Discovery of proxy/registrar insufficient (GRASP and more).

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

Re: [Anima] Discovery of proxy/registrar insufficient (GRASP and more).

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

Re: [Anima] Discovery of proxy/registrar insufficient (GRASP and more).

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

Re: [Anima] grasp-dnssd and services-dns-autoconfig [was ANIMA IETF113 notes posted]

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 >

Re: [Anima] grasp-dnssd and services-dns-autoconfig [was ANIMA IETF113 notes posted]

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

[Anima] grasp-dnssd and services-dns-autoconfig [was ANIMA IETF113 notes posted]

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

Re: [Anima] Opsdir last call review of draft-ietf-anima-constrained-join-proxy-09

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

Re: [Anima] [Last-Call] [OPS-DIR] Opsdir last call review of draft-ietf-anima-constrained-join-proxy-09

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

[Anima] Fixed on-the-wire bug in Python GRASP

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

Re: [Anima] recursive system dependencies (Was: Re: New Version Notification for draft-trossen-rtgwg-impact-of-dlts-00.txt)

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

Re: [Anima] I-D Action: draft-ietf-anima-network-service-auto-deployment-01.txt

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 +

Re: [Anima] ANIMA: pls comment: draft-eckert-anima-services-dns-autoconfig-01 / draft-eckert-anima-grasp-dnssd-03

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

Re: [Anima] ANIMA: pls comment: draft-eckert-anima-services-dns-autoconfig-01 / draft-eckert-anima-grasp-dnssd-03

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

Re: [Anima] I-D Action: draft-ietf-anima-asa-guidelines-07.txt

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

Re: [Anima] I-D Action: draft-ietf-anima-rfc8366bis-00.txt

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

Re: [Anima] Intdir telechat review of draft-ietf-anima-asa-guidelines-05

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

Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-asa-guidelines-05: (with DISCUSS and COMMENT)

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"

Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-asa-guidelines-05: (with DISCUSS and COMMENT)

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)

Re: [Anima] Éric Vyncke's No Objection on draft-ietf-anima-asa-guidelines-05: (with COMMENT)

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"

Re: [Anima] John Scudder's No Objection on draft-ietf-anima-asa-guidelines-05: (with COMMENT)

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”

Re: [Anima] Warren Kumari's No Objection on draft-ietf-anima-asa-guidelines-05: (with COMMENT)

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

[Anima] Fwd: I-D Action: draft-ietf-anima-asa-guidelines-05.txt

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

Re: [Anima] RFC8992bis? [was RFC 9164 on Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes]

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. >

Re: [Anima] RFC8992bis? [was RFC 9164 on Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes]

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

[Anima] RFC8992bis? [was RFC 9164 on Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes]

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

Re: [Anima] Artart last call review of draft-ietf-anima-asa-guidelines-04

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

Re: [Anima] Opsdir last call review of draft-ietf-anima-asa-guidelines-04

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.

Re: [Anima] Call for adoption: draft-richardson-anima-rfc8366bis, ends December 19th, 2021

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

Re: [Anima] Genart last call review of draft-ietf-anima-asa-guidelines-04

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

Re: [Anima] Constrained-join-proxy: use of DNS-SD discovery of a Join Proxy

- 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

Re: [Anima] Constrained-join-proxy: use of DNS-SD discovery of a Join Proxy

;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

Re: [Anima] Constrained-join-proxy: use of DNS-SD discovery of a Join Proxy

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

Re: [Anima] Constrained-join-proxy: use of DNS-SD discovery of a Join Proxy

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

Re: [Anima] AD review of draft-ietf-anima-asa-guidelines-03

--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

Re: [Anima] AD review of draft-ietf-anima-asa-guidelines-03

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

Re: [Anima] AD review of draft-ietf-anima-asa-guidelines-03

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

Re: [Anima] services-dns-autoconfig

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.

Re: [Anima] Call for adoption: draft-dang-anima-network-service-auto-deployment

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,

Re: [Anima] I-D Action: draft-ietf-anima-asa-guidelines-03.txt

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

  1   2   3   4   5   6   7   >