Re: [Emu] Adoption call for eap.arpa
Hi Michael, You know homenet details much better. The only point I was trying to make is that it is possible to have sub-domains under a special use domain. "home.arpa" is one example. "e164.arpa" from RFC 6116 (https://www.rfc-editor.org/rfc/rfc6116.html) seems to be another example. Whether sub domains are resolvable and how they are registered/managed can be (and will be) different. As you wrote in another email, if we have a good justification, IAB will likely bless with appropriate guidance. Hope you + others in the working group had an enjoyable and productive week in Brisbane. Safe travels! --Mohit On 3/22/24 11:24, Michael Richardson wrote: Mohit Sethi wrote: > As far as I can tell, we will not be the first ones using such a > scheme. ".home.arpa." defined in RFC 8375 > (https://www.rfc-editor.org/rfc/rfc8375.html) allows sub domains. It says: > "For an administrative domain that uses subdomains of 'home.arpa.', such as a > homenet, the recursive resolvers provided by that domain will be able to > answer queries for subdomains of 'home.arpa.'" It's not at all the same thing :-) home.arpa is a real anchor which home routers can serve names into using DNS. (Replacing ".local" [which implies mDNS], and .lan, which some home routers use) > We are taking a more conservative approach where subdomains need expert > review and registration before they are allocated and can be used in > deployments. I would not characterize it this way at all. I suspect we can have what we want, we just need to explain it to the IAB well enough. Unfortunately too late in the week for a hallway conversation. I found some IESG to talk to at the last break, but no IAB. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
Mohit Sethi wrote: > As far as I can tell, we will not be the first ones using such a > scheme. ".home.arpa." defined in RFC 8375 > (https://www.rfc-editor.org/rfc/rfc8375.html) allows sub domains. It says: > "For an administrative domain that uses subdomains of 'home.arpa.', such as a > homenet, the recursive resolvers provided by that domain will be able to > answer queries for subdomains of 'home.arpa.'" It's not at all the same thing :-) home.arpa is a real anchor which home routers can serve names into using DNS. (Replacing ".local" [which implies mDNS], and .lan, which some home routers use) > We are taking a more conservative approach where subdomains need expert > review and registration before they are allocated and can be used in > deployments. I would not characterize it this way at all. I suspect we can have what we want, we just need to explain it to the IAB well enough. Unfortunately too late in the week for a hallway conversation. I found some IESG to talk to at the last break, but no IAB. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
As far as I can tell, we will not be the first ones using such a scheme. ".home.arpa." defined in RFC 8375 (https://www.rfc-editor.org/rfc/rfc8375.html) allows sub domains. It says: "For an administrative domain that uses subdomains of 'home.arpa.', such as a homenet, the recursive resolvers provided by that domain will be able to answer queries for subdomains of 'home.arpa.'" We are taking a more conservative approach where subdomains need expert review and registration before they are allocated and can be used in deployments. --Mohit On 3/22/24 09:30, Alan DeKok wrote: On Mar 22, 2024, at 1:58 PM, Michael Richardson wrote: I think its an IAB question. IANA with implement whatever we ask for. It would be EMU's Expert Reviewers that would decide, I guess. It's late in the week to pigeon hole someone, but ... maybe we can find someone. OK. Is a sub-domain the only technical solution? I'm sure we will need to answer that. I don't think it's the only technical solution. But it's a very good one. If we don't use subdomains, then we have to use user portions in a well-known format. e.g. provisioning.t...@eap.arpa instead of provision...@teap.eap.arpa I think the second looks clearer to me. Alan DeKok, ___ Emu mailing list Emu@ietf.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu=05%7C02%7Cmohit.sethi%40aalto.fi%7Cfb9fb88083ca4a5ef85208dc4a24a4d1%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C638466768444326336%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=i%2BXBJ0hiTOat7lVelLhLTfl07E%2BBHqUdZt3CEcidf50%3D=0 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
On Mar 22, 2024, at 1:58 PM, Michael Richardson wrote: > I think its an IAB question. IANA with implement whatever we ask for. > It would be EMU's Expert Reviewers that would decide, I guess. > It's late in the week to pigeon hole someone, but ... maybe we can find > someone. OK. > Is a sub-domain the only technical solution? > I'm sure we will need to answer that. I don't think it's the only technical solution. But it's a very good one. If we don't use subdomains, then we have to use user portions in a well-known format. e.g. provisioning.t...@eap.arpa instead of provision...@teap.eap.arpa I think the second looks clearer to me. Alan DeKok, ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
Alan DeKok wrote: > 1. Instead of servers deciding the EAP method based on the username >part of the NAI, the EAP method could be decided based on the sub domain >under eap.arpa in the realm portion of the NAI. Thus a peer wanting to >be provisioned would use provision...@noob.eap.arpa or >provision...@tls.eap.arpa depending on whether it supports: EAP-NOOB or >EAP-TLS for provisioning. Leaving the username semantics to individual >provisioning drafts (example: draft-ietf-emu-bootstrapped-tls) might be >beneficial in the long run as explained below. > That's a good idea. My once concern is if IANA / IAB would allow for a > separate sub-registry for the subdomains, and allow EMU to control that > registry. I think its an IAB question. IANA with implement whatever we ask for. It would be EMU's Expert Reviewers that would decide, I guess. It's late in the week to pigeon hole someone, but ... maybe we can find someone. Is a sub-domain the only technical solution? I'm sure we will need to answer that. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
On Mar 21, 2024, at 11:30 PM, Mohit Sethi wrote: > > I would like to support the adoption of the document with two caveats based > on my deployment experience thus far. Obviously, Alan and Heikki have much > more expertise and experience than me but just providing a data point: > > 1. Instead of servers deciding the EAP method based on the username part of > the NAI, the EAP method could be decided based on the sub domain under > eap.arpa in the realm portion of the NAI. Thus a peer wanting to be > provisioned would use provision...@noob.eap.arpa or provision...@tls.eap.arpa > depending on whether it supports: EAP-NOOB or EAP-TLS for provisioning. > Leaving the username semantics to individual provisioning drafts (example: > draft-ietf-emu-bootstrapped-tls) might be beneficial in the long run as > explained below. That's a good idea. My once concern is if IANA / IAB would allow for a separate sub-registry for the subdomains, and allow EMU to control that registry. > The username part will likely be needed to distinguish, for example, initial > certificate enrollment during provisioning (NAI provision...@teap.eap.arpa) > from later certificate renewal during re-provisioning (NAI > re-provision...@teap.eap.arpa). I assume the certificates issued will have a > limited lifetime and need to be renewed. There are other good reasons where > the username part is used to indicate the provisioning state. For example, if > provisioning a certificate and a password, the peer may use different > username in the NAI: pha...@teap.eap.arpa for provisioning the certificate > and pha...@teap.eap.arpa for provisioning the password. There have been > proposals in the past about provisioning different types of credentials: > https://datatracker.ietf.org/doc/draft-pala-tian-eap-creds-spp/ I think this is a good idea. > There are other legitimate reasons for avoiding such limitation. For example, > a network owner wants to outsource the provisioning of a new device to the > device vendor. Such scenarios were briefly discussed a while back: > https://datatracker.ietf.org/doc/html/draft-st-t2trg-nw-access-01 and there > was support from Hannes Tschofenig and others. It was later covered in the > media as well so I presume there was some interest: > https://www.theregister.com/2018/07/25/internet_draft_iot_security/. > > Finally, there are situations where the device vendor installs the device at > the customer site and uses the the customer network for Internet-connectivity > but is still responsible for the device provisioning, lifecycle management, > services, maintenance, etc. For example, a bunch of elevators installed at > customer premises using customer network for sending back maintenance > requests. Here again, the customer intentionally wants the device to be > provisioned and managed by a remote vendor server. It would be useful to allow some local self-allocation for this case. So that a site can see requests in the eap.arpa domain, and associate them with a remote vendor that it has a relationship with. Perhaps subdomains? e.g. "provision...@vendor.teap.eap.arpa". I'll have to think about that some more. > I don't think all these scenarios need to be described in this draft. Just > removing the limitation is sufficient. My pull request already includes such > a change, should this amenable to Alan and others in the working group: > https://github.com/FreeRADIUS/eap-arpa/pull/1 I would lean towards explaining the common use-cases in this document. Otherwise I'm worried that it either won't meet peoples needs, or people will get it wrong. > If the working group finds these requests amenable and my pull requests are > useful, I'd also volunteer to co-author and help drive > this document to the RFC editor queue. I'll take a look. > Also, at some later point, if volunteers are needed for the IANA expert > registry or something else, I'd be available. > > --Mohit > > PS: There was also an issue that the current draft recommends Expert Review > for assignment of new values but then also expects RFCs: "The intention is > that any non-prefix allocation will be accompanied by a published RFC.". I > think it will be beneficial to have "Specification Required". Note "Expert > Review" and "RFC Required" are separate things in RFC 8126. Agreed. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
I would like to support the adoption of the document with two caveats based on my deployment experience thus far. Obviously, Alan and Heikki have much more expertise and experience than me but just providing a data point: 1. Instead of servers deciding the EAP method based on the username part of the NAI, the EAP method could be decided based on the sub domain under eap.arpa in the realm portion of the NAI. Thus a peer wanting to be provisioned would use provision...@noob.eap.arpa or provision...@tls.eap.arpa depending on whether it supports: EAP-NOOB or EAP-TLS for provisioning. Leaving the username semantics to individual provisioning drafts (example: draft-ietf-emu-bootstrapped-tls) might be beneficial in the long run as explained below. The username part will likely be needed to distinguish, for example, initial certificate enrollment during provisioning (NAI provision...@teap.eap.arpa) from later certificate renewal during re-provisioning (NAI re-provision...@teap.eap.arpa). I assume the certificates issued will have a limited lifetime and need to be renewed. There are other good reasons where the username part is used to indicate the provisioning state. For example, if provisioning a certificate and a password, the peer may use different username in the NAI: pha...@teap.eap.arpa for provisioning the certificate and pha...@teap.eap.arpa for provisioning the password. There have been proposals in the past about provisioning different types of credentials: https://datatracker.ietf.org/doc/draft-pala-tian-eap-creds-spp/ I have already created a pull request for such a change should this be amenable to Alan and others in the working group: https://github.com/FreeRADIUS/eap-arpa/pull/1 2. It may beneficial to not limit the provisioning to a local network only. First, while developing EAP-NOOB, there was a specific request from Rhys Smith and Josh Howlett from JISC. Their use case wanted to support provisioning of student IoT devices when they were on an exchange semester in a visiting university. See slide 8 onward: https://datatracker.ietf.org/meeting/106/materials/slides-106-emu-slides-106-draft-aura-eap-noob-00. There are other legitimate reasons for avoiding such limitation. For example, a network owner wants to outsource the provisioning of a new device to the device vendor. Such scenarios were briefly discussed a while back: https://datatracker.ietf.org/doc/html/draft-st-t2trg-nw-access-01 and there was support from Hannes Tschofenig and others. It was later covered in the media as well so I presume there was some interest: https://www.theregister.com/2018/07/25/internet_draft_iot_security/. Finally, there are situations where the device vendor installs the device at the customer site and uses the the customer network for Internet-connectivity but is still responsible for the device provisioning, lifecycle management, services, maintenance, etc. For example, a bunch of elevators installed at customer premises using customer network for sending back maintenance requests. Here again, the customer intentionally wants the device to be provisioned and managed by a remote vendor server. I don't think all these scenarios need to be described in this draft. Just removing the limitation is sufficient. My pull request already includes such a change, should this amenable to Alan and others in the working group: https://github.com/FreeRADIUS/eap-arpa/pull/1 If the working group finds these requests amenable and my pull requests are useful, I'd also volunteer to co-author and help drive this document to the RFC editor queue. Also, at some later point, if volunteers are needed for the IANA expert registry or something else, I'd be available. --Mohit PS: There was also an issue that the current draft recommends Expert Review for assignment of new values but then also expects RFCs: "The intention is that any non-prefix allocation will be accompanied by a published RFC.". I think it will be beneficial to have "Specification Required". Note "Expert Review" and "RFC Required" are separate things in RFC 8126. On 3/8/24 04:08, Peter Yee wrote: This is an adoption call for the eap.arpa Internet-Draft (draft-dekok-emu-eap-arpa). This is an ancillary draft that Alan DeKok briefed during the Prague (IETF 118) meeting. Seeing as it primarily exists as a forward-looking extraction of certain descriptive material and IAB .arpa domanrequests from other EMU documents, we consider it within the scope of the WG charter. Alan did a recent minor update to the document and will speak briefly about it during IETF 119. With that said, your WG chairs would appreciate hearing your feedback on whether this document is adopted or not. While it's not critical to adopt, it really simplifies the domain registration for things like TLS-POK and would have been great back when we did EAP-NOOB. We are particularly interested in hearing from parties who are willing to
Re: [Emu] Adoption call for eap.arpa
On Fri, 8 Mar 2024 at 08:38, Peter Yee wrote: > We are particularly interested in hearing from parties who are > willing to review the specification. So, if you've got interest in > seeing the work adopted, please formalize that by responding > to the EMU mailing list with your position. > I have read the draft and support its adoption. I will reply with comments separately and help with reviewing the draft -- Heikki Vatiainen h...@radiatorsoftware.com ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
On Mar 13, 2024, at 9:51 AM, Michael Richardson wrote: >>> I don't think it's that straight forward. For Enterprise-WiFi we >>> still need cryptographic keys for the WiFi 4-way handshake, so >>> establishing a TLS-Tunnel is needed to derive the WPA keys. We also need it for MacSec on wired connections. Perhaps the document should be updated to say it SHOULD run a method which derives MSK and EMSK, and MUST NOT simple return an EAP Success. > Doing this is significantly better than either unencrypted wifi (w/portal), > or encrypted WPA-PSK wifi. > > So yes, we always want to run EAP-TLS to generate keys. > This document is related to > https://datatracker.ietf.org/doc/draft-richardson-emu-eap-onboarding/, (which > I'll repost on Saturday), but modularizes the work into smaller pieces. EAP-TLS has had peer unauthenticated mode since 2008 (RFC 5216 Section 2.1.1). But there's been no way to actually use it. Hopefully this set of documents will address that issue. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
Alexander Clouter wrote: >>> On Tue, 12 Mar 2024, at 12:37, Yanlei(Ray) wrote: My understanding here is that the EAP server and client will not authenticate each other in EAP-TLS, and all the authentication will be done in the " captive portal ". So why recommend EAP-TLS as a provisioning method? Just send the identifier "por...@eap.arpa" and then jump to a " captive portal ". Is that OK? >>> >>> So for OOB provisioning (ie. get an IP to access a captive portal) >>> the conversation would be: >>> >>> >>> EAP-Identity Request <<< EAP-Identity Response[por...@eap.arpa] >>> >>> EAP-Success >>> >>> Sounds sensible. >> >> I don't think it's that straight forward. For Enterprise-WiFi we >> still need cryptographic keys for the WiFi 4-way handshake, so >> establishing a TLS-Tunnel is needed to derive the WPA keys. > Nice catch. Doing this is significantly better than either unencrypted wifi (w/portal), or encrypted WPA-PSK wifi. So yes, we always want to run EAP-TLS to generate keys. This document is related to https://datatracker.ietf.org/doc/draft-richardson-emu-eap-onboarding/, (which I'll repost on Saturday), but modularizes the work into smaller pieces. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
On Tue, 12 Mar 2024, at 14:45, Jan-Frederik Rieckers wrote: > On 12.03.24 13:45, Alexander Clouter wrote: >> On Tue, 12 Mar 2024, at 12:37, Yanlei(Ray) wrote: >>> My understanding here is that the EAP server and client will not >>> authenticate each other in EAP-TLS, and all the authentication will be >>> done in the " captive portal ". So why recommend EAP-TLS as a >>> provisioning method? Just send the identifier "por...@eap.arpa" and >>> then jump to a " captive portal ". Is that OK? >> >> So for OOB provisioning (ie. get an IP to access a captive portal) the >> conversation would be: >> >> >>> EAP-Identity Request >> <<< EAP-Identity Response[por...@eap.arpa] >> >>> EAP-Success >> >> Sounds sensible. > > I don't think it's that straight forward. > For Enterprise-WiFi we still need cryptographic keys for the WiFi 4-way > handshake, so establishing a TLS-Tunnel is needed to derive the WPA keys. Nice catch. Cheers ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
On 12.03.24 13:45, Alexander Clouter wrote: On Tue, 12 Mar 2024, at 12:37, Yanlei(Ray) wrote: My understanding here is that the EAP server and client will not authenticate each other in EAP-TLS, and all the authentication will be done in the " captive portal ". So why recommend EAP-TLS as a provisioning method? Just send the identifier "por...@eap.arpa" and then jump to a " captive portal ". Is that OK? So for OOB provisioning (ie. get an IP to access a captive portal) the conversation would be: EAP-Identity Request <<< EAP-Identity Response[por...@eap.arpa] EAP-Success Sounds sensible. I don't think it's that straight forward. For Enterprise-WiFi we still need cryptographic keys for the WiFi 4-way handshake, so establishing a TLS-Tunnel is needed to derive the WPA keys. Cheers, Janfred -- Herr Jan-Frederik Rieckers Security, Trust & Identity Services E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370 Pronomen: er/sein | Pronouns: he/him __ DFN - Deutsches Forschungsnetz | German National Research and Education Network Verein zur Förderung eines Deutschen Forschungsnetzes e.V. Alexanderplatz 1 | 10178 Berlin https://www.dfn.de Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | Christian Zens Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch VR AG Charlottenburg 7729B | USt.-ID. DE 136623822 smime.p7s Description: S/MIME Cryptographic Signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
On Tue, 12 Mar 2024, at 12:37, Yanlei(Ray) wrote: > My understanding here is that the EAP server and client will not > authenticate each other in EAP-TLS, and all the authentication will be > done in the " captive portal ". So why recommend EAP-TLS as a > provisioning method? Just send the identifier "por...@eap.arpa" and > then jump to a " captive portal ". Is that OK? So for OOB provisioning (ie. get an IP to access a captive portal) the conversation would be: >>> EAP-Identity Request <<< EAP-Identity Response[por...@eap.arpa] >>> EAP-Success Sounds sensible. Cheers ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
I think this work is useful for bootstrapping IoT devices. I am in favour of adoption. There is also a comment. In Section 5.1 EAP-TLS, " This identifier signals the EAP server that the peer wishes to obtain "peer unauthenticated access" as per [RFC5216] Section 2.1.1 and [RFC9190]. " and " The device SHOULD ignore the EAP server certificate entirely, as the servers identity does not matter. Any verification of servers can be done at the HTTPS layer when the device access the captive portal. " My understanding here is that the EAP server and client will not authenticate each other in EAP-TLS, and all the authentication will be done in the " captive portal ". So why recommend EAP-TLS as a provisioning method? Just send the identifier "por...@eap.arpa" and then jump to a " captive portal ". Is that OK? Regards, Lei YAN -Original Message- From: Emu On Behalf Of Peter Yee Sent: Friday, March 8, 2024 6:38 AM To: emu@ietf.org Subject: [Emu] Adoption call for eap.arpa This is an adoption call for the eap.arpa Internet-Draft (draft-dekok-emu-eap-arpa). This is an ancillary draft that Alan DeKok briefed during the Prague (IETF 118) meeting. Seeing as it primarily exists as a forward-looking extraction of certain descriptive material and IAB .arpa domanrequests from other EMU documents, we consider it within the scope of the WG charter. Alan did a recent minor update to the document and will speak briefly about it during IETF 119. With that said, your WG chairs would appreciate hearing your feedback on whether this document is adopted or not. While it's not critical to adopt, it really simplifies the domain registration for things like TLS-POK and would have been great back when we did EAP-NOOB. We are particularly interested in hearing from parties who are willing to review the specification. So, if you've got interest in seeing the work adopted, please formalize that by responding to the EMU mailing list with your position. The deadline for feedback is March 21st. Yes, that's during IETF 119 but after the EMU time slot, so hopefully you will have formed an opinion by then, if not sooner. We hope to hear from lots of you! Joe and Peter 1) https://datatracker.ietf.org/doc/draft-dekok-emu-eap-arpa/ ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
On Thu, 7 Mar 2024, at 22:38, Peter Yee wrote: > The deadline for feedback is March 21st. Yes, that's during IETF > 119 but after the EMU time slot, so hopefully you will have > formed an opinion by then, if not sooner. We hope to hear > from lots of you! > > 1) https://datatracker.ietf.org/doc/draft-dekok-emu-eap-arpa/ I am in favour of adoption. Regards ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
I think this work is useful, emu is the right WG for that, so I'm in favor of adopting. Cheers, Janfred On 07.03.24 23:38, Peter Yee wrote: This is an adoption call for the eap.arpa Internet-Draft (draft-dekok-emu-eap-arpa). This is an ancillary draft that Alan DeKok briefed during the Prague (IETF 118) meeting. Seeing as it primarily exists as a forward-looking extraction of certain descriptive material and IAB .arpa domanrequests from other EMU documents, we consider it within the scope of the WG charter. Alan did a recent minor update to the document and will speak briefly about it during IETF 119. With that said, your WG chairs would appreciate hearing your feedback on whether this document is adopted or not. While it's not critical to adopt, it really simplifies the domain registration for things like TLS-POK and would have been great back when we did EAP-NOOB. We are particularly interested in hearing from parties who are willing to review the specification. So, if you've got interest in seeing the work adopted, please formalize that by responding to the EMU mailing list with your position. The deadline for feedback is March 21st. Yes, that's during IETF 119 but after the EMU time slot, so hopefully you will have formed an opinion by then, if not sooner. We hope to hear from lots of you! Joe and Peter 1) https://datatracker.ietf.org/doc/draft-dekok-emu-eap-arpa/ -- Herr Jan-Frederik Rieckers Security, Trust & Identity Services E-Mail: rieck...@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370 Pronomen: er/sein | Pronouns: he/him __ DFN - Deutsches Forschungsnetz | German National Research and Education Network Verein zur Förderung eines Deutschen Forschungsnetzes e.V. Alexanderplatz 1 | 10178 Berlin https://www.dfn.de Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | Christian Zens Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch VR AG Charlottenburg 7729B | USt.-ID. DE 136623822 smime.p7s Description: S/MIME Cryptographic Signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Adoption call for eap.arpa
I've read draft-dekok-emu-eap-arpa, I think it important step in getting a number of other efforts underway. Please adopt. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
