On Wed, 10 May 2023, Valery Smyslov wrote:
I do think that is very confusing. I would prefer to see the field
described once to make it more clear there is only one format.
Do you think the figure above should be added to the document
with fields description?
No, I thought using just one figure would be more clear. But based on
the link you provided with Tero's discusion, I'm okay to leave it as.
and then kludge around depending on numhash and adnlen. And if there
are spare bytes left, I guess that must map to a cert digest then.
Sorry, but I don't buy this argument. IKEv2 has such attributes from
the very beginning. For example, to correctly parse SUPPORTED_ATTRIBUTES
We don't support that one, but point taken.
First, you still have to parse this attribute differently
depending on the "Num Hash Agls" value. But worse (wearing my implementation
hat),
this format is less friendly for parsing.
Ok, we disagree so with no clear winner, let's not make any further
changes and leave it as is. Thanks for your clarifications.
The format is actually the same, but depending on the request/response
some fields may be omitted. Don't you find it is weird that
in IKEv2 the whole data is omitted in the request if the length of the
attribute is 0?
I believe we follow the similar logic :-)
I understand, but it gets more complicated code wise when there are more
than one of these in the format. As implementer, we strongly prefer at
most of of these :)
I've cleared my DISCUSS (assuming the changed agreed will make it in the
next version).
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
