Re: [Dots] AD Review of draft-ietf-dots-multihoming-10

[Roman Danyliw <[e-mail]>]

Hi Med!

Thanks for these changes.  They address my AD review.  I've advanced the document to IETF LC.

Roman

> -----Original Message-----
> From: Dots <[e-mail]> On Behalf Of
> [e-mail]
> Sent: Wednesday, February 9, 2022 4:11 AM
> To: Roman Danyliw <[e-mail]>; [e-mail]
> Subject: Re: [Dots] AD Review of draft-ietf-dots-multihoming-10
> 
> Hi Roman,
> 
> Many thanks for the review. Much appreciated!
> 
> The changes can be tracked at: https://tinyurl.com/dots-multihoming-latest.
> 
> Please see inline for more context.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Dots <[e-mail]> De la part de Roman Danyliw Envoyé :
> > mercredi 9 février 2022 00:16 À : [e-mail] Objet : [Dots] AD
> > Review of draft-ietf-dots-multihoming-10
> >
> > Hi!
> >
> > I performed an AD review of draft-ietf-dots-multihoming-10.  Ben and I
> > swapped on this document so I'll be the responsible AD from now on.
> > Thanks for writing these operational considerations.
> >
> > The document is in good shape. I primarily have a few suggested
> > editorial clarifications and a few places where a bit more clarity
> > might be helpful.
> >
> > ** Section 5.*.  Should the diagrams or the associated text be clearer
> > on the relationship between the CPE and the DOTS clients.
> >
> > -- For Section 5.1, C = the CPE?
> > -- For Section 5.2, G = the CPE?
> > -- For Section 5.3, G1 and G2 = the CPEs?
> 
> [Med] I agree. Updated the text and the figures as appropriate.
> 
> > etc...
> >
> > ** Section 5.1.
> >    For each provisioning domain, the DOTS client MUST resolve the DOTS
> >    server's name provided by a provisioning domain [RFC8973] using the
> >    DNS servers learned from the respective provisioning domain (or the
> >    DNS servers associated with the interface(s) for which a DOTS server
> >    was explicitly configured).
> >
> > -- Editorially, given the repetition of "provisioning domain", I had
> > trouble parting this sentence.
> >
> > -- I'm also wondering if the first step of this scenario is that the
> > interface should provision itself per [RFC8973]?
> 
> [Med] RFC8973 covers also explicit configuration. The first sentence says that:
> assuming that a name is available from the upstream domain following the
> means discussed in 8973, here is what to do for resolving that name.
> 
> >
> > -- Per the guidance on resolving the DOTS server.  The options seem to
> > be to use the DNS server the CPE learned from the network or the one
> > configured for the interface.  The direction is clear, but I'm trying
> > to understand the intent.  Is this trying to provide explicit guidance
> > to not use some system wide resolver configuration?
> 
> [Med] The text covers the specific case when the DOTS server is provided by
> the upstream domain. Blindly using any DNS server may lead to failure to
> resolve the name.
> 
>   If you don't get the
> > DNS configuration from local policy and not from the network, I'm not
> > sure where else if could come from.
> >
> > To be concrete, does the following mean the same thing:
> >
> > NEW
> > For each provisioning domain, the DOTS client MUST use the procedures
> > of [RFC8973] to discover the associated DOTS server(s).  Furthermore,
> > the DOTS client MUST resolve the DOTS server's name using either the
> > DNS server learned from the provisioning domain or from a DNS server
> > explicitly configured with the interface .
> 
> [Med] What about the following:
> 
>    The DOTS client MUST resolve the DOTS server's name provided by each
>    provisioning domain using either the DNS servers learned from the
>    respective provisioning domain or from the DNS servers associated
>    with the interface(s) for which a DOTS server was explicitly
>    configured (Section 4).
> 
> 
> Note that the pointer to Section 4 targets specifically this part:
> 
>    If a DOTS server is explicitly configured, it is assumed that an
>    interface is also provided to bind the DOTS service to an
>    interconnection link.  If no interface is provided, this means that
>    the DOTS server can be reached via any active interface.
> 
> >
> > ** Section 5.1.
> >   The DOTS client SHOULD use the certificate
> >    provisioned by a provisioning domain to authenticate itself to the
> >    DOTS server(s) provided by the same provisioning domain.
> >
> > Is there an automated mechanism to get this certificate being hinted
> > at, or is this certificate provisioned by some out-of-band (and
> > out-of-
> > scope) mechanism?
> 
> [Med] This is out of scope. Added a note to record this.
> 
> >
> > ** Section 5.1
> >    The DOTS client MUST be able to associate a DOTS server with each
> >    provisioning domain.
> >
> > The subsequent example text clarifies the intent.  On first read it
> > seems like the normative guidance is that there must be a DOTS server
> > with each PD.  Would the following be clearer?
> >
> > NEW:
> > The DOTS client MUST be able to associate a DOTS server with the
> > provisioning domain it serves.
> 
> [Med] Works for me. Thanks.
> 
> >
> > ** Section 5.2.
> >    Figure 6 illustrates a first set of DOTS sessions that can be
> >    established with a client-domain DOTS gateway
> >
> > What are the "first set of DOTS sessions"?
> 
> [Med] s/first set of DOTS sessions/DOTS sessions
> 
> >
> > ** Section 5.2. Typo. s/addreses/addresses/
> 
> [Med] Fixed.
> 
> >
> > ** Section 5.2
> >
> >    The CPE MUST select the appropriate source IP address when forwarding
> >    DOTS messages received from an internal DOTS client.
> >
> > Is this guidance specific only to Figure 6 where the gateway is present?
> 
> [Med] This applies when the CPE does not host a dots gateway. Made this
> change for better clarity (merge):
> 
> OLD:
> 
>    For both deployments depicted in Figures 7 and 8, each DOTS client
>    SHOULD be provided with policies (e.g., a prefix filter that will be
>    against DDoS detection alarms) that will trigger DOTS communications
>    with the DOTS servers.  Such policies will help the DOTS client to
>    select the appropriate destination DOTS server.
> 
>    The CPE MUST select the appropriate source IP address when forwarding
>    DOTS messages received from an internal DOTS client.
> 
> NEW:
> 
>    For both deployments depicted in Figures 7 and 8, each DOTS client
>    SHOULD be provided with policies (e.g., a prefix filter that will be
>    against DDoS detection alarms) that will trigger DOTS communications
>    with the DOTS servers.  Such policies will help the DOTS client to
>    select the appropriate destination DOTS server.  The CPE MUST select
>    the appropriate source IP address when forwarding DOTS messages
>    received from an internal DOTS client.
> 
> >
> > ** Section 5.3.  Editorial.
> > OLD
> > A client-domain DOTS gateway is enabled in each CPE (rtr1, rtr2).
> >
> > NEW
> > A client-domain DOTS gateway is enabled in each CPE (rtr1 and rtr2 per
> > Table 1; and G1 and G2 per Figure 9).
> >
> 
> [Med] Changed to:
> 
>    o  A client-domain DOTS gateway is enabled in each CPE (rtr1 and rtr2
>       per Table 1).
> 
> The link between rtrs/Gs was clarified in the updated Figure 9.
> 
> > Regards,
> > Roman
> >
> > _______________________________________________
> > Dots mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dots
> 
> ___________________________________________________________________
> ______________________________________________________
> 
> 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.
> 
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots