On Sat, Sep 23, 2017 at 03:31:44PM +1200, Brian E Carpenter wrote:
> Well, settle the name between the ACP and BRSKI authors
Sure
> > 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?
As soon as you want to include discovery parameters such as the sender-ttl
or the dns SRV style weight/prio the map for example.
> All that IANA registration really requires is a name and a reference document,
> so this comes at the RFC stage.
Sure. Its more about feeling safe enough that the idea is right
before asking IANA to maintain a registry. Easier done when there
is more time to revisit the decision.
> > 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.
What's the CBOR/CDDL tool you're using, i'll try it myelf first
before yelling for help ;-)
> 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.
I was just trying to follow what seems to be common practice and
minimize the new wheels we're inventing by re--using existing wheels.
> One more comment below...
> > 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.
Right. Which is why the objective-value structure proposal also hass
the whole "service" element as an optional subelement only.
> > "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.
Yes, pretty sure "join_registrar" was some BRSKI collaborator idea.
> > 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.
Thats what the objective-value proposal is doing.
> > 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.
I hope i did mention initialy in my email that the proposed structure
for objetive-value was primarily for flooded objectives and just trying
to establish a structure that allows to define cross-objective shared
eleemnts - without limiting the objective specific ones.
Cheers
Toerless
> 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
> >
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
