Hi John, Thanks for the follow-up - which is greatly appreciated. Please find my comment inline.
The current changes can be seen on the commit below: https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/72988ac88aafeda3d0a3417af048cf7553f348ba We are happy to address the changes as they are being discussed and will publish a new version as soon as the publication is open. Yours, Daniel On Thu, Oct 27, 2022 at 4:25 PM John Scudder <j...@juniper.net> wrote: > Hi Daniel, > > I haven’t reviewed the full change set yet, but I have a couple of > comments I didn’t want to hold back while I find time to review the rest. > > > On Oct 20, 2022, at 1:23 AM, Daniel Migault <mglt.i...@gmail.com> wrote: > > [… snip …] > > > ### Section 4.3 > > > > I don't understand what this paragraph is telling me about the provision > of the > > IP address by the HNA: > > > > ``` > > The HNA works as a primary authoritative DNS server, while the DM > > works like a secondary. As a result, the HNA must provide the IP > > address the DM is using to reach the HNA. The synchronization > > Channel will be set between that IP address and the IP address of the > > DM. By default, the IP address used by the HNA in the Control > > Channel is considered by the DM and the specification of the IP by > > the HNA is only OPTIONAL. The transport channel (including port > > number) is the same as the one used between the HNA and the DM for > > the Control Channel. > > ``` > > > > You start out by saying the "the HNA must provide the IP address the DM > is > > using to reach the HNA". (By the way when you say "is using" I think you > mean > > "should use". No?) I note the use of "must". > > > > > > But then you go on to say that "the specification of the IP by the HNA > is only > > OPTIONAL". (I assume that "the IP" here means "the IP address" that was > > discussed a few sentences back, probably you should add the word > "address" if > > so.) > > > > These two sentences, the "must" in the first one and the "OPTIONAL" in > the > > later, seem directly in opposition to one another. :-( > > > > To set the synchronization channel the secondary needs to know the IP > address of the secondary. (must). > > I guess you must mean the secondary needs the IP address of the *primary*? > So, in this case, that means the DM needs to know the IP address of the HNA. > > > Either the IP is derived as the IP addressed used in the control channel > or the IP address is explicitly provided. The latest option is optional. > > I hope the addition of explicit addresses your concerns: > > > > By default, the IP address used by the HNA in the Control Channel is > considered by the DM and the explicit specification of the IP by the HNA > is only OPTIONAL. > > I finally (think that I) get it, but I think the addition of “explicit” > doesn’t really clarify it very much. Here’s how the text stands in version > 21: > > ``` > The HNA works as a primary authoritative DNS server, while the DM > works like a secondary. As a result, the HNA must provide the IP > address the DM should use to reach the HNA. The synchronization > Channel will be set between that IP address and the IP address of the > DM. By default, the IP address used by the HNA in the Control > Channel is considered by the DM and the explicit specification of the > IP by the HNA is only OPTIONAL. The transport channel (including > port number) is the same as the one used between the HNA and the DM > for the Control Channel. > ``` > A possible version that would be clearer to me: > > The HNA works as a primary authoritative DNS server, while the DM > works as a secondary. As a result, the DM needs to know what IP > address it should use to reach the HNA. Since the HNA initiates the > control channel to the DM, the DM will normally be able to use the > source address from the control channel as the IP address it will use > to reach the HNA. The explicit specification of the IP address by the > HNA is only OPTIONAL. The transport channel (including port number) > is the same as the one used between the HNA and the DM for the > Control Channel. > > Does that correctly capture what’s meant? > This captures what we were trying to say. I am happy to take your text. > > Although, now that I read the text again, I’m also having a hard time > understanding what is meant by the final sentence, "The transport channel > (including port number) is the same as the one used between the HNA and the > DM for the Control Channel.” I’m assuming that by “the transport channel” > you mean the transport connection for the synchronization channel, but I > still don’t understand what you mean about the port. Are you saying that > the DM gleans the port it should use to contact the HNA, in the same manner > as it gleans the HNA’s IP address? > > What we meant by transport channel was DNS over TLS on port MM where MM is either the standard port or a port that parties have agreed on. The DM is serving on that port MM and the DM is setting the control channel over that port MM, so we do not expect any issue. The source port NNNN is not an issue and we generally do not have control over that port. The first figure below is what we meant but NNNN of the control channel and NNNN of the synchronization channel do not have to be the same. A more appropriate figure might be HNA DM --------- --------- port NNNN --------control channel--------> port MM port MM <-----synchronization channel----- port NNNN' I believe that the Section "Synchronization Channel" {#sec-synch} details how ports are handled with port XX and YYYY. What might be confusing here is that what we call a transport channel includes the necessary parameters that define the channel ( which do not include the source port) as opposed to an established channel which includes a source port. Let me know if the text below is clearer. OLD: The transport channel (including port number) is the same as the one used between the HN 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. 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 > > Thanks, > > —John -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
