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://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)' <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.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
