Re-, Made this change at https://github.com/boucadair/draft-ietf-ipsecme-add-ike/commit/da014c757aae35454bf9e4296e4b9dec08047380.
Thanks Rob. Cheers, Med > -----Message d'origine----- > De : Rob Wilton (rwilton) <rwil...@cisco.com> > Envoyé : jeudi 27 avril 2023 15:54 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; > The IESG <i...@ietf.org> > Cc : draft-ietf-ipsecme-add-...@ietf.org; ipsecme-cha...@ietf.org; > ipsec@ietf.org; kivi...@iki.fi > Objet : RE: Robert Wilton's Discuss on draft-ietf-ipsecme-add-ike- > 11: (with DISCUSS and COMMENT) > > Hi Med, > > Yes, that text would be sufficient to clear my discuss. However, > I would suggest a slight rewording of your new sentence (that you > may use or ignore at your leisure): > > YOUR PROPOSED: > * 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. When set to '0' in CFG_REQUEST, this > means that no IP address is enclosed in the attribute. > > NEW PROPOSED: > * 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 may be set to 0 in CFG_REQUEST > Payloads to indicate that no IP address is encoded in the > attribute. > > Either way, I'll clear my discuss. > > Regards, > Rob > > > > -----Original Message----- > > From: mohamed.boucad...@orange.com > > <mohamed.boucad...@orange.com> > > Sent: 27 April 2023 14:44 > > To: Rob Wilton (rwilton) <rwil...@cisco.com>; The IESG > <i...@ietf.org> > > Cc: draft-ietf-ipsecme-add-...@ietf.org; ipsecme- > cha...@ietf.org; > > ipsec@ietf.org; kivi...@iki.fi > > Subject: RE: Robert Wilton's Discuss on draft-ietf-ipsecme-add- > ike-11: > > (with DISCUSS and COMMENT) > > > > Rob, > > > > FWIW, the candidate changes to address your review (and also > Paul/Éric > > reviews) can be seen here: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > tinyurl.com%2Fadd-ike- > latest&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C776a25e5899 > c406cb0a208db4726cec6%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7 > C638182004230396127%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC > JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata > =VS8AF4Y5UeRbNvUquQZ8Gu0iWszRzmsCVCeFIUW5WE8%3D&reserved=0. > > > > 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)' <rwil...@cisco.com>; The IESG > > > <i...@ietf.org> Cc : draft-ietf-ipsecme-add-...@ietf.org; > > > ipsecme-cha...@ietf.org; ipsec@ietf.org; kivi...@iki.fi > 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) <rwil...@cisco.com> Envoyé : jeudi > 27 > > > avril > > > > 2023 12:12 À : BOUCADAIR Mohamed INNOV/NET > > > > <mohamed.boucad...@orange.com>; The IESG <i...@ietf.org> > Cc : > > > > draft-ietf-ipsecme-add-...@ietf.org; ipsecme- > cha...@ietf.org; > > > > ipsec@ietf.org; kivi...@iki.fi Objet : RE: Robert Wilton's > > > Discuss on > > > > draft-ietf-ipsecme-add-ike- > > > > 11: (with DISCUSS and COMMENT) > > > > > > > > Hi Med, > > > > > > > > > -----Original Message----- > > > > > From: mohamed.boucad...@orange.com > > > > <mohamed.boucad...@orange.com> > > > > > Sent: 27 April 2023 10:48 > > > > > To: Rob Wilton (rwilton) <rwil...@cisco.com>; The IESG > > > > <i...@ietf.org> > > > > > Cc: draft-ietf-ipsecme-add-...@ietf.org; ipsecme- > > > > cha...@ietf.org; > > > > > ipsec@ietf.org; kivi...@iki.fi > > > > > 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 <nore...@ietf.org> > > > Envoyé : > > > > jeudi > > > > > > 27 avril 2023 11:19 À : The IESG <i...@ietf.org> Cc : > > > > > > draft-ietf-ipsecme-add-...@ietf.org; ipsecme- > > > cha...@ietf.org; > > > > > > ipsec@ietf.org; kivi...@iki.fi; kivi...@iki.fi 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. _________________________________________________________________________________________________________________________ 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
