Some opinions/suggestions:
a) Name of objective should be "ACP_registrar". The registrar supports multiple
services, eg: brski-join, est-renewal, and if we had ducklings also
est-enroll.
ACP_*, because it's not AN_* unless we could guarantee we always have intent
(which we don't), and not ANI_* because we also do not necessarily always
have
BRSKI (but eg: Netconf Zero Touch + ACP).
But this is terminology. I have an option, but i am happy getting anything
that works.
ultimately i do not care about this part.
b) More importantliy, elements in objective-value should be standardizeable,
reuseable,
extensible and optional.
AFAIK, for extensible and optionality, we need to use maps instead of
arrays in CBOR ({} instead of [] in CDDL).
For standardizeable, we should define the structure to include standards
elements
c) The IMHO most easy and useful standardized options are the ones that
a) allow for objective services to be aligned with DNS-SD so that
we have a superset of the service-selection facilities of DNS-SD and
if desired the same name space.
d) So, for the ACP draft, i think i would want to write down the most simple
subset of the intended syntax for objective-values and not describe the
background and also not yet start to worry about IANA registration,
because that would make sense only once we agree on the need of
extensibility.
Worst case, the following syntax would not be extended in future, then
we just made it a bit more generic than necessary:
objective-value = {
std: {
sender-ttl: 255,
service: { "brski-join" },
service: { "est-renew" },
}
}
e) In a separate small document we could detail those GRASP aspects in more
detail,
this doc could update ACP RFC, so we can take more time without holding up
ACP RFC.
And we could then also ask for the IANA registries when we feel that there
really
is enough future add-ons to justify the registry.
Here is my current definition i would use (aka superset of avove example):
objective-value = { *parameter } ; map of parameters to be extensible and
; all prameters can be optional.
parameter /= std: { *std-param } ; create subset of parameters
standardized
; the std-param names would be an IANA
registry.
; parameter /= ... ; Any parameter specific to an
objective.
std-param /= sender-ttl: 1..255 ; value of ttl field of flood-message
; as set by sender. Upon receipt,
; (sender-ttl - ttl) is the distance of
; the receiver from the sender.
std-param /= service: { ; Services supported by objective.
service-name, ; Name must be registered according to
RFC6335
*service-param ; would therefore also useable in
RFC2782
} ; For newly registered service names,
do not
; allocate/register protocol/port
numbers. These
; are learned via other GRASP message
elements
service-name = tstr
service-param /= selection-param
selection-param /= priority: 0..65535 ; Same semantic as rfc2782. Default = 0
selection-param /= weight: 0..65535 ; Same semantic as rfc2782. Default = 0
Aka: pretty much allowing 1:1 mapping of the DNS-SD SRV parameters we need
(service-name, priority, weight) to GRASP "services". And make "services"
a sub-element of an objective. And RFC6335 also explains why not to use
capital letters in "est-renew", "brski-join" (uncommon to use capital letters
in RFC6335).
As you see, i did not make sender-ttl part of service, so we may use
sender-ttl
even if some objective does not want a "service:" parameter.
We may need to add locator options to service-params, thats and example of
how this is yet incomplete. With just one service indicated the locator
element of the existing GRASP is sufficient.
Cheers
Toerless
On Thu, Sep 21, 2017 at 02:51:48PM +1200, Brian E Carpenter wrote:
> Works for me. Just decide whether you want AN_registrar or AN_join_registrar.
a) OK, let me obsess about terminology a bit:
I always think of objectives as services, which would make
"XXX_registrar" the right word - it does not prescribe what
to do with the service: ignore, consume(join), buy-stock, resell, attack...
"objective" to me always implies an action, which i think is why
"XXX_join_registrar" was preferred choosen ?
When we, as i suggest have the same registrar objective used for both BRSKI
and EST, we have at least two actions: BRKI-join and EST-renew. Logically
we could also have EST-enroll, but that one is a no-no (eg: ducking enrollment
without voucher).
So we could call what we named "method" also "action" or "service" and
call them BRSKI-join and EST-renew. But those words do then not imply the
transport stack to use (TLS).
I would like XXX = ACP because XXX = AN seems to imply the network is
autonomic, which i think by definition it is not unless we have intent ;-P.
XXX = ANI would also be wrong if for example we combine ACP with Netconf
Zero Touch and only offer EST-renew but not BRSKI-enroll.
b) I would like the parameters of an objective reuseable, extensible and
optional when not needed. I think that we need to use a map instead of
an array in CBOR to get extensibility and optionality (CDDL
concerned about the word objective - i am never sure if i will not run
into a service where there is really more than
>
> > c) Given my ABNF/CDDL dyslexia, would you mind to propose a correct CDDL
> > for the
> > objective-value structure to include the TTL and method, eg: fixup the
> > following:
> >
> >>> objective-value = [ sender-ttl, method-list [, future-extensions]* ]
> >>> method-list = [ method ]*1
> >>> methd = BRSKI-TLS | EST-TLS | ...
> >>> sender-ttl = NUM
>
> I would go for this:
>
> objective-value = [ sender-ttl, method-list, *[ future-extensions ] ]
> method-list = [ +method ]
> method = "BRSKI-TLS" / "EST-TLS"
> sender-ttl = 0..255
> future-extensions = any
>
> The "+" prefix means 1 or more in CDDL and "*" means zero or more.
> The commas in lists like [+method] are implied. (I checked
> this fragment with the CDDL tool.)
>
> I used strings for the method for simplicity; if you want to save a few
> bytes you could use symbols but then they have to be assigned values like
> BRSKI-TLS = 0
> EST-TLS = 1
> and you end up with another IANA registry in your life.
>
> Regards
> Brian
>
> > If we do not get further feedback from the WG supporting my simple
> > TTL=255 approach,
> > i would rather go with this structure approach, so that we can let the
> > TTL disussion
> > take its natural course (figure out it should be 255 over 10 years ;-P).
> > Primarily,
> > because i like the idea to show off a bit the flexiblity of GRASP for
> > the objective
> > value being a structure. ANd because it would be a good reference for
> > further objectives
> > where we want to discover/select closest instance (and we didn't include
> > this into the
> > GRASP document proper).
> >
> > Cheers
> > Toerless
> >
> >>> (pretty sure i didn't get the CBOR template not right, but i am sure
> >>> you get the idea)
> >>
> >> Not only do I get the idea, I tested it out many months ago; actually
> >> after the
> >> discussions in Berlin, I think. In my Pythonic world it was very easy, but
> >> it is
> >> indeed a bit more complicated than the 255-N method.
> >>
> >>>
> >>> That way, the recipient can compare sender-ttl with the TTL of the
> >>> received objective
> >>> and threeby figue out which one is closest.
> >>>
> >>> I fine either way. I just tried to go for the most simple, logical option.
> >>
> >> Right, so the question for the WG (are you all listening?) is whether we
> >> want to defend the value of the loop count in limiting propagation of
> >> multicast
> >> messages. (Remember that it has another role in negotiation sessions, where
> >> it really is a loop-prevention counter.)
> >>
> >> I will note that in testing on looped topologies I have seen looped
> >> multicasts
> >> dropped because of the session ID; theoretically that is sufficient, and
> >> the
> >> loop count is logically redundant.
> >>
> >> Otherwise, me happy.
> >>
> >> Thanks again for all the work,
> >>
> >> 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
