Thanks, Brian
I thought i had mentioned elsewhere already that one follow-on work
i would like to write up (hopefully until singapore) is a simple
set of GRASP objectives to allow autoconfigurion of the ANI infra
against common NOC services. This would exactly be a target
standards track followup work from the "stable-connectivity concept.
It would use exactly the format i descriped for GRASP objective-value
in my last email. I primarily have to figure out how to cut the work into
one or more small docs.
In any case i would first want to concentrate on the small add-on / refinements
needed to implement full systems out of the current charter item work.
Cheers
Toerless
On Sat, Sep 23, 2017 at 08:12:21AM +1200, Brian E Carpenter wrote:
> On 22/09/2017 20:44, Liubing (Leo) wrote:
> > Hi Dear all,
> >
> > To response to the Chairs' calling, I'd like to firstly mention an existing
> > work, draft-carpenter-anima-ani-objectives, which belongs to the first
> > category as Sheng defined below:
> >> Leveraging the Current ANI (GRASP, ACP & BRISK)
> >
> > It is very specific technical details (just like "option names" in other
> > protocols) related to all ANI components (BRSKI, ACP and GRASP), but
> > necessary for interoperability.
> > We used to have some discussion about whether to define these objectives in
> > each ANI component. But there is two problems as I see:
> >
> > 1. This draft defines an additional value for GRASP message syntax to
> > indicate transport-protocol. So far it is actually used for BRSKI to
> > indicate IP-in-IP encapsulation. However, from definition perspective, this
> > value is generic than BRSKI-specific, so I'm not very sure it is proper to
> > defined it in BRSKI.
> >
> > 2. Technically, it is ok to define each GRASP-objective in each ANI
> > document, but would it be a bit scattered?
> >
> > In any case, I think the ANI objective content should reach consensus and
> > be published as soon as possible.
> > Then, the problem again: shall we make it as a standalone draft, or
> > incorporate them into each ANI draft?
>
> The first conclusion after the previous IETF was to add the objectives into
> the
> corresponding drafts. That is in progress for BRSKI and ACP. For the "stable
> connectivity" draft, it is not included in
> draft-ietf-anima-stable-connectivity-06
> but it is also not clear what is needed. Toerless should comment, but I think
> he believes that NOC services are expected to be discovered via DNS-SD
> in non-ANIMA scenarios, so maybe the best approach is to bridge ANIMA based
> discovery to DNS-SD somehow. I have done a little work on that topic**,
> but we need some clarity on the requirements.
>
> So in answer to your question, I think we can let the ani-objectives draft
> expire, but we may need a new draft on the DNSSD aspect.
>
> ** At https://github.com/becarpenter/graspy, see AskDNSSD.py and GetDNSSD.py
>
> Regards
> Brian
>
> _______________________________________________
> 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
