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

[Daniel Migault <[e-mail]>]

Hi Warren,

I am doing the follow-up and would like to know if there are any technical
concerns in the current version. Feel free to let us which they are so we
can address them shortly.

Yours,
Daniel

On Fri, Oct 28, 2022 at 4:49 PM Daniel Migault <[e-mail]> wrote:

>
> Hi Warren,
>
> This is a follow-up of the comments we could get from the notes of teh PDF
> you shared. As far as I can tell we are addressing all notes we have found.
> These notes did not result in any text being updated.
>
> In your DISCUSS you mention "The specification is impossible to
> implement..." The protocol has technical flaws...", "It is unlikely that
> multiple implementations...". However, so far we have not been able to
> identify 1) why do you believe the protocol is impossible to implement - 2)
> what these flaws are. Please point these aspects to us.
>
> As we have implemented multiple comments received so far the description
> might be clearer. We would appreciate you focusing on what you believe is a
> flaw or what makes the protocol impossible to be implemented as opposed to
> nits and grammar. The current version is available here on github.  We do
> update it as we receive comments, so do not hesitate to provide comments
> without performing a full review.
>
>
> https://github.com/ietf-homenet-wg/ietf-homenet-hna/blob/master/draft-ietf-homenet-front-end-naming-delegation.txt
>
> Yours,
> Daniel
>
>
>
>
> Upon receiving the response, the HNA MUST validate format and
> properties of the SOA, NS and A or AAAA RRsets. If an error occurs,
> the HNA MUST stop proceeding and MUST log an error. Otherwise, the
> HNA builds the Public Homenet Zone by setting the MNAME value of the
> SOA as indicated by the SOA provided by the AXFR response. The HNA
> SHOULD set the value of NAME, REFRESH, RETRY, EXPIRE and MINIMUM of
> the SOA to those provided by the AXFR response.
>
> Warren: Only those?
>
> mglt: It is unclear to me what that note refers to. If the comment refers
> to the SOA, the only fields we are missing are the RNAME and SERIAL. For
> the RNAME, we believe that both the HNA and the DOI may set it, the SERIAL
> is to be set by the primary. Is there any text you would like to see for
> the RNAME ?
>
> If the comment is associated with the number of RR we believe that these
> RRsets are sufficient to carry the necessary information from the DM to the
> HNA to configure the Public Homenet Zone in accordance with what is
> publishable by the DOI. If any additional information is needed more RRsets
> can be used.
>
> 4.5.2. Providing information for the DNSSEC chain of trust
> To provide the DS RRset to initialize the DNSSEC chain of trust the
> HNA MAY send a DNS update [RFC2136] message.
>
> Warren:
> If you have all of this, why are you not just using dns updates normally?
>
> Authentication?!
>
> mglt:
> I suppose the question is why do we set a primary/secondary as opposed to
> using DNS Update. The reason is that we are looking at synchronizing zones
> and not working on the level of the individual RRsets. Check Ted's response
> for reasons to do so. On the DOI perspective, zone synchronization is
> performed at the initiative of the DOI, not the end user, which is a better
> design against DDoS.
> The discussion can be endless and we are not claiming there are no
> possible ways to do it with DNS update. We believe zone synchronization is
> more appropriate.
>
> I do not understand what is the comment about authentication, in our case
> we could have used it over TLS for example, or TSIG. We also believe TSL is
> more appropriate for privacy reasons.
>
>
> Upon receiving the DNS update request, the DM reads the DS RRset in
> the Update section. The DM checks ZNAME corresponds to the parent
> zone. The DM SHOULD ignore non-empty the Pre-requisite and
> Additional Data section. The DM MAY update the TTL value before
> updating the DS RRset in the parent zone. Upon a successful update,
> the DM should return a NOERROR response as a commitment to update the
> parent zone with the provided DS. An error indicates the MD does not
> update the DS, and other method should be used by the HNA.
>
> Warren:
> Like what? How does the user know when a rollover happens?
> Appropriate?
>
> As the user is generating the zone. he knows when he is changing the key.
>
> I cannot tell what  Appropriate means in that context.
>
>
>
>
>
>
> On Thu, Oct 20, 2022 at 1:43 AM Daniel Migault <[e-mail]>
> wrote:
>
>> Hi Warren,
>>
>> Thanks for the review. I went through all comments and addressed them
>> here:
>>
>> https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/451133ab826df6bae6d10d3b6042d970a122e2ee
>>
>> Unless I am missing a previous message. None of your comments in this
>> email concerning the actual protocol. Though the number of comments is
>> impressive (and thank you for doing it), all concerns raised are mostly
>> concerns grammars and nits. 28 of of the 50 comments concerns sections that
>> can easily be removed if that is what you want.
>>
>> Given the DISCUSS and given that your comments are not addressing the
>> protocol sections - we expect you to clarify:
>> * what is impossible to implement
>> * what are the technical or clarity issues
>> * what are the protocol flaws
>> * why multiple implementations of the specification would interoperate,
>> usually due to vagueness or incomplete specification.
>>
>> We are happy to address what needs to be clarified.
>>
>> Yours,
>> Daniel
>>
>> On Mon, Oct 17, 2022 at 12:42 PM Warren Kumari via Datatracker <
>> [e-mail]> wrote:
>>
>>> Warren Kumari has entered the following ballot position for
>>> draft-ietf-homenet-front-end-naming-delegation-18: Discuss
>>>
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to
>>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>>> for more information about how to handle DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> Please see:
>>>
>>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>>>
>>> I am (reluctantly) balloting DISCUSS on the following criteria:
>>> * The specification is impossible to implement due to technical or
>>> clarity
>>> issues. * The protocol has technical flaws that will prevent it from
>>> working
>>> properly, or the description is unclear in such a way that the reader
>>> cannot
>>> understand it without ambiguity. * It is unlikely that multiple
>>> implementations
>>> of the specification would interoperate, usually due to vagueness or
>>> incomplete
>>> specification.
>>>
>>> I apologize for doing this, as I know that this will be a difficult set
>>> of
>>> comments to address. This isn't just a few "here are the DISCUSS
>>> points", but
>>> rather "there are a sufficient number of lack of clarity issues (and
>>> readability issues) that I don't think it can be understood and
>>> implemented
>>> without ambiguity."
>>>
>>> I have reviewed most of the document, but have only transcribed my
>>> comments up
>>> to page 13. Because there are both nits and substantive comments on the
>>> same
>>> bits of text (and to stop this gettign even longer) I have not separated
>>> them
>>> into separate sections like I normally would.
>>>
>>> I wanted to send this out now, so that the authors, WG and AD can start
>>> reviewing and we can discuss some way to resolve this...
>>>
>>>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>>
>>> Section 1:
>>> 1:
>>> O: The remaining of the document is as follows.
>>> P: The remainder of the document is as follows:
>>> C: Nit - Grammar
>>>
>>>  fixed
>>
>>> 2:
>>> O: Section 3 provides an architectural view of the HNA, DM and DOI as
>>> well as
>>> its different communication channels P: Section 3 provides an
>>> architectural
>>> view of the HNA, DM and DOI as well as their different communication
>>> channels
>>> C: Nit - Plural.
>>>
>>>  fixed
>>
>>> 3:
>>> O: Section 7 and Section 9 respectively details HNA security policies as
>>> well
>>> as DNSSEC P: Section 7 and Section 9 respectively detail HNA security
>>> policies
>>> as well as DNSSEC C: Nit - Grammar / plural
>>>
>>>  fixed
>>
>>> Section 1.1:
>>> 4:
>>> O: Of these the link-local are never useful for the Public
>>> Zone,
>>> C: I don't really agree with the "never" - the document does discuss
>>> failing back to the Public zone if needed, and so this may sometimes be
>>> useful. I agree that it is much less common / useful, and this this is
>>> probably a nit...
>>>
>>> changed to 'almost never'
>>
>>> 5:
>>> O: "However, since communications
>>>  are established with names which remains a global identifier, the
>>>  communication can be protected by TLS the same way it is protected on
>>>  the global Internet."
>>>
>> C: "However" implies that the sentence follows on from a previous point
>>> and
>>> provides a refutation / comparison, and this sentence doesn't - it is
>>> more of a
>>> fragment / new thought.
>>
>> removed however
>>
>>> C: s/remains/remain/ (grammar) C: More text is needed
>>> here - I'm *assuming* that you are meaning that because the name is
>>> globally
>>> resolvable to an address, that this can be used to obtain a certificate
>>> for
>>> that name? If so, that's really not clear.
>>>
>>>  The new text is as follows:
>> Since communications are established with names which remain a global
>> identifier, the co
>> mmunication can be protected by TLS the same way it is protected on the
>> global Internet
>> - using certificates.
>>
>> Section 1.2:
>>> 6:
>>> O: "An alternative existing solution is to have a single zone, where a
>>>  host uses a RESTful HTTP service to register a single name into a
>>>  common public zone. "
>>> P: "An alternative existing solution for residential customers is to..."
>>>
>> changed
>>
>>> C: There are a number of alternative solutions, for example many
>>> companies use
>>> DHCP to populate a zone (usually using RFC 2136), Windows Active
>>> Directory does
>>> something similar, many cloud / hosting providers will add and remove
>>> entries,
>>> etc.
>>>
>>
>>
>>>
>>> 7:
>>> O: "This is often called "Dynamic DNS" [DDNS], and
>>>  there are a number of commercial providers. While the IETF has
>>>  defined Dynamic Update [RFC3007], in many - as far as the co-authors
>>>  know in all cases - case commercial "Dynamic Update" solutions are
>>>  implemented via a HTTPS RESTful API."
>>>  C1: I think that you need to be much clearer that the "Dynamic DNS" you
>>> are
>>>  talking about in the first sentence is different to Dynamic Updates.
>>
>>  While the IETF has defined a DNS based mechanism Dynamic Update
>> {{?RFC2136}}, in many -- as far as the co-authors know in all cases -- case
>> commercial "Dynamic Update" solutions are implemented via a HTTPS RESTful
>> API.
>>
>>> C2: I
>>>  think that that is the wrong reference - RFC2136 is the Dynamic Updates
>>> RFC,
>>>  RFC3007 wraps it in TSIG.
>>
>> changed reference
>>
>>> C3: You have a repeated "case" (actually, "case"
>>>  should move before the hyphen, and the second "cases" should be
>>> removed). C4:
>>>  30 seconds with a search engine shows that Dyn DNS (of of the largest
>>>  providers) supports RFC2136 dynamic DNS updates -
>>> https://help.dyn.com/tsig/,
>>>  as does Dynu - https://www.dynu.com/DynamicDNS/IPUpdateClient/NSUpdate
>>> . I'm
>>>  assuming that many others to too...
>>>
>>> The link you provide shows this is a paid option, so probably not the
>> most deployed one. This does not change the fundamental issue which is the
>> configuration at the host level and the lack of scalability of such a
>> solution.
>> Your link below clearly states that iussue as well that is:
>>
>> https://www.noip.com/support/knowledgebase/how-to-configure-ddns-in-router/
>> ""Configuring DDNS in your router means that you don’t have to use our
>> Dynamic Update Client ""
>>
>>
>>> 8:
>>>  O: "For a very few numbers of hosts, the use of such a system provides
>>> an
>>>  alternative to the architecture described in this document."
>>>  C: Why? There are a huge number of users/hosts using Dynamic DNS
>>> services, and
>>>  many of the Dynamic DNS providers are doing quite well, so I don't
>>> understand
>>>  how their users count as "a very few".
>>>
>> The problem is not on the provider side but on the homenet side. Managing
>> numerous hosts causes a management issue.
>>
>>  9:
>>>  O: "Dynamic
>>>  DNS - even adapted to IPv6 and ignoring those associated to an IPv4
>>>  development - does suffer from some severe limitations:"
>>>  C1: Why do you say "even adapted to IPv6"? IPv6 Dynamic DNS already
>>> exists and
>>>  is deployed -- e.g:
>>>  https://www.noip.com/blog/2019/11/03/ip-now-offers-ipv6-dynamic-dns/
>>> C2: " and
>>>  ignoring those associated to an IPv4 development" - I'm unable to parse
>>> this.
>>>
>>> This is what we are saying. The section started mentioning the IPv4
>> context in which Dynamic Update has been created. What the sentence says
>> here is that even IPv4 constraints are not being considered - that is in a
>> full IPv6 environment, the use of dynamic update comes with the following
>> drawbacks.
>>
>>
>>  10:
>>> O: "* the CPE/HNA router is unaware of the process, and cannot respond
>>>  to queries for these names and communications to these names
>>>  require an Internet connectivity is order to perform the DNS
>>>  resolution."
>>> C: In many many cases the CPE itself is the Dynamic DNS clinet, e.g:
>>>
>>> https://www.noip.com/support/knowledgebase/how-to-configure-ddns-in-router/
>>> lists 9 vendors of CPE whose devices do DDNS, and I'm aware of many many
>>> more.
>>>
>>> *We were mostly describing the case where DDNS was set on every device.
>> This is correct that having the service on the CPE itself is getting closer
>> to what we are proposing.  We still believe that for large zone zone
>> synchronization is more appropriate.*
>>
>> The draft was initiated in a context were  the eISP would be proposing to
>> be a DOI. Do we think that reasonably any ISP could provide such service
>> via a CPE. The following lines seems to indicate only the big one can.
>>
>> *Please Note:** If your router does not list No-IP, you can try updating
>> your firmware to see if we were added in the latest update. Otherwise, you
>> will need to run our Dynamic Update Client
>> <http://www.noip.com/download> on a computer at the network location. You
>> can also check if another device, such as an NVR/DVR, on your network
>> supports No-IP for DDNS*
>>
>> Now this has been said, I am wondering what is the point of your
>> comments. There are alternatives: YES. We are trying not to hide this. We
>> can remove the entire section Dynamic DNS Alternative solutions if that
>> the sense of your comments.
>>
>> 11:
>>> O: "* the CPE/HNA router cannot control the process. Any host can do
>>>  this regardless of whether or not the home network administrator
>>>  wants the name published or not."
>>> C: This proposal doesn't "fix" that -- any host will stil be able to run
>>> a DDNS
>>> client and publish a name. I don't really view this as a bug, but if you
>>> are
>>> pointing out "issues"/"limitations" with something that you are aiming to
>>> replace, you should clarify that your proposal doesn't address some of
>>> them.
>>>
>>>  sure. We were more speaking in terms of manageability.
>>
>> 12:
>>> O: "* "all the good names are taken" - current services provide a small
>>>  set of zones shared by all hosts across all home networks. More
>>>  especially, there is no notion of a domain specific home network."
>>>  C: That's completely wrong - a number of Dynamic DNS providers do this.
>>> 10
>>>  seconds with a search engine show:
>>>
>>> https://www.noip.com/support/knowledgebase/can-i-use-my-own-domain-name-with-no-ip/
>>>
>>> https://www.namecheap.com/support/knowledgebase/article.aspx/595/11/how-do-i-enable-dynamic-dns-for-a-domain/
>>>  https://blog.jswart.xyz/posts/cloudflare-dynamic-dns/
>>>  https://support.google.com/domains/answer/6147083?hl=en
>>>
>>>  again if one pays everything is possible of course.
>>
>>  13:
>>>  O: "* Dynamic Updates solution are not interoperable and each provider
>>>  has its own way to implement it."
>>>  C: This is also wrong. A number of providers support the 'dyndns2'
>>> protocol,
>>>  including Dyn DNS, Amazon Route 53, Google Domains, No-IP, etc.
>>>
>>>  A number of actors are using a given protocol. This does not mean
>> whoever claims to support dynamic DNS is interoperable.
>>
>>  Section 1.3.1:
>>>  14:
>>>  O: "A specific vendor with specific relations with a registrar or a
>>>  registry may sell a CPE that is provisioned with provisioned domain
>>>  name."
>>> C: "is provisioned with provisioned"
>>>
>>> changed
>>
>>> 15:
>>> O: "Such domain name does not need to be necessary human readable."
>>> C1: "Such *a* domain name"
>>>
>> changed
>>
>>> C2: Remove "necessary"
>>>
>> changed
>>
>>> C3: Is it really useful to have a name like
>>> "aheriuthga23.somevendor.exmaple.com"?
>>>
>>> for device management it could be sufficient.
>>
>>> 16:
>>> O: "One possible way is that the vendor also provisions..."
>>> C: One possible way to what? The previous sentence talks about a vendor
>>> selling
>>> CPE, so one possible way for them to sell something? You probably need
>>> some
>>> text around "one way for a vendor to bootstrap" or "provision this", or
>>> something. Needs work.
>>>
>>>  one possible scenario
>>
>>> 17:
>>> O: "One possible way is that the vendor also provisions the HNA with a
>>>  private and public keys as well as a certificate."
>>> C1: Either "with a private and public keys" or "with a
>>>  private and public key"
>>>
>> changed
>>
>>> C2: You say with keys and a certificate, and then talk about what the
>>> purpose
>>> of the keys are, but not what the cert is used for.
>>>
>>> clarified
>>
>>> 18:
>>> O: "Instead these
>>>  keys are solely used by the HNA to proceed to the authentication."
>>> C: "solely used" - does this mean that they cannot / must not be used for
>>> anything else?
>>
>> yes
>>
>>> C: "proceed to the authentication" does not parse. Perhaps "used
>>> for authentication" or "to the authentication phase" (not that that is
>>> really
>>> described either)
>>>
>>> for the authentication
>>
>>> 19:
>>> O: "The reason to combine the domain name and the
>>>  key is that DOI are likely handle names better than keys and that
>>>  domain names might be used as a login which enables the key to be
>>>  regenerated."
>>> C: "are likely handle" doesn't parse.
>>>
>> likely handles names
>>
>>> C: "domain names might be used as a login" - the domain name and what?
>>> Presumably I cannot just login with the credential "foo.cpe.example"
>>> without
>>> some other piece of information or anyone could regenerate the keys. And
>>> in
>>> that case, why are keys pre-provisioned on the device?
>>>
>>> I think some ISPs does so.
>>
>>
>>> 20:
>>> O: "When the home network owner plugs the CPE at home, ...""
>>> C: "plugs in the CPE"
>>>
>>> changed
>>
>>
>>> Section 1.3.2. Agnostic CPE:
>>> 21:
>>> O: "An CPE that is not preconfigured may also take advantage to the
>>>  protocol defined in this document but some configuration steps will
>>>  be needed."
>>> C: s/An CPE/A CPE/
>>>
>>  changed
>>
>>> C: s/may also take advantage to the protocol/may also take advantage of
>>> the
>>>  protocol/ (actually I think "may also use the protocol", but
>>> whatever...)
>>>
>>> changed
>>
>>> 22:
>>> O: " 1. The owner of the home network buys a domain name to a registrar,
>>>  and as such creates an account on that registrar"
>>> C: s/to a registrar/from a registrar/
>>>
>>> changed
>>
>>> 23:
>>> O: "A good way to provide the
>>>  parameters would be the home network be able to copy/paste a JSON
>>>  object"
>>> C: home networks cannot copy and paste. Perhaps "One potential mechanism
>>> would
>>> be to provide the user with a JSON object which they can copy and paste
>>> into
>>> the CPE" (or similar).
>>>
>>> changed with your proposal
>>
>>> 24:
>>> O: "What matters at that point is the DOI
>>>  being able to generate authentication credentials for the HNA to
>>>  authenticate itself to the DOI.
>>> C: s/being able/is able/
>>> C: It also isn't that it needs to be able to do this, but rather that it
>>> can
>>> provide authentication credentials to the HNA.
>>>
>>> text change from previous comments
>>
>>> 25:
>>> O: "If the DOI is not the registrar, then the proof of ownership needs
>>>  to be established using protocols like ACME [RFC8555] for example
>>>  that will end in the generation of a certificate."
>>> C: Why does it need to "end in the generation of a certificate"? All you
>>> need
>>> is proof of ownership, yes? And ACME is generally used to prove
>>> ownership of a
>>> hostname / SAN - it is very unclear here what exactly you are proving
>>> ownership
>>> of / to -- the hostname to the IP/device? Presumably not because the
>>> purpose of
>>> this is to create that delegation...
>>>
>>
>> the certificate is used for the authentication
>>
>>>
>>> 26:
>>> O: "ACME is used
>>>  here to the purpose of automating the generation of the
>>>  certificate, the CA may be a specific CA or the DOI. "
>>> C: Why "a specific CA or the DOI"? If I get a (valid) cert from any old
>>> CA, is
>>> that not valid? And it I get a cert from the DOI, it is acting as a CA,
>>> isn't
>>> it? What is this actually trying to say?
>>>
>>
>> because the DOI may only trust certificates it has issued.
>>
>>
>>>
>>> 27:
>>> O: "With that
>>>  being done, the DOI has a roof of ownership and can proceed as
>>>  above."
>>> C: "proof of ownership"
>>>
>>> already changed.
>>
>>
>>> Section 3. Architecture Description
>>> 28:
>>> O: "Note that
>>>  Appendix B defines necessary parameter to configure the HNA."
>>> C: Does this mean that Appendix B is normative?
>>>
>> no it is provided as an example. we changed to appendix shows.
>>
>>
>>> C: s/parameter/parameters/
>>>
>>> already changed
>>
>>
>>> 29:
>>> O: "The DOI will
>>>  serve every DNSSEC request of the Public Homenet Zone coming from
>>>  outside the home network."
>>> C: The DOI gets DNS requests, not DNSSEC requests (there isn't really
>>> such a
>>> thing as a DNSSEC request) C: "every"? C: What about if a device inside
>>> the
>>> home queries the DOI? It should still respond, yes?
>>>
>>> yes.
>>
>>
>>> 30:
>>> O: "the resolution is expected to be handled by the Homenet
>>>  Resolver as detaille din further details below."
>>> C: "detailed in"
>>>
>>> already changed
>>
>>> 31:
>>> O: "Registered Homenet Domain Name"
>>> C: You don't have "Registered Homenet Domain Name" in the terminology
>>> section,
>>> either add it or (better yet) s/Name/name/
>>>
>>> corrected
>>
>>> 32:
>>> O: "The HNA SHOULD build the Public Homenet Zone in a single view
>>>  populated ..."
>>> C: It is unclear what "in a single view" means here - views are a way of
>>> mapping clients to different sets of answers, and they are not in a zone.
>>>
>>>  we mean everyone gets the same response, so a single view of the zone
>> exists.
>>
>> 33:
>>> O: "Once the Public Homenet Zone has been built, the HNA communicates and
>>>  synchronizes it with the DOI using a primary/secondary setting as
>>>  described in Figure 1. "
>>> C: It is unclear what "using a primary/secondary setting" means, and it
>>> isn't
>>> "described in Figure 1."
>>>
>>
>> The text is the following one:
>> Once the Public Homenet Zone has been built, the HNA communicates and
>> synchronizes it wi
>> th the DOI using a primary/secondary setting as described in
>> {{fig-naming-arch}}.
>> The HNA acts as a hidden primary {{?RFC8499}} while the DM behaves as a
>> secondary respon
>> sible to distribute the Public Homenet Zone to the multiple Public
>> Authoritative Servers
>> that DOI is responsible
>>
>> The figure 1 describes the relation between the HNA and the DOI which we
>> mention as primary/secondary. The following sentence explains what a
>> primary secondary is.
>>
>>>
>>> 34:
>>> O: "The HNA acts as a hidden primary [RFC8499]"
>>> C: 8499 doesn't define hidden primary; it does define Hidden master and
>>> Primary
>>> server. It also says that a master and a primary are the same, but the
>>> reference should be clearer.
>>>
>>>  The HNA acts as a hidden master (now designated as hidden primary) {{?
>> RFC8499}}
>>
>>> 35:
>>> O: "the DM behaves as a secondary responsible to distribute the
>>>  Public Homenet Zone to the multiple Public Authoritative Servers that
>>>  DOI is responsible for."
>>>  C: s/responsible to distribute/responsible for distributing/
>>>
>> changed
>>
>>>  C: "the multiple Public Authoritative Servers" - which servers? A DOI
>>> may have
>>>  many many sets of authoritative servers, only some of which may be
>>>  authoritative for this zone.
>>>
>> do we say anything that prevents this ?
>>
>>>
>>>  36:
>>>  O: "one or more Distribution Channels (Section 6 that distribute the
>>>  Public Homenet Zone from the DM to the Public Authoritative Server
>>>  serving the Public Homenet Zone on the Internet."
>>> C: (Section 6/ (Section 6)/
>>> C: s/Public Authoritative Server/Public Authoritative Servers/
>>>
>>> changed
>>
>>> 37:
>>> O: "Resolution is performed by the DNSSEC resolvers."
>>> C: Which "the DNSSEC resolvers"? ("the" implies a specific set) Also,
>>> why are
>>> these "DNSSEC resolvers"? Does this mean that non-DNSSEC validating DNS
>>> servers
>>> cannot resolve these names (presumably not, but...)
>>>
>>>  Resolution is performed by DNS(SEC) resolvers.
>>
>>> 38:
>>> O: "When the resolution
>>>  is performed outside the home network, the DNSSEC Resolver resolves
>>>  the DS record on the Global DNS and the name associated to the Public
>>>  Homenet Zone (myhome.example) on the Public Authoritative Servers."
>>> C: What is this actually trying to say? The DS record is resolved on the
>>> "Global DNS" but the name is resolved on the "Public Authoritative
>>> Servers" -
>>> is this supposed to mean that the Public Authoritative Servers are not
>>> part of
>>> the Global DNS? And the DS record is part of the "name associated to the
>>> Public
>>> Homenet Zone", but published at the parent. Is this supposed to just be
>>> "is
>>> resolved like any other name"?
>>>
>>
>> the latest.
>>
>>>
>>> 39:
>>> O: "On the other hand, to
>>>  provide resilience to the Public Homenet Zone in case of WAN
>>>  connectivity disruption, the Homenet DNSSEC Resolver SHOULD be able
>>>  to perform the resolution on the Homenet Authoritative Servers."
>>> C: "the Homenet DNSSEC Resolver" - this implies that this is only one.
>>> It also
>>> seems odd to say that it "SHOLD be able to", and then immediately say
>>> that this
>>> can't actually be done because this isn't any (current) way to configure
>>> the
>>> DNSSEC information (or, if it is defined in 7788 I missed it)
>>>
>>> The current text says 1) what we expect, 2) how it should be done. and
>> leave it to further work.
>>
>> These servers are not expected to be mentioned in the Public Homenet
>> Zone, nor to be acc
>> essible from the Internet.
>>
>> As such their information as well as the corresponding signed DS record
>> MAY be provided
>> by the HNA to the Homenet DNSSEC Resolvers, e.g., using HNCP {{?RFC7788}}
>> or a by config
>> uring a trust anchor {{?I-D.ietf-dnsop-dnssec-validator-requirements}}.
>>
>> Such configuration is outside the scope of this document.
>>
>>>
>>
>>
>>
>>> 40:
>>> O: "How the Homenet Authoritative Servers are provisioned is also out of
>>>  scope of this specification. It could be implemented using primary
>>>  and secondary servers, or via rsync."
>>> C: It is unclear what this is trying to say - "are provisioned" with
>>> what? It
>>> this trying to say "how the zone information is syncronized between the
>>> servers"? Or how the domains are provisioned onto the servers?
>>>
>>> It says the document does not describe how the homenet authoritative
>> servers are provisioned with the zone they serve.
>>
>>
>>> 41:
>>> O: "The main issue is that the Dynamic DNS update would also update the
>>>  parent zone's (NS, DS and associated A or AAAA records) while the
>>>  goal is to update the DM configuration files. The visible NS records
>>> SHOULD
>>>  remain pointing at the cloud provider's server IP address - which in
>>> many
>>>  cases will be an anycast addresses. Revealing the address of the HNA in
>>> the
>>>  DNS is not desirable. "
>>> C: Huh? *What* main issue? Is this text just misplaced and supposed to be
>>> somewhere else? It seems completely unrelated to this section. Also, what
>>> "cloud provider"? This is the only mention of a cloud provider. And what
>>> Dynamic DNS update are you talking about here?
>>>
>>> This has been rephrased in Matt's comments. I think we clarified this.
>>
>>
>>> 42:
>>> O: "While
>>>  information is carried from the DOI to the HNA and from the HNA to
>>>  the DOI, the HNA is always initiating the exchange in both
>>>  directions.
>>>  As such the HNA has a prior knowledge of the DM identity (X509
>>>  certificate), the IP address and port number to use and protocol to
>>>  set secure session."
>>> C: "As such" doesn't make sense here (or I'm unable to parse it) -- the
>>> first
>>> bit says that the HNA initiates the exchanges, but the second bit says
>>> that "As
>>> such it has knowledge" - perhaps you mean "requires"? I have no idea
>>> what this
>>> is supposed to say.
>>>
>>>
>> Since the HNA starts the exchange it knows which DM he is establishing a
>> session with.
>>
>> Section 4.1. Information to Build the Public Homenet Zone:
>>> 43:
>>> O: "The HNA builds the Public Homenet Zone based on information retrieved
>>>  from the DM."
>>> C: Retrieved how? (Link to 4.5.1, otherwise the reader will be very
>>> confused.)
>>>
>>> added link
>>
>>> 44:
>>> O: "The information includes at least names and IP addresses of the
>>>  Public Authoritative Name Servers. In term of RRset information this
>>>  includes:
>>>  * the MNAME of the SOA,"
>>>  C: This says "this includes at least names and IP addresses" but then
>>> also
>>>  suddenly throws in the MNAME. Also, what is the MNAME actually used
>>> for? The
>>>  document says that you have to put it in the zone, but why must it be
>>> what the
>>>  DM says, but the other parameter in the SOA can be changed?
>>>
>>>
>> The list points where these servers appears. The MNAME belongs to the  Public
>> Authoritative Name Servers
>>
>>  45:
>>> O: "The DM MAY also provide operational parameters such as other fields
>>>  of SOA (SERIAL, RNAME, REFRESH, RETRY, EXPIRE and MINIMUM)."
>>> C: S 4.5.1 says that this is received over AXFR, so the HNA always gets
>>> the SOA
>>> -- so how is this a "MAY also provide"? Or is it supposed to be that it
>>> always
>>> provides these, but the HNA can ignore some or all of them?
>>>
>> yes, it is up to the DM.
>>
>>>
>>> Section "4.2. Information to build the DNSSEC chain of trust"
>>> 46:
>>> O: "The HNA SHOULD provide the hash of the KSK (DS RRset), so the DOI
>>>  provides this value to the parent zone."
>>> C: Is it that the HNA should provide the DS, or a hash of the KSK? (The
>>> DS is
>>> more than just the hash). C: "so that the DOI can provide"
>>>
>>> The section says:
>> By accepting the DS RR, the DM commits in taking care of advertising the
>> DS to the parent zone.
>> Upon refusal, the DM clearly indicates it does not have the capacity to
>> proceed to the update.
>>
>> We clarified saying:
>> The HNA SHOULD provide the hash of the KSK via the DS RRset,
>>
>> 47:
>>> O: "When such relation exists, the
>>>  HNA should be able to request the DOI to update the DS RRset in the
>>>  parent zone."
>>> C: "should be able to request" - this implies that there is a specific
>>> way for
>>> the HNA to request this, if this relationship exists -- how would the
>>> HNA know
>>> this? Shouldn't it always send the DS?
>>>
>>
>> We do not say MUST send the DS but we say SHOULD send the DS.
>>
>>>
>>> 48:
>>> O: "The HNA SHOULD provide... " and "Though the HNA may also later
>>> directly
>>> update the values of the DS
>>>  via the Control Channel, it is RECOMMENDED to use other mechanisms".
>>>  "SHOULD provide" how? Over the Control Channel? And how does that
>>> relate to
>>>  the RECOMMEND to use other mechanisms?
>>>
>>> We only provide one way to provide it. When other mechanism are used it
>> needs to be provided once.
>>
>>
>>> Section 4.3. Information to set the Synchronization Channel
>>> 49:
>>> O: "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."
>>> C: This entire paragraph is really confusing. I'm guessing that this is
>>> trying
>>> to sat that the HNA provides the IP for the DM to contact it? C: It also
>>> says
>>> that the DM "considers" the IP used by the HNA, and so the specification
>>> of the
>>> IP is OPTIONAL. I'm guessing that this is trying to say that the DM
>>> will, by
>>> default, use the IP that the HNA used to contact it? In the non-default
>>> case,
>>> how exactly does the HNA specify the address? (how is this
>>> communicated?). C:
>>> Also, "The transport channel (including port
>>>  number) is the same as the one used between the HNA and the DM for
>>>  the Control Channel." -- so the transport channel and Control Channel
>>> use the
>>>  same IPs and ports? How are messages disambiguated? Isn't this jsut one
>>>  channel then?
>>>
>>> It says the two channels are using the same IP.  Section shows why there
>> is not possible ambiguation.
>>
>>
>>>
>>> _______________________________________________
>>> homenet mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/homenet
>>>
>>
>>
>> --
>> Daniel Migault
>> Ericsson
>>
>
>
> --
> Daniel Migault
> Ericsson
>


-- 
Daniel Migault
Ericsson