[manet] DLEP unspecified handling behavior

["Sipos, Brian J." <[e-mail]>]

All,

This seems like an errata item for DLEP RFC 8175, but it's really an
omission rather than an error in specific existing text. Currently the text
in Section 11.3 "DLEP Generic Data Item" indicates the correct TLV encoding
for each Data Item but it doesn't recommend how a receiver of a DLEP signal
or message should handle a case where a data item Value contains either more
or fewer octets than expected based on the Data Item Type. Some current
implementations ignore too-large Value (i.e. treat it as padding) while
others treat the signal/message as being malformed and throw the whole thing
away (or, worse, mishandle the Value and desync the decoder from the data
item alignment causing later phantom data items).

It seems like an issue processing an individual data item Value should not
cause the entire signal/message to be discarded, but maybe this is desirable
behavior.

 

The same kind of logic seems to also apply to signal Length field vs the
actual datagram size. Throw away the entire signal or decode the items you
can and process that? Treat any additional datagram octets as padding?

 

Any thoughts from the WG?

Thanks,

Brian S.