Re: [homenet] John Scudder's Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)

[Daniel Migault <[e-mail]>]

On Fri, Oct 28, 2022 at 4:18 PM John Scudder <[e-mail]> wrote:

> > On Oct 28, 2022, at 2:52 PM, Daniel Migault <[e-mail]> wrote:
> >
> > Let me know if the text below is clearer.
>
> So much clearer! Thanks!
>
> > OLD:
> > The transport channel (including port number) is the same as the one
> used between theHN
> > A and the DM for the Control Channel.
> >
> > NEW:
> > The DNS exchanges performed by the DM to synchronize the zone is using
> the same destination port and same transport protocol as for the Control
> Channel.
> > This document only specifies DNS over TLS as the transport protocol.
> > If the Control Channel between the HNA and the DM uses DNS over TLS
> {{!RFC7858}} over port XX (XX being 853 by default), the Synchronization
> Channel between the DM and the HNA will use DNS Zone transfer over TLS
> {{!9103}} using port XX. Note that the source port may be different for
> both channels (see {{sec-synch}} for more details ).
> >
> > HNA                                        DM
> > ---------                                  ---------
> > port NNNN --------control channel--------> port MM
> > port MM <-----synchronization channel----- port NNNN
> >
> > where arrow directions indicate who the initiator of the connection is,
> port NNNN denotes an ephemeral port, and port MM denotes a well-known port.
> As written, the most literal interpretation would be:
> >
> > HNA                                        DM
> > ---------                                  ---------
> > port NNNN --------control channel--------> port MM
> > port NNNN <-----synchronization channel--- port MM
> >
> > which regrettably doesn’t make sense. Without a better understanding of
> your intended meaning, I’m afraid I can’t propose wording.
> >
> > [… snip …]
> >
> > > ### Section 4.5.3
> > >
> > > ```
> > >    Similarly to Section 4.5.2, DNS errors are used and an error
> > >    indicates the DM is not configured as a secondary.
> > > ```
> > >
> > > Related to the previous comment -- is this true regardless of what
> error code
> > > is returned, for example would a FORMERR mean that the DM is not
> configured as
> > > a secondary?
> > >
> > > Even given that any error implies that the operation failed, what if
> the DM had
> > > already been previously configured as secondary, and the operation
> were merely
> > > updating some parameter? Would the previous configuration be voided,
> as the
> > > text currently implies? Or would the DM remain configured as
> secondary, using
> > > the previous configuration?
> > >
> > > We used DNS errors to imply that the standard DNS behavior is
> expected. When teh update fails, the data remains in its previous step.
> >
> > Doesn’t that mean the text as written isn’t accurate, though? A possible
> rewrite could be “… an error indicates that the requested update to the DM
> will not take effect."
> >
> > Just to avoid any confusion. In this case, DNS Updates are just ways to
> carry some configuration parameters from the HNA to the DM. In other words,
> they would not result in any update of a zone. - updates of the zone are
> handled by the synchronization channel. As result, an error of the DNS
> update indicates the secondary is not configured.
>
> I thought we had previously agreed ("the data remains in its previous
> step") that if the DM had been previously successfully configured as
> secondary, after the failure the DM would still be a secondary.
>
> > Updates in the zone can only happen when the secondary is configured.
> >
> > I think your proposal is correct that an error to the DNS update
> indicates  requested update to the DM will not take effect, but I think it
> introduces some ambiguity that an effective update of the Public homenet
> zone was expected with this request. If we agree on this, I would prefer
> not to introduce such ambiguity and prefer to stick to the consequences
> which is that the DM is not configured . I am though happy to consider any
> other wordings
>
> I’m sorry, I can’t figure out how we get from “the data remains in its
> previous step” to “the DM is not configured”. :-( Maybe I’m still missing
> some subtlety, it’s Friday after all. :-/
>
> Thanks,
>
> —John


Let me restart from zero.
The DNS update in the control channel is not used to update any sort of
zone. The control channel is just a channel to agree on some parameters.
The control channel could have been implemented by POSTing/Getting a JSON
file with the sufficient parameters. Instead the WG decided to use some DNS
payloads and the WG decided to use AXFR and DNS update DNS exchange.

On the control channel, a DNS update represents how the HNA provides
information to the DM. When an error occurs, on the DM view such
information does not exist - whatever the reason for the error is. On the
DM view everything happens as if the DNS Update has not happened. This is
how DNS updates work when an update in a zone is actually performed. A
failed DNS UPdate does not result in the configuration to be erased,
forcing the HNA to restart from scratch.

If that information is required to set the secondary (by the DM) and the DM
does not have such information, it will not be able to act as a secondary.


Now that I am reading your comment, if your concern is how we can update
the configuration of a running DM. Of course the secondary configuration
may be "simply" updated along time, but I tend to believe that maintaining
states to follow what needs to be updated is probably adding significant
complexity as opposed to simply reconfiguring from scratch such complexity
has to be balanced with a single DNS exchange which I do not think really
worth the pain. But as you mentioned, that is Friday night ;-)



-- 
Daniel Migault
Ericsson