By the way, I just realised the obvious: we could write much more
succinct CDDL definitions of objective-values if we wanted to.
For my suggestion below, this means exactly the same:
objective-value = [ 0..255, [ +("BRSKI-TLS" / "EST-TLS") ], *[ any ] ]
Regards
Brian
On 21/09/2017 14:51, Brian E Carpenter wrote:
> On 21/09/2017 05:07, Toerless Eckert wrote:
>> Thanks, Brian
>>
>> a) i will fix the ABNF with next update (for Shengs review).
>
> Great.
>
>> b) Given the order of likely last calls, i will suggest in the bootstrap
>> meeting that we
>> define the AN_Registrar objective authoritatively in ACP and BRSKI adds
>> to it the
>> "BRSKI" method. BRSKI already should have no issue having ACP as
>> normative reference.
>> Lets see how that discussion goes.
>
> Works for me. Just decide whether you want AN_registrar or AN_join_registrar.
>
>> 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
