Hi Roman, The version to address you review is now online: https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-add-ike-09
Please let us know if any further change is needed. Thank you. Cheers, Med > -----Message d'origine----- > De : BOUCADAIR Mohamed INNOV/NET > Envoyé : lundi 20 février 2023 09:06 > À : 'Roman Danyliw' <r...@cert.org>; ipsec@ietf.org > Objet : RE: AD review of draft-ietf-ipsecme-add-ike-08 > > Hi Roman, > > Thanks for the review. A candidate version is available at: > https://tinyurl.com/add-ike-latest > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : IPsec <ipsec-boun...@ietf.org> De la part de Roman Danyliw > Envoyé > > : vendredi 17 février 2023 21:43 À : ipsec@ietf.org Objet : > [IPsec] AD > > review of draft-ietf-ipsecme-add-ike-08 > > > > Hi > > > > I performed an AD review of draft-ietf-ipsecme-add-ike-08. > Thanks for > > this document. Below is my feedback: > > > > ** Section 3.1 > > > > Section 3.1.5 of > > [I-D.ietf-add-dnr] lists a set of service parameters that are > > recommended to be supported by implementations. > > > > The referenced section in draft-ietf-add-dnr provides MTI and > > RECOMMENDED options. Are both of these applicable here? > > [Med] We do already have the following: > > Section 3.1.5 of > [I-D.ietf-add-dnr] lists a set of service parameters that > are > recommended to be supported by implementations. > > > > > ** Section 3.2. Is the RESERVED field 2 or 3 octets? Figure 2 > and > > 3 says two and the text says three. > > > > [Med] This should be 2, but I agree with Paul/Valery here that we > can simply remove this field. > > > ** Section 3.2. Per the Certificate Digest field, please provide > a > > normative reference to computing a SPKI hash. > > > > [Med] OK > > > ** Section 3.2. Typo. s/theENCDNS_DIGEST_INFO/the > ENCDNS_DIGEST_INFO/ > > > > [Med] Fixed. > > > ** Section 4 > > If the request includes multiple bitwise identical attributes, > only > > the first occurrence is processed, and the rest SHOULD be > ignored by > > the responder. > > > > If only the first attribute should be processed why is the > second > > clause not a MUST. What would be the expected extraordinary > behavior > > given this SHOULD? > > > > [Med] Valery clarified this one. The next sentence right the one > you cited says the following: > > The responder MAY discard the full > request if the count of repeated attributes exceeds an > (implementation specific) threshold. > > > ** Section 4. > > These > > instances SHOULD be processed by initiators following their > service > > priority (i.e., smaller service priority values indicates a > higher > > preference). > > > > Can the intent of "processed" be clarified here? There are times > when > > the service priority should be ignored? > > > > [Med] I think that we were mixing the behavior of the IKE > initiator and DNS client components. As this text is about the IKE > initiator, I suggest we record as follows: > > NEW: > > These instances MUST be presented to a local DNS client > following their > service priority (i.e., smaller service priority values > indicates > a higher preference). > > > > Regards, > > Roman > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec _________________________________________________________________________________________________________________________ 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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
