Hi Roman, thank you for the review, please see inline.
> 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? I rely on my co-authors here. > ** Section 3.2. Is the RESERVED field 2 or 3 octets? Figure 2 and 3 says two > and the text says three. The text is a leftover from recent changes. It must be 2, as in the figure. > ** Section 3.2. Per the Certificate Digest field, please provide a normative > reference to computing a SPKI > hash. OK. > ** Section 3.2. Typo. s/theENCDNS_DIGEST_INFO/the ENCDNS_DIGEST_INFO/ OK, thanks. > ** 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? We have had an off-the-list discussion among the authors regarding this piece of text. The intention for using SHOULD here is that the following sentence allows the responder to ignore the whole request if it contains too many repeated attributes (SHOULD, alternatively MAY). We were having some doubts, whether SHOULD here might cause any confusion and MUST should be used instead, but finally left SHOULD. > ** 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? I'll leave this to my co-authors. Regards, Valery. > Regards, > Roman > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
