> On Aug 11, 2022, at 2:13 AM, Valery Smyslov <smyslov.i...@gmail.com> wrote: > > Hi Tommy, > > thank you for the review and for the proposed changes. > I reviewed them and they look good to me. > I still disagree with one requested change, see below. > > From: IPsec <ipsec-boun...@ietf.org <mailto:ipsec-boun...@ietf.org>> On > Behalf Of Tommy Pauly > Sent: Wednesday, August 10, 2022 7:33 PM > To: Tero Kivinen <kivi...@iki.fi <mailto:kivi...@iki.fi>>; ipsec@ietf.org > <mailto:ipsec@ietf.org> > Subject: Re: [IPsec] WGLC of draft-ietf-ipsecme-add-ike > > I’ve done a review pass of this document. In general, I think it is > technically good. > > I did find several places where I think additional clarity or editorial > improvements could be made. To address these, I’ve proposed the following > pull request: https://github.com/boucadair/draft-ietf-ipsecme-add-ike/pull/5 > <https://github.com/boucadair/draft-ietf-ipsecme-add-ike/pull/5> > > Some of the revenant items I am trying to address are: > - Make it more clear early on that the attributes are generically > communicating encrypted DNS resolvers, and don’t define specific details for > DoH/DoT/DoQ (that comes from the SVCB-DNS draft) > - Be more explicit about how ENCDNS_IP* are two specific types, ENCDNS_IP4 > and ENCDNS_IP6 > - Introduce and explain ENCDNS_DIGEST_INFO earlier on. Currently, it is > defined with no explanation until a later section. > - Clarify the behavior of the initiator for including ENCDNS_IP* attributes. > Specifically, I believe this is intended to be: either include exactly one > empty ENCDNS_IP* attribute of a given type to request “any” encrypted DNS > resolver on that address family; OR, include one or more of that type with > hints about the addresses and APNs being requested. This was implied by the > text previously, but not clear. > > I think there is some inconsistency here and the proposed text doesn't > address it. > The text requires that the initiator MUST NOT send more than one empty > attribute of a given type, > but what about sending multiple non-empty attributes with the same content? > > I believe we should say that the initiator MAY send several ENCDNS_IP4 and > ENCDNS_IP6 attributes, > but all of them MUST be distinct (either empty or specifying different > resolvers). > The responder MUST ignore repeated attributes if any.
Sure, being even more clear to explain that each attribute must be distinct is good! Please amend the text to that effect, as you see fit. Best, Tommy > > Regards, > Valery. > > If these items are addressed, I’m happy to see this progress. > > Thanks, > Tommy > > >> On Aug 9, 2022, at 1:47 PM, Tero Kivinen <kivi...@iki.fi >> <mailto:kivi...@iki.fi>> wrote: >> >> This is the start of 2 week WGLC on the document, ending 2022-08-17. >> Please submit your comments to the list, also send a note if you have >> reviewed the document, so we can see how many people are interested in >> getting this out. >> -- >> kivi...@iki.fi <mailto:kivi...@iki.fi> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org <mailto:IPsec@ietf.org> >> https://www.ietf.org/mailman/listinfo/ipsec >> <https://www.ietf.org/mailman/listinfo/ipsec> >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
