Re: [Anima] how to process RFC8791 examples
Hi Michael, You should run it with "--tree-print-structures". Cheers, Med > -Message d'origine- > De : Anima De la part de Michael > Richardson > Envoyé : jeudi 24 novembre 2022 00:31 > À : net...@ietf.org > Cc : anima@ietf.org; mbj+i...@4668.se; a...@yumaworks.com > Objet : [Anima] how to process RFC8791 examples > > > Hi, I've been looking at how to move RFC8366 from YANG- > DATA/RFC8040 to RFC8791. > I think that maybe we can solve the multiple inclusion/derivation > problem in > 8791 space rather than 8040 space. > > I extracted the A.1. "structure" Example to a file and ran: >pyang >--path=.../yang/modules/ietf >-f tree --tree-print-groupings example-module.yang > > and I get nothing out, because that example module doesn't > actually express something, just defines a structure. > At least, that's what I think. Maybe I'm doing it wrong. > > I look back at what I did with draft-ietf-core-sid, and actually I > don't see any clear difference. So how do I get the tree > structure printed from the examples in RFC8791? > > -- > Michael Richardson. o O ( IPv6 IøT > consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] sids not allocated for sx_structure/RFC8791.
Hi, if you haven't seen my thread on how ANIMA can do extensions for YANG modules, then please go read: https://mailarchive.ietf.org/arch/msg/netmod/1z7qo_6kZ0aTZmXeU4ELuwt-Rxo/ Maybe I've found a solution at the YANG level, but at the SID level, it's worse. a) No SID values get allocated to any leaves. b) A module SID value for B,C,D are created, and the old ones removed, which is wrong. c) New SID files are being created, despite having specified the --sid-update-file. This is probably not a bug in the ietf-core-sid specification, or in the RFC9254 that we published, but in the PYANG tool. However: https://github.com/mbj4668/pyang/issues/716 there was some confusion, but it seems that SIDs were generated for groupings. I don't know if I need to re-introduce deeper groupings, I don't think so. I have opened: https://github.com/mbj4668/pyang/issues/835 -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [netmod] mcr's YANG question raised during the ANIMA WG session
I have taken a third pass at getting the extension of yang modules done.
This time, I am using RFC8791 (Structure), rather than YANG-DATA.
I do not use Augment (or structure-augment). Not sure how I would.
My module D, which wants to inherit from A, B and C, even though B and C also
inherit from A, looks like this:
sx:structure module-D-things {
uses module-D;
}
grouping module-D {
description "A module D structure";
container module-D {
description "A wrapper container for the module-D things";
uses vA3:module-A-contents;
uses vB3:module-B-contents;
uses vC3:module-C-contents;
uses module-D-contents;
}
}
grouping module-D-contents {
leaf attribute-D-Delta {
type binary;
description "DeltaThree";
}
}
This produces a tree printout of:
module: module-D3
grouping module-D:
+-- module-D
+-- attribute-A-Alpha? binary
+-- attribute-B-Beta?binary
+-- attribute-C-Gamma? binary
+-- attribute-D-Delta? binary
grouping module-D-contents:
+-- attribute-D-Delta? binary
This is not great, but better than before.
The results are still at:
https://github.com/mcr/yang-augment-test
look at module-?3.yang and practice3.sh.
Please tell me/us (ANIMA WG) if we can do better.
We have revisions to RFC8366 that we'd like to go forward with, but we need
to make sure that we accomodate the extensions that are planned.
Probably converting to RFC8791 is also a good thing.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
[Anima] how to process RFC8791 examples
Hi, I've been looking at how to move RFC8366 from YANG-DATA/RFC8040 to RFC8791. I think that maybe we can solve the multiple inclusion/derivation problem in 8791 space rather than 8040 space. I extracted the A.1. "structure" Example to a file and ran: pyang --path=.../yang/modules/ietf -f tree --tree-print-groupings example-module.yang and I get nothing out, because that example module doesn't actually express something, just defines a structure. At least, that's what I think. Maybe I'm doing it wrong. I look back at what I did with draft-ietf-core-sid, and actually I don't see any clear difference. So how do I get the tree structure printed from the examples in RFC8791? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] DNS-SD in GRASP - draft-eckert-anima-grasp-dnssd-04
On 23-Nov-22 23:09, Esko Dijk wrote: Hello Brian, GRASP is a CBOR-based protocol and the values of GRASP objectives MUST be in CBOR. Yes, I was also thinking about such a solution. You could define an objective 'service announcement' and include a CBOR byte string there that encodes one or more advertised services in today's DNS(-SD) format. And a pure-GRASP element such as distance/range to all these services can be additionally encoded in CBOR. Similarly an objective 'service query' is defined, with same CBOR byte string encoding the Question(s). ... That's a substantial reduction in complexity. True, for the GRASP node that doesn't have to include the DNS parser. And for the programmers of it :) But another kind of complexity comes in return, that is, documents and format definitions in the IETF (specifically now here in the ANIMA WG). It creates a mapping of DNS onto CBOR format that is not 100% complete. And the documents hint at future extensions to include features of DNS to make it more complete, which means more documents, while the basic DNS format already has all these things. Both formats may diverge in subtle ways that will only emerge later. But I do understand the desire to 'modernize' the DNS format; a similar effort is done in CoRE to encode a URI as a CBOR structure which avoids a node having to do URI parsing. (It's 'preparsed' so to speak.) But it did lead to a lot of discussions, iterations, and unexpected semantic problems in that case. ... they had no choice, but do we seriously want to force that complexity onto constrained nodes? Some constrained nodes do include DNS-SD; e.g. in OpenThread the optional DNS client has all this and looks like ~10KB compiled on an embedded platform. It's still an impressive amount of source code though. So I'm trying to establish what is the constraint on an ACP-node here, probably not flash size, but rather wanting to avoid DNS code complexity which might open up opportunities for error and (therefore) potential attacks? What the draft does is *centralize* the lookups and the complexity. It gives the distributed clients a central place to do lookups for them. The draft says "Future work can also define DNS-SD <-> GRASP gateway functions.", so a centralized gateway seems not in scope? (Gateway like GetDNSSD2.py is implementing ...? ) Yes. I don't think it's possible to implement what Toerless proposes *without* such a gateway, in fact. It also says "Also, the document allows for automatically discovering DNS-SD servers." which to me reads as the ACP-node uses GRASP to find a DNS(-SD) server and then it can use that server in the classic way. Similar to how you discover an NTP time server and then use that server in the classic way. You could, but (IMHO) the only purpose of the proposal is to off-load the DNS-SD details from the client system. In fact I find it strange that the IOT world is not aggressively doing this (and not only for DNS-SD; for almost every protocol that was originally designed for 1980's mini-computers and mainframes). My strong impression of the draft is that it defines an mDNS-like lookup of services, which services can then be used in the way they're supposed to. Any node on the ACP could offer a particular service, like NTP, DNS, Radius, etc and the distributed discovery then helps to find one or more (nearby) instances of a wanted service. That doesn't look centralized to me, but maybe other authors could chime in. Toerless needs to answer, but do remember that the original target for ANIMA was *not* IOT devices, but network elements in an enterprise or ISP network Flooding is a bad idea at that scale. It's a weakness in the GRASP model and is the motivation for work like draft-ietf-anima-grasp-distribution, but we aren't done with that yet. Indeed this was one of the motivations for the dnssd WG "SRP" protocol, e.g. in context of constrained mesh networks with potentially 100s of nodes, to avoid the all-to-all communication model of mDNS. So the draft may emphasize some scalability recommendations, like only advertising a few key services 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 22, 2022 21:14 To: Esko Dijk ; anima@ietf.org Cc: Toerless Eckert Subject: 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 functionality over an ACP by using GRASP” with unsolicited (flooded) service announcements, plus service
Re: [Anima] DNS-SD in GRASP - draft-eckert-anima-grasp-dnssd-04
Hello Brian, > GRASP is a CBOR-based protocol and the values of GRASP objectives MUST be in > CBOR. Yes, I was also thinking about such a solution. You could define an objective 'service announcement' and include a CBOR byte string there that encodes one or more advertised services in today's DNS(-SD) format. And a pure-GRASP element such as distance/range to all these services can be additionally encoded in CBOR. Similarly an objective 'service query' is defined, with same CBOR byte string encoding the Question(s). > ... That's a substantial reduction in complexity. True, for the GRASP node that doesn't have to include the DNS parser. And for the programmers of it :) But another kind of complexity comes in return, that is, documents and format definitions in the IETF (specifically now here in the ANIMA WG). It creates a mapping of DNS onto CBOR format that is not 100% complete. And the documents hint at future extensions to include features of DNS to make it more complete, which means more documents, while the basic DNS format already has all these things. Both formats may diverge in subtle ways that will only emerge later. But I do understand the desire to 'modernize' the DNS format; a similar effort is done in CoRE to encode a URI as a CBOR structure which avoids a node having to do URI parsing. (It's 'preparsed' so to speak.) But it did lead to a lot of discussions, iterations, and unexpected semantic problems in that case. > ... they had no choice, but do we seriously want to force that complexity > onto constrained nodes? Some constrained nodes do include DNS-SD; e.g. in OpenThread the optional DNS client has all this and looks like ~10KB compiled on an embedded platform. It's still an impressive amount of source code though. So I'm trying to establish what is the constraint on an ACP-node here, probably not flash size, but rather wanting to avoid DNS code complexity which might open up opportunities for error and (therefore) potential attacks? > What the draft does is *centralize* the lookups and the complexity. It gives > the distributed clients a central place to do lookups for them. The draft says "Future work can also define DNS-SD <-> GRASP gateway functions.", so a centralized gateway seems not in scope? (Gateway like GetDNSSD2.py is implementing ...? ) It also says "Also, the document allows for automatically discovering DNS-SD servers." which to me reads as the ACP-node uses GRASP to find a DNS(-SD) server and then it can use that server in the classic way. Similar to how you discover an NTP time server and then use that server in the classic way. My strong impression of the draft is that it defines an mDNS-like lookup of services, which services can then be used in the way they're supposed to. Any node on the ACP could offer a particular service, like NTP, DNS, Radius, etc and the distributed discovery then helps to find one or more (nearby) instances of a wanted service. That doesn't look centralized to me, but maybe other authors could chime in. > Flooding is a bad idea at that scale. It's a weakness in the GRASP model and > is the motivation for work like draft-ietf-anima-grasp-distribution, but we > aren't done with that yet. Indeed this was one of the motivations for the dnssd WG "SRP" protocol, e.g. in context of constrained mesh networks with potentially 100s of nodes, to avoid the all-to-all communication model of mDNS. So the draft may emphasize some scalability recommendations, like only advertising a few key services 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.) Regards Esko -Original Message- From: Brian E Carpenter Sent: Tuesday, November 22, 2022 21:14 To: Esko Dijk ; anima@ietf.org Cc: Toerless Eckert Subject: 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 > functionality over an ACP by using GRASP” with unsolicited (flooded) service > announcements, plus service queries. That looks quite useful to have (looking > at draft-eckert-anima-services-dns-autoconfig-02 for the motivation for this.) > > First question is, why do we want to define a separate GRASP i.e. CBOR format > for the DNS(-SD) information? That's an easy one. GRASP is a CBOR-based protocol and the values of GRASP objectives MUST be in CBOR. Of course, exactly how the DNS information is respresented in CBOR is a matter of design choice. I'll leave Toerless to explain the choice that he proposes. I'll just say that it wasn't too hard to implement it in Python, which is of course a very natural
