[net2-wg] TEP 119 : MAY vs SHOULD

[Rodrigo Fonseca]

Phil,

you alluded to cases in which you might not want to signal receive at
the root, after receiving a packet. I have two questions int hat
regard:
 1. can you think of some examples (you mention the case of forwarding
packets directly to the UART)
 2. in any of those examples, is there any reason you couldn't do that
as a client to the receive interface?

I could see not signaling receive if buffers are full, or, as a more
involved example, in case we want to avoid network-wide duplicates. In
this example, the roots can communicate out-of-band (for example, they
are all connected to a LAN outside of the WSN), and one tells the
other about packets it has received.

I think 2 above is important to decide between MAY and SHOULD. If
there are no compelling answers to 2, then it should be SHOULD,
otherwise, MAY.

Rodrigo


On Tue, Aug 19, 2008 at 2:43 PM, Philip Levis <pal at cs.stanford.edu> wrote:
>
> On Aug 19, 2008, at 2:42 PM, Omprakash Gnawali wrote:
>
>> On Tue, Aug 19, 2008 at 2:10 PM, Philip Levis <pal at cs.stanford.edu>
>> wrote:
>>>
>>> On Aug 19, 2008, at 2:05 PM, Omprakash Gnawali wrote:
>>>
>>>> This is the MAY vs SHOULD debate we had several weeks ago during a
>>>> net2
>>>> meeting.
>>>>
>>>> Related to the following comment on TEP 119:
>>>>
>>>> "6. In section 3, the following part, "ColletionC MUST NOT signal
>>>> Receive.receive on non-root nodes. CollectionC MAY signal
>>>> Receive.receive on a root node when a data packet successfully
>>>> arrives
>>>> at that node."
>>>>
>>>> For the second sentence, I believe "CollectionC SHOULD signal
>>>> Receive.receive on a root node when a data packet successfully
>>>> arrives
>>>> at that node" is the correct way of saying it. Because CTP will
>>>> mostly
>>>> be used in cases to collect data, signaling Receive.receive SHOULD
>>>> be
>>>> the right thing to do at the root.
>>>> "
>>>>
>>>> We received these three responses -
>>>>
>>>> 1. I think I agree. -om
>>>>
>>>> 2. I'm on the fence on this one. I can imagine lots of collection
>>>> protocols that don't signal receive because they do other things
>>>> with
>>>> the packets. Older collection protocols (1.x) actually just
>>>> forwarded
>>>> to the UART automatically. It's clear that implementations today
>>>> signal Receive, but it's perfectly reasonable to have one that
>>>> doesn't. -pal
>>>>
>>>> 3. I don't see why calling receive would restrict you from doing
>>>> anything. You can easily implement 'forward to the UART' in the
>>>> receive handler. MAY is still fine, though. -rodrigo
>>>>
>>>>
>>>> Are MAY and SHOULD mutually exclusive?
>>>>
>>>> MAY makes an argument about what kind of guarantees that do not
>>>> exist.
>>>>
>>>> SHOULD makes a recommendation on good practices based on experience.
>>>>
>>>> If we think that we don't have reasonable experience to recommend
>>>> one
>>>> way or the other, we should drop SHOULD. But what is a reasonable
>>>> level of experience? It does not make us an expert in collection
>>>> but a
>>>> lot of us has used collection in one form or other for a few years
>>>> now. Is there anything we can say from our experience? If we have
>>>> learned something about how collection SHOULD be used, that is an
>>>> important statement to make so others can benefit from that
>>>> experience.
>>>
>>> I'm a little wary of having a SHOULD in an interface specification.
>>> Usually,
>>> SHOULD relates to some kind of implementation point. If it's
>>> SHOULD, then
>>> people might assume the collection layer does it, when some might
>>> not.
>>>
>>> Maybe we should change this to "SHOULD provide the Receive
>>> interface"?
>>>
>>
>> The downside is it can lead to signature incompatibility even among
>> compliant implementations.
>
> Well, it's better to be a compile-time error that you expect to
> receive packets but won't...
>
> Phil
> _______________________________________________
> net2-wg mailing list
> net2-wg at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/net2-wg
>