Hi Med! Thanks for merging the substance of the discussion triggered from AD review into -09. I'm advancing the document.
Roman > -----Original Message----- > From: IPsec <ipsec-boun...@ietf.org> On Behalf Of > mohamed.boucad...@orange.com > Sent: Monday, February 27, 2023 11:10 AM > To: Roman Danyliw <r...@cert.org>; ipsec@ietf.org > Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-add-ike-08 > > 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
