Re: [Editorial Errata Reported] RFC4666 (4475)
2015-09-16 09:30:09 GMT
(Sorry I’m forced to top post)
It would be interesting to know what has actually been implemented.
(No one will have generated 32 byte alignment.)
We’d assumed that the parameter length excluded any required pad, and that
the diagram showed it because this was one place where padding was likely to be needed.
Indeed how many implementations actually support the key management messages.
AFAICT the main commercial implementation of M3UA still uses RFC 3332.
If the length of this parameter includes these pad bytes, then what should you do
if a zero is followed by a non-zero byte?
There's a clear statement on page 32 of RFC 4666 that indicates that the "Parameter Length does not include any padding octets".
Even though SI parameter specification violates this "rule", it is quite plausible that there may be a number of implementations that may have followed this specification with padding octets.
Thus, how practical would it be to indicate that there will be no padding for SI parameter that does not contain multiple of four SIs, considering that we may end up converting a number of compliant implementations into a score of non-compliant ones.
I think that changing 32-byte to 32-bit alignment is much safer (and considerably cheaper) option.
Registration No: 1397386 (Wales)
P Please consider the environment and don't print this e-mail unless you really need to
_______________________________________________ Sigtran mailing list Sigtran <at> ietf.org https://www.ietf.org/mailman/listinfo/sigtran