Thank you very much for the feed backs. I will have a look at the comments today and should be able to implement them by early next week. Yours, Daniel
On Thu, Jun 9, 2022 at 7:44 PM Kiran M <kiran.i...@gmail.com> wrote: > Hi Daniel, > > I finally managed to finish the review of front-end naming document. My > apologies for the delay. Many thanks for addressing the first round of > comments, the readability has improved quite a bit. The remainder of the > comments are in the Github. Hope we will see a revision soon. > > Cheers, > Kiran > > > ------------------------------ > *From:* Daniel Migault [mailto:mglt.i...@gmail.com <mglt.i...@gmail.com>] > *Sent:* Thursday, June 2, 2022, 6:36 AM > *To:* Eric Vyncke (evyncke) > *Cc:* Eric Vyncke (evyncke); homenet@ietf.org; kiran.i...@gmail.com; > Michael Richardson; Stephen Farrell > *Subject:* [homenet] naming drafts > > We are working on it with Kiran, I actually started yesterday to consider > her latest feedback (2nd round) - not yet being pushed, but that should > happen very soon. > > Yours, > Daniel > > On Thu, Jun 2, 2022 at 7:30 AM Eric Vyncke (evyncke) <evyn...@cisco.com> > wrote: > >> As we are halfway between IETF-113 and IETF-114, it is time to make a >> check as I have seen no revised version for those 2 ‘naming’ drafts. >> >> >> >> You may also have noticed that Ted’s ‘stub networking’ work is going in a >> SNAC BoF at IETF-114 (please attend and contribute to the s...@ietf.org >> mailing list). >> >> >> >> Therefore, the plan is to close Homenet early July 2022 if nothing >> changes. >> >> >> >> Hoping to see you in “Philly” to celebrate the achievments of Homenet ! >> >> >> >> Regards >> >> >> >> -éric >> >> >> >> *From: *homenet <homenet-boun...@ietf.org> on behalf of "Eric Vyncke >> (evyncke)" <evyncke=40cisco....@dmarc.ietf.org> >> *Date: *Thursday, 14 April 2022 at 09:16 >> *To: *"homenet@ietf.org" <homenet@ietf.org> >> *Cc: *"kiran.i...@gmail.com" <kiran.i...@gmail.com>, Michael Richardson < >> mcr+i...@sandelman.ca>, Daniel Migault <mglt.i...@gmail.com>, Stephen >> Farrell <stephen.farr...@cs.tcd.ie> >> *Subject: *Re: [homenet] naming drafts >> >> >> >> Dear Homenet, >> >> >> >> After 9 months, it is time to resurrect this email thread and move >> forward with the 'naming drafts', which are still in WG Last Call since May >> 2021: >> >> - draft-ietf-homenet-front-end-naming-delegation >> >> - draft-ietf-homenet-naming-architecture-dhc-options >> >> >> >> AT IETF-113, there was a meeting with two authors, the chairs, and I (as >> the responsible AD for Homenet). The plan is to give the authors a chance >> to issue a revised I-D considering Chris Blox's review as well as trying to >> improve the readability and flow of the text (which suffers from multiple >> revisions that have rendered the I-D difficult to read). Once done, the >> chairs will close the WGLC and will request publication to continue the >> process. This should be done by IETF-114 (July 2022) if not earlier. >> >> >> >> About the DynDNS discussion of last year, I am in favor of going forward >> anyway with the homenet drafts and wait for the IETF Last Call + IESG >> evaluation to get a broader scope than the Homenet WG on this very specific >> topic. >> >> >> >> Final point, the chairs and I have decided that once those 2 drafts have >> been approved by the IESG [1], then the Homenet WG can be closed after 11 >> years [2]. >> >> >> >> Of course, feedback and comments on the above are welcome. >> >> >> >> Regards >> >> >> >> -éric >> >> >> >> [1] or if the publication is not requested before IETF-114, then I will >> declare those two I-D as "dead" and proceed anyway with the closing of >> Homenet. >> >> [2] a new home will need to be found for Ted Lemon's drafts on "stub >> networking" >> >> >> >> *From: *homenet <homenet-boun...@ietf.org> on behalf of Daniel Migault < >> mglt.i...@gmail.com> >> *Date: *Tuesday, 13 July 2021 at 23:28 >> *To: *Chris Box <chris.box.i...@gmail.com> >> *Cc: *"homenet@ietf.org" <homenet@ietf.org> >> *Subject: *Re: [homenet] naming drafts >> >> >> >> Hi, >> >> >> >> Thanks for the follow up Chris. I apologize for the delay. >> >> >> >> Yours, >> >> Daniel >> >> >> >> On Tue, Jun 22, 2021 at 12:31 PM Chris Box <chris.box.i...@gmail.com> >> wrote: >> >> Daniel, >> >> >> >> On Wed, 16 Jun 2021 at 01:27, Daniel Migault <mglt.i...@gmail.com> wrote: >> >> >> >> The HNA SHOULD drop any packets arriving on the WAN interface that are >> not issued from the DM. >> >> Depending how the communications between the HNA and the DM are secured, >> only packets associated to that protocol SHOULD be allowed. >> >> >> The separation looks good, but I'd like to tweak the second paragraph. By >> "only packets associated to that protocol" do you mean destination port >> filtering? >> >> >> >> To me IP and port filtering are implemented by the previous line. "only >> packets associated with that protocol" to me means that only TLS packets >> are allowed. The reason we are not mentioning TLS explicitly is that >> other protocols may be used. >> >> >> >> Ah, I see, so this is about the payload of the packets. But surely >> intelligent validation of the incoming packets is always going to happen? >> This is a key property of any security protocol. >> >> If the DM is listening on TCP 443, and the incoming packet is not a TLS >> Client Hello that it is happy with, it'll get ignored. >> >> If the DM is listening on UDP 500, and the incoming packet is not an >> IKE_SA_INIT that it is happy with, it'll get ignored. >> >> >> >> So I'm not disagreeing with you, I'm just questioning whether the >> sentence is needed. I don't really mind if it stays. >> >> This may not be necessary, but the reason I would prefer to keep it is to >> head up that additional checks - when possible - may be performed in >> addition to port filtering. So unless you have a strong preference, I would >> prefer to keep this additional check that could be performed by the >> terminating node or a firewall. >> >> >> >> >> >> I'm not concerned about the additional round trip. I was more concerned >> that the DM could be implemented as a frontend/backend architecture. The >> FQDN would resolve to the front end, and this is likely to be a small list >> of addresses, or even a single address. But the backend servers would have >> distinct, different addresses. Connections from the DM to the HNA might be >> initiated from the backend. If the HNA only looked up the FQDN, it would >> drop legitimate connections. This suggests we need a way to inform the HNA >> of the set of legitimate source addresses. >> >> >> >> >> >> What did you think of this last point? >> >> >> >> I see your point. The architecture document envisioned this case by >> specifying the dm_acl parameter in the informative section 14. >> >> We did not include it into the DHCP option as we were requested to >> implement the simplest use case that is envisioned. My understanding was >> that DHCP Options had some history where complex options had been designed >> but hardly used. >> >> That said, if that is something you believe is really needed, we may >> bring this discussion and add this parameter to the current DHCP Options. >> It still represents a minor change as already considered in the >> architecture document. >> >> >> >> Another alternative may also consider adding an extension so the acl may >> be negotiated through the control channel, which I see more scalable than >> designing large DHCP options. At that point, I would rather keep the >> architecture as it is a let such option for future work - though fairly >> easy to set. >> >> >> >> >> >> >> >> >> >> Chris >> >> >> >> >> -- >> >> Daniel Migault >> >> Ericsson >> > > > -- > Daniel Migault > Ericsson > > -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
