Re: [lisp] Virtual meeting
Luigi, I believe we can plan a slot for this? Yours, Joel On 4/7/2020 11:09 PM, Prakash Jain (prakjain) wrote: Hi Joel, Sorry, missed this earlier. I have earlier asked a slot in Vancouver to present lisp-site-external-connectivity draft (https://tools.ietf.org/html/draft-jain-lisp-site-external-connectivity-00). If slots are still available in virtual session, we would like to have 10 min slot to discuss this. Thanks, Prakash On 3/10/20, 2:44 PM, "lisp on behalf of Joel M. Halpern" wrote: Vancouver has been cancelled. We have several ways we can hold a virtual interim. (The chairs have a webex available, and Fabio has offered one.) I understand that folks want to present their work. But what I am looking for if we are going to get folks together is actual engagement on the list. Indication that there are things worth discussing. Yours, Joel ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Virtual meeting
Hi Joel, Sorry, missed this earlier. I have earlier asked a slot in Vancouver to present lisp-site-external-connectivity draft (https://tools.ietf.org/html/draft-jain-lisp-site-external-connectivity-00). If slots are still available in virtual session, we would like to have 10 min slot to discuss this. Thanks, Prakash On 3/10/20, 2:44 PM, "lisp on behalf of Joel M. Halpern" wrote: Vancouver has been cancelled. We have several ways we can hold a virtual interim. (The chairs have a webex available, and Fabio has offered one.) I understand that folks want to present their work. But what I am looking for if we are going to get folks together is actual engagement on the list. Indication that there are things worth discussing. Yours, Joel ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Virtual meeting
> I like it. This is actually something that Fabio and I discussed some time > ago as a possible option but we never really closed on it. So both the Map-Request AD and Map-Reply AD need changes to include the wrapped pubsub key (I referred to this key in the last email as the “new key-material”). So a summary: (1) The MS generates random number, that is the pubsub key, encrypts it with the ITR-OTK. Either proxy replies to the ITR or forwards Map-Request to the ETR with the wrapped pubsub key in the AD field. In the latter case, the ETR forwards that wrapped key to the ITR. (2) The ITR decrypts the wrapped key with the ITR-OTK. (3) Any Map-Notify messages are signed with the pubsub key and verified by the ITR with the same shared pubsub key. Both the ITR and MS (where the subscription state is stored) holds the pubsub key. Rekeying can reoccur whenever the above is done again and the map-server decides to allocate an new random number. Agree? Comments? Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Virtual meeting
Yep, that fills in the details nicely. I started from "we should be able to bootstrap the security through lisp-sec". Yours, Joel On 3/31/2020 8:27 PM, Dino Farinacci wrote: Sorry, yes, it is the MS, not the MR, who provides the information to construct the key, since it is the MS who is generating the notifies. Sorry I still cross them up. Oh good. That is more clear now. So if you are saying this: (1) Use LISP-sec as defined today. (2) Have the MS wrap some new key material with the MS-OTK and pass it to the ETR. (3) The ETR replies as it does today but we have new protected key material in the Map-Reply. (4) The MS stores the new key-material. (5) The ITR generates the new key-material because it can unwrap the MS-OTK that is derived from the ITR-OTK. (6) Any subsequent unsolicited Map-Notify messages from the MS (for an RLOC-change) are signed with the new key-material. Which the ITR can verify since it has the new key-material from step (5). That is a shared-key created with the pair of OTKs. I think that can work. Fabio needs to verify. I know you didn’t say all these details but I’m progressing your point, for discussion. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Virtual meeting
> Sorry, yes, it is the MS, not the MR, who provides the information to > construct the key, since it is the MS who is generating the notifies. Sorry I > still cross them up. Oh good. That is more clear now. So if you are saying this: (1) Use LISP-sec as defined today. (2) Have the MS wrap some new key material with the MS-OTK and pass it to the ETR. (3) The ETR replies as it does today but we have new protected key material in the Map-Reply. (4) The MS stores the new key-material. (5) The ITR generates the new key-material because it can unwrap the MS-OTK that is derived from the ITR-OTK. (6) Any subsequent unsolicited Map-Notify messages from the MS (for an RLOC-change) are signed with the new key-material. Which the ITR can verify since it has the new key-material from step (5). That is a shared-key created with the pair of OTKs. I think that can work. Fabio needs to verify. I know you didn’t say all these details but I’m progressing your point, for discussion. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Virtual meeting
Sorry, yes, it is the MS, not the MR, who provides the information to construct the key, since it is the MS who is generating the notifies. Sorry I still cross them up. Yours, Joel On 3/31/2020 8:01 PM, Dino Farinacci wrote: Yes, but that’s a new precedent requiring the MR to store state. We should try to make it lighter weight. And you can’t do what you want on the MR, because its the MS’s OTK as spec’ed today that is passed to the ETR. Dino On Mar 31, 2020, at 4:58 PM, Joel M. Halpern wrote: We could reuse the OTK directly. My actual inclination would be for the MR to send back (via the ETR) some data which, when combined with the OTK, produced a separate key for use with the notify messages. Clearly, the MR would have to store whatever security key we want it to use as long as the subscription persisted. Yours, Joel On 3/31/2020 7:27 PM, Dino Farinacci wrote: I may have missed something, but I think that in the case of the first notify, it does actually start at the Itr. Specifically, it starts with an ItR sending a subscribe request. The MS responds to that with a notify. What I am suggesting is that (when security is desired) the Itr includes the same kind of information in its subscribe that goes into lisp-sec. And that the reply, instead of going directly from the MS back to the ITR goes through the ETR so that the rest of the lisp-sec procedures can be applied. Yes, and in that Subscribe-Request you can include an OTK. But that one-time-key would be used more than one time. To send the Map-Notify to reply with the RLOC-set to the ITR as well as acknowledger from the Map-Server that subscription has been accepted. But then the one-time-key would have to be *stored* in the Map-Server and then used later when the RLOC-set changes to send an unsolicited Map-Notify. So the one-time-key would be “two time” and we would set a precedent to make it no longer ephemeral. In previous cases, the OTK was not stored anywhere. I would then use that as a bootstrap, putting necessary secrets to create the key information so that the MS can sign and the ITR can verify future notifies that go directly from the MS to the ITR. If the working group believes that the OTK should be stored and then used again, then both the Map-Server and ITR would have to store it. In the original case, the ITR stores the OTK only until the time a Map-Reply or Map-Notify is received. But the Map-Server would have to store it indefinintely (per ITR that subscribes). Dino Yours, Joel On 3/31/2020 1:33 PM, Dino Farinacci wrote: thinking about Alberto's request, and reading the document, I wondered if the security could be improved by sending the first notify back via the ETR, and coupling it to LISP-SEC to protect the information and provide needed keys for further messages? It seems like we do need a way to protect the notifications, and requiring associations from every ITR to every MS who may provide notifications seems impossible. You can’t use LISP-SEC because the transactional nature of it starts with an ITR and a one-time-key, that is used to signed Map-Replies returning to it. For Map-Notify messages send from Map-Server via ETR, there would be no ITR one-time-key. And if the Map-Server used its own one-time-key, the ITR couldn’t derive it. Note with LISP-SEC the map-server one-time-key is derived from the ITR’s one-time-key in the Map-Request. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Virtual meeting
Yes, but that’s a new precedent requiring the MR to store state. We should try to make it lighter weight. And you can’t do what you want on the MR, because its the MS’s OTK as spec’ed today that is passed to the ETR. Dino > On Mar 31, 2020, at 4:58 PM, Joel M. Halpern wrote: > > We could reuse the OTK directly. My actual inclination would be for the MR > to send back (via the ETR) some data which, when combined with the OTK, > produced a separate key for use with the notify messages. Clearly, the MR > would have to store whatever security key we want it to use as long as the > subscription persisted. > > Yours, > Joel > > On 3/31/2020 7:27 PM, Dino Farinacci wrote: >>> I may have missed something, but I think that in the case of the first >>> notify, it does actually start at the Itr. >>> Specifically, it starts with an ItR sending a subscribe request. The MS >>> responds to that with a notify. What I am suggesting is that (when >>> security is desired) the Itr includes the same kind of information in its >>> subscribe that goes into lisp-sec. And that the reply, instead of going >>> directly from the MS back to the ITR goes through the ETR so that the rest >>> of the lisp-sec procedures can be applied. >> Yes, and in that Subscribe-Request you can include an OTK. But that >> one-time-key would be used more than one time. To send the Map-Notify to >> reply with the RLOC-set to the ITR as well as acknowledger from the >> Map-Server that subscription has been accepted. But then the one-time-key >> would have to be *stored* in the Map-Server and then used later when the >> RLOC-set changes to send an unsolicited Map-Notify. So the one-time-key >> would be “two time” and we would set a precedent to make it no longer >> ephemeral. In previous cases, the OTK was not stored anywhere. >>> I would then use that as a bootstrap, putting necessary secrets to create >>> the key information so that the MS can sign and the ITR can verify future >>> notifies that go directly from the MS to the ITR. >> If the working group believes that the OTK should be stored and then used >> again, then both the Map-Server and ITR would have to store it. In the >> original case, the ITR stores the OTK only until the time a Map-Reply or >> Map-Notify is received. But the Map-Server would have to store it >> indefinintely (per ITR that subscribes). >> Dino >>> >>> Yours, >>> Joel >>> >>> On 3/31/2020 1:33 PM, Dino Farinacci wrote: > thinking about Alberto's request, and reading the document, I wondered if > the security could be improved by sending the first notify back via the > ETR, and coupling it to LISP-SEC to protect the information and provide > needed keys for further messages? It seems like we do need a way to > protect the notifications, and requiring associations from every ITR to > every MS who may provide notifications seems impossible. You can’t use LISP-SEC because the transactional nature of it starts with an ITR and a one-time-key, that is used to signed Map-Replies returning to it. For Map-Notify messages send from Map-Server via ETR, there would be no ITR one-time-key. And if the Map-Server used its own one-time-key, the ITR couldn’t derive it. Note with LISP-SEC the map-server one-time-key is derived from the ITR’s one-time-key in the Map-Request. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Virtual meeting
We could reuse the OTK directly. My actual inclination would be for the MR to send back (via the ETR) some data which, when combined with the OTK, produced a separate key for use with the notify messages. Clearly, the MR would have to store whatever security key we want it to use as long as the subscription persisted. Yours, Joel On 3/31/2020 7:27 PM, Dino Farinacci wrote: I may have missed something, but I think that in the case of the first notify, it does actually start at the Itr. Specifically, it starts with an ItR sending a subscribe request. The MS responds to that with a notify. What I am suggesting is that (when security is desired) the Itr includes the same kind of information in its subscribe that goes into lisp-sec. And that the reply, instead of going directly from the MS back to the ITR goes through the ETR so that the rest of the lisp-sec procedures can be applied. Yes, and in that Subscribe-Request you can include an OTK. But that one-time-key would be used more than one time. To send the Map-Notify to reply with the RLOC-set to the ITR as well as acknowledger from the Map-Server that subscription has been accepted. But then the one-time-key would have to be *stored* in the Map-Server and then used later when the RLOC-set changes to send an unsolicited Map-Notify. So the one-time-key would be “two time” and we would set a precedent to make it no longer ephemeral. In previous cases, the OTK was not stored anywhere. I would then use that as a bootstrap, putting necessary secrets to create the key information so that the MS can sign and the ITR can verify future notifies that go directly from the MS to the ITR. If the working group believes that the OTK should be stored and then used again, then both the Map-Server and ITR would have to store it. In the original case, the ITR stores the OTK only until the time a Map-Reply or Map-Notify is received. But the Map-Server would have to store it indefinintely (per ITR that subscribes). Dino Yours, Joel On 3/31/2020 1:33 PM, Dino Farinacci wrote: thinking about Alberto's request, and reading the document, I wondered if the security could be improved by sending the first notify back via the ETR, and coupling it to LISP-SEC to protect the information and provide needed keys for further messages? It seems like we do need a way to protect the notifications, and requiring associations from every ITR to every MS who may provide notifications seems impossible. You can’t use LISP-SEC because the transactional nature of it starts with an ITR and a one-time-key, that is used to signed Map-Replies returning to it. For Map-Notify messages send from Map-Server via ETR, there would be no ITR one-time-key. And if the Map-Server used its own one-time-key, the ITR couldn’t derive it. Note with LISP-SEC the map-server one-time-key is derived from the ITR’s one-time-key in the Map-Request. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Virtual meeting
> I may have missed something, but I think that in the case of the first > notify, it does actually start at the Itr. > Specifically, it starts with an ItR sending a subscribe request. The MS > responds to that with a notify. What I am suggesting is that (when security > is desired) the Itr includes the same kind of information in its subscribe > that goes into lisp-sec. And that the reply, instead of going directly from > the MS back to the ITR goes through the ETR so that the rest of the lisp-sec > procedures can be applied. Yes, and in that Subscribe-Request you can include an OTK. But that one-time-key would be used more than one time. To send the Map-Notify to reply with the RLOC-set to the ITR as well as acknowledger from the Map-Server that subscription has been accepted. But then the one-time-key would have to be *stored* in the Map-Server and then used later when the RLOC-set changes to send an unsolicited Map-Notify. So the one-time-key would be “two time” and we would set a precedent to make it no longer ephemeral. In previous cases, the OTK was not stored anywhere. > I would then use that as a bootstrap, putting necessary secrets to create the > key information so that the MS can sign and the ITR can verify future > notifies that go directly from the MS to the ITR. If the working group believes that the OTK should be stored and then used again, then both the Map-Server and ITR would have to store it. In the original case, the ITR stores the OTK only until the time a Map-Reply or Map-Notify is received. But the Map-Server would have to store it indefinintely (per ITR that subscribes). Dino > > Yours, > Joel > > On 3/31/2020 1:33 PM, Dino Farinacci wrote: >>> thinking about Alberto's request, and reading the document, I wondered if >>> the security could be improved by sending the first notify back via the >>> ETR, and coupling it to LISP-SEC to protect the information and provide >>> needed keys for further messages? It seems like we do need a way to protect >>> the notifications, and requiring associations from every ITR to every MS >>> who may provide notifications seems impossible. >> You can’t use LISP-SEC because the transactional nature of it starts with an >> ITR and a one-time-key, that is used to signed Map-Replies returning to it. >> For Map-Notify messages send from Map-Server via ETR, there would be no ITR >> one-time-key. And if the Map-Server used its own one-time-key, the ITR >> couldn’t derive it. Note with LISP-SEC the map-server one-time-key is >> derived from the ITR’s one-time-key in the Map-Request. >> Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Virtual meeting
I may have missed something, but I think that in the case of the first notify, it does actually start at the Itr. Specifically, it starts with an ItR sending a subscribe request. The MS responds to that with a notify. What I am suggesting is that (when security is desired) the Itr includes the same kind of information in its subscribe that goes into lisp-sec. And that the reply, instead of going directly from the MS back to the ITR goes through the ETR so that the rest of the lisp-sec procedures can be applied. I would then use that as a bootstrap, putting necessary secrets to create the key information so that the MS can sign and the ITR can verify future notifies that go directly from the MS to the ITR. Yours, Joel On 3/31/2020 1:33 PM, Dino Farinacci wrote: thinking about Alberto's request, and reading the document, I wondered if the security could be improved by sending the first notify back via the ETR, and coupling it to LISP-SEC to protect the information and provide needed keys for further messages? It seems like we do need a way to protect the notifications, and requiring associations from every ITR to every MS who may provide notifications seems impossible. You can’t use LISP-SEC because the transactional nature of it starts with an ITR and a one-time-key, that is used to signed Map-Replies returning to it. For Map-Notify messages send from Map-Server via ETR, there would be no ITR one-time-key. And if the Map-Server used its own one-time-key, the ITR couldn’t derive it. Note with LISP-SEC the map-server one-time-key is derived from the ITR’s one-time-key in the Map-Request. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Virtual meeting
> thinking about Alberto's request, and reading the document, I wondered if the > security could be improved by sending the first notify back via the ETR, and > coupling it to LISP-SEC to protect the information and provide needed keys > for further messages? It seems like we do need a way to protect the > notifications, and requiring associations from every ITR to every MS who may > provide notifications seems impossible. You can’t use LISP-SEC because the transactional nature of it starts with an ITR and a one-time-key, that is used to signed Map-Replies returning to it. For Map-Notify messages send from Map-Server via ETR, there would be no ITR one-time-key. And if the Map-Server used its own one-time-key, the ITR couldn’t derive it. Note with LISP-SEC the map-server one-time-key is derived from the ITR’s one-time-key in the Map-Request. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Virtual meeting
thinking about Alberto's request, and reading the document, I wondered if the security could be improved by sending the first notify back via the ETR, and coupling it to LISP-SEC to protect the information and provide needed keys for further messages? It seems like we do need a way to protect the notifications, and requiring associations from every ITR to every MS who may provide notifications seems impossible. Yours, Joel On 3/17/2020 11:56 PM, Alberto Rodriguez Natal (natal) wrote: Thanks Joel, I've tried to summarize my line of thought below. There may be other aspects I'm missing. In traditional LISP, there is some shared state between a Map-Server and an ETR in order to validate Map-Notifies. First, for integrity protection Map-Notifies include some authentication data generated using a shared key between the Map-Server and the ETR. Second, to protect against replay attacks the nonce used in the Map-Register/Map-Notify exchange is incremented over time. This requires that both the Map-Server and the ETR are in synch regarding the shared key and incremental nonce. PubSub introduces a new protocol operation where a Map-Server can send Map-Notify messages to ITRs. This departs from the traditional ETR-MS relationship stated above and introduces a few questions. How to keep a shared key at scale between ITRs and a Map-Server? The ratio of ITRs-to-MS is potentially orders of magnitude bigger than the ratio of ETRs-to-MS, are shared keys even feasible? Besides, how to handle the nonce increment when the ITR is also an ETR? Do we need to keep track of two Map-Notify nonces, one for the Map-Register exchange and another for PubSub operation? Thanks, Alberto On 3/16/20, 11:24 AM, "Joel Halpern Direct" wrote: Thank you Alberto. To see if folks want to engage on the topic, could you write a short email describing the question and, if you can, some of the things that you would like to discuss? Folks, let's be clear. I do expect we will have a virtual interim. Maybe even more than one. I would really like to see groundwork on the email list so that any request by the chairs for folks to make time is for more than just some presentations. Thank you, Joel On 3/16/2020 2:15 PM, Alberto Rodriguez Natal (natal) wrote: > Joel, all, > > I'm in favor of having a virtual interim meeting. One of the points that I have on my personal list of "things to discuss when we have time" is the aspect of (unsolicited) Map-Notifies on PubSub. I think it can benefit from some deeper discussion with the WG regarding, nonces, security associations, ITR-MS relationship, etc. If the WG is up to it, I can bring the topic for discussion and get some opinions on an interim. > > Thanks, > Alberto > > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Virtual meeting
Thanks Joel, I've tried to summarize my line of thought below. There may be other aspects I'm missing. In traditional LISP, there is some shared state between a Map-Server and an ETR in order to validate Map-Notifies. First, for integrity protection Map-Notifies include some authentication data generated using a shared key between the Map-Server and the ETR. Second, to protect against replay attacks the nonce used in the Map-Register/Map-Notify exchange is incremented over time. This requires that both the Map-Server and the ETR are in synch regarding the shared key and incremental nonce. PubSub introduces a new protocol operation where a Map-Server can send Map-Notify messages to ITRs. This departs from the traditional ETR-MS relationship stated above and introduces a few questions. How to keep a shared key at scale between ITRs and a Map-Server? The ratio of ITRs-to-MS is potentially orders of magnitude bigger than the ratio of ETRs-to-MS, are shared keys even feasible? Besides, how to handle the nonce increment when the ITR is also an ETR? Do we need to keep track of two Map-Notify nonces, one for the Map-Register exchange and another for PubSub operation? Thanks, Alberto On 3/16/20, 11:24 AM, "Joel Halpern Direct" wrote: Thank you Alberto. To see if folks want to engage on the topic, could you write a short email describing the question and, if you can, some of the things that you would like to discuss? Folks, let's be clear. I do expect we will have a virtual interim. Maybe even more than one. I would really like to see groundwork on the email list so that any request by the chairs for folks to make time is for more than just some presentations. Thank you, Joel On 3/16/2020 2:15 PM, Alberto Rodriguez Natal (natal) wrote: > Joel, all, > > I'm in favor of having a virtual interim meeting. One of the points that I have on my personal list of "things to discuss when we have time" is the aspect of (unsolicited) Map-Notifies on PubSub. I think it can benefit from some deeper discussion with the WG regarding, nonces, security associations, ITR-MS relationship, etc. If the WG is up to it, I can bring the topic for discussion and get some opinions on an interim. > > Thanks, > Alberto > > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Virtual meeting
Another topic that I’ve been holding off on (in favor of finalizing publication of the RFC bis documents) is the federation of control planes. We’ve come across this requirement in many cross-organizational environments (the ones for which we started working on Uberlay). I’ll send a separate note (under a dedicated header) to the list so we can get warmed up ahead of the virtual interim. In a nutshell, we have multiple providers in the Civil Aviation space who currently peer with each other in a very traditional manner (control and data plane peering). The policies enforced at these peering points are key to their business. The intent is to evolve this backbone to use LISP as the control plane and simplify the peering arrangement by focusing on enforcing the policies at the control plane level. Many benefits to pursuing this, which we can discuss as the WG gets involved. Cheers, -v > On Mar 16, 2020, at 11:24 AM, Joel Halpern Direct > wrote: > > Thank you Alberto. To see if folks want to engage on the topic, could you > write a short email describing the question and, if you can, some of the > things that you would like to discuss? > > Folks, let's be clear. I do expect we will have a virtual interim. Maybe > even more than one. I would really like to see groundwork on the email list > so that any request by the chairs for folks to make time is for more than > just some presentations. > > Thank you, > Joel > > On 3/16/2020 2:15 PM, Alberto Rodriguez Natal (natal) wrote: >> Joel, all, >> I'm in favor of having a virtual interim meeting. One of the points that I >> have on my personal list of "things to discuss when we have time" is the >> aspect of (unsolicited) Map-Notifies on PubSub. I think it can benefit from >> some deeper discussion with the WG regarding, nonces, security associations, >> ITR-MS relationship, etc. If the WG is up to it, I can bring the topic for >> discussion and get some opinions on an interim. >> Thanks, >> Alberto >> > > ___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Virtual meeting
Thank you Alberto. To see if folks want to engage on the topic, could you write a short email describing the question and, if you can, some of the things that you would like to discuss? Folks, let's be clear. I do expect we will have a virtual interim. Maybe even more than one. I would really like to see groundwork on the email list so that any request by the chairs for folks to make time is for more than just some presentations. Thank you, Joel On 3/16/2020 2:15 PM, Alberto Rodriguez Natal (natal) wrote: Joel, all, I'm in favor of having a virtual interim meeting. One of the points that I have on my personal list of "things to discuss when we have time" is the aspect of (unsolicited) Map-Notifies on PubSub. I think it can benefit from some deeper discussion with the WG regarding, nonces, security associations, ITR-MS relationship, etc. If the WG is up to it, I can bring the topic for discussion and get some opinions on an interim. Thanks, Alberto ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Virtual meeting
I think a great topic to discuss. And an important problem to solve of course. ;-) Dino > On Mar 16, 2020, at 11:15 AM, Alberto Rodriguez Natal (natal) > wrote: > > Joel, all, > > I'm in favor of having a virtual interim meeting. One of the points that I > have on my personal list of "things to discuss when we have time" is the > aspect of (unsolicited) Map-Notifies on PubSub. I think it can benefit from > some deeper discussion with the WG regarding, nonces, security associations, > ITR-MS relationship, etc. If the WG is up to it, I can bring the topic for > discussion and get some opinions on an interim. > > Thanks, > Alberto > > > ___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Virtual meeting
Joel, all, I'm in favor of having a virtual interim meeting. One of the points that I have on my personal list of "things to discuss when we have time" is the aspect of (unsolicited) Map-Notifies on PubSub. I think it can benefit from some deeper discussion with the WG regarding, nonces, security associations, ITR-MS relationship, etc. If the WG is up to it, I can bring the topic for discussion and get some opinions on an interim. Thanks, Alberto ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Virtual meeting
No, fundamentally, WG sessions are not supposed to be opportunities to present. They are supposed to be opportunities to use higher bandwidth to resolve issues. Even virtual meetings are supposed to be for that goal. Of the several presentations at the last meeting, most had no comments, some had one or two comments (from me and Fabio if I recall, I ahve not checked the minutes), and I think one got some good discussion. I expect you know of multiple issues. I would not be surprised (and it is normal and acceptable) if you discuss those issues with your co-authors. Bring some of those issues to the list. Side-note: I am not talking about the issues around the document advancement. that is a different problem. Yours, Joel On 3/10/2020 6:02 PM, Dino Farinacci wrote: Many of the things that I believe folks would like to discuss are in charter. Dino, I think you misunderstood my point. I understood the point. But if people don’t get the opportunity to present, then there isn’t much to discuss. If members want to discuss anything they feel is important, they can always bring that up on the list. So there is nothing special about a virtual meeting that would warrant discussion. But if there are presenters, then we should have a virtual meeting. I am looking to see discussion on the list to give me confidence that a virtual session will be useful. I have been It will be useful if there are presenters. disappointed in the one-way nature of the last several working group meetings, and do not wish to waste a virtual meeting on such. It is less waste than having a physical meeting. There was one-way nature in the last working group? Can you be more specific? I saw discussion at the mic. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Virtual meeting
> Many of the things that I believe folks would like to discuss are in charter. > Dino, I think you misunderstood my point. I understood the point. But if people don’t get the opportunity to present, then there isn’t much to discuss. If members want to discuss anything they feel is important, they can always bring that up on the list. So there is nothing special about a virtual meeting that would warrant discussion. But if there are presenters, then we should have a virtual meeting. > I am looking to see discussion on the list to give me confidence that a > virtual session will be useful. I have been It will be useful if there are presenters. > disappointed in the one-way nature of the last several working group > meetings, and do not wish to waste a virtual meeting on such. It is less waste than having a physical meeting. There was one-way nature in the last working group? Can you be more specific? I saw discussion at the mic. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Virtual meeting
Many of the things that I believe folks would like to discuss are in charter. Dino, I think you misunderstood my point. I am looking to see discussion on the list to give me confidence that a virtual session will be useful. I have been disappointed in the one-way nature of the last several working group meetings, and do not wish to waste a virtual meeting on such. Sure, we are not going to be able to last-call things yet. But we can get them ready for IETF LC. (Whether we hold a WG LC or defer that probably depends upon whether there is dependency on the currently blocking comments for PS publication.) Yours, Joel On 3/10/2020 5:50 PM, Dino Farinacci wrote: I understand that folks want to present their work. But what I am looking for if we are going to get folks together is actual engagement on the list. Indication that there are things worth discussing. There are things worth discussing if we can discuss non-RFCbis material. There are many working group documents ready for last call but consensus wants to hold them until RFCbis documents are in RFC. Since that is taking a bit long, we are seeing delays unfortunately. But more importantly, if people want to discuss, people should attend virtually. I will attend virtually when it is decided to have the virtual meeting. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Virtual meeting
> I understand that folks want to present their work. > But what I am looking for if we are going to get folks together is actual > engagement on the list. Indication that there are things worth discussing. There are things worth discussing if we can discuss non-RFCbis material. There are many working group documents ready for last call but consensus wants to hold them until RFCbis documents are in RFC. Since that is taking a bit long, we are seeing delays unfortunately. But more importantly, if people want to discuss, people should attend virtually. I will attend virtually when it is decided to have the virtual meeting. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
[lisp] Virtual meeting
Vancouver has been cancelled. We have several ways we can hold a virtual interim. (The chairs have a webex available, and Fabio has offered one.) I understand that folks want to present their work. But what I am looking for if we are going to get folks together is actual engagement on the list. Indication that there are things worth discussing. Yours, Joel ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
