Re: [Anima] ACP -10 [was Re: I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt]

[Brian E Carpenter <[e-mail]>]

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
>>