Re: [Anima-signaling] Two definite proposals for GRASP protocol change

[Carsten Bormann <[e-mail]>]

Hi Brian,

looking over the CDDL again, I'm stumbling over the presence and absence
of an initiator in the messages.

First of all, the overall pattern

     message /= [MESSAGE_TYPE, session-id, ?initiator, *option]

(3.7.1) is ambiguous in that an initiator looks just like an option, so
you cannot write a general parser that understands this pattern.
(This is OK since the specific messages define whether an initiator is
present or not, but it still feels a bit odd.)

More odd to me is that the session-id only makes sense in conjunction
with the initiator, but the latter is not always given.  I can't quite
make rhyme and reason out of when it's there and when not.  Maybe that
should be explained in the text (beyond what's in 3.6), including how
the initiator is implied when not present in the message (source IP
address of UDP packet?).  Maybe I'm just confused that discovery pairs
with response, and not request.  Oh, and there is a certain danger that
implementation errors in this space are not caught until two initiators
happen to use the same session-id.  (Protocols with infrequent cases
where certain protocol behavior becomes important for correctness are
harder to test.)

(I also have a suspicion that the protocol might not react well when
responses are sent from IP addresses different than to which the request
was sent.  It is harder to get this right with UDP than it should be.)

Editorially, I'm not sure I have said that, but I'm not a big fan of the
non-parsable ("fragmentary") pieces of CDDL in the CDDL fragments.
They make it a bit harder to extract all the fragments and check
automatically whether they are consistent with the overall structure in
section 6.  (They also make we want to quibble over the exact
fragmentary syntax to be used.)  Instead of

     initiator /=   ; defined below
     objective /=   ; defined below

how about:
     ; initiator and objective are defined below

(But then, saying four times that initiator and six times that objective
is defined below doesn't make a lot of sense either.)

All this is more in the sense of food for thought than in the sense of
"Houston, we have a problem".

Grüße, Carsten



Brian E Carpenter wrote:
> On 11/12/2015 03:50, Carsten Bormann wrote:
>> ... and looking at the CDDL after extracting it manually:
>>
>> MESSAGE_TYPE is what kind of thing?
>>
>> Assuming this might need to extensible, I think specifying something like
>>
>> MESSAGE_TYPE = 0..255 ; a constant defined below
>>
>> might help (alternatively: 0..99, if you want to keep them separate from
>> option numbers).
> 
> Yes, thanks.
> 
>> MESSAGE_TYPE = M_DISCOVERY / M_RESPONSE / M_REQUEST / M_NEGOTIATE /
>> M_END / M_WAIT
>>
>> (We might also define `option` and `OPTION_TYPE`, where the former
>> includes the ip locator options as well as the options built from type
>> numbers.)
> 
> Might be cleaner.
> 
>> s/tstr/text/g, I'd say.
> 
> Yes
> 
>> What does it mean to use the same objective-name with different
>> objective-flags?
> 
> You use D when only conducting discovery, and N or S when also
> conducting negotiation or synchronization respectively. It's possible
> these flags are not really needed - to be frank I will know that when
> I have completed coding my prototype. If I never need to test the flags
> they can be removed.
> 
> Regards
>    Brian
> 
>> Grüße, Carsten
>>
>>
>> Carsten Bormann wrote:
>>> Brian E Carpenter wrote:
>>>> 1)
>>>>
>>>> I invented the PEN field so I think I can also kill it. My proposal is that we take
>>>> this out of the protocol itself. We state that an objective's name is ":whatever" if
>>>> it's generic and "vendorString:whatever" if it's vendor specific. The formal
>>>> definition of vendorString is that it's a unique UTF-8 string not including ":".
>>>> The format MAY be an FQDN, an email address, or a PEN (represented as a decimal
>>>> number).
>>> With the last sentence, there is some hope of uniqueness.
>>>
>>> (Of course, we have about a million ways of doing this already in the
>>> IETF; URNs etc., but the above selection sounds good.)
>>>
>>> There is no need for the initial : if you stipulate that generic
>>> (registered) objectives cannot contain a :.
>>>
>>>> As far as GRASP is concerned, an objective name is now simply a string.
>>>> Simpler protocol, simpler code.
>>> Sounds good.
>>>
>>>
>>>> 2)
>>>>
>>>> Add a global IP address in all Discovery and Response messages, which is
>>>> a valid address for the initiator, to avoid the remote chance of clashing
>>>> session IDs. 
>>> 1) I may not have a global address yet at the time I build such a
>>> message, right?
>>>
>>> 2) Because people will start using these fields for all kinds of things
>>> (starting side conversations etc.), I'd rather be careful about adding
>>> mechanism that implies some semantics (here: that of an IP address).
>>>
>>> Better to mix in more of this information into a session ID (which needs
>>> to be long enough to make clashes after a reboot unlikely).
>>>
>>>
>>>> I'm happy. My Python code for GRASP discovery is beginning to work.
>>>> This doesn't look much, but it's telling me there is something in the
>>>> discovery cache:
>>>>
>>>>>>> discovery_cache[0].asa_locators[0].locator
>>>>     IPv6Address('2406:e007:6917:1:28cc:dc4c:9703:6781')
>>>>>>> discovery_cache[0].objective.name
>>>>     ':Boot'
>>>>>>> discovery_cache[0].objective.disc
>>>>     True
>>>
>>> Nice!
>>>
>>> One thing I'd like to see is extractable CDDL.
>>>
>>> 1) Right now, I can't use the usual XPath expression
>>>
>>>    //artwork[@type='CDDL']/text()
>>>
>>> because the artwork elements don't have type attributes.
>>>
>>> 2) The "fragmentary CDDL" concept does not work if the extracted CDDL is
>>> to be useful to run checks over it etc.  So, I'd change constructs of
>>> the form
>>>
>>>      option /=      ; one of the options defined below
>>>
>>> into
>>>
>>>      ; use
>>>      ;    option /= ...
>>>      ; to define choices for the options.
>>>
>>> (BTW, please have a look at
>>>
>>> https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-07#appendix-B.1.5
>>>
>>> for a way to combine a general format with specific choices.)
>>>
>>> Grüße, Carsten
>>>
>>> _______________________________________________
>>> Anima-signaling mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/anima-signaling
>>>
>>>
> 
> _______________________________________________
> Anima-signaling mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima-signaling
> 
>