Category: IETF

Oct 29

My First RFC – 7649 On "The Jabber Scribe Role at IETF Meetings"

Rfc7649 jabber scribe role 660px

Last month the first Request For Comments (RFC) was published where I was one of the co-authors. Ironically, this RFC 7649 had nothing to do with SIP, VoIP, telecom, IPv6, DNSSEC, security... or any of the other open Internet standards I've been working on in recent years!

In fact, it's not a "standard" at all but rather an "informational" document.

This document collects together a series of best practices for how someone can fill the role of the "jabber scribe" at IETF meetings, such as the IETF 94 meeting about to happen in Yokohama, Japan, starting this weekend. (Which I will not be attending due to scheduling challenges.) You can read RFC 7659 at:

http://tools.ietf.org/html/rfc7649

As the abstract states:

During IETF meetings, individual volunteers often help sessions run more smoothly by relaying information back and forth between the physical meeting room and an associated textual chatroom. Such volunteers are commonly called "Jabber scribes". This document summarizes experience with the Jabber scribe role and provides some suggestions for fulfilling the role at IETF meetings.

The document came about because over the years that I've been involved with the Internet Engineering Task Force (IETF) I've come to both value the critical role the "jabber scribe" can play - and I've also tried to do the best I can to perform that role when I'm in working group sessions at IETF meetings. I typically volunteer as a jabber scribe in any of the sessions I'm in and try to make the experience as good as possible for remote participants.

Largely my interest is because I spent many IETF meetings as a remote participant and I knew how poor that experience can be.

A few years ago after one of the IETF meetings, I made a comment to a couple of people that we ought to write down some of the suggestions and best practices so that people could easily get some ideas for how they could help out in the role. If they were new to the idea... or even if they had been around but were interested in doing the role better.

I kept track of some ideas ... and a small group of us kept occasionally bouncing ideas around... but none of us had the cycles to write the actual document.

Then last year at, I think, the Toronto IETF meeting in July, Peter St. Andre and I were talking about it again - and this time we actually got it off the ground! More precisely, Peter kicked it off and then he and I went through several rounds of revisions and comments.

Given that Peter's authored 35+ RFCs and countless Internet-Drafts (I-Ds), he knows the IETF process inside and out and so was able to guide the document through the publishing process, including having it move through the "independent submission" stream of RFC documents. I've written a number of Internet-Drafts over the years, but none have yet progressed to an RFC. I learned a great bit from Peter through the process and look forward to using that knowledge in the future.

I greatly appreciate Peter's leadership on this - and I hope that this document will be helpful to many folks out there who are helping involve more people remotely in the IETF's standards process.

Given the timezone difference with Japan, I'm not sure how many of the IETF 94 working group sessions I'll actually be able to attend remotely... but if I do, I'll be hoping that whomever is acting as the Jabber scribe will help include those of us who are remote.

Meanwhile, it is kind of fun to have my name on an RFC, even if it's an Informational one. I look forward to being able to play even more of a role in the IETF standards process in the years ahead...

Oct 29

Links To DNS / DNSSEC / DANE / DPRIVE Projects From IETF 93 Hackathon

With IETF 94 starting this weekend in Yokohama, Japan, I realized that I had not posted the results of the great work that the “DNS team” did at the IETF 93 Hackathon back in July in Prague.  Here’s a slideshow that outlines the results:

Slide 2 really shows the different aspects of “DNS security” that the team worked on:

Summary of DNS work at IETF 93 hackathon

Perhaps the more important fact was that we had actual code released publicly. Here were the releases:

And yes, this last one was a little experiment in playing with JSON and python that I did.

To our amazement, our DNS team (which grew from the time we first started talking about it) received the “Best in Show” award based on the judges’ view of what we did.  Here was a photo of some of the team and some of the judges (when the winners were announced some team members had already gone to other meetings):

DNS team at IETF 93 hackathon

There will be another “DNS team” at the IETF 94 Hackathon this weekend and while I won’t be there myself, I do hope they have a great time!

P.S. If you want to get started with DNSSEC and DANE yourself, please visit our Start Here page!

Jul 14

IETF 93 Hackathon July 18-19: DNSSEC, DANE, DPRIVE and DNS Security

IETF HackathonHow can we improve the tools and services that use DNSSEC or DANE?  How can we make DNS more secure and private? (And, why spend a beautiful weekend exploring Prague when we could be inside a hotel conference room working on code???) For a number of us, we’re going to be spending this coming weekend, July 18-19, looking to answer those questions through writing code and changing/updating software as part of the IETF 93 Hackathon.  More info is at:

https://www.ietf.org/hackathon/93-hackathon.html

As IETF Chair Jari Arkko wrote about on the IETF blog, these hackathons are a way to bring “running code” back into the IETF meetings – and also just a great way to advance the deployment and usage of IETF protocols.  They are also just a fantastic way to strengthen the relationships between members of the IETF community.

I’ll be there as one of the “champions” of DNSSEC / DANE / DPRIVE (DNS confidentiality/privacy) along with Allison Mankin, Benno Overeinder, Sara Dickinson and Daniel Kahn Gillmor.  A number of others from within the DNS community have also signed up to join in to the effort – and we’re hoping to attract some of the other participants as well.

On the wiki page listing the technologies, we wrote this for some of the ideas:

 

  • Contribute to access of end-systems to new developments in DNS
  • Protocols: DANE support for webmail, DNS-over-TLS (application uses), DNS-over-DTLS (stack and uses), TLSA client certs, client privacy election for EDNS client-subnet, getdns language bindings, etc.
  • Tools: portable tool for creating and adding DANE RR’s to zones, changes to existing tools to support new crypto algorithms, etc.
  • Measurement: New tools or sites for measuring DNSSEC or DANE deployment

 

We’ve had some other ideas, too… we’ll see what we come up with!  (And you’re welcome to send me your ideas for tools you’d like to see!)  I’m personally interested in expanding some of the metrics… and I’m also interested in anything that expands the usage or support of the ECDSA algorithm (I’m thinking more about … what interfaces could be extended to add ECDSA support?)

I’ll post a report back here on the site once the hackathon is over.  If you are going to be at the Hackathon at IETF 93, please do consider joining with us!

P.S. And if you want to get started with DNSSEC and DANE, please see our Start Here page!

Apr 01

RFC 7511 – Scenic Routing for IPv6

IETF LogoCarrying on a grand old April 1 tradition, the IETF today released RFC 7511, Scenic Routing for IPv6. Given the amount of attention in the industry to environmentally-friendly “Green IT”, this RFC aims to help all the poor IPv6 packets that are trapped inside of wires and cables… and instead gives those packets some fresh air!

https://tools.ietf.org/html/rfc7511

Yes, indeed, this new RFC 7511 recommends that packets travel using the RFC 1149 method: “A Standard for the Transmission of IP Datagrams on Avian Carriers“.  Either that or over wireless networks… some way that those poor, deprived packets can see some sunlight! :-)

I did enjoy the little dig at IPv4:

As of the widely known acceptance of the current version of the
Internet Protocol (IPv6), this document only focuses on version 6 and
ignores communication still based on Vintage IP.

Anyway… in the spirit of the day, you may enjoy RFC 7511.

We’ll be back at you tomorrow, when people may actually take things we write more seriously!

Happy April Fools Day!

Mar 27

Deploy360@IETF92, Day 5: EPPEXT… and we’re done!

Face of IETFOn this  final day of IETF 92 our Deploy360 attention will be focused on only one working group, EPPEXT, that is looking at communication between registries, registrars and other entities working with domain names.   There only two blocks of working group sessions today… and then everyone heads home!  Here’s what this abbreviated day looks like for us…

NOTE: If you are unable to attend IETF 92 in person, there are multiple ways to participate remotely.

The sessions in the first 0900-1130 CDT block are not ones that we typically follow.  I may be monitoring CORE, as it deals with Internet of Things (IoT) issues, or perhaps MMUSIC as there is a draft dealing with IPv4 vs IPv6 connectivity.

Finally, in the very last 1150-1320 session, the Extensible Provisioning Protocol Extensions (EPPEXT) working group will be meeting in the Oak Room.  I mentioned EPPEXT in my Rough Guide to IETF 92 post but at the time the agenda was not available.  The IETF 92 agenda is now available, and it includes:

One of the existing documents of interest to us is one that helps with the automation of relaying DNSSEC key material between DNS operators.  We’re also just interested in general with steps that can help automate the communication among these various entities.

And then… with that… IETF 92 will draw to a close!

Many thanks for reading along this week… please do read our other IETF 92-related posts … and we’ll see you at IETF 93 in Prague in July!

Relevant Working Groups:

For more background on what is happening at IETF 92, please see our “Rough Guide to IETF 92″ posts on the ITM blog:

If you are at IETF 92 in Dallas, please do feel free to say hello to our Chris Grundemann. And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.

Image: some of the faces and scenes appearing in Olaf Kolkman’s collection of IETF 92 photos. Used with his permission.

Mar 27

Deploy360@IETF92, Day 5: EPPEXT… and we’re done!

Face of IETFOn this  final day of IETF 92 our Deploy360 attention will be focused on only one working group, EPPEXT, that is looking at communication between registries, registrars and other entities working with domain names.   There only two blocks of working group sessions today… and then everyone heads home!  Here’s what this abbreviated day looks like for us…

NOTE: If you are unable to attend IETF 92 in person, there are multiple ways to participate remotely.

The sessions in the first 0900-1130 CDT block are not ones that we typically follow.  I may be monitoring CORE, as it deals with Internet of Things (IoT) issues, or perhaps MMUSIC as there is a draft dealing with IPv4 vs IPv6 connectivity.

Finally, in the very last 1150-1320 session, the Extensible Provisioning Protocol Extensions (EPPEXT) working group will be meeting in the Oak Room.  I mentioned EPPEXT in my Rough Guide to IETF 92 post but at the time the agenda was not available.  The IETF 92 agenda is now available, and it includes:

One of the existing documents of interest to us is one that helps with the automation of relaying DNSSEC key material between DNS operators.  We’re also just interested in general with steps that can help automate the communication among these various entities.

And then… with that… IETF 92 will draw to a close!

Many thanks for reading along this week… please do read our other IETF 92-related posts … and we’ll see you at IETF 93 in Prague in July!

Relevant Working Groups:

For more background on what is happening at IETF 92, please see our “Rough Guide to IETF 92″ posts on the ITM blog:

If you are at IETF 92 in Dallas, please do feel free to say hello to our Chris Grundemann. And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.

Image: some of the faces and scenes appearing in Olaf Kolkman’s collection of IETF 92 photos. Used with his permission.

The post Deploy360@IETF92, Day 5: EPPEXT… and we’re done! appeared first on Internet Society.

Mar 26

Deploy360@IETF92, Day 4: More IPv6 Operations, TLS, and much Security

IETF 92 - Kathleen MoriartyThis  fourth day of IETF 92 has a heavy focus on security for us on the Deploy360 team.  While the day starts with the second of two IPv6 Operations (v6OPS) working group sessions, the rest of the day is pretty much all about security, security, security!

NOTE: If you are unable to attend IETF 92 in person, there are multiple ways to participate remotely.

In the 0900-1130 CDT block this morning, the second IPv6 Operations (v6OPS) sessions continues with their busy agenda in the Gold Room. Here are today’s topics:

A number of those should generate good discussion.

Meanwhile, over in the Oak Room, the TLS Working Group will be discussing improvements to this incredibly critical protocol that we are using to encrypt so many different communications over the Internet.  As my colleague Karen O’Donahue wrote:

The tls (Transport Layer Security) working group is actively working on an update to the TLS protocol. They recently conducted an interim meeting in Seattle, WA, on 10-11 March 2015. Agenda items for IETF 92 include backwards compatibility, rekeying, and client authentication.

After lunch the 1300-1500 CDT block has the Security Area Open Meeting in the International Room. The current agenda is this:

  • Joe Bonneau/HSTS and HPKP in practice (30 mins)
  • Adam Langley/QUIC (15 mins)
  • Jan Včelák/NSEC5 (10 mins)
  • Ladar Levinson/Darkmail (20 mins)
  • Paul Wouters/Opportunistic IPsec update (1 minute)
  • Eric Rescorla/Secure Conferencing (5 mins)

Several of these presentations tie directly into the work we are doing here.  The HSTS/HPKP is “certificate pinning” and very relevant to TLS, as is the QUIC presentation.  The NSEC5 is a new proposal for DNSSEC that, judging by the mailing list traffic, should get strong debate.

The 1520-1720 CDT block doesn’t contain any of the working groups we usually track, but there will be both a Routing Area Open Meeting as well as an Operations Area Open Meeting.

In the final 1740-1840 CDT block the Operational Security (OPSec) Working Group will be meeting in the Far East Room with a number of IPv6 and routing issues on their agenda.

Bits-and-Bites

The day will end with the Bits-and-Bites reception from 1900-2100 CDT  where attendees can get food and drink and also see various exhibits from sponsors and other organizations.  As I wrote in my Rough Guide post:

 I’m told that one table will be from Verisign Labs where they will be showing demonstrations of the getdns API being used with DNSSEC and DANE.  I’m not exactly sure what will be there, but if you are going to Bits-and-Bites you may want to stop by their table and see what it is about.

I understand there may be some cool demos from other vendors and groups as well. (I’m looking forward to seeing photos!)

For some more background, please read these Rough Guide posts from Andrei, Phil and Karen:

Relevant Working Groups:

For more background on what is happening at IETF 92, please see our “Rough Guide to IETF 92″ posts on the ITM blog:

If you are at IETF 92 in Dallas, please do feel free to say hello to our Chris Grundemann. And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.

Image: a photo from Jari Arkko of Kathleen Moriarty and Lisandro Granville at the IETF 92 Administrative Plenary

Mar 26

Deploy360@IETF92, Day 4: More IPv6 Operations, TLS, and much Security

IETF 92 - Kathleen MoriartyThis  fourth day of IETF 92 has a heavy focus on security for us on the Deploy360 team.  While the day starts with the second of two IPv6 Operations (v6OPS) working group sessions, the rest of the day is pretty much all about security, security, security!

NOTE: If you are unable to attend IETF 92 in person, there are multiple ways to participate remotely.

In the 0900-1130 CDT block this morning, the second IPv6 Operations (v6OPS) sessions continues with their busy agenda in the Gold Room. Here are today’s topics:

A number of those should generate good discussion.

Meanwhile, over in the Oak Room, the TLS Working Group will be discussing improvements to this incredibly critical protocol that we are using to encrypt so many different communications over the Internet.  As my colleague Karen O’Donahue wrote:

The tls (Transport Layer Security) working group is actively working on an update to the TLS protocol. They recently conducted an interim meeting in Seattle, WA, on 10-11 March 2015. Agenda items for IETF 92 include backwards compatibility, rekeying, and client authentication.

After lunch the 1300-1500 CDT block has the Security Area Open Meeting in the International Room. The current agenda is this:

  • Joe Bonneau/HSTS and HPKP in practice (30 mins)
  • Adam Langley/QUIC (15 mins)
  • Jan Včelák/NSEC5 (10 mins)
  • Ladar Levinson/Darkmail (20 mins)
  • Paul Wouters/Opportunistic IPsec update (1 minute)
  • Eric Rescorla/Secure Conferencing (5 mins)

Several of these presentations tie directly into the work we are doing here.  The HSTS/HPKP is “certificate pinning” and very relevant to TLS, as is the QUIC presentation.  The NSEC5 is a new proposal for DNSSEC that, judging by the mailing list traffic, should get strong debate.

The 1520-1720 CDT block doesn’t contain any of the working groups we usually track, but there will be both a Routing Area Open Meeting as well as an Operations Area Open Meeting.

In the final 1740-1840 CDT block the Operational Security (OPSec) Working Group will be meeting in the Far East Room with a number of IPv6 and routing issues on their agenda.

Bits-and-Bites

The day will end with the Bits-and-Bites reception from 1900-2100 CDT  where attendees can get food and drink and also see various exhibits from sponsors and other organizations.  As I wrote in my Rough Guide post:

 I’m told that one table will be from Verisign Labs where they will be showing demonstrations of the getdns API being used with DNSSEC and DANE.  I’m not exactly sure what will be there, but if you are going to Bits-and-Bites you may want to stop by their table and see what it is about.

I understand there may be some cool demos from other vendors and groups as well. (I’m looking forward to seeing photos!)

For some more background, please read these Rough Guide posts from Andrei, Phil and Karen:

Relevant Working Groups:

For more background on what is happening at IETF 92, please see our “Rough Guide to IETF 92″ posts on the ITM blog:

If you are at IETF 92 in Dallas, please do feel free to say hello to our Chris Grundemann. And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.

Image: a photo from Jari Arkko of Kathleen Moriarty and Lisandro Granville at the IETF 92 Administrative Plenary

The post Deploy360@IETF92, Day 4: More IPv6 Operations, TLS, and much Security appeared first on Internet Society.

Mar 25

Deploy360@IETF92, Day 3: IPv6 Operations, Sunset4, ACME and Global Internet Routing (GROW)

Jen Linkova at IETF 92Today’s third day of IETF 92 turns out to be a quieter one for the topics we cover here on Deploy360.  The big activity will be in the first of two IPv6 Operations (v6OPS) working group sessions.  There will also be a reboot of the SUNSET4 working group and what should be an interesting discussion about “route leaks” in the GROW working group.  Here’s what our day looks like…

NOTE: If you are unable to attend IETF 92 in person, there are multiple ways to participate remotely.

In the 0900-1130 CDT block this morning, we’re not actively tracking any of the listed working groups as they don’t tie directly into our Deploy360 topics. However the BESS session about BGP-enabled services could be interesting, as could the SPUD BOF looking at what are barriers to implementing new transport protocols on the Internet (more info in the SPUD overview presentation).

After lunch from 1300-1500 CDT in the International Room will be the first of two IPv6 Operations (v6OPS) sessions (the second being tomorrow) with a packed agenda looking at design choices for IPv6 networks, IPv6 deployment case studies / lessons learned and more.  As IPv6 deployment continues to grow month over month, incorporating feedback from that deployment process back into the standards process is an essential part of ensuring continued growth.

In the 1520-1620 CDT block over in the Gold Room, the IPv6 discussion will continue in the SUNSET4 working group that is chartered to document and explore how well things will work in an IPv6-only environment when IPv4 is no longer available (i.e. IPv4 has “sunsetted”).  As noted in the SUNSET4 agenda, the working group has had a loss of momentum and will be looking today at how to restart efforts to move work items along.

Simultaneously over in the Parisian Room the Global Routing Operations (GROW) working group will be looking at how to improve the operations of the Internet’s global routing infrastructure.  As my colleague Andrei Robachevsky wrote in his Rough Guide to IETF 92 post:

In general, the focus of the GROW WG is on operational problems associated with the global routing system, such as routing table growth, the effects of interactions between interior and exterior routing protocols, and the effect of operational policies and practices on the global routing system, its security and resilience.

One of these items, which originally emerged in the SIDR WG and is now being discussed in the GROW WG, is so-called “route-leaks.” Simply speaking, this describes a violation of “valley-free” routing when, for example, a multi-homed customer “leaks” an announcement from one upstream provider to another one. Since usually customer announcements have the highest priority, if no precautions are taken this results in traffic from one provider to another bypassing the customer – potential for a staged MITM attack. But this is an explanation in layman terms, and the group was working on nailing down the definition and the problem statement, see https://datatracker.ietf.org/doc/draft-ietf-grow-route-leak-problem-definition/.

This issue of “route leaks” is one that comes up repeatedly and is causing problems on the global Internet. For instance, yesterday DynResearch tweeted about a route hijack of Google’s site by Belarus Telecom – now I don’t know if that was an actual “route leak”, but it’s the kind of routing issue we do see often on the Internet… which is why this class of issues needs to be identified and solutions proposed.

And just because we really want to be in three places at once… over in the Venetian Room during this same 1520-1620 time block will be the “Automated Certificate Management Environment (ACME)” BOF looking at ways to automate management of TLS certificates. As the agenda indicates, the session is primarily about discussing draft-barnes-acme and the efforts being undertaken as part of the Let’s Encrypt initiative.  The ideas are intriguing and proposals that help automate the security of the Internet can certainly help reduce the friction for regular users.

After all of that is over we’ll be joining in for the Operations and Administrative Plenary from 1640-1910 CDT.  You can view a live video stream of the plenary at http://www.ietf.org/live/    And then… we’ll be getting ready for Day 4…

For some more background, please read these Rough Guide posts from Andrei, Phil and I:

Relevant Working Groups:

For more background on what is happening at IETF 92, please see our “Rough Guide to IETF 92″ posts on the ITM blog:

If you are at IETF 92 in Dallas, please do feel free to say hello to our Chris Grundemann. And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.

Image: a photo by Olaf Kolkman of Jen Linkova at IETF 92. Part of a larger set of IETF 92 photos Olaf has published.

The post Deploy360@IETF92, Day 3: IPv6 Operations, Sunset4, ACME and Global Internet Routing (GROW) appeared first on Internet Society.

Mar 25

Deploy360@IETF92, Day 3: IPv6 Operations, Sunset4, ACME and Global Internet Routing (GROW)

Jen Linkova at IETF 92Today’s third day of IETF 92 turns out to be a quieter one for the topics we cover here on Deploy360.  The big activity will be in the first of two IPv6 Operations (v6OPS) working group sessions.  There will also be a reboot of the SUNSET4 working group and what should be an interesting discussion about “route leaks” in the GROW working group.  Here’s what our day looks like…

NOTE: If you are unable to attend IETF 92 in person, there are multiple ways to participate remotely.

In the 0900-1130 CDT block this morning, we’re not actively tracking any of the listed working groups as they don’t tie directly into our Deploy360 topics. However the BESS session about BGP-enabled services could be interesting, as could the SPUD BOF looking at what are barriers to implementing new transport protocols on the Internet (more info in the SPUD overview presentation).

After lunch from 1300-1500 CDT in the International Room will be the first of two IPv6 Operations (v6OPS) sessions (the second being tomorrow) with a packed agenda looking at design choices for IPv6 networks, IPv6 deployment case studies / lessons learned and more.  As IPv6 deployment continues to grow month over month, incorporating feedback from that deployment process back into the standards process is an essential part of ensuring continued growth.

In the 1520-1620 CDT block over in the Gold Room, the IPv6 discussion will continue in the SUNSET4 working group that is chartered to document and explore how well things will work in an IPv6-only environment when IPv4 is no longer available (i.e. IPv4 has “sunsetted”).  As noted in the SUNSET4 agenda, the working group has had a loss of momentum and will be looking today at how to restart efforts to move work items along.

Simultaneously over in the Parisian Room the Global Routing Operations (GROW) working group will be looking at how to improve the operations of the Internet’s global routing infrastructure.  As my colleague Andrei Robachevsky wrote in his Rough Guide to IETF 92 post:

In general, the focus of the GROW WG is on operational problems associated with the global routing system, such as routing table growth, the effects of interactions between interior and exterior routing protocols, and the effect of operational policies and practices on the global routing system, its security and resilience.

One of these items, which originally emerged in the SIDR WG and is now being discussed in the GROW WG, is so-called “route-leaks.” Simply speaking, this describes a violation of “valley-free” routing when, for example, a multi-homed customer “leaks” an announcement from one upstream provider to another one. Since usually customer announcements have the highest priority, if no precautions are taken this results in traffic from one provider to another bypassing the customer – potential for a staged MITM attack. But this is an explanation in layman terms, and the group was working on nailing down the definition and the problem statement, see https://datatracker.ietf.org/doc/draft-ietf-grow-route-leak-problem-definition/.

This issue of “route leaks” is one that comes up repeatedly and is causing problems on the global Internet. For instance, yesterday DynResearch tweeted about a route hijack of Google’s site by Belarus Telecom – now I don’t know if that was an actual “route leak”, but it’s the kind of routing issue we do see often on the Internet… which is why this class of issues needs to be identified and solutions proposed.

And just because we really want to be in three places at once… over in the Venetian Room during this same 1520-1620 time block will be the “Automated Certificate Management Environment (ACME)” BOF looking at ways to automate management of TLS certificates. As the agenda indicates, the session is primarily about discussing draft-barnes-acme and the efforts being undertaken as part of the Let’s Encrypt initiative.  The ideas are intriguing and proposals that help automate the security of the Internet can certainly help reduce the friction for regular users.

After all of that is over we’ll be joining in for the Operations and Administrative Plenary from 1640-1910 CDT.  You can view a live video stream of the plenary at http://www.ietf.org/live/    And then… we’ll be getting ready for Day 4…

For some more background, please read these Rough Guide posts from Andrei, Phil and I:

Relevant Working Groups:

For more background on what is happening at IETF 92, please see our “Rough Guide to IETF 92″ posts on the ITM blog:

If you are at IETF 92 in Dallas, please do feel free to say hello to our Chris Grundemann. And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.

Image: a photo by Olaf Kolkman of Jen Linkova at IETF 92. Part of a larger set of IETF 92 photos Olaf has published.