On 23/09/2017 11:01, Toerless Eckert wrote:
> 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.
Well, settle the name between the ACP and BRSKI authors
>
> 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).
I would argue that in many cases of simple objectives this would be a mistake.
It's a conceptual and practical complication for the ASA writer, unless a
map (and probably JSON) is already "native" for the problem at hand.
I am absolutely not against maps for cases where they are the natural
solution. But if the objective happens to be a simple value, why?
> 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.
Sure, when we are dealing with that sort of objective. (More below on that.)
> 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.
All that IANA registration really requires is a name and a reference document,
so this comes at the RFC stage.
> 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" },
> }
> }
Please work with Carsten to get that right, all I can tell
you is that the tool reports a parse error.
> 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):
Again, a parse error.
>
> 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).
All the same, DNS-SD is Unicode, so you can in theory use anything for the
Instance name (human readable part). I agree that the DNS-SD Service name
is case-folded ASCII.
> 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
One more comment below...
>
> 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...
Well, these objectives and probably many associated with a NOC are
services. But if the ASA is handling some sort of optimisation
or resource management, the objective really is a parameter.
It might be a real number or more complicated, but it's not
a service. Really a GRASP objective is just a container.
> "objective" to me always implies an action, which i think is why
> "XXX_join_registrar" was preferred choosen ?
I just tried to copy the terminology in BRSKI.
> 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.
Sure, but you can expand the semantics by adding a field to the objective-value
if you want.
> 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
Maybe you won't in the NOC space, but if we're optimising usage of
radio links in 3D space maybe you will find complex numbers in
the control loop, and therefore in the objective values.
Brian
>
>>
>>> 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
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
