Benjamin Mord <b...@mord.io> writes:
> One thing I find useful in RFCs is a brief discussion about the meaning of
> terms like MUST, SHOULD, MAY, etc.. as used in the subsequent protocol
> definition.
Hi Benjamin!
Weird, I always find them kinda useless. RFC2119 pretty much
covers it.
> When a BOLT says that a lightning node MUST do some X, what does that mean
> exactly? I'm thinking it means we should stigmatize it as "non-compliant"
> with protocol consensus as documented in BOLTs, whenever we discuss the
> implementation. I think violation of a MUST should be considered hostile. I
> think a MUST encourages nodes to fail a channel or connection upon
> observing a violation of that MUST, and even to take
> implementation-specific defensive measures as deemed appropriate by
> implementers (so long as they have cryptographic evidence that the
> violation is not forged). But in no way does a MUST assure implementers
> that they may assume this MUST will be respected by remote nodes, as it is
> not the purpose of MUST to convey that cryptographic safeguards or such
> elsewhere in the protocol design have arranged to force adherence..
This is why we attempt to divide requirements into sender and receiver.
For example, this is an absolute unchangable protocol requirement:
Sender MUST set X.
Receiver MUST close channel if X is not set.
or:
Sender MUST set X.
If X is set, Receiver MUST ...
The latter implies that future versions of the spec may have senders not
setting X.
I thought about writing a BOLT on how to write BOLTs, but it would
doubtless come across as inane navel-gazing.
Note also that the spec does not live up to this property in all places,
but we bugfix where we find that.
Cheers,
Rusty.
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
