Hi!
No problem. Let's do that next week, that sounds perfectly fine to me.
Yours,
Daniel
On Tue, Nov 22, 2022 at 4:43 PM John Scudder <j...@juniper.net> wrote:
> Hi Daniel,
>
> I’m not sure I’ll be able to do this before next week, but it’s at the
> front of my to-do list.
>
> Thanks,
>
> —John
>
> On Nov 22, 2022, at 4:24 PM, Daniel Migault <mglt.i...@gmail.com> wrote:
>
>
>
> 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
>
>
--
Daniel Migault
Ericsson
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
