Yaron Sheffer wrote: > > - Section A.1 should say that the notation used for the example > > ticket formats is intended to be pseudo-code, and does not specify > > exact octet-by-octet format. (And probably things like > > "reserved[3]" should be removed, since they don't really belong in > > pseudo-code like this.) > > > > This is an example only, but it can still be precise. It *does* > specify an octet-by-octet format, except you're free to implement > something else, or change whatever you feel like. In general, I > think an implementer is better off starting from a precise > definition than from a vague pseudo-code description.
The text never specifies how e.g. "opaque state_ref" would be encoded (e.g. if it's variable length, there's probably some kind of length field somewhere), so IMHO it does not specify octet-by-octet format (two persons reading this would very likely end up with different octets). Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec