Thanks, Brian I hope i captured your concerns correctly in github:
https://github.com/anima-wg/grasp-dns/issues/3 For draft-carpenter-anima-grasp-config i am a bit at a loss when & why one would apply the encodings defined there. Is this meant to be ?mandatory? objective parameters whenever you flood ? In which case i would have to see that i make grasp-dnssd include these parameters because it is meant to flood ?? Could you maybe give an example ? I am just guessing, but the DNS-SD service announcements are typically meant to be used to allow selecting a server and then connecting to it. But the general flooding of information is not limited to announcing servers. It could simply be about flooding of e.g.: intent which has to be just locally followed ("network wider parameters"). Just as a counter-example of what would IMHO NOT fit into the grasp-dnssd case... 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 code recently, but it can be found at: > https://github.com/becarpenter/graspy/blob/master/GetDNSSD2.py > https://github.com/becarpenter/graspy/blob/master/AskDNSSD2.py > > So, the mechanism for mapping DNSSD info to a GRASP objective works. > > The question that came to me was whether the proposed family of > SRV.<service-name> objectives was too general or not general enough. > > Too general, because it claims to be applicable to, well, anything. > > Not general enough, because for draft-carpenter-anima-grasp-config, > it didn't make much sense to define that as SRV.GraspConfig. However, > I found the CBOR map approach to defining an extensible objective very > useful. Hence, the code at: > https://github.com/becarpenter/graspy/blob/master/GRASPconfig.py > does *not* use the exact draft-eckert-anima-grasp-dnssd mapping, > but is directly based on it. > > All the same, I think this approach to integrating GRASP-based service > management with DNSSD and with legacy NOC services is very interesting > and seems to be something ANIMA should consider carefully. > > Could the authors deal with the various TBDs in both documents? > > Regards > Brian Carpenter > > On 05-Mar-22 07:15, Toerless Eckert wrote: > > Dear ANIMA WG members, > > > > I have refreshed the two drafts to complete a solution for a real > > standalone ACP: > > > > a) use DNS-SD service compatible service discovery in ANIMA/ACP via GRASP: > > https://datatracker.ietf.org/doc/draft-eckert-anima-grasp-dnssd/ > > b) Use service discovery for ANIMA/ACP to autoconfigure its own core > > services > > > > https://datatracker.ietf.org/doc/draft-eckert-anima-services-dns-autoconfig/ > > > > Could I ask you to review and comment these two drafts ? > > > > If the responses are not too averse, I will request a call for adoption. > > > > Thanks > > Toerless > > > > Btw: I am happy to swap mutual review cycles, so if you are waiting for > > more reviews > > of your very own draft for ANIMA, i'll be happy to reciprocate ;-)) > > > > _______________________________________________ > > Anima mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/anima > > -- --- [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
