Re-, > 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.
I'm afraid this is a matter of taste. FYI, we used to have one single figure/field description till -06, and then split the figure into two as per a comment from Tero (https://mailarchive.ietf.org/arch/msg/ipsec/8-NcOjbBTk08lCHyYuU0zV5v_uM/). We made some changes to clarify that there is one single format. Please check the diff at: https://tinyurl.com/add-ike-latest. Cheers, Med > -----Message d'origine----- > De : Paul Wouters <[email protected]> > Envoyé : dimanche 7 mai 2023 22:54 > À : Valery Smyslov <[email protected]> > Cc : 'Paul Wouters' <[email protected]>; 'The IESG' > <[email protected]>; [email protected]; ipsecme- > [email protected]; [email protected]; [email protected] > Objet : Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme- > add-ike-11: (with DISCUSS and COMMENT) > > On Tue, 25 Apr 2023, Valery Smyslov wrote: > > > Actually, the format is the same for both request and response, > but > > depending on Num Hash Algs and AND Length and also on Length, > some > > fields may be omitted. > > > The most generic format is: > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-----------------------------+------------------------------- > + > > |R| Attribute Type | Length > | > > +-+-----------------------------+---------------+--------------- > + > > | Num Hash Algs | ADN Length | > | > > +---------------+---------------+ > + > > ~ Authentication Domain Name > ~ > > +--------------------------------------------------------------- > + > > ~ Digest Hash Alg Identifiers ~ > > +--------------------------------------------------------------- > + > > ~ Certificate Digest > ~ > > +-------------------------------+------------------------------- > + > > > > Figures 2 and 3 just show how this attribute looks when Num Hash > Algs, > > AND Length and Length have specific values, which make sense for > the > > request and response. > > 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. > > > > But even so, wearing my implementer hat, this is not a friendly > format to parse as various fields depend on other fields two > levels deep. > That is, I have to read in the data into a struct that has: > > struct ENC_DNS4 { > uint32_t attr_type; > uint32_t length; > int numhash; > int adnlen; > char *blob > }; > > 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. > > compare that to say: > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-----------------------------+------------------------------- > + > |R| Attribute Type | Length > | > +-+-----------------------------+---------------+--------------- > + > | Num Hash Algs | Digest Hash Alg Identifiers > ~ > +---------------+ > ~ > ~ > ~ > +--------------------------------------------------------------- > + > ~ Certificate Digest > ~ > +--------------------------------------------------------------- > + > ~ ADN > ~ > +--------------------------------------------------------------- > + > > This way we also do not need "ADN Length" anymore. It can state if > "Num Hash Agls" is not 1, Certificate Digest is omited. > > I'm still a little weirded out by how different request/response > format is - it is supposed to be the same thing, but filled in, > and the fact that the fields vary is kinda weird. > > Paul _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
