Subject: [MIPSHOP-MIH-DT] Editorial work up to Jan 3rd

From: Telemaco Melia <[email-masked]>
Date: Mon, 17 Dec 2007 18:18:22 +0100

Guys,

Due to my removal I will not be able to edit the document until the 
first week of Jan.
I just posted as -00 version the document we presented in Vancouver.
Please find attached the xml source. I use xmlMind to edit and xml2rfc 
to convert...pretty handy tools.

Nada would you mind to take over the editorial leadership?

Thanks for your support and Merry Christmas to you all.

Regards,
Tele

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-mipshop-mstp-solution-00"
     ipr="full3978">
  <front>
    <title abbrev="MSTP">Mobility Services Transport Protocol Design</title>

    <author fullname="Telemaco Melia" initials="T." role="editor"
            surname="Melia">
      <organization>NEC</organization>

      <address>
        <postal></postal>

        <email>[email-masked]</email>
      </address>
    </author>

    <author fullname="Gabor Bajko" initials="G." surname="Bajko">
      <organization>Nokia</organization>

      <address>
        <postal></postal>

        <email>[email-masked]</email>
      </address>
    </author>

    <author fullname="Subir Das" initials="S." surname="Das">
      <organization>Telcordia</organization>

      <address>
        <postal></postal>

        <email>[email-masked]</email>
      </address>
    </author>

    <author fullname="Nada Golmie" initials="N." surname="Golmie">
      <organization>NIST</organization>

      <address>
        <postal></postal>

        <email>[email-masked]</email>
      </address>
    </author>

    <author fullname="Sam Xia" initials="S." surname="Xia">
      <organization>Huawei</organization>

      <address>
        <postal></postal>

        <email>[email-masked]</email>
      </address>
    </author>

    <author fullname="Juan Carlos Zuniga" initials="JC" surname="Zuniga">
      <organization>InterDigital</organization>

      <address>
        <postal></postal>

        <email>[email-masked]</email>
      </address>
    </author>

    <date day="17" month="December" year="2007" />

    <area>Internet Area</area>

    <workgroup>Mipshop WG</workgroup>

    <abstract>
      <t>This document describes a design solution for the IEEE 802.21 Media
      Independent Handover (MIH) protocol that addresses identified issues
      associated with the transport of MIH messages. The document describes
      mechanisms for mobility service (MoS) discovery and transport layer
      mechanisms for the reliable delivery of MIH messages.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>This document proposes a solution to the issues identified in the
      problem statement document <xref
      target="I-D.ietf-mipshop-mis-ps"></xref> for the layer 3 transport of
      IEEE 802.21 MIH protocols.</t>

      <t>The MIH Layer 3 transport problem is divided in two main parts: the
      discovery of a node that supports specific Mobility Services (MoS) and
      the transport of the information between a mobile node (MN) and the
      discovered node. The discovery process is required for the MN to obtain
      the information needed for MIH protocol communication with a peer node.
      The information includes the transport address (e.g., the IP address) of
      the peer node and the types of MoS provided by the peer node.</t>

      <t>This document lists the major MoS deployment scenarios. It next
      describes the solution architecture, including the MSTP reference model
      and MIHF identifiers. A description follows of MoS discovery procedures
      when the MN is in a home or remote network. The remainder of the
      document describes the MIH transport architecture, example message flows
      for several signaling scenarios, and security issues.</t>
    </section>

    <section title="Terminology">
      <t>The following acronyms and terminology are used in this
      document:<list style="hanging">
          <t hangText="MIH">Media Independent Handover: the handover support
          architecture defined by the IEEE 802.21 working group that consists
          of the MIH Function (MIHF), MIH Network Entities, MIH Event
          messages, and MIH command messages.</t>

          <t hangText="MIHF">Media Independent Handover Function: a
          cross-layer function that provides handover services including the
          Event Service (ES), Information Service (IS), and Command Service
          (CS), through service access points (SAPs) defined by the IEEE
          802.21 working group.</t>

          <t hangText="MIHF User">an MIH client that uses the MIH SAPs to
          access MIHF services, and which is responsible for initiating and
          terminating MIH signaling</t>

          <t hangText="MIHFID">Media Independent Handover Function Identifier:
          an identifier required to uniquely identify the MIHF endpoints for
          delivering mobility services (MoS); it is implemented as either a
          FQDN or NAI.</t>

          <t hangText="MoS">Mobility Services: those services, as defined in
          the MIH problem statement document <xref
          target="I-D.ietf-mipshop-mis-ps"></xref> , which include the MIH IS,
          CS, and ES services defined by the IEEE 802.21 standard.</t>

          <t hangText="MoSh">Mobility Services assigned in the mobile
          node&rsquo;s Home Network</t>

          <t hangText="MoSv">Mobility Services assigned in the Visited
          Network, which is any network other than the mobile node&rsquo;s
          home network</t>

          <t hangText="MoS3">Mobility Services assigned in a 3rd Party
          Network, which is a network that is neither the Home Network nor the
          current Visited Network.</t>

          <t hangText="MN">Mobile Node: an Internet device whose location
          changes, along with its point of connection to the network.</t>

          <t hangText="NN">Network Node: an Internet device whose location and
          network point of attachment do not change</t>

          <t hangText="MSTP">Mobility Services Transport Protocol: a protocol
          that is used to deliver MIH signaling messages from an MIHF to other
          MIH-aware nodes in a network.</t>

          <t hangText="IS">Information Service: a MoS that originates at the
          lower or upper layers and sends information to the local or remote
          upper or lower layers. It can use secure or insecure ports to
          transport information elements (IEs) and information about various
          neighboring nodes. Its architecture is outside the scope of the IEEE
          802.21 draft document.</t>

          <t hangText="ES">Event Service: a MoS that originates at a remote
          MIHF or the lower layers and sends information to the local MIHF or
          local higher layers. The purpose of the ES is to report changes in
          link status (e.g. Link Going Down messages) and transmission
          status.</t>

          <t hangText="CS">Command Service: a MoS that sends commands from the
          remote MIHF or local upper layers to the local lower layers to
          switch links or to get link status.</t>

          <t hangText="FQDN">Fully-Qualified Domain Name: a complete domain
          name for a host on the Internet, consisting of a host name followed
          by a domain name (e.g. hostname.domain.org)</t>

          <t hangText="NAI">Network Access Identifier: the user ID that a user
          submits during PPP authentication. For mobile users, the NAI
          identifies the user and helps to route the authentication request
          message.</t>

          <t hangText="NAT">Network Address Translator: A device that
          implements the Network Address Translation function described in
          [RFC3022], in which local or private network layer addresses are
          mapped to valid network addresses and port numbers.</t>

          <t hangText="DHCP">Dynamic Host Configuration Protocol: a protocol
          described in [RFC2131] that allows Internet devices to obtain IP
          addresses, subnet masks, default gateway addresses, and other IP
          configuration information from DHCP servers.</t>

          <t hangText="DNS">Domain Name System: a protocol described in
          [RFC1035] that translates domain names to IP addresses.</t>

          <t hangText="AAA">Authentication, Authorization and Accounting: a
          set of network management services that respectively determine the
          validity of a user&rsquo;s ID, determine whether a user is allowed
          to use network resources, and track users&rsquo; use of network
          resources.</t>

          <t hangText="AAA home">AAA server: an AAA server located on the
          MN&rsquo;s home network</t>

          <t hangText="AAA visited">AAA server: an AAA server located a
          visited network that is not the MN&rsquo;s home network</t>

          <t hangText="MIH ACK">MIH Acknowledgement Message: a MIH signaling
          message that a MIHF sends in response to an MIH message from a
          sending MIHF, when UDP is used as the MSTP.</t>

          <t hangText="PoS">Point of Service, a network-side MIHF instance
          that exchanges MIH messages with a MN-based MIHF</t>

          <t hangText="NAS">Network Access Server: a server to which a MN
          initially connects when it is trying to gain a connection to a
          network and which determines whether the MN is allowed to connect to
          the NAS&rsquo;s network</t>

          <t hangText="UDP">Network Access Server: a server to which a MN
          initially connects when it is trying to gain a connection to a
          network and which determines whether the MN is allowed to connect to
          the NAS&rsquo;s network</t>

          <t hangText="TCP">Transmission Control Protocol: a stream-oriented
          transport layer protocol that provides a reliable delivery service
          with congestion control, defined in RFC 793.</t>

          <t hangText="RTT">Round-Trip Time: a estimation of the time required
          for a segment to travel from a source to a destination and an
          acknowledgement to return to the source that is used by TCP in
          connection with timer expirations to determine when a segment is
          considered lost and should be resent.</t>

          <t hangText="MTU">Maximum Transmission Unit: the largest size packet
          that can be sent on a network without requiring fragmentation
          [RFC1191].</t>

          <t hangText="TLS">Transport Layer Security Protocol: an application
          layer protocol that assures privacy and data integrity between two
          communicating network entities [RFC4346].</t>
        </list></t>
    </section>

    <section anchor="scenarios" title="Deployment Scenarios">
      <t>This section describes the various possible deployment scenarios for
      the MN and the MoS. The relative positioning of MN and MoS affects
      resource discovery as well as the performance of the MIH signaling
      service.</t>

      <section title="Scenario S1: Home Network MoS">
        <t>In this scenario, the MN and the services are located in the home
        network. We refer to this set of services as MoSh as in <xref
        target="MoSh"></xref>. The MoSh can be located at the access point the
        MN uses to connect to the home network, or it can be located
        elsewhere.<figure anchor="MoSh" title="MoS in the Home network">
            <preamble></preamble>

            <artwork><![CDATA[+--------------+  +====+
| HOME NETWORK |  |MoSh|
+--------------+  +====+
     /\
     ||
     \/
+--------+
|   MN   |
+--------+
]]></artwork>
          </figure></t>
      </section>

      <section title="Scenario S2: Visited Network MoS">
        <t>In this scenario, the MN is in the visited network and mobility
        services are also provided by the visited network. We refer to this as
        MoSv as shown in <xref target="MoSv"></xref>.<figure anchor="MoSv"
            title="MoSV in the Visited Network">
            <preamble></preamble>

            <artwork><![CDATA[
          +--------------+
          | HOME NETWORK |
          +--------------+
                /\
                ||
                \/
 +====+ +-----------------+
 |MoSv| | VISITED NETWORK |
 +====+ +-----------------+
                /\
                ||
                \/
            +--------+
            |   MN   |
            +--------+]]></artwork>
          </figure></t>
      </section>

      <section title="Scenario S3: Roaming MoS">
        <t>In this scenario, the MN is located in the visited network and all
        MIH services are provided by the home network, as shown in <xref
        target="MoSvh"></xref>.<figure anchor="MoSvh"
            title="MoS provided by the home while in visited">
            <preamble></preamble>

            <artwork><![CDATA[
 +====+   +--------------+
 |MoSh|   | HOME NETWORK |
 +====+   +--------------+
                /\
                ||
                \/
       +-----------------+
       | VISITED NETWORK |
       +-----------------+
                /\
                ||
                \/
            +--------+
            |   MN   |
            +--------+]]></artwork>
          </figure></t>
      </section>

      <section title="Scenario S4: Third party MoS">
        <t>In this scenario, the MN is in its home network or in a visited
        network and services are provided by a 3rd party network. We refer to
        this situation as MoS3 as shown in <xref target="MoS3"></xref><figure
            anchor="MoS3" title="MoS form a third party">
            <preamble></preamble>

            <artwork><![CDATA[                                   +--------------+
                                   | HOME NETWORK |
+====+    +--------------+         +--------------+
|MoS3|    | THIRD PARTY  |  <===>        /\
+====+    +--------------+               ||
                                         \/
                                 +-----------------+
                                 | VISITED NETWORK |
                                 +-----------------+
                                         /\
                                         ||
                                         \/
                                     +--------+
                                     |   MN   |
                                     +--------+]]></artwork>
          </figure></t>
      </section>

      <t>Different types of MoS can be provided independently of other types
      and there is no strict relationship between ES, CS and IS, nor is there
      a requirement that the entities that provide these types be co-located.
      However, while IS tends to involve large amounts of static information,
      ES and CS are dynamic services and some relationship between them can be
      expected, e.g. a handover command (CS) could be issued upon reception of
      a link event (ES). Hence, while in theory MoS can be implemented in
      different locations, it is expected that ES and CS will be co-located,
      whereas IS can be co-located with ES/CS or located elsewhere. Therefore,
      having the flexibility at the MSTP to discover different services in
      different locations is an important feature that can be used to optimize
      handover performance. Resource discovery is discussed in more detail in
      <xref target="discovery"></xref>.</t>
    </section>

    <section anchor="overview" title="Solution Overview">
      <t>As mentioned in <xref target="intro"></xref> the solution space is
      being divided into two functional domains: discovery and transport. The
      following assumptions have been made:<list style="hanging">
          <t hangText="o">The solution is aimed at supporting 802.21 MIH
          services, namely Information Service (IS), Event Service (ES), and
          Command Service (CS).</t>

          <t hangText="o">If the MIHFID is available, FQDN or NAI's realm is
          used for mobility service discovery.</t>

          <t hangText="o">The solutions are chosen to cover all possible
          deployment scenarios as described in <xref
          target="scenarios"></xref>.</t>

          <t hangText="o">MoS discovery can be performed during initial
          network attachment or thereafter.</t>
        </list>For the discovering the location of an MoS, the MN could either
      be pre-configured with the address of the MoS, or this address could be
      dynamically assigned through DHCP or DNS by the network. The dynamic
      assignation methods are described in <xref
      target="discovery"></xref>.</t>

      <t>The configuration of the MoS could be executed either upon network
      attachment or after successful IP configuration. The methodology to be
      used depends on the considered deployment scenario.</t>

      <t>Once the MIHF peer has been discovered, MIH information can be
      exchanged between MIH peers over a trasnport protocol such as UDP or
      TCP. The usage of transport protocols is described in <xref
      target="transport"></xref>.</t>

      <section title="Architecture ">
        <t><xref target="MN"></xref> depicts the MSTP reference model and its
        components within a node. The topmost layer is the MIHF user. This set
        of applications consists of one or more MIH clients that are
        responsible for such operations as maintaining MIH databases
        associated with the IS, processing Layer 2 triggers as part of the ES,
        and initiating and carrying out handover operations as part of the CS.
        Beneath the MIHF user set is the MIHF itself. This function is
        responsible for MoS discovery, as well as creating, maintaining,
        modifying, and destroying MIH signaling associations with other MIHFs
        located in MIH peer nodes. Below the MIHF are various transport layer
        protocols as well as address resolution functions.</t>

        <t><figure anchor="MN" title="MN stack">
            <preamble></preamble>

            <artwork><![CDATA[ 
 +--------------------------+
 |       MIHF User          |
 +--------------------------+
              ||
 +--------------------------+
 |           MIHF           |
 +--------------------------+
     ||         ||       ||
 +---------+ +------+ +-----+
 | TCP/UDP | | DHCP | | DNS |
 +---------+ +------+ +-----+]]></artwork>

            <postamble></postamble>
          </figure></t>

        <t>The MIHF relies on the services provided by TCP and UDP for
        transporting MIH messages, and relies on DHCP and DNS for peer
        discovery. In cases where the peer MIHF IP address is not
        pre-configured, the source MIHF needs to discover it either via DHCP
        or DNS or a combination of both as described in <xref
        target="discovery"></xref>. Once the peer MIHF is discovered, MIHF
        must exchange messages with its peer over either UDP or TCP. Specific
        recommendations regarding the choice of transport protocols are
        provided in <xref target="transport"></xref>.</t>

        <t>The above reference architecture however does not include other
        services such as message fragmentation and security. Depending upon
        the MIH service type (e.g., ES, CS and IS) the message size can be
        very large. In case where the underlying layers do not support
        fragmentation, this may be an issue. There are no security features
        currently defined as part of the MIH protocol level. However, security
        can be provided either at the transport or IP layer where it is
        necessary. <xref target="Security"></xref> provides some guidelines
        and recommendations for security.</t>
      </section>

      <section title="MIHF Identifiers (FQDN, NAI)">
        <t>An MIHFID is an identifier required to uniquely identify the MIHF
        end points for delivering the mobility services (MoS). Thus an MIHF
        identifier needs to be unique within a domain where mobility services
        are provided and invariant to interface IP addresses. An MIHFID MUST
        be represented either in the form of an FQDN <xref
        target="RFC2181"></xref> or NAI <xref target="RFC4282"></xref>. An
        MIHFID can be pre-configured or discovered through the discovery
        methods described in <xref target="discovery"></xref>.</t>
      </section>
    </section>

    <section anchor="discovery" title="MoS Discovery">
      <t>The MoS discovery method depends on whether the MN attempts to
      discover an MoS in the home network, in the visited network, or in a 3rd
      party remote network that is neither the home network nor the visited
      network.</t>

      <t>In case MoS is provided locally (scenarios S1 and S2) , the discovery
      techniques described in <xref
      target="I-D.bajko-mos-dhcp-options"></xref> and <xref
      target="I-D.bajko-mos-dns-discovery"></xref> are both applicable and
      either one MAY be used to discover the MoS.</t>

      <t>In case MoS is provided in the home network while the MN is in the
      visited network (scenario S3), the DNS based discovery described in
      <xref target="I-D.bajko-mos-dns-discovery"></xref> is applicable, while
      the DHCP based discovery method would require an interaction between the
      DHCP and the AAA infrastructure, similarly to what specified in <xref
      target="I-D.ietf-mip6-bootstrapping-integrated-dhc"></xref> . This
      latter case assumes that MoS assignment is performed during access
      authentication and authorization.</t>

      <t>In case MoS is provided in a remote network other than visited or
      home network (scenario S4), only the DNS based discovery method
      described in <xref target="I-D.bajko-mos-dns-discovery"></xref> is
      applicable.</t>

      <section anchor="section51"
               title="MoS Discovery when MN and MoSh are in the home network (Scenario S1)">
        <t>To discover an MoS in the home network, the MN SHOULD use the DNS
        based MoS discovery method described in <xref
        target="I-D.bajko-mos-dns-discovery"></xref>. In order to use that
        mechanism, the MN MUST first find out the domain name of its home
        network. Home domains are usually pre-configured in the MNs, thus the
        MN can simply read its configuration data to find out the home domain
        name (scenario S1). The DNS query option is shown in <xref
        target="s1"></xref>b. Alternatively, the MN MAY use the DHCP options
        for MoS discovery<xref target="I-D.bajko-mos-dhcp-options"></xref> as
        shown in<xref target="s1"> </xref>a.</t>

        <figure anchor="s1"
                title="MOS Discovery (a) Using DNS query, (b) using DHCP option">
          <preamble></preamble>

          <artwork><![CDATA[                           +-------+      
            +----+         |Domain |
            | MN |-------->|Name   | 
            +----+         |Server | 
                           +-------+ 
             [email-masked]

                          (a) using DNS Query

                         +-----+      +------+      
            +----+       |     |      |DHCP  | 
            | MN |<----->| DHCP|<---->|Server| 
            +----+       |Relay|      |      | 
                         +-----+      +------+ 

                          (b)  Using DHCP Option]]></artwork>

          <postamble></postamble>
        </figure>

        <t></t>
      </section>

      <section title="MoS Discovery when MIN is in visited network and MoSv is also in visited network (Scenario S2)">
        <t>To discover an MoS in the visited network, the MN SHOULD attempt to
        use the DHCP options for MoS discovery <xref
        target="I-D.bajko-mos-dhcp-options"></xref> as shown in <xref
        target="s2"></xref>a. If the DHCP method fails, the MN SHOULD attempt
        to use the DNS based MoS discovery method described in [<xref
        target="I-D.bajko-mos-dns-discovery"></xref> as shown in <xref
        target="s2"></xref>b. In order to use that, the MN MUST first learn
        the domain name of the local network. There are a number of ways how
        the domain name of a network can be learned:<list style="hanging">
            <t hangText="DHCP --">In order to find out the domain name of the
            local network, the MN SHOULD use the dhcpv4 option 15 for learning
            the domain name <xref target="RFC1533"></xref>. A similar solution
            is available for dhcpv6 <xref
            target="I-D.ietf-dhc-dhcpv6-opt-dnsdomain"></xref> .</t>

            <t hangText="Reverse dns query --">When DHCP does not provide the
            required domain name, the MN MAY use reverse DNS (DNS PTR record)
            to find the domain name associated with the IP address it is using
            in the visited network. Note, that when a NAT device exists
            between the MN and the visited network, the MN will first need to
            find out the external IP address of the NAT device. Some possible
            methods for determining the NAT's external IP address are STUN
            <xref target="RFC3849"></xref> or UPnP [UPnP_IDG_DCP]. Once the MN
            has determined the external IP address of the NAT device, it MUST
            use that address in the reverse DNS query.</t>
          </list><figure anchor="s2"
            title="Discovery (a) using DHCP option, (b) Using DNS">
            <preamble></preamble>

            <artwork><![CDATA[                         +-----+      +------+      
            +----+       |     |      |DHCP  | 
            | MN |<----->| DHCP|<---->|Server| 
            +----+       |Relay|      |      | 
                         +-----+      +------+ 

                   (a) MOS Discovery using DHCP options 

                           +-------+      
            +----+         |Domain |
            | MN |-------->|Name   | 
            +----+         |Server | 
                           +-------+ 

                    (b) Reverse DNS Query (starting from the IP address)]]></artwork>

            <postamble></postamble>
          </figure></t>
      </section>

      <section title="MOS Discovery when the MN is in a visited Network and Services are at the Home network (Scenario S3)">
        <t>To discover an MoS in the visited network when MIH services are
        provided by the home network, both the DNS based discovery method
        described in <xref target="I-D.bajko-mos-dns-discovery"></xref> and
        the DHCP based discovery method described in <xref
        target="I-D.bajko-mos-dhcp-options"></xref> are applicable.</t>

        <t>To discover the MoS at home while in a visited network using DNS,
        the MN SHOULD use the procedures described in section <xref
        target="section51"></xref></t>

        <t>Alternatively, the MN MAY also use the DHCP based discovery method.
        Using the DHCP based discovery may be required in deployments where
        the usage of MoS located in the home network is enforced and included
        in the subscription profile. Similarly to <xref
        target="I-D.ietf-mip6-bootstrapping-integrated-dhc"></xref> in this
        integrated scenario the mobile node utilizes network access
        authentication process to bootstrap MIH services. It is assumed that
        the access service authorizer is mobility service aware. This allows
        for MoS discovery at the time of access authentication and
        authorization. Also, the mechanism defined in this document requires
        the NAS to support MIH specific AAA attributes and a collocated DHCP
        relay agent. In order to provide the mobile node with information
        about the assigned MoS the AAAh conveys the assigned MoS's information
        to the NAS via AAA protocol similarly to <xref
        target="I-D.ietf-dime-mip6-integrated"></xref> and described in <xref
        target="appendix"></xref>.</t>

        <t>In these deployment scenarios the AAAh sends the MoS address at
        home to the AAAv during the network access authentication. The
        relation beween functional components supporting such procedure is
        shown in <xref target="s3"></xref>.</t>

        <t>The mobile node executes the network access authentication
        procedure (e.g., IEEE 802.11i/802.1X) and it interacts with the NAS.
        The NAS is in the visited and it interacts with the AAAh to
        authenticate the mobile node. In the process of authorizing the mobile
        node the AAAh verifies in the AAA profile that the mobile node is
        allowed to use MoS service. The AAAh assigns the MoS in the home and
        returns this information to the NAS. The NAS may keep the received
        information for a configurable duration or it may keep the information
        for as long as the MN is connected to the NAS.</t>

        <t>The mobile node sends a DHCPv6 Information Request message <xref
        target="RFC3315"></xref> to the All_DHCP_Relay_Agents_and_Servers
        multicast address. In this message the mobile node (DHCP client) SHALL
        include the Option Code for MoS Identifier Option <xref
        target="I-D.bajko-mos-dhcp-options"></xref> in the OPTION_ORO, MoS
        Identifier Option with id-type set to 1 and the MoS Identifier field
        set to the network realm of the home. The mobile node SHALL also
        include the OPTION_CLIENTID to identify itself to the DHCP server.</t>

        <t>The Relay Agent intercepts the Information Request from the mobile
        node and forwards it to the DHCP server. The Relay Agent also includes
        the received MoS information from the AAAh in the MIH Relay Agent
        Option <xref target="I-D.bajko-mos-dhcp-options"></xref>. If a NAS
        implementation does not store the received information as long as the
        MN's session remains in the visited, and if the MN delays sending DHCP
        request, the NAS/DHCP relay does not include the MIH Relay Agent
        Option in the Relay Forward message.</t>

        <t>The DHCP server identifies the client by looking at the DUID for
        the client in the OPTION_CLIENTID. The DHCP server also determines
        that the mobile node is requesting MoS information in the home by
        looking at the MoS Identifier Option (id-type 1). The DHCP server
        determines that the home agent is allocated by the AAAh by looking at
        the MIH sub-option in the MIH Relay Agent Option. The DHCP server
        extracts the allocated home agent information from the MIH Relay Agent
        Option and includes it in the MoS Information Option <xref
        target="I-D.bajko-mos-dhcp-options"></xref> in the Reply Message. If
        the requested information is not available in the DHCP server, it
        follows the behavior described in <xref
        target="I-D.bajko-mos-dhcp-options"></xref>.</t>

        <t>The Relay Agent relays the Reply Message from the DHCP server to
        the mobile node. At this point, the mobile node has the home agent
        information that it requested.</t>

        <t>It should be noted that the AAAh does not know the preferences of
        the MN at the time of authentication, i.e. whether the MoS in the home
        or in the local network is to be sent to the MN. The MoS information
        will anyway be sent to the AAAV, then stored in the relay agent and
        ultimately sent to the MN if the MN asks for it, using the procedures
        defined in <xref target="I-D.bajko-mos-dhcp-options"></xref>.</t>

        <t><figure anchor="s3"
            title="MOS Discovery using Network Access Authentication and DHCP options ">
            <preamble></preamble>

            <artwork><![CDATA[
                        Visited             |          Home
                                            |
                                            |
                        +-------+           |        +-------+
                        |       |           |        |       |
                        |AAAV   |-----------|--------|AAAH   |
                        |       |           |        |       |
                        |       |           |        |       |                        
                        +-------+           |        +-------+
                            |               |
                            |               |
                            |               |
                            |               |
                            |               |       +--------+
                            |               |       |        |
                            |               |       |  MoSh  |
                        +-----+    +------+ |       +--------+
            +----+      |     |    |DHCP  | |
            | MN |------| NAS/|----|Server| |
            +----+      | DHCP|    |      | |   
                        |Relay|    |      | |
                        +-----+    +------+ |
                                            |

       AAAv -- Visited AAA
       AAAH -- Home AAA
       NAS  -- Network Access Server ]]></artwork>

            <postamble></postamble>
          </figure></t>
      </section>

      <section title="MoS discovery when MIH services are in a 3rd party remote network (scenario S4)">
        <t>To discover an MoS in a remote network other than home network, the
        MN MUST use the DNS based MoS discovery method described in <xref
        target="I-D.bajko-mos-dns-discovery"></xref>. The MN MUST first learn
        the domain name of the network containing the MoS it is searching for.
        If the MN does not yet know the domain name of the network, learning
        it may require more than one operation, as pre-configuration and DHCP
        methods can not be used. The MN MAY attempt to first discover an MoS
        in either the local or home network (as in <xref target="s4"></xref>
        part (a)) and query that MoS to find out the domain name of a specific
        network or the domain name of a network at a specific location (as in
        <xref target="s4"></xref> part (b)). Alternatively, the MN MAY query
        an MoS previously known to learn the domain name of the desired
        network (e.g., via an IS Query). Finally the MN can use DNS queries to
        find MoS in the remote network as in<xref target="s4"></xref> part(c).
        It should be noted that step c can only be performed upon obtaining
        the domain name of the remote network.</t>

        <t><figure anchor="s4"
            title="MOS Discovery using (a) DHCP Options, (b) IS Query to a known Server, (c) DNS Query">
            <preamble></preamble>

            <artwork><![CDATA[                                +-------+
                 +----+         |DHCP   |
                 | MN |-------->|       |
                 +----+         |Server |
                                +-------+
                  [email-masked]

        (a) Discover MoS in local network with DHCP
                            +------------+
             +----+         |            |
             |    |         |Information |
             | MN |-------->| Server     |
             |    |         |(previously |
             +----+         |discovered) |
                            +------------+

   (b) Using IS query to find the FQDN on the remote network

                              +-------+
               +----+         |Domain |
               | MN |-------->|Name   |
               +----+         |Server |
                              +-------+
                [email-masked]

         (c) using DNS Query in the remote network
]]></artwork>

            <postamble></postamble>
          </figure></t>
      </section>
    </section>

    <section anchor="transport" title="MIH Transport Options">
      <t>Once the Mobility Services have been discovered, MIH peers MAY
      exchange information over TCP, UDP or any other transport supported by
      both the server and client, as described in <xref
      target="I-D.rahman-mipshop-mih-transport"></xref>. The client MAY use
      the DNS discovery mechanism to discover which transport protocols are
      supported by the server in addition to TCP and UDP. While either
      protocol can provide the basic transport functionality required, there
      are performance trade-offs and unique characteristics associated with
      each that need to be considered in the context of the MIH services for
      different network loss and congestion conditions. The objectives of this
      section are to discuss these trade-offs for different MIH settings such
      as the MIH message size and rate, and the retransmission parameters. In
      addition, factors such as NAT traversal are also discussed. Given the
      reliability requirements for the MIH transport, it is assumed in this
      discussion that the MIH ACK mechanism is to be used in conjunction with
      UDP, while it is preferred to avoid using MIH ACKs with TCP since TCP
      includes acknowledgement and retransmission functionality</t>

      <section title="MIH Message size">
        <t>Although the MIH message size varies widely from about 30 bytes
        (for a broadcast capability discovery request) to around 65000 bytes
        (for an IS MIH_Get_Information response primitive), a typical MIH
        message size for the ES/CS service ranges between 50 to100 bytes <xref
        target="IEEE80221"></xref>. Thus, considering the effects of the MIH
        message size on the performance of the transport protocol brings us to
        discussing two main issues, related to fragmentation of long messages
        in the context of UDP and the concatenation of short messages in the
        context of TCP. Since transporting long MIH messages may require
        fragmentation that is not available in UDP, if MIH is using UDP a
        limit MUST be set on the size of the MIH message, unless fragmentation
        functionality is added to the MIH layer or IP layer fragmentation is
        used instead. In this latter case, the loss of an IP fragment leads to
        the retransmission of an entire MIH message, which in turn leads to
        poor end-to-end delay performance in addition to wasted bandwidth
        utilization. Additional recommendations in <xref
        target="I-D.ietf-tsvwg-udp-guidelines"></xref> apply for limiting the
        size of the MIH message when using UDP and assuming IP layer
        fragmentation. In terms of dealing with short messages, TCP has the
        capability to concatenate very short messages in order to reduce the
        overall bandwidth overhead. However, this reduced overhead comes at
        the cost of additional delay to complete an MIH transaction, which may
        not be acceptable for CS and ES services. Note also that TCP is a
        stream oriented protocol and measures data flow in terms of bytes, not
        messages. Thus it is possible to split messages across multiple TCP
        segments if they are long enough. Even short messages can be split
        across two segments. This can also cause unacceptable delays,
        especially if the link quality is severely degraded as is likely to
        happen when the MN is exiting a wireless access coverage area.</t>
      </section>

      <section title="MIH Message rate">
        <t>The frequency of MIH messages varies according to the MIH service
        type. It is expected that CS/ES message arrive at a rate of one in
        hundreds of milliseconds in order to capture quick changes in the
        environment and/ or process handover commands. On the other hand, IS
        messages are exchanged mainly every time a new network is visited
        which may be in order of hours or days. Therefore a burst of either
        short CS/ES messages or long IS message exchanges (in the case of
        multiple MIH nodes requesting information) may lead to network
        congestion. While the built-in rate-limiting controls available in TCP
        may be well suited for dealing with these congestion conditions, this
        may result in large transmission delays that may be unacceptable for
        the timely delivery of ES/CS messages. On the other hand, if UDP is
        used, a rate-limiting effect similar to the one obtained with TCP may
        be obtained by adequately adjusting the parameters of a token bucket
        regulator as defined in the MIH specifications <xref
        target="IEEE80221"></xref>. Recommendations for tocken bucket
        parameter settings are specific to the scenario considered.</t>
      </section>

      <section title="Retransmission">
        <t>For TCP, the retransmission timeout is adjusted according to the
        measured RTT. However due to the exponential backoff mechanism, the
        delay associated with retransmission timeouts may increase
        significantly with increased packet loss.</t>

        <t>If UDP is being used to carry MIH messages, MIH SHOULD use MIH
        ACKs. An MIH message is retransmitted if its corresponding MIH ACK is
        not received by the generating node within a timeout interval set by
        the MIHF. This approach does not include an exponential backoff and
        therefore tends to degrade more gracefully than TCP when the packet
        loss rate becomes large, in the sense that the expected delay does not
        increase exponentially. The number of retransmissions is limited,
        which reduces head-of-line blocking of other MIH messages, but this
        can cause important ES/CS messages to be lost.</t>

        <t>Additionally, instead of retransmitting an unacknowledged message,
        the MIH may choose to update the information and transmit a new
        message.</t>
      </section>

      <section title="NAT Traversal">
        <t>There are no known issues for NAT traversal when using TCP. The
        default connection timeout of 24 hours is considered adequate for MIH
        transport purposes. However, issues with NAT traversal using UDP are
        documented in <xref target="I-D.ietf-tsvwg-udp-guidelines"></xref>.
        Communication failures are experienced when middleboxes destroy the
        per-flow state associated with an application session during periods
        when the application does not exchange any UDP traffic. Hence,
        communication between the MN and the MoS SHOULD be able to gracefully
        handle such failures and implement mechanisms to re-establish their
        UDP sessions. In addition and in order to avoid such failures, MIH
        messages MAY be sent periodically, similarly to keep-alive messages,
        to attempt to refresh middlebox state (e.g. ES reports could be used
        for this purpose). As <xref target="RFC4787"></xref> requires a
        minimum state timeout of two minutes or more, MIH messages using UDP
        as transport SHOULD be sent once every two minutes.</t>
      </section>

      <section title="General guidelines">
        <t>Since ES and CS messages are small in nature and have tight latency
        requirements, UDP in combination with MIH acknowledgement SHOULD be
        used for transporting ES and CS messages. On the other hand, IS
        messages are more resilient in terms of latency constraints and some
        long IS messages could exceed the MTU of the path to the destination.
        Therefore, TCP SHOULD be used for transporting IS messages. For both
        UDP and TCP cases, if a port number is not explicitly assigned (e.g.
        by the DNS SRV), MIH messages sent over UDP, TCP or other supported
        transport MUST use the default port number defined for that particular
        transport..</t>

        <t>The server side MUST support both UDP and TCP for MIH transport,
        and the MN MAY support either UDP or TCP. Additionally, the server and
        MN MAY support additional transport mechanisms. The MN MAY use the
        procedures defined in <xref
        target="I-D.bajko-mos-dns-discovery"></xref> to discover additional
        transport protocols supported by the server.</t>
      </section>

      <t></t>
    </section>

    <section title="Operation Flows ">
      <t><xref target="f1"></xref> gives an example operation flow between
      MIHF peers when an MIH user requests for an IS service. Scenario 1 is in
      effect, i.e. the MoS and the MN are both in the MN&rsquo;s home network.
      Thus DHCP is used for MoS discovery and TCP is used for establishing a
      transport connection to carry the IS messages. When MOS is not
      pre-configured, the MIH user needs to discover the IP address of MOS to
      communicate with the remote MIHF. Therefore the MIH user sends a
      discovery request message to the local MIHF as defined in <xref
      target="IEEE80221"></xref></t>

      <t>In this example, we assume that MoS discovery is performed before a
      transport connection is established with the remote MIHF, and the DHCP
      client process is invoked via some internal APIs. DHCP Client sends DHCP
      INFORM message according to standard DHCP and with the MoS option as
      defined in <xref target="I-D.bajko-mos-dhcp-options"></xref>. DHCP
      server replies via DHCP ACK message with the IP address of the MoS. The
      MOS address is then passed to the MIHF locally via some internal APIs.
      MIHF generates the discovery response message and passes it on to the
      corresponding MIH user. The MIH user generates an IS query addressed to
      the remote MoS. MIHF invokes the underlying TCP client which establishes
      a transport connection with the remote peer. Once the transport
      connection is established, MIHF sends the IS query via MIH protocol
      REQUEST message. The message and query arrive at the destination MIHF
      and MIH user respectively. The MoS MIH user responds to the
      corresponding IS query and the MoS MIHF sends the IS response via MIH
      protocol RESPONSE message. The message arrives to the source MIHF which
      passes the IS response on to the corresponding MIH user.</t>

      <figure anchor="f1"
              title="Example Flow of Operation Involving MIH User ">
        <preamble></preamble>

        <artwork><![CDATA[                MN                                             MoS
|====================================|    |======|   |===================|
 + ---------+                                                 + ---------+
 | MIH USER |       +------+  +------+    +------+   +------+ | MIH USER |
 | +------+ |       | TCP  |  |DHCP  |    |DHCP  |   | TCP  | | +------+ |
 | | MIHF | |       |Client|  |Client|    |Server|   |Server| | | MIHF | |
 +----------+       +------+  +------+    +------+   +------+ +----------+
     |                 |         |           |          |          |
     |MIH Discovery    |         |           |          |          |
     |Request          |         |           |          |          |
     |(MIH User-> MIHF)|         |           |          |          |
     |======>          |         |           |          |          |
     |                 |         |           |          |          |
     |Invoke DHCP Client         |           |          |          |
     |(Internal process with MoS)|DHCP INFORM|          |          |
     |==========================>|==========>|          |          |
     |                 |         |           |          |          |
     |                 |         |           |          |          |
     |                 |         |  DHCP ACK |          |          |
     |                 |         |<==========|          |          |
     |    Inform MoS address     |           |          |          |
     |<==========================|           |          |          |
     |    (internal process)     |           |          |          |
     |                           |           |          |          |
     |Discovery        |         |           |          |          |
     |Response         |         |           |          |          |
     |<======          |         |           |          |          |
     |(MIH User<- MIHF)|         |           |          |          |
     |                 |         |           |          |          |
     |IS Query         |         |           |          |          |
     |=======>         |         |           |          |          |
     |(MIH User-> MIHF)|         |           |          |          |
     |                 |         |           |          |          |
     |Invoke TCP Client|         |           |          |          |
     |================>|         |           |          |          |
     |(Internal process|         |           |          |          |
     |with MOS)        |         |           |          |          |
     |                 |         |           |          |          |
     |                 |  TCP connection established    |          |
     |                 |<==============================>|          |
     |                 |         |           |          |          |
     |                 |         |           |          |          |
     |                 |         |           |          |          |
     |                 IS  QUERY REQUEST (via MIH protocol)        |
     |============================================================>|
     |                 |         |           |          |          |
     |                 |         |           |          |          |
     |                 |         |           |          |          |
     |                 |         |           |          |  IS QUERY|
     |                 |         |           |          |   REQUEST|
     |                 |         |           |          |=========>|
     |                 |         |           |    (MIHF-> MIH User)|
     |                 |         |           |          |          |
     |                 |         |           |          |     QUERY|
     |                 |         |           |          |  RESPONSE|
     |                 |         |           |          |   <======|
     |                 |         |           |  |(MIHF <-MIH User) |
     |                 |         |           |          |          |
     |                 | IS QUERY RESPONSE (via MIH protoco        |
     |<============================================================|
     |                 |         |           |          |          |
     |    IS           |         |           |          |          |
     |RESPONSE         |         |           |          |          |
     |<========        |         |           |          |          |
     |(MIH User <-MIHF)|         |           |          |          |
     |                 |         |           |          |          |]]></artwork>
      </figure>

      <t></t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>There are a number of security issues that need to be taken into
      account during node discovery and information exchange via a transport
      connection <xref target="I-D.ietf-mipshop-mis-ps"></xref></t>

      <t>In case where DHCP is used for node discovery and authentication of
      the source and content of DHCP messages are required, it is recommended
      that network administrators should use DHCP authentication option
      described in <xref target="RFC3118"></xref>, where available or rely
      upon link layer security. This will also protect the denial of service
      attacks to DHCP server.<xref target="RFC3118"></xref> provides
      mechanisms for both entity authentication and message
      authentication.</t>

      <t>In case where DNS is used for discovering MoS, fake DNS requests and
      responses may cause DoS and the inability of the MN to perform a proper
      handover, respectively. Where networks are exposed to such DoS, it is
      recommended that DNS service providers use the Domain Name System
      Security Extensions (DNSSEC) as described in <xref
      target="RFC4033"></xref>. Readers may also refer to <xref
      target="RFC4641"></xref> to consider the aspects of DNSSEC Operational
      Practices.</t>

      <t>In case where reliable transport protocol such as TCP is used for
      transport connection between two MIHF peers, TLS <xref
      target="RFC4346"></xref> should be used for message confidentiality and
      data integrity. In particular, TLS is designed for client/server
      applications and to prevent eavesdropping, tampering, or message
      forgery. Readers should also follow the recommendations in <xref
      target="RFC4366"></xref> that provides generic extension mechanisms for
      the TLS protocol suitable for wireless environments.</t>

      <t>In case where unreliable transport protocol such as UDP is used for
      transport connection between two MIHF peers, DTLS <xref
      target="RFC4347"></xref> should be used for message confidentiality and
      data integrity. The DTLS protocol is based on the Transport Layer
      Security (TLS) protocol and provides equivalent security guarantees.</t>

      <t>Alternatively, generic IP layer security, such as IPSec <xref
      target="RFC2401"></xref> may be used where neither transport layer
      security for a specific transport is available nor server only
      authentication is required.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document registers the following TCP and UDP port(s) with
      IANA:</t>

      <t><figure>
          <preamble></preamble>

          <artwork><![CDATA[ Keyword         Decimal   Description
 -------        -------    -----------
 ieee-mih-IS    XXX/tcp    Media Independent Handover Information Services
 ieee-mih-IS    XXX/udp    Media Independent Handover Information Services
 ieee-mih-ES    XXX/tcp    Media Independent Handover Event Services
 ieee-mih-ES    XXX/udp    Media Independent Handover Event Services
 ieee-mih-CS    XXX/tcp    Media Independent Handover Command Services
 ieee-mih-CS    XXX/udp    Media Independent Handover Command Services
]]></artwork>

          <postamble></postamble>
        </figure></t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Patrick Stupar for his valuable
      comments and fruitful discussions.</t>
    </section>

    <section anchor="appendix" title="Appendix">
      <t>This appendix contains AAA specifications to convey MoS related
      information from the AAAh to the NAS for scenario 3. Due to lack of time
      we did not post a separate ID.</t>

      <section title="Attribute Value Pair Definitions">
        <t></t>

        <section title="MoS Info">
          <t>The MoS-Info AVP (AVP code TBD) is type of Grouped and contains
          necessary information to assign a MoS to the MN. When the MoS-Info
          AVP is present in a message, it MUST contain either a
          MIH-MoS-Address AVP or a MIH-MoS-FQDN AVP, but not both. The grouped
          AVP has the following grammar:</t>

          <figure>
            <preamble></preamble>

            <artwork><![CDATA[artwork <MoS-Info> ::= < AVP Header: TBD >
                             [ MIH-MoS-Address ]
                             [ MIH-MoS-FQDN ]
                           * [ AVP ]]]></artwork>

            <postamble></postamble>
          </figure>
        </section>

        <section title="MIH-MoS-Address AVP ">
          <t>The MIH-MoS-Address AVP (AVP Code TBD) is of type Address and
          contains the MoS address. The Diameter server MAY decide to assign a
          MoS to the MN that is in close proximity to the point of attachment
          (e.g., determined by the NAS-Identifier AVP). There may be other
          reasons for dynamically assigning MoSs to the MN, for example to
          share the traffic load.</t>

          <t>This AVP MAY also be attached by the NAS when sent to the
          Diameter server in a request message as a hint of a locally assigned
          MoS address.</t>
        </section>

        <section title="MIH-MoS-FQDN AVP">
          <t>The MIH-MoS-FQDN AVP (AVP Code TBD) is of type UTF8String and
          contains the FQDN of a MoS. The usage of this AVP is equivalent to
          the MIH-MoS-Address AVP but offers an additional level of
          indirection via the DNS infrastructure.</t>
        </section>

        <section title="MoS Capability">
          <t>The MoS-Capability AVP (AVP Code TBD) is of type Unsigned64 and
          contains a 64 bits flags field of supported capabilities of the
          NAS/ASP. Sending and receiving the MoS-Capability AVP with value 0
          MUST be supported.</t>

          <t>The NAS MAY include this AVP to indicate capabilities of the
          NAS/ASP to the Diameter server. For example, the NAS may indicate
          that a local MoS can be provided. Similarly, the Diameter server MAY
          include this AVP to inform the NAS/ASP about which of the NAS/ASP
          indicated capabilities are supported or authorized by the
          ASA/MSA(/MSP).</t>

          <t>The following capabilities are defined in this document:<list
              style="symbols">
              <t>MoS_SERVCE_CAPABILITY (0x0000000000000000) -- The
              MoS-Capability AVP MAY contain value 0 (zero) with the semantics
              that are defined in this document for the Mobile IPv6
              bootstrapping functionality. This 'zero' flag is always
              implicitly set when the MoS AVP is used.</t>

              <t>LOCAL_MOS_ASSIGNMENT (0x0000000000000001) -- This flag is set
              by the NAS/ASP when a local MoS can be assigned to the MN. This
              flag is set by the ASA/MSA(/MSP) when the use of a local MoS is
              authorized.</t>
            </list></t>
        </section>
      </section>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119" include="reference.RFC.2181" include="reference.RFC.4282" include="reference.I-D.ietf-tsvwg-udp-guidelines" 
include="reference.I-D.ietf-mipshop-mis-ps"
include="reference.RFC.1536" include="reference.RFC.2988" include="reference.RFC.4787" include="reference.RFC.1533"
include="reference.I-D.draft-bajko-mos-dns-discovery-00" include="reference.I-D.draft-bajko-mos-dhcp-options-00"
include="reference.RFC.4033" include="reference.RFC.3118" include="reference.RFC.4641"
include="reference.RFC.2132" include="reference.RFC.4346" include="reference.RFC.4366" include="reference.RFC.2401"
include="reference.I-D.ietf-mip6-bootstrapping-integrated-dhc" include="reference.I-D.ietf-dhc-dhcpv6-opt-dnsdomain"
include="reference.RFC.3849" include="reference.RFC.3315" include="reference.RFC.4347"
include="reference.I-D.ietf-mip6-hiopt" include="reference.I-D.ietf-dime-mip6-integrated"
include="reference.I-D.draft-rahman-mipshop-mih-transport-03"?>

      <reference anchor="IEEE80221">
        <front>
          <title abbrev="IEEE 802.21 Draft Standard">Draft IEEE Standard for
          Local and Metropolitan Area Networks: Media Independent Handover
          Services</title>

          <date month="July" year="2007" />
        </front>

        <seriesInfo name="IEEE LAN/MAN Draft " value="IEEE P802.21/D07.00" />
      </reference>
    </references>

    <references title="Informative References"></references>
  </back>
</rfc>

_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

---

From: Nada Golmie <[email-masked]>
Date: Mon, 17 Dec 2007 14:38:23 -0500

Hi Telemaco,

No problem.  To do that though, I would need the list of agreed upon 
edits. Do we have such a list?
Alternatively, let's circulate edits on the mailing list. I will capture 
that before January 3rd.

-Nada

Telemaco Melia wrote:
> ------------------------------------------------------------------------
>

-- 
Nada Golmie, Ph.D. 
Manager, High Speed Network Technologies Group
National Institute of Standards and Technology
100 Bureau Dr. Stop 8920
Gaithersburg, MD 20899
Email: [email-masked]
Phone: (301) 975-4190
Fax:   (301) 590-0932
Web: http://w3.antd.nist.gov

---

From: Telemaco Melia <[email-masked]>
Date: Tue, 18 Dec 2007 10:01:12 +0100

I think we need to:
- address Srini's comments
- address Cheng Hong' s comments
- update the text about the transport  recommendation as agreed in Vancouver

Anything missing?

tele

Nada Golmie ha scritto:
> Alternatively, let's circulate edits on the mailing list. I will 
> capture that before January 3rd.
>
> -Nada
>
>
> Telemaco Melia wrote:
>> Guys,
>>
>> Please find attached the xml source. I use xmlMind to edit and 
>> xml2rfc to convert...pretty handy tools.
>>