Re: [admin-discuss] [IAB] Consultation on IETF Administrative Strategic Plan 2023

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Jay again,

I just realised that I actually had a few more comments on the text (not only the transitions) which I apparently never hit send on. I hope that is still useful input for you. Please see below.

Mirja

——————————
“The Director of Communications has had a content curation and coordination role for many years, both when at ISOC and now at the IETF LLC, but this needs a higher level of management and the IETF LLC appears to be the only part of the IETF with the inclination and resources to do that. The IETF LLC has been moving into that role for some time with a rolling program of tackling specific areas of content (e.g. authors, WG chairs, meetings).”

Just because there is a gap, it doesn’t mean the LLC has to fill it. The LLC should work on finding the right process to ensure that the gap is filled but authority about the content can not move to the LLC.


“The IETF LLC and Secretariat have moved past the point where they respond to every request/suggestion/complaint by changing the way they do things, and changes to processes are now made on a more measured and planned approach.”

I agree changes should not be driven by individual complains but based on either community input or in collaboration with the respective leadership group (IESG/IAB/IRFT/LLC). In cases were an immediate decision is needed, reporting is important and needs to be improved. This could be spelled out.


“The work on offsetting carbon emissions is close to the final stage of identifying and procuring carbon offsets, but this is still sufficiently important to be a top level strategic transformation.”

Finding “potential options for carbon offset” was already in the last strategic plan and since then you did some blog post and side meeting but I feel we actually never established community consensus about offsetting carbon emissions.


“Large donors, such as foundations, often provide a package of funding. For example, a portion of the funding may need to be dedicated to outreach and so the IETF LLC will need to work with the IAB and IESG to have plans pre-prepared on how to use outreach funds, which can then be shared with potential donors.”

This point is not well reflected in the transitions.


“There has been a lot of work on remote participation leading to a significantly improved experience. However, further improvement is sought, particularly around the social engagement aspect.”

It would be more useful to say where and why improvements are needed. This only mentions the social engagement aspect but that again something for the IESG to care about in general - of course tooling support is something for the LLLC but the IESG needs to decide if and with what goal they want to improve there. However, there are many things about user experience that need still need improvement and continues development that should be mentioned here more explicit.


> On 17. Nov 2023, at 13:26, Mirja Kuehlewind <mirja.kuehlewind=[e-mail]> wrote:
> 
> Hi Jay,
> 
> please see replies inline (marked with [MK]).
> 
> Mirja
> 
> On 16.11.23, 14:04, "Jay Daley" <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> Hi Mirja
> 
> 
> Thank you for such detailed feedback. Some thoughts below:
> 
> 
>> On 15 Nov 2023, at 22:09, Mirja Kuehlewind <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hi Jay,
>> 
>> sorry for my late input. But I have to say putting the deadline on a Monday after an IETF meeting is not really ideal, at least not if you want feedback from leadership.
> 
> 
> This consultation set a four week period for feedback, starting sufficiently in advance of an IETF meeting that people are caught up in planning for that, and intentionally finishing just after an IETF meeting so that the community has an opportunity to raise any issues directly with the IETF LLC Board including asking questions at plenary. 
> 
> [MK] That thinking to run it over the week of IETF meeting is fine but finishing right on Monday afterwards is the problem. This tight deadline also does not give people who might only have seen this during the plenary a lot of time to catch up. So basically, maybe two weeks more would have been valuable. Just to consider for next time. Another option would have been to more explicitly reach out to the IESG and IAB and maybe even actively use the meeting for feedback. I would have proposed this but didn't realize in time how much more this new strategic plan relies on input from other leadership groups.
> 
> 
>> I do have quite some concerns about the direction of the new strategic plan. While I generally agree to the most of the goals, I'm uncertain about the responsibility and role of the LLC for some of these goals. I believe this aligns with the concerns raised by Brian and Stephen,
> 
> 
> Theirs was a separate point about ensuring that the nomcom-appointed community members remain in control of any strategic process, and wording has been proposed to clarify the IETF LLC position on that [1]. This was a concern raised in 2020 when the first IETF LLC strategy was consulted on and many in the community have been watching for this carefully but since then, very few concerns have been raised about that, suggesting that the IETF LLC has both understood this concern and worked within its boundaries. 
> 
> [MK] I don't think this is a separate point, but I let Brian and Stephen comment more if they want.
> 
> 
>> however, I think we already crossed the line for some proposed transitions at least the way they are formulated right now. The main points are about the webpage and meeting, where I think the IESG is the main responsible party in order to ensure productivity and quality. Please see my detailed comments below.
> 
> 
> Will do.
> 
> 
>> I also would like to comment on one thing that I'm missing in the strategic plan. In March the LLC published a statement on Remote Meeting Participation (https://www.ietf.org/blog/ietf-llc-statement-on-remote-meeting-participation/ <https://www.ietf.org/blog/ietf-llc-statement-on-remote-meeting-participation/>). In this statement the LLC commits to certain operational principles including the following one:
>> 
>> 5. The long-term aspirational goal is for all participation in the IETF to be free, including IETF Meetings.
>> 
>> I don't see this reflected in the strategic plan. I don't know what you mean by aspirational, but I hope it doesn't mean that you don't take it seriously. However, I think a strategic plan needs to reflect these long-term goals. More concreate I would like to see the follow transition added:
>> 
>> From: Remote participants need to pay a registration fee which can be a barrier to participation -> To: Sufficient funding is raised to enable remote participation without requiring a fee
> 
> 
> That wasn’t added because it did not seem even close to achievable within the three year timeframe of this strategy. However, I will note this as a possible amendment for the board to review.
> 
> [MK] That highly disappointing. Basically you are saying you expect to fails and therefore don't even try? Yes, please reconsider.
> 
> 
> 
> 
>> Please see more comments below!
>> 
>> Mirja
>> 
>> 
>> -------------------------
>>> 1) From: IESG and IAB neither seek nor receive any professional support for any strategic planning they might wish to adopt. -> To: IESG and IAB use the LLC to provide professional support for their strategic planning, as required.
>> 
>> I really don't understand how you can make the IESG/IAB "use" the LLC. I think it's on the IESG/IAB to decide if they want that support or not. The IESG is from time to time discussion long-term strategy, and yes there are things were some support would be helpful, however, the outcome of most of those effort was more limited due to how the IETF is structural set up. But again, it's on the IESG/IAB to decide where and if they want to do strategic planning and not the LLC. Also, at minimum I think you should have discussed this point with the IESG/IAB which didn't happen.
> 
> 
> This is a shift that is already well underway and has been for some time and so this was included in order to be transparent about that. That shift is primarily something that individual members of those bodies are instigating and I agree that a more explicit discussion about this would be valuable and that this wording gives the impression that has already happened.
> 
> [MK] Yes, we need to have a more explicit discussion. Thanks! However, the wording is also problematic because it implies that the IESG and IAB need to have a strategic plan. Independent of the question if they should or not, it's definitely not for the LLC to decide this. I think that is also what Ekr said. Please engage with the IESG/IAB explicitly about this and revise the wording.
> 
> 
>>> 2) From Slow progress by the IETF in addressing some long-standing and important strategic issues. -> To: The IETF makes significant progress on addressing long-standing and important strategic issues.
>> 
>> Again, I think these issues are more structural, so I don't see the role of the LLC here. And again, this is a goal for the IESG/IAB and not the LLC, especially this this very generally talks about "strategic issue" without narrowing down to things that the LLC has responsibility for.
> 
> 
> In this transformation, and in many others with a similar broad scope, the IETF LLC is not asserting any form of ownership or control of either the problem or the solution. These are common issues across the whole IETF that all parts need to work towards and the IETF LLC is aiming to be transparent in both recognising the existence of issues and that it will contribute to the work on these.
> 
> 
> A good example here is the the long-standing issue of the gender balance of IETF participants. The IETF LLC has recently commissioned and published a report aimed to help understand the underlying problem and the impact of that, and assist all parts of the community who wish to have a role here. I have yet to see anything but support for this action, which I think demonstrates well that the IETF LLC understands the difference between ownership and contribution.
> 
> Looking through the full text, I can see that this is not explicitly explained, so I will consider some text to propose to the board that makes this clear.
> 
> [MK] Rather than talking about strategic issues for the IETF generally, it would be much more useful to identify the issues and more importantly the LLC's role in these issues and include those in the strategic plan. If you still need to do more work to identify the issues where the LLC has a role, then maybe that's your strategic goal. E.g. I think it would be great for the LLC to develop a plan how to improve gender diversity and inclusivity in general and then provide this plan to the IESG (and potentially IAB depending on the proposed actions), so that these leadership group can than take action or request support from the LLC respectively. More concretely, please note that both eodir and systers are teams that are managed by the IETF chair  as part of the chair's role as GEN AD, similar as other area directorates and teams work. These groups are community groups and the role of LLC staff who are involved in the group leads is to manage the groups. I think it is great to see that new ideas are proposed and implement but the IESG needs to be in the loop, especially when meeting organization and agenda planning are impacted, and I already see that vanishing.
> 
> 
>>> 3) From: No overall strategy for the development of content and engagement channels, with sporadic use of measurement and partially defined participant journey -> To: Content and engagement channels developed and managed under an overall strategy, based on comprehensive measurement and a well defined participant journey.
>> 
>> There might be a role here for the LLC to provide measurement data, however, the responsible for the content of the webpage lies not with the LLC, at least not for the most parts; of course the LLC maintains the info about the LLC and maybe some other operational aspects as well. This should be a goal, at least as it is phrased currently for the IESG and not the LLC.
>> 
>> 4) From: Website and other channels beset with out of date content, poor information architecture, poor content coordination across sites and with important gaps in content. -> To: Up to date, effective content with all the important subjects/paths covered, good content coordination between sites and channels, and an established process to keep it this way.
>> 
>> I don't really understand how this point is different from the previous one as I would think the reason to have a strategy is to make sure it's up-to-date. However, the same comment as above applies and even more thought because this explicitly talks about content where I think the responsibility mostly sits by the IESG. Btw. I agree that the IESG is not working enough on this responsibility, and I think we need to develop a process where LLC staff can work on content for the IESG but that's not what the transition goal states. And again, the IESG needs to decide on that strategy.
> 
> 
> IETF staff have had operational control of the website and related communications for far longer than the IETF LLC has been in existence, with the same member of staff doing this for many years. However, as is clear from the list of problems identified, there has been a significant gap in site/content design and the IETF LLC has indeed been moving to fix that by rewriting content, producing plans, commissioning web development etc. All of which has been based as closely as possible on existing community content, community feedback and website analytics.
> 
> [MK] As you said, staff has operational control, however, one of the reasons why we are where we are is that responsibility for content is not part of that. Yes, the LLC has been working on rewriting content, however, we actually created a leadership comms team to review that. Unfortunately, that process is not working appropriately and we need to fix that. The two us have been discussing this issue and I like would to be very pragmatic about this right now in order to be able to make any progress finally. However, that doesn't mean that we can just ignore responsibilities in future and not try to address the issue appropriately. The solution cannot be that the LLC is the sole decision holder and moves ahead unilaterally. As such the goal for the LLC should really be here to define a process and clarify responsibilities such that in future we have an update process that clearly defines roles and avoids blockage as we have had it until now.
> 
> 
> This is happening entirely transparently and with significant community engagement including regular updates to the IESG and discussions on tao-discuss and reporting to open tools meetings. In all of that engagement there have been no objections to the IETF LLC doing this and considerable support for the aims. For example, one key aim is to have as much web content as possible on GitHub to greatly reduce the barrier for community contributions. I have yet to hear from the IESG that it objects to this and where the IESG specifically wants control, such as for the I-D Guidelines, then this has been maintained.
> 
> [MK] Taking the example of Github: just providing Github support is a tooling question and support generally the ability for the community to engage. However, the question about who approves finally content changes proposed on github is in my opinion still open and need a better process.
> 
> 
> The outputs of this work include some real successes such as the consolidation of multiple disparate data sources into authors.ietf.org and wgchairs.ietf.org, the replacements of 100+ trac wikis with wiki.ietf.org and new guides drawn from the Tao and other sources. [2]
> 
> [MK] As you said , these are foremost  tooling changes and I welcome the effort to structure our tooling landscape more clearly. Because of the nature of these changes, these steps also let to consolidation of content which is a pragmatic approach in the current situation and also something we should do for the webpage content, mainly just in order to be able to establish a more well-process from there on. However, maintenance of the content of these sources in future needs a better approach.
> 
> 
> Looking forward, the IETF LLC would like to see a better defined community structure to oversee, contribute and engage on this topic and it has previously suggested that something like a content team could be formed to do that. But that is a community decision to make and not for the IETF LLC. 
> 
> [MK] I think this is a discussion we need to have within the leadership groups to then make a proposal to the community. I could even see it as a goal for the LLC to engage with leadership and the community to work on such a process. The maintenance of the content itself cannot be the goal.
> 
> 
>>> 5) Form: The IETF hoards old content and old data, long past the point of usefulness. -> To: A strategy in place for archiving and/or deletion of old content and data.
>> 
>> While I agree that we have a lack of a strategy to archive content, I find the "from" statement rather provocative and a bit ungrounded. First step here is to make an assessment about what is old and useless and again I don't think that sits in the responsibility of the LLC.
> 
> 
> There is significant evidence to support the "from" though I agree it should be worded better. For example, we keep old websites [3] [4] with no plan at all for why and how long, and some of it is clearly past the point of usefulness.
> 
> [MK] Yes, we have a lot of old data and content (that is an objective fact) and I'm very sure some of it is not useful anymore. However, that assessment of what is useful and what not, and what needs to be archived and what not has not been made and I don't think the LLC can make that assessment. Maybe LLC can propose assessment criteria or may to provide an assessment to  the leadership groups and community but the final decision does not sit with the LLC.
> 
> The IETF LLC is responsible for preserving all of this data and ensuring access to it, which comes with a non-trivial cost and effort, and so it seems quite reasonable for the IETF LLC, through the tools team, to be the one to try and manage this to ensure we meet community needs. There certainly doesn’t appear to be any other body that has either the time or inclination to do this. The IESG has two tools liaisons who are actively engaged in any such discussions.
> 
> [MK] Just because the responsibility body doesn't have "time or inclination" to do something does not mean that the LLC can take it over. However, I otherwise agree to what you wrote above. Managing old data and archiving it appropriately without clearly knowing the community needs is a problem for the LLC and I support a goal of the LLC to engage with the community and leadership about these needs and then develop a plan for content handling based on these needs. I'm just saying the "From" statement seems to imply that these needs are already known.
> 
> 
>>> 6) From: Community engagement on IETF LLC services is often based on opinion and personal perspective, not data or broader principles. -> To: Community engagements on IETF LLC services largely based on data and broader established principles.
>> 
>> On this point I have some guesses, but I actually don't understand this point really the way it is phrased. What does community engagement based on data mean? Doesn't that contradict each other. If you want community feedback it always about getting different view. If you want to base your decision on data, you don't need community input...?
> 
> 
> Perhaps "interpretation of data" might explain this better?
> 
> 
> This was much the same in the 2020 strategy and is close to being achieved, so it may be hard to remember that some years ago, much of the feedback we received was based solely on personal opinion whereas now it regularly considers (or requests) data and/or considers the broader principles. 
> 
> 
> I will propose to the board that this one can be removed given the progress made on it.
> 
> 
>>> 7) From: Current implementation of RFC 8718 (venue selection) guidance leads to a restricted choice of venues, difficult judgment calls and does not fairly distribute the pain. -> To: New implementation of RFC 8718 (and if necessary a -bis document) that provides more venue options, more fairly distributes the pain and reduces the difficult judgment calls.
>> 
>> How can there be a new and an old implementation of an RFC? I thought the idea of having a spec in an RFC is to guidance the implementation!? However, the text also talks about the bis and it is for sure not the role of the LLC to push changes to RFCs though the community process. As soon as anybody from the LLC (or leadership) writes a draft, that person should do that as an individual community member. If that person then edits a wg document, it does it on behave of the group reflecting the group consensus and not any goals of the LLC.
> 
> 
> All policies need an implementation that has all the operational details that are inappropriate for the policy, and this refers to the IETF LLC reviewing and changing its implementation. This has already been proposed [5] and a response to the consultation is to be discussed at the IETF LLC board meeting next week.
> 
> [MK] It is true that the current practice leads to restricted choice of venues, but it is not clear yet that this is actually a problem or maybe just what the community wants. I personally agree that I believe the community wants a change here but as long as we didn't establish consensus about that, the policy in the RFC remains binding to the LLC. I think there is a real problem for the LLC about finical implication about that and thereby resulting in judgement calls but that not what the transition says. Also, this point about distributing pain is of course part of the discussion but I don't think we have a good definition or agreement what it actually means, therefore I find it not very useful to mention it here.
> 
> 
> On the question of changes to the RFC - at the gendispatch session at IETF 116 Yokohama, the IETF LLC presented an I-D asking the community to consider some questions and provide guidance, presumably in the form of an RFC, to address these questions. In other words, maintaining that separation you are advocating for above. The feedback from this session was that the community wanted the IETF LLC to take the lead on this, which then led to a second version of the I-D [6] that takes this approach. This role for the IETF LLC was then explicitly checked at the genarea session at IETF 118 Prague and no objections were raised and it was noted in the report back to the community of that session [7] and again no objections were raised. 
> 
> [MK] I think the community wanted the LLC to take the lead on editing the draft that then can be used to establish community consensus. However, that doesn't guarantee (yet) that we will reach consensus on the proposed changes. I think the most confusing word is " necessary" because it seems to imply that just because the LLC thinks a change is necessary it will so happen. Let me be clear I think you are doing the right thing, but it is not correctly reflected by the wording of this transition.
> 
> 
>>> 8) From: RFC 8719 (geographic rotation) is too restrictive -> To: Less restrictive geographic rotation rules.
>> 
>> Again, I think we have a problem with our venue selection, however, we don't have establish consensus that RFC8719 is too restrictive, so I don't think it is correct to set this as a strategic goal overruling the community consensus. You can take the task of starting a community discussion on the rules in RFC8719 but you can't dictate the outcome.
> 
> 
> I agree, this is a community decision to make and so i will propose to the IETF LLC board that this is removed.
> 
> 
>>> 9) From: Little measurements and analysis of interims and their impact -> To: Better data on interims and how they are used, to inform the IESG
>> 
>> I don't think the "From" statement is for the LLC to make an assessment. Yes, you can support the IESG with data and in this specific case the IESG is discussing it and requested some data, however, the data providing part is already covered by other goals. I don't think there should be any specific to _impact_ of interim meeting in the LLC's strategic plan as assessing that is a responsibility of the IESG.
> 
> 
> As you have noted yourself, the "from" statement reflects a request from the IESG and it has been checked by the IETF Chair. There is nothing in this transformation that even suggests that the IETF LLC will be assessing impact, this is clearly just a data gathering excercise that is again included for transparency.
> 
> [MK] The transformation explicitly says "analysis of interims and their _impact_". I think it's great that you support the IESG in providing the needed data but the analysis of the impact needs to stay with the IESG.
> 
> 
>>> 10) From: Complex and difficult I-D authoring tools and technical process -> To: A simple to use and fully featured I-D authoring tool and simplified technical process.
>> 
>> What do you mean by "technical process" here?
> 
> 
> Validating, converting and submitting an I-D
> 
> [MK] Please spell that out. Thanks!
> 
> 
>> Also, the assessment that authoring tools are complex and different is unfounded.
> 
> 
>> I know there is an issue that people have barriers in editing their "first" draft, however, I don't know if your conclusion that tools are too complex is correct. I think there are many other barriers and many other ways to help first time authors. For long term authors I think we actually have a very good set of tools. That doesn't stop anybody from developing additional tools but the starting statement is not correct in my point of view.
> 
> 
> The 2021 survey of I-D authors [8] had "ease of use" has the highest importance/satisfaction gap of any characteristic of the authoring tools. Since then, while much progress has been made, this point has been discussed in many different fora, including iirc the IETF 118 Prague plenary, and the views expressed overwhelmingly agree with this assessment.
> 
> [MK] This survey does not say that there is satisfaction gap. The question solely asked what are important features and did not fully assess if these are provided by any of the existing tools. 
> 
> 
>>> 11) From: Low utility and low authority RFC Editor website -> To: High utility and high authority RFC Editor website
>> 
>> I think the responsibility for the RFC editor website clearly lies with the RFC editor and RPC. Yes, the LLC needs to support the RPC with tooling and funding but the goal as stated should not be a goal for the LLC.
> 
> 
> Similar to the discussion on websites and content above, there is a gap here, which you acknowledged during the RFC Editor Future discussions [9]. This was resolved as something for the IETF LLC and RPC to work together on, supported by the RSCE, and engage with the community on [10]. 
> 
> 
> A major project to revamp the website was well discussed in the RSWG [11] and this transformation sets the key goal, as discussed and agreed with the RPC, for that project. Including it here provides necessary transparency and ensures that the IETF LLC ensures that the RPC delivers this.
> 
> [MK] As you say yourself in [11]  the only specific role for the LLC here is to resource this project" that is not what the transition says. If you want to increase the transparency that the RPC/RFC Editor would need to publish their own strategic plan and add that goal. The absence of such a plan does not justify for the LLC to include it in their plan.
> 
> 
>>> 12) From: Significant external (outside of the IETF) misunderstanding of the status of RFCs (and I-Ds). -> To: Where it is important, external people understand the status of I-Ds and RFCs.
>> 
>> This very last point is in my few far overstepping the responsibility of the LLC. This is an issue that is not easy to fix and effectively the reason why we have the RFC editor model v3 and that's where the responsibility sits.
> 
> 
> As noted above, there has been a staff communications function for many years longer than the IETF LLC has been in existence, and this has been a long-standing goal for that function. This function is largely driven by IESG requirements and has a specific advisory group with IESG members and keeps the IESG well informed on its work. 
> 
> [MK] Which advisory group are you talking about? However, maybe we are not talking about the same thing which simply shows that the transition is phrased too generally and would need to be reworded. I think it is impossible to make people understand the status and e.g. stream implications of RFCs without changing what an RFC is and that's really not in the scope of the LLC. If you talk about improving our tooling to highlight the different states and streams better that is very welcome but again the requirement needs to come from the stream manager, RPC , or eventually RSWG and the LLC needs to implement it.
> 
> 
> 
> 
> thanks again for the feedback
> Jay
> 
> 
> 
> 
> [1] https://mailarchive.ietf.org/arch/msg/admin-discuss/xsdpMO2BYUjRbKUGb59zGagiw_U/ <https://mailarchive.ietf.org/arch/msg/admin-discuss/xsdpMO2BYUjRbKUGb59zGagiw_U/>
> [2] https://www.ietf.org/how/meetings/guide-ietf-meetings/ <https://www.ietf.org/how/meetings/guide-ietf-meetings/>
> [3] https://www6.ietf.org/ <https://www6.ietf.org/>
> [4] https://iaoc.ietf.org/ <https://iaoc.ietf.org/>
> [5] https://www.ietf.org/blog/proposed-response-to-meeting-venue-consultations-and-the-complex-issues-raised/ <https://www.ietf.org/blog/proposed-response-to-meeting-venue-consultations-and-the-complex-issues-raised/>
> [6] https://datatracker.ietf.org/doc/draft-daley-gendispatch-venue-requirements/ <https://datatracker.ietf.org/doc/draft-daley-gendispatch-venue-requirements/>
> [7] https://mailarchive.ietf.org/arch/msg/mtgvenue/Y-_o_ZKYNHIJy4GMCW5IsguGeXw/ <https://mailarchive.ietf.org/arch/msg/mtgvenue/Y-_o_ZKYNHIJy4GMCW5IsguGeXw/>
> [8] https://www.ietf.org/media/documents/REPORT__Survey_of_I-D_Authors_on_Formats_and_Tools.pdf <https://www.ietf.org/media/documents/REPORT__Survey_of_I-D_Authors_on_Formats_and_Tools.pdf> (page 13)
> [9] https://mailarchive.ietf.org/arch/msg/rfced-future/2JTjAgB1ciDeqwYkLwZcbKa3qfE/ <https://mailarchive.ietf.org/arch/msg/rfced-future/2JTjAgB1ciDeqwYkLwZcbKa3qfE/>
> [10] https://mailarchive.ietf.org/arch/msg/rfced-future/b76RoT8_jCFNQaYteNQgCd3xb0w/ <https://mailarchive.ietf.org/arch/msg/rfced-future/b76RoT8_jCFNQaYteNQgCd3xb0w/>
> [11] https://mailarchive.ietf.org/arch/msg/rswg/qivBngIXNfzgtTyAAmUsec-Q0w4/ <https://mailarchive.ietf.org/arch/msg/rswg/qivBngIXNfzgtTyAAmUsec-Q0w4/>
> 
> 
> -- 
> Jay Daley
> IETF Executive Director
> [e-mail] <mailto:[e-mail]>
> 
> 
>