rfc8719xml2.original.xml   rfc8719.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="bcp" conse
nsus="true" docName="draft-ietf-mtgvenue-meeting-policy-07" indexInclude="true"
<!ENTITY RFC4071 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC ipr="trust200902" number="8719" prepTime="2020-02-26T17:09:59" scripts="Common,L
.4071.xml"> atin" seriesNo="226" sortRefs="true" submissionType="IETF" symRefs="true" tocDep
<!ENTITY I-D.ietf-mtgvenue-iaoc-venue-selection-process SYSTEM "http://xml.resou th="4" tocInclude="true" xml:lang="en">
rce.org/public/rfc/bibxml3/reference.I-D.ietf-mtgvenue-iaoc-venue-selection-proc <link href="https://datatracker.ietf.org/doc/draft-ietf-mtgvenue-meeting-polic
ess.xml"> y-07" rel="prev"/>
]> <link href="https://dx.doi.org/10.17487/rfc8719" rel="alternate"/>
<link href="urn:issn:2070-1721" rel="alternate"/>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="bcp" docName="draft-ietf-mtgvenue-meeting-policy-07" ipr="trust20
0902">
<front> <front>
<title abbrev="IETF Meeting Policy">High-Level Guidance for the Meeting Poli
<title abbrev="IETF Meeting Policy">High level guidance for the meeting poli cy of the IETF</title>
cy of the IETF</title> <seriesInfo name="RFC" value="8719" stream="IETF"/>
<seriesInfo name="BCP" value="226" stream="IETF"/>
<author fullname="Suresh Krishnan" initials="S." <author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
surname="Krishnan"> <organization showOnFrontPage="true">Kaloom</organization>
<organization>Kaloom</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city/>
<city></city> <region/>
<code/>
<region></region> <country/>
<code></code>
<country></country>
</postal> </postal>
<email>suresh@kaloom.com</email> <email>suresh@kaloom.com</email>
</address> </address>
</author> </author>
<date month="02" year="2020"/>
<date/>
<area>General</area> <area>General</area>
<workgroup>Meeting Venue Working Group</workgroup>
<workgroup>Internet Engineering Task Force</workgroup> <keyword>geographic distribution location</keyword>
<keyword>IASA</keyword>
<abstract> <abstract pn="section-abstract">
<t>This document describes a meeting location policy for the IETF and the <t pn="section-abstract-1">This document describes a meeting location poli
various stakeholders for realizing such a policy.</t> cy for the IETF and
the various stakeholders required to realize this policy.</t>
</abstract> </abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t pn="section-boilerplate.1-1">
This memo documents an Internet Best Current Practice.
</t>
<t pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further information
on BCPs is available in Section 2 of RFC 7841.
</t>
<t pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8719" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t pn="section-boilerplate.2-1">
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent
="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-introduction">Introductio
n</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent
="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-the-1-1-1-meeting-policy"
>The 1-1-1-* Meeting Policy</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent
="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-implementation-of-the-pol
ic">Implementation of the Policy</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent
="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-procedure-for-initiating-
pr">Procedure for Initiating Proposals for Exploratory Meetings</xref></t>
</li>
<li pn="section-toc.1-1.5">
<t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent
="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-re-evaluation-and-changes
-t">Re-evaluation and Changes to This Policy</xref></t>
</li>
<li pn="section-toc.1-1.6">
<t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent
="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-references">References</x
ref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t keepWithNext="true" pn="section-toc.1-1.6.2.1.1"><xref derive
dContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-normative-ref
erences">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t keepWithNext="true" pn="section-toc.1-1.6.2.2.1"><xref derive
dContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-informative-r
eferences">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent
="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedC
ontent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknow
ledgments</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent
="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedC
ontent="" format="title" sectionFormat="of" target="name-authors-address">Author
's Address</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section numbered="true" toc="include" removeInRFC="false" pn="section-1">
<section title="Introduction"> <name slugifiedName="name-introduction">Introduction</name>
<t pn="section-1-1">
<t> The work of the IETF is primarily conducted on working group (WG)
The work of the IETF is primarily conducted on the working group mailing lists, while face-to-face WG meetings mainly provide a high-bandwidth
mailing lists, while face-to-face WG meetings mainly provide a high mechanism for working out unresolved issues. The IETF
bandwidth mechanism for working out unresolved issues. The IETF
currently strives to have a 1-1-1 meeting policy currently strives to have a 1-1-1 meeting policy
<xref target="IETFMEET"/> where the goal is to distribute the meetings where the goal is to distribute the meetings equally between North America,
equally between North America, Europe, and Asia. These are the locations Europe, and Asia (see "Meeting Location Distribution" (slides 14 and 15) of
most of the IETF participants have come from in the recent past. This <xref target="IETFMEET" format="default" sectionFormat="of" derivedContent="IETF
meeting rotation is mainly aimed at distributing the travel effort for MEET"/> for details). These are the
locations from which most of the IETF participants have come in the recent past.
This meeting rotation is mainly aimed at distributing the travel effort for
the existing IETF participants who physically attend meetings and for the existing IETF participants who physically attend meetings and for
distributing the timezone difficulty for those who participate remotely. distributing the timezone difficulty for those who participate remotely.
This policy has neither been defined precisely nor documented in an This policy has been neither defined precisely nor documented in an
IETF consensus document until now. This document is meant to serve as a consensu IETF consensus document until now. This BCP RFC is meant to serve as a
s-backed statement of this policy published as a BCP. consensus-backed statement of this policy.
</t> </t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2">
<section title="The 1-1-1-* meeting policy"> <name slugifiedName="name-the-1-1-1-meeting-policy">The 1-1-1-* Meeting Po
<t>Given that the majority of the current participants come from licy</name>
North America, Europe, and Asia <xref target="CONT-DIST"/>, the <t pn="section-2-1">Given that the majority of the current meeting partici
IETF policy is that our meetings should primarily be in those pants come from
regions. i.e., the meeting policy (let's call this the "1-1-1" North America, Europe, and Asia <xref target="CONT-DIST" format="default" sec
tionFormat="of" derivedContent="CONT-DIST"/>, the
IETF policy is that the meetings should primarily be held in those
regions. That is, the meeting policy (let's call this the "1-1-1"
policy) is that meetings should rotate between North America, policy) is that meetings should rotate between North America,
Europe, and Asia. Please note that the boundaries between those Europe, and Asia. Note that the boundaries between those
regions has been purposefully left undefined. It regions have been purposefully left undefined. It
is important to note that such rotation and any effects to is important to note that such rotation and any effects to
distributing travel pain should be considered from a long-term distributing travel pain should be considered from a long-term
perspective. While a potential cycle in an IETF year may be a perspective. While a potential cycle in an IETF year may be a
meeting in North America in March, a meeting in Europe in July, and meeting in North America in March, a meeting in Europe in July, and
a meeting in Asia on November, the 1-1-1 policy does not imply a meeting in Asia on November, the 1-1-1 policy does not imply
such a cycle, as long as the distribution to these regions over such a cycle, as long as the distribution to these regions over
multiple years is roughly equal. There are many reasons why meetings multiple years is roughly equal. There are many reasons why meetings
might be distributed differently in a given year. Meeting locations in subseq might be distributed differently in a given year. Meeting locations in
uent years should seek to re-balance the distribution if possible.</t> subsequent years should seek to rebalance the distribution, if
possible.</t>
<t>While this meeting rotation caters to the current set of IETF <t pn="section-2-2">While this meeting rotation caters to the current set
of IETF
participants, it is important to recognize that due to the dynamic and participants, it is important to recognize that due to the dynamic and
evolving nature of participation, there may be significant changes evolving nature of participation, there may be significant changes
to the regions that provide a major share of participants in the to the regions that provide a major share of participants in the
future. The 1-1-1-* meeting policy is a slightly modified version future. Therefore, the 1-1-1-* meeting policy is a slightly modified version
of the aforementioned 1-1-1 meeting policy that allows for of the aforementioned 1-1-1 meeting policy that allows for
additional flexibility in the form of an exploratory meeting denoted as additional flexibility in the form of an exploratory meeting (denoted with
a "*". This exploratory meeting can be used to experiment with an "*"). Exploratory meetings can be used to experiment with
exceptional meetings without extensively impacting the regular exceptional meetings without extensively impacting the regular
meetings. e.g. these exploratory meetings can include meetings in meetings. For example, these exploratory meetings can include meetings in
other geographical regions, virtual meetings and additional other geographical regions, virtual meetings, and additional
meetings past the three regular meetings in a calendar year. meetings beyond the three regular meetings in a calendar year.
</t> </t>
<t> <t pn="section-2-3">
The timing and frequency of future exploratory meetings will be based The timing and frequency of future exploratory meetings will be based
on IETF consensus as determined by the IETF chair. Once a meeting on IETF consensus as determined by the IETF chair. Once a meeting
proposal is initiated, the IESG will make a decision in consultation with proposal is initiated, the IESG will make a decision in consultation with
the Internet Administrative Support Activity (IASA) to ensure that the the IETF Administrative Support Activity (IASA) <xref target="RFC8711" format=
proposal can be realistically implemented. The final decision will be communic "default" sectionFormat="of" derivedContent="RFC8711"/> to ensure that the propo
ated back to the sal can be realistically
implemented. The final decision will be communicated back to the
community to ensure that there is adequate opportunity to comment. community to ensure that there is adequate opportunity to comment.
</t> </t>
<t>NOTE: There have not been a large number of meetings that would <aside pn="section-2-4">
qualify as exploratory meetings under the current 1-1-1-* policy (with <t pn="section-2-4.1">NOTE: There have not been a large number of meetin
IETF95 in Buenos Aires and IETF47 in Adelaide being the exceptional gs that would
instances). IETF27 (Amsterdam) and IETF54(Yokohama) were earlier qualify as exploratory meetings under the 1-1-1 policy (with
IETF 95 in Buenos Aires and IETF 47 in Adelaide being the exceptional
instances). IETF 27 (Amsterdam) and IETF 54 (Yokohama) were earlier
examples of exploratory meetings that pioneered Europe and Asia as examples of exploratory meetings that pioneered Europe and Asia as
regular IETF destinations.</t> regular IETF destinations.</t>
</section> </aside>
</section>
<section title="Implementation of the policy"> <section numbered="true" toc="include" removeInRFC="false" pn="section-3">
<t>IASA should understand the policy written in this document to be the aspir <name slugifiedName="name-implementation-of-the-polic">Implementation of t
ation of the IETF community. Similarly, any he Policy</name>
<t pn="section-3-1">IASA should understand the policy
written in this document to be the aspiration of the IETF community. Simil
arly, any
exploratory meeting decisions will also be communicated to the IASA to exploratory meeting decisions will also be communicated to the IASA to
be implemented. The actual selection of the venue would be be implemented. The actual selection of the venue would be
performed by the IASA following the process described in <xref performed by the IASA following the process described in <xref target="RFC871
target="I-D.ietf-mtgvenue-iaoc-venue-selection-process"/>. 8" format="default" sectionFormat="of" derivedContent="RFC8718"/>.
</t> </t>
<t>As mentioned in <xref <t pn="section-3-2">As mentioned in <xref target="RFC8718" format="default
target="I-D.ietf-mtgvenue-iaoc-venue-selection-process"/>, the IASA will also " sectionFormat="of" derivedContent="RFC8718"/>, the IASA will also be responsib
be responsible le for the following:
<list style="symbols"> </t>
<t>to assist the community in the development of detailed meeting <ul spacing="normal" bare="false" empty="false" pn="section-3-3">
criteria that are feasible and implementable, and </t> <li pn="section-3-3.1">assisting the community in the development of det
<t>to provide sufficient transparency in a timely manner ailed meeting
criteria that are feasible and implementable, and </li>
<li pn="section-3-3.2">providing sufficient transparency in a timely man
ner
concerning planned meetings so that community feedback can be concerning planned meetings so that community feedback can be
collected and acted upon.</t> collected and acted upon.</li>
</list> </ul>
</t> <t pn="section-3-4">Given that the geographical location of the venue has
<t>Given that the geographical location of the venue has a a
significant influence on the venue selection process, it needs to significant influence on the venue selection process, it needs to
be considered at the same level as the other Important Criteria be considered at the same level as the other Important Criteria
specified in Section 3.2 of specified in <xref target="RFC8718" sectionFormat="of" section="3.2" format="
<xref default" derivedLink="https://rfc-editor.org/rfc/rfc8718#section-3.2" derivedCon
target="I-D.ietf-mtgvenue-iaoc-venue-selection-process"/> (including tent="RFC8718"/> (including
potentially trading off the geographical region to meet other potentially trading-off the geographical region to meet other
criteria, and notifying the community if the geographical region criteria and notifying the community if the geographical region
requirement cannot be met)</t> requirement cannot be met).</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-4">
<section title="Procedure for initiating proposals for exploratory meetings" <name slugifiedName="name-procedure-for-initiating-pr">Procedure for Initi
> ating Proposals for Exploratory Meetings</name>
<t>Someone who is interested in pursuing an exploratory venue <t pn="section-4-1">Someone who is interested in pursuing an exploratory v
enue
proposes it on the IETF discussion list or on a future proposes it on the IETF discussion list or on a future
discussion list expressly setup and announced for this discussion list expressly set up and announced for this
purpose. The community gets to comment on the venue and to offer purpose. The community gets to comment on the venue and offer
their opinions. If the IETF chair determines that there is their opinions. If the IETF chair determines that there is
community consensus to pursue the venue further, the venue will community consensus to pursue the venue further, the venue will
be put up for discussion on the venue-selection mailing be put up for discussion on the venue-selection mailing
list. This would allow the interested party(ies) to refine their list &lt;<eref target="https://www.ietf.org/mailman/listinfo/venue-selecti
proposal with those tasked with evaluating it and providing on" brackets="none"/>&gt;.
further insightful feedback regarding the logistics of the This would allow the interested party(ies) to refine their proposal
venue. Once the venue selection process takes place, the final based on insightful feedback regarding the logistics of the venue
decision will be communicated back to the community to ensure from those tasked with evaluating it. Once the venue selection process
that there is adequate opportunity to comment.</t> takes place, the final decision will be communicated back to the
community to ensure that there is adequate opportunity to comment.
</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5">
<section title="Re-evaluation and changes to this policy"> <name slugifiedName="name-re-evaluation-and-changes-t">Re-evaluation and C
<t> Given the dynamic nature of participant distribution in the hanges to This Policy</name>
IETF, it is expected that this policy needs to be periodically <t pn="section-5-1">Given the dynamic nature of participant distribution i
n the
IETF, it is expected that this policy will need to be periodically
evaluated and revised to ensure that the stated goals continue evaluated and revised to ensure that the stated goals continue
to be met. to be met. The criteria that are to be met need to be agreed upon by the
The criteria that are to be met need to be agreed upon by the community community prior to initiating a revision of this document (e.g., try to
prior to initiating a revision of this document (e.g. try to mirror draft auth mirror draft author distribution over the preceding five years).
or
distribution over the preceding five years).
</t> </t>
</section> </section>
<section title="Acknowledgments">
<t>The author would like to thank Jari Arkko, Alia Atlas, Fred
Baker, Brian Carpenter, Alissa Cooper, Dave Crocker, Spencer
Dawkins, Stephen Farrell, Tobias Gondrom, Eric Gray, Bob Hinden,
Ole Jacobsen, Olaf Kolkman, Eliot Lear, Andrew Malis, Yoav Nir,
Ray Pelletier, Melinda Shore, John Klensin, Charles Eckel, Russ
Housley, Andrew Sullivan, Eric Rescorla, Richard Barnes, Cullen
Jennings, Ted Lemon, Lou Berger, John Levine, Adam Roach, Mark
Nottingham, Tom Petch, Randy Bush, Roni Even, Julien Meuric,
Lloyd Wood, Alvaro Retana and Martin Vigoureux for their ideas
and comments to improve this document. </t>
</section>
</middle> </middle>
<back> <back>
<references pn="section-6">
<references title="Normative References"> <name slugifiedName="name-references">References</name>
<references pn="section-6.1">
&RFC4071; <name slugifiedName="name-normative-references">Normative References</na
me>
</references> <reference anchor="RFC8711" target="https://www.rfc-editor.org/info/rfc8
711" quoteTitle="true" derivedAnchor="RFC8711">
<references title="Informative References"> <front>
<title>Structure of the IETF Administrative Support Activity, Versio
&I-D.ietf-mtgvenue-iaoc-venue-selection-process; n 2.0</title>
<author initials="B." surname="Haberman">
<reference anchor="CONT-DIST" target="https://datatracker.ietf.org/stats/m <organization showOnFrontPage="true"/>
eeting/continent/"> </author>
<front> <author initials="J." surname="Hall">
<title>Number of attendees per continent across meetings</title> <organization showOnFrontPage="true"/>
<author> </author>
<organization>IETF</organization> <author initials="J." surname="Livingood">
</author> <organization showOnFrontPage="true"/>
</author>
<date year="2016"/> <date month="February" year="2020"/>
</front> </front>
</reference> <seriesInfo name="BCP" value="101"/>
<seriesInfo name="RFC" value="8711"/>
<reference anchor="IETFMEET" target="https://www.ietf.org/proceedings/79/s <seriesInfo name="DOI" value="10.17487/RFC8711"/>
lides/plenaryw-3.pdf"> </reference>
<front> </references>
<title>IETF 1-1-1 Meeting Policy</title> <references pn="section-6.2">
<name slugifiedName="name-informative-references">Informative References
<author> </name>
<organization>IAOC Plenary Presentation</organization> <reference anchor="CONT-DIST" target="https://datatracker.ietf.org/stats
</author> /meeting/continent/" quoteTitle="true" derivedAnchor="CONT-DIST">
<front>
<date year="2010"/> <title>Number of attendees per continent across meetings</title>
</front> <author>
</reference> <organization showOnFrontPage="true">IETF</organization>
</author>
</front>
</reference>
<reference anchor="IETFMEET" target="https://www.ietf.org/proceedings/79
/slides/plenaryw-3.pdf" quoteTitle="true" derivedAnchor="IETFMEET">
<front>
<title>IAOC Report IETF79</title>
<author initials="B." surname="Hinden" fullname="Bob Hinden">
<organization showOnFrontPage="true">IAOC Plenary Presentation</or
ganization>
</author>
<author initials="R" surname="Pelletier" fullname="R. Pelletier">
<organization showOnFrontPage="true">IAOC Plenary Presentation</or
ganization>
</author>
<date month="November" year="2010"/>
</front>
</reference>
<reference anchor="RFC8718" target="https://www.rfc-editor.org/info/rfc8
718" quoteTitle="true" derivedAnchor="RFC8718">
<front>
<title>IETF Plenary Meeting Venue Selection Process</title>
<seriesInfo name="BCP" value="226"/>
<seriesInfo name="RFC" value="8718"/>
<seriesInfo name="DOI" value="10.17487/RFC8718"/>
<author initials="E" surname="Lear" fullname="Eliot Lear" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<date month="February" year="2020"/>
</front>
</reference>
</references>
</references> </references>
<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
ndix.a">
<name slugifiedName="name-acknowledgments">Acknowledgments</name>
<t pn="section-appendix.a-1">The author would like to thank
<contact fullname="Jari Arkko"/>,
<contact fullname="Alia Atlas"/>,
<contact fullname="Fred Baker"/>,
<contact fullname="Brian Carpenter"/>,
<contact fullname="Alissa Cooper"/>,
<contact fullname="Dave Crocker"/>,
<contact fullname="Spencer Dawkins"/>,
<contact fullname="Stephen Farrell"/>,
<contact fullname="Tobias Gondrom"/>,
<contact fullname="Eric Gray"/>,
<contact fullname="Bob Hinden"/>,
<contact fullname="Ole Jacobsen"/>,
<contact fullname="Olaf Kolkman"/>,
<contact fullname="Eliot Lear"/>,
<contact fullname="Andrew Malis"/>,
<contact fullname="Yoav Nir"/>,
<contact fullname="Ray Pelletier"/>,
<contact fullname="Melinda Shore"/>,
<contact fullname="John Klensin"/>,
<contact fullname="Charles Eckel"/>,
<contact fullname="Russ Housley"/>,
<contact fullname="Andrew Sullivan"/>,
<contact fullname="Eric Rescorla"/>,
<contact fullname="Richard Barnes"/>,
<contact fullname="Cullen Jennings"/>,
<contact fullname="Ted Lemon"/>,
<contact fullname="Lou Berger"/>,
<contact fullname="John Levine"/>,
<contact fullname="Adam Roach"/>,
<contact fullname="Mark Nottingham"/>,
<contact fullname="Tom Petch"/>,
<contact fullname="Randy Bush"/>,
<contact fullname="Roni Even"/>,
<contact fullname="Julien Meuric"/>,
<contact fullname="Lloyd Wood"/>,
<contact fullname="Alvaro Retana"/>,
and
<contact fullname="Martin Vigoureux"/> for their ideas
and comments to improve this document. </t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.b">
<name slugifiedName="name-authors-address">Author's Address</name>
<author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
<organization showOnFrontPage="true">Kaloom</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>suresh@kaloom.com</email>
</address>
</author>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 33 change blocks. 
193 lines changed or deleted 379 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/