Hi John,
Just let us know what remains to be addressed or clarified. We are happy to
move that document forward.
Yours,
Daniel
On Fri, Oct 28, 2022 at 5:38 PM Daniel Migault <mglt.i...@gmail.com> wrote:
>
>
> On Fri, Oct 28, 2022 at 4:18 PM John Scudder <j...@juniper.net> wrote:
>
>> > On Oct 28, 2022, at 2:52 PM, Daniel Migault <mglt.i...@gmail.com>
>> 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
>
--
Daniel Migault
Ericsson
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
