Thanks, Brian
a) i will fix the ABNF with next update (for Shengs review).
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.
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
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
