Rob, FWIW, the candidate changes to address your review (and also Paul/Éric reviews) can be seen here: https://tinyurl.com/add-ike-latest.
Please let us know if this solves your concerns. Thanks. Cheers, Med > -----Message d'origine----- > De : BOUCADAIR Mohamed INNOV/NET > Envoyé : jeudi 27 avril 2023 15:18 > À : 'Rob Wilton (rwilton)' <[email protected]>; The IESG > <[email protected]> > Cc : [email protected]; [email protected]; > [email protected]; [email protected] > Objet : RE: Robert Wilton's Discuss on draft-ietf-ipsecme-add-ike- > 11: (with DISCUSS and COMMENT) > > Re-, > > Thanks for the follow-up. > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Rob Wilton (rwilton) <[email protected]> Envoyé : jeudi 27 > avril > > 2023 12:12 À : BOUCADAIR Mohamed INNOV/NET > > <[email protected]>; The IESG <[email protected]> Cc : > > [email protected]; [email protected]; > > [email protected]; [email protected] Objet : RE: Robert Wilton's > Discuss on > > draft-ietf-ipsecme-add-ike- > > 11: (with DISCUSS and COMMENT) > > > > Hi Med, > > > > > -----Original Message----- > > > From: [email protected] > > <[email protected]> > > > Sent: 27 April 2023 10:48 > > > To: Rob Wilton (rwilton) <[email protected]>; The IESG > > <[email protected]> > > > Cc: [email protected]; ipsecme- > > [email protected]; > > > [email protected]; [email protected] > > > Subject: RE: Robert Wilton's Discuss on draft-ietf-ipsecme- > add- > > ike-11: > > > (with DISCUSS and COMMENT) > > > > > > Hi Rob, > > > > > > Thanks for the review. > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > > > Orange Restricted > > > > > > > -----Message d'origine----- > > > > De : Robert Wilton via Datatracker <[email protected]> > Envoyé : > > jeudi > > > > 27 avril 2023 11:19 À : The IESG <[email protected]> Cc : > > > > [email protected]; ipsecme- > [email protected]; > > > > [email protected]; [email protected]; [email protected] Objet : > Robert > > > > Wilton's Discuss on draft-ietf-ipsecme-add-ike-11: > > > > (with DISCUSS and COMMENT) > > > > > > > > Robert Wilton has entered the following ballot position for > > > > draft-ietf-ipsecme-add-ike-11: Discuss > > > > > > > > When responding, please keep the subject line intact and > reply > > to > > > > all email addresses included in the To and CC lines. (Feel > > free to > > > > cut this introductory paragraph, however.) > > > > > > > > ------------------------------------------------------------ > -- > > ---- > > > > ---- > > > > DISCUSS: > > > > ------------------------------------------------------------ > -- > > ---- > > > > ---- > > > > > > > > Hi, > > > > > > > > Thanks for this document. > > > > > > > > This should be a trivial discuss to resolve, and only > flagging > > it as > > > > a discuss because I think that it makes the spec unclear (or > > wrong): > > > > > > > > (1) p 4, sec 3.1. ENCDNS_IP* Configuration Payload > Attributes > > > > > > > > * IP Address(es) (variable) - Includes one or more IP > > addresses > > > > that > > > > can be used to reach the encrypted DNS resolver > > identified by > > > > the > > > > Authentication Domain Name. For ENCDNS_IP4 this field > > > > contains > > > > one or more 4-octet IPv4 addresses, and for ENCDNS_IP6 > > this > > > > field > > > > contains one or more 16-octet IPv6 addresses. > > > > > > > > Shouldn't this be zero or more IP addresses? Otherwise, the > > example > > > > that only contains a domain and no IP address appears to be > > invalid. > > > > > > > > > > [Med] That text is correct. The field is present only when > there > > is an IP address > > > to convey; otherwise the field is skipped. The presence is > > indicated by this field: > > > > > > Num Addresses (1 octet) - Indicates the number of enclosed > IPv4 > > (for > > > ENCDNS_IP4) or IPv6 (for ENCDNS_IP6) addresses. > > [Rob Wilton (rwilton)] > > > > I've just rechecked it, and I still don't find the text clear in > that > > section that this field is optional. I think that some more > words are > > required somewhere :-) > > > > E.g., the overall length field is defined like this: > > > > * Length (2 octets, unsigned integer) - Length of the > enclosed > > data > > in octets. In particular, this field is set to: > > > > - 0 if the Configuration payload has types CFG_REQUEST > (if no > > specific DNS resolver is requested) or CFG_ACK. If the > > 'Length' field is set to 0, then later fields shown in > Figure > > 1 > > are not present. > > > > ADN Length is defined as: > > > > * ADN Length (1 octet) - Indicates the length of the > > "Authentication > > Domain Name" field in octets. When set to '0', this means > that > > no > > ADN is enclosed in the attribute. > > > > Whereas, Num Addresses is defined as: > > > > * Num Addresses (1 octet) - Indicates the number of enclosed > > IPv4 > > (for ENCDNS_IP4) or IPv6 (for ENCDNS_IP6) addresses. This > value > > MUST NOT be set to 0 if the Configuration payload is of > type > > CFG_REPLY or CFG_SET. > > > > - This doesn't indicate that 0 addresses allowed (which might be > > okay), but it also doesn't indicate that the IP Addresses field > is > > absent if there are no addresses. > > [Med] There must be always an IP address in a response (to avoid > falling back to Do53 to resolve the name). However, the request > does not have that constraint (hence no mention of CFG_REQUEST > under Num Addresses). An initiator can send an ADN as a hint > without including any suggested address value as in this example: > > CP(CFG_REQUEST) = > INTERNAL_IP6_ADDRESS() > INTERNAL_IP6_DNS() > ENCDNS_IP6(1, 0, 15, "doh.example.com") > > Figure 7: Example of CFG_REQUEST with a Preferred > Resolver > Identified by Its ADN > > Will see how to make this better in the text. > > > > > As in I would still read section 3.1 in its entirety as needing > as > > least 1 IP address to be specified unless ADN Length is set to > 0. > > > > Thanks, > > Rob > > _________________________________________________________________________________________________________________________ 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
