<?xml version="1.0" encoding="UTF-8"?>
<rfc-index xmlns="http://www.rfc-editor.org/rfc-index" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.rfc-editor.org/rfc-index http://www.rfc-editor.org/rfc-index.xsd">
    <bcp-entry>
        <doc-id>BCP0001</doc-id>
        <is-also>
            <doc-id>RFC1818</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0002</doc-id>
        <is-also>
            <doc-id>RFC1871</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0003</doc-id>
        <is-also>
            <doc-id>RFC1915</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0004</doc-id>
        <is-also>
            <doc-id>RFC1917</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0005</doc-id>
        <is-also>
            <doc-id>RFC1918</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0006</doc-id>
        <is-also>
            <doc-id>RFC1930</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0007</doc-id>
        <is-also>
            <doc-id>RFC2008</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0008</doc-id>
        <is-also>
            <doc-id>RFC2014</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0009</doc-id>
        <is-also>
            <doc-id>RFC2026</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0010</doc-id>
        <is-also>
            <doc-id>RFC3777</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0011</doc-id>
        <is-also>
            <doc-id>RFC2028</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0012</doc-id>
        <is-also>
            <doc-id>RFC2050</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0013</doc-id>
        <is-also>
            <doc-id>RFC2048</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0014</doc-id>
        <is-also>
            <doc-id>RFC2119</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0015</doc-id>
        <is-also>
            <doc-id>RFC2148</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0016</doc-id>
        <is-also>
            <doc-id>RFC2182</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0017</doc-id>
        <is-also>
            <doc-id>RFC2219</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0018</doc-id>
        <is-also>
            <doc-id>RFC2277</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0019</doc-id>
        <is-also>
            <doc-id>RFC2978</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0020</doc-id>
        <is-also>
            <doc-id>RFC2317</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0021</doc-id>
        <is-also>
            <doc-id>RFC2350</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0022</doc-id>
        <is-also>
            <doc-id>RFC2360</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0023</doc-id>
        <is-also>
            <doc-id>RFC2365</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0024</doc-id>
        <is-also>
            <doc-id>RFC2379</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0025</doc-id>
        <is-also>
            <doc-id>RFC2418</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0026</doc-id>
        <is-also>
            <doc-id>RFC2434</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0027</doc-id>
        <is-also>
            <doc-id>RFC2438</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0028</doc-id>
        <is-also>
            <doc-id>RFC2488</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0029</doc-id>
        <is-also>
            <doc-id>RFC2489</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0030</doc-id>
        <is-also>
            <doc-id>RFC2505</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0031</doc-id>
        <is-also>
            <doc-id>RFC2506</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0032</doc-id>
        <is-also>
            <doc-id>RFC2606</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0033</doc-id>
        <is-also>
            <doc-id>RFC2611</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0034</doc-id>
        <is-also>
            <doc-id>RFC2644</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0035</doc-id>
        <is-also>
            <doc-id>RFC2717</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0036</doc-id>
        <is-also>
            <doc-id>RFC2736</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0037</doc-id>
        <is-also>
            <doc-id>RFC2780</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0038</doc-id>
        <is-also>
            <doc-id>RFC2827</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0039</doc-id>
        <is-also>
            <doc-id>RFC2850</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0040</doc-id>
        <is-also>
            <doc-id>RFC2870</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0041</doc-id>
        <is-also>
            <doc-id>RFC2914</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0042</doc-id>
        <is-also>
            <doc-id>RFC2929</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0043</doc-id>
        <is-also>
            <doc-id>RFC2939</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0044</doc-id>
        <is-also>
            <doc-id>RFC2964</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0045</doc-id>
        <is-also>
            <doc-id>RFC3005</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0046</doc-id>
        <is-also>
            <doc-id>RFC3013</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0047</doc-id>
        <is-also>
            <doc-id>RFC3066</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0048</doc-id>
        <is-also>
            <doc-id>RFC3150</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0049</doc-id>
        <is-also>
            <doc-id>RFC3152</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0050</doc-id>
        <is-also>
            <doc-id>RFC3155</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0051</doc-id>
        <is-also>
            <doc-id>RFC3171</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0052</doc-id>
        <is-also>
            <doc-id>RFC3172</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0053</doc-id>
        <is-also>
            <doc-id>RFC3180</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0054</doc-id>
        <is-also>
            <doc-id>RFC3184</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0055</doc-id>
        <is-also>
            <doc-id>RFC3227</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0056</doc-id>
        <is-also>
            <doc-id>RFC3205</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0057</doc-id>
        <is-also>
            <doc-id>RFC3228</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0058</doc-id>
        <is-also>
            <doc-id>RFC3233</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0059</doc-id>
        <is-also>
            <doc-id>RFC3349</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0060</doc-id>
        <is-also>
            <doc-id>RFC3360</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0061</doc-id>
        <is-also>
            <doc-id>RFC3365</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0062</doc-id>
        <is-also>
            <doc-id>RFC3366</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0063</doc-id>
        <is-also>
            <doc-id>RFC3372</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0064</doc-id>
        <is-also>
            <doc-id>RFC3383</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0065</doc-id>
        <is-also>
            <doc-id>RFC3405</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0066</doc-id>
        <is-also>
            <doc-id>RFC3406</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0067</doc-id>
        <is-also>
            <doc-id>RFC3427</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0068</doc-id>
        <is-also>
            <doc-id>RFC3438</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0069</doc-id>
        <is-also>
            <doc-id>RFC3449</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0070</doc-id>
        <is-also>
            <doc-id>RFC3470</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0071</doc-id>
        <is-also>
            <doc-id>RFC3481</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0072</doc-id>
        <is-also>
            <doc-id>RFC3552</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0073</doc-id>
        <is-also>
            <doc-id>RFC3553</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0074</doc-id>
        <is-also>
            <doc-id>RFC3584</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0075</doc-id>
        <is-also>
            <doc-id>RFC3665</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0076</doc-id>
        <is-also>
            <doc-id>RFC3666</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0077</doc-id>
        <is-also>
            <doc-id>RFC3677</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0078</doc-id>
        <is-also>
            <doc-id>RFC3978</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0079</doc-id>
        <is-also>
            <doc-id>RFC3979</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0080</doc-id>
        <is-also>
            <doc-id>RFC3681</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0081</doc-id>
        <is-also>
            <doc-id>RFC3688</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0082</doc-id>
        <is-also>
            <doc-id>RFC3692</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0083</doc-id>
        <is-also>
            <doc-id>RFC3683</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0084</doc-id>
        <is-also>
            <doc-id>RFC3704</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0085</doc-id>
        <is-also>
            <doc-id>RFC3725</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0086</doc-id>
        <is-also>
            <doc-id>RFC3766</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0087</doc-id>
        <is-also>
            <doc-id>RFC3785</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0088</doc-id>
        <is-also>
            <doc-id>RFC3818</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0089</doc-id>
        <is-also>
            <doc-id>RFC3819</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0090</doc-id>
        <is-also>
            <doc-id>RFC3864</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0091</doc-id>
        <is-also>
            <doc-id>RFC3901</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0092</doc-id>
        <is-also>
            <doc-id>RFC3932</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0093</doc-id>
        <is-also>
            <doc-id>RFC3933</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0094</doc-id>
        <is-also>
            <doc-id>RFC3934</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0095</doc-id>
        <is-also>
            <doc-id>RFC3935</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0096</doc-id>
        <is-also>
            <doc-id>RFC3936</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0097</doc-id>
        <is-also>
            <doc-id>RFC3967</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0098</doc-id>
        <is-also>
            <doc-id>RFC3968</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0099</doc-id>
        <is-also>
            <doc-id>RFC3969</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0100</doc-id>
        <is-also>
            <doc-id>RFC4020</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0101</doc-id>
        <is-also>
            <doc-id>RFC4071</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0102</doc-id>
        <is-also>
            <doc-id>RFC4052</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0103</doc-id>
        <is-also>
            <doc-id>RFC4053</doc-id>
        </is-also>
    </bcp-entry>
    <bcp-entry>
        <doc-id>BCP0104</doc-id>
        <is-also>
            <doc-id>RFC4084</doc-id>
        </is-also>
    </bcp-entry>
    <fyi-entry>
        <doc-id>FYI0001</doc-id>
        <is-also>
            <doc-id>RFC1150</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0002</doc-id>
        <is-also>
            <doc-id>RFC1470</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0003</doc-id>
        <is-also>
            <doc-id>RFC1175</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0004</doc-id>
        <is-also>
            <doc-id>RFC2664</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0005</doc-id>
        <is-also>
            <doc-id>RFC1178</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0006</doc-id>
        <is-also>
            <doc-id>RFC1198</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0007</doc-id>
        <is-also>
            <doc-id>RFC1207</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0008</doc-id>
        <is-also>
            <doc-id>RFC2196</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0009</doc-id>
        <is-also>
            <doc-id>RFC1336</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0010</doc-id>
        <is-also>
            <doc-id>RFC1402</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0011</doc-id>
        <is-also>
            <doc-id>RFC2116</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0012</doc-id>
        <is-also>
            <doc-id>RFC1302</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0013</doc-id>
        <is-also>
            <doc-id>RFC1308</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0014</doc-id>
        <is-also>
            <doc-id>RFC1309</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0015</doc-id>
        <is-also>
            <doc-id>RFC1355</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0016</doc-id>
        <is-also>
            <doc-id>RFC1359</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0017</doc-id>
        <is-also>
            <doc-id>RFC3160</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0018</doc-id>
        <is-also>
            <doc-id>RFC1983</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0019</doc-id>
        <is-also>
            <doc-id>RFC1463</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0020</doc-id>
        <is-also>
            <doc-id>RFC1462</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0021</doc-id>
        <is-also>
            <doc-id>RFC1491</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0022</doc-id>
        <is-also>
            <doc-id>RFC1941</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0023</doc-id>
        <is-also>
            <doc-id>RFC1580</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0024</doc-id>
        <is-also>
            <doc-id>RFC1635</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0025</doc-id>
        <is-also>
            <doc-id>RFC1689</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0026</doc-id>
        <is-also>
            <doc-id>RFC1709</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0027</doc-id>
        <is-also>
            <doc-id>RFC1713</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0028</doc-id>
        <is-also>
            <doc-id>RFC1855</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0029</doc-id>
        <is-also>
            <doc-id>RFC2007</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0030</doc-id>
        <is-also>
            <doc-id>RFC2151</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0031</doc-id>
        <is-also>
            <doc-id>RFC2150</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0032</doc-id>
        <is-also>
            <doc-id>RFC2235</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0033</doc-id>
        <is-also>
            <doc-id>RFC2398</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0034</doc-id>
        <is-also>
            <doc-id>RFC2504</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0035</doc-id>
        <is-also>
            <doc-id>RFC2635</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0036</doc-id>
        <is-also>
            <doc-id>RFC2828</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0037</doc-id>
        <is-also>
            <doc-id>RFC2901</doc-id>
        </is-also>
    </fyi-entry>
    <fyi-entry>
        <doc-id>FYI0038</doc-id>
        <is-also>
            <doc-id>RFC3098</doc-id>
        </is-also>
    </fyi-entry>
    <rfc-entry>
        <doc-id>RFC0001</doc-id>
        <title>Host Software</title>
        <author>
            <name>S. Crocker</name>
        </author>
        <date>
            <month>April</month>
            <day>07</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21088</char-count>
            <page-count>11</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0002</doc-id>
        <title>Host software</title>
        <author>
            <name>B. Duvall</name>
        </author>
        <date>
            <month>April</month>
            <day>09</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17145</char-count>
            <page-count>10</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0003</doc-id>
        <title>Documentation conventions</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>April</month>
            <day>09</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2323</char-count>
            <page-count>2</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0010</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0004</doc-id>
        <title>Network timetable</title>
        <author>
            <name>E.B. Shapiro</name>
        </author>
        <date>
            <month>March</month>
            <day>24</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5933</char-count>
            <page-count>6</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0005</doc-id>
        <title>Decode Encode Language (DEL)</title>
        <author>
            <name>J. Rulifson</name>
        </author>
        <date>
            <month>June</month>
            <day>02</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26408</char-count>
            <page-count>17</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0006</doc-id>
        <title>Conversation with Bob Kahn</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>April</month>
            <day>10</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1568</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0007</doc-id>
        <title>Host-IMP interface</title>
        <author>
            <name>G. Deloche</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13408</char-count>
            <page-count>7</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0008</doc-id>
        <title>Functional specifications for the ARPA Network</title>
        <author>
            <name>G. Deloche</name>
        </author>
        <date>
            <month>May</month>
            <day>05</day>
            <year>1969</year>
        </date>
        <notes>Not Available Online.</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0009</doc-id>
        <title>Host software</title>
        <author>
            <name>G. Deloche</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1969</year>
        </date>
        <notes>Not Available Online.</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0010</doc-id>
        <title>Documentation conventions</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>July</month>
            <day>29</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3348</char-count>
            <page-count>3</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0003</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0016</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC0024</doc-id>
            <doc-id>RFC0027</doc-id>
            <doc-id>RFC0030</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0011</doc-id>
        <title>Implementation of the Host-Host software procedures in GORDO</title>
        <author>
            <name>G. Deloche</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1969</year>
        </date>
        <notes>Not Available Online.</notes>
        <obsoleted-by>
            <doc-id>RFC0033</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0012</doc-id>
        <title>IMP-Host interface flow diagrams</title>
        <author>
            <name>M. Wingfield</name>
        </author>
        <date>
            <month>August</month>
            <day>26</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>177</char-count>
            <page-count>1</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>1489750</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>1163721</char-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0013</doc-id>
        <title>Zero Text Length EOF Message</title>
        <author>
            <name>V. Cerf</name>
        </author>
        <date>
            <month>August</month>
            <day>20</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1070</char-count>
            <page-count>1</page-count>
        </format>
        <notes>Referring to NWG/RFC 11.</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0014</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0015</doc-id>
        <title>Network subsystem for time sharing hosts</title>
        <author>
            <name>C.S. Carr</name>
        </author>
        <date>
            <month>September</month>
            <day>25</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10695</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0016</doc-id>
        <title>M.I.T</title>
        <author>
            <name>S. Crocker</name>
        </author>
        <date>
            <month>August</month>
            <day>27</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>682</char-count>
            <page-count>1</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0010</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0024</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC0024</doc-id>
            <doc-id>RFC0027</doc-id>
            <doc-id>RFC0030</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0017</doc-id>
        <title>Some questions re: Host-IMP Protocol</title>
        <author>
            <name>J.E. Kreznar</name>
        </author>
        <date>
            <month>August</month>
            <day>27</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6065</char-count>
            <page-count>4</page-count>
        </format>
        <notes>17a Follows</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0018</doc-id>
        <title>IMP-IMP and HOST-HOST Control Links</title>
        <author>
            <name>V. Cerf</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>634</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0019</doc-id>
        <title>Two protocol suggestions to reduce congestion at swap bound nodes</title>
        <author>
            <name>J.E. Kreznar</name>
        </author>
        <date>
            <month>October</month>
            <day>07</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3392</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0020</doc-id>
        <title>ASCII format for network interchange</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <date>
            <month>October</month>
            <day>16</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18504</char-count>
            <page-count>9</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0021</doc-id>
        <title>Network meeting</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <date>
            <month>October</month>
            <day>17</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2143</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0022</doc-id>
        <title>Host-host control message formats</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <date>
            <month>October</month>
            <day>17</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4606</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0023</doc-id>
        <title>Transmission of Multiple Control Messages</title>
        <author>
            <name>G. Gregg</name>
        </author>
        <date>
            <month>October</month>
            <day>16</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>690</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0024</doc-id>
        <title>Documentation Conventions</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>November</month>
            <day>21</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3460</char-count>
            <page-count>3</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0016</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC0010</doc-id>
            <doc-id>RFC0016</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0027</doc-id>
            <doc-id>RFC0030</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0025</doc-id>
        <title>No High Link Numbers</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>October</month>
            <day>30</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>479</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0026</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0027</doc-id>
        <title>Documentation Conventions</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>December</month>
            <day>09</day>
            <year>1969</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3661</char-count>
            <page-count>3</page-count>
        </format>
        <updates>
            <doc-id>RFC0010</doc-id>
            <doc-id>RFC0016</doc-id>
            <doc-id>RFC0024</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0030</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0028</doc-id>
        <title>Time Standards</title>
        <author>
            <name>W.K. English</name>
        </author>
        <date>
            <month>January</month>
            <day>13</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>557</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0029</doc-id>
        <title>Response to RFC 28</title>
        <author>
            <name>R.E. Kahn</name>
        </author>
        <date>
            <month>January</month>
            <day>19</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>790</char-count>
            <page-count>1</page-count>
        </format>
        <see-also>
            <doc-id>RFC0028</doc-id>
        </see-also>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0030</doc-id>
        <title>Documentation Conventions</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>February</month>
            <day>04</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4041</char-count>
            <page-count>3</page-count>
        </format>
        <updates>
            <doc-id>RFC0010</doc-id>
            <doc-id>RFC0016</doc-id>
            <doc-id>RFC0024</doc-id>
            <doc-id>RFC0027</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0031</doc-id>
        <title>Binary Message Forms in Computer</title>
        <author>
            <name>D. Bobrow</name>
        </author>
        <author>
            <name>W.R. Sutherland</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1968</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11191</char-count>
            <page-count>7</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0032</doc-id>
        <title>Some Thoughts on SRI's Proposed Real Time Clock</title>
        <author>
            <name>J. Cole</name>
        </author>
        <date>
            <month>February</month>
            <day>05</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2216</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0033</doc-id>
        <title>New Host-Host Protocol</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>February</month>
            <day>12</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44167</char-count>
            <page-count>19</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0011</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC0036</doc-id>
            <doc-id>RFC0047</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0034</doc-id>
        <title>Some Brief Preliminary Notes on the Augmentation Research Center Clock</title>
        <author>
            <name>W.K. English</name>
        </author>
        <date>
            <month>February</month>
            <day>26</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2534</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0035</doc-id>
        <title>Network Meeting</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>March</month>
            <day>03</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1282</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0036</doc-id>
        <title>Protocol Notes</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>March</month>
            <day>16</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13893</char-count>
            <page-count>8</page-count>
        </format>
        <updates>
            <doc-id>RFC0033</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0039</doc-id>
            <doc-id>RFC0044</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0037</doc-id>
        <title>Network Meeting Epilogue, etc</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>March</month>
            <day>20</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9107</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0038</doc-id>
        <title>Comments on Network Protocol from NWG/RFC #36</title>
        <author>
            <name>S.M. Wolfe</name>
        </author>
        <date>
            <month>March</month>
            <day>20</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2536</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0039</doc-id>
        <title>Comments on Protocol Re: NWG/RFC #36</title>
        <author>
            <name>E. Harslem</name>
        </author>
        <author>
            <name>J.F. Heafner</name>
        </author>
        <date>
            <month>March</month>
            <day>25</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4779</char-count>
            <page-count>3</page-count>
        </format>
        <updates>
            <doc-id>RFC0036</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0040</doc-id>
        <title>More Comments on the Forthcoming Protocol</title>
        <author>
            <name>E. Harslem</name>
        </author>
        <author>
            <name>J.F. Heafner</name>
        </author>
        <date>
            <month>March</month>
            <day>27</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3825</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0041</doc-id>
        <title>IMP-IMP Teletype Communication</title>
        <author>
            <name>J.T. Melvin</name>
        </author>
        <date>
            <month>March</month>
            <day>30</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1038</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0042</doc-id>
        <title>Message Data Types</title>
        <author>
            <name>E. Ancona</name>
        </author>
        <date>
            <month>March</month>
            <day>31</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5247</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0043</doc-id>
        <title>Proposed Meeting</title>
        <author>
            <name>A.G. Nemeth</name>
        </author>
        <date>
            <month>April</month>
            <day>08</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1600</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0044</doc-id>
        <title>Comments on NWG/RFC 33 and 36</title>
        <author>
            <name>A. Shoshani</name>
        </author>
        <author>
            <name>R. Long</name>
        </author>
        <author>
            <name>A. Landsberg</name>
        </author>
        <date>
            <month>April</month>
            <day>10</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7381</char-count>
            <page-count>3</page-count>
        </format>
        <updates>
            <doc-id>RFC0036</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0045</doc-id>
        <title>New Protocol is Coming</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>April</month>
            <day>14</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1130</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0046</doc-id>
        <title>ARPA Network protocol notes</title>
        <author>
            <name>E. Meyer</name>
        </author>
        <date>
            <month>April</month>
            <day>17</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41338</char-count>
            <page-count>17</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0047</doc-id>
        <title>BBN's Comments on NWG/RFC #33</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>S. Crocker</name>
        </author>
        <date>
            <month>April</month>
            <day>20</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5343</char-count>
            <page-count>4</page-count>
        </format>
        <updates>
            <doc-id>RFC0033</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0048</doc-id>
        <title>Possible protocol plateau</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>April</month>
            <day>21</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41696</char-count>
            <page-count>18</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0049</doc-id>
        <title>Conversations with S. Crocker (UCLA)</title>
        <author>
            <name>E. Meyer</name>
        </author>
        <date>
            <month>April</month>
            <day>25</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12384</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0050</doc-id>
        <title>Comments on the Meyer Proposal</title>
        <author>
            <name>E. Harslen</name>
        </author>
        <author>
            <name>J. Heafner</name>
        </author>
        <date>
            <month>April</month>
            <day>30</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4070</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0051</doc-id>
        <title>Proposal for a Network Interchange Language</title>
        <author>
            <name>M. Elie</name>
        </author>
        <date>
            <month>May</month>
            <day>04</day>
            <year>1970</year>
        </date>
        <notes>Not Available Online</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0052</doc-id>
        <title>Updated distribution list</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5088</char-count>
            <page-count>3</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0069</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0053</doc-id>
        <title>Official protocol mechanism</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>June</month>
            <day>09</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2330</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0054</doc-id>
        <title>Official Protocol Proffering</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J. Newkirk</name>
        </author>
        <author>
            <name>M. Kraley</name>
        </author>
        <date>
            <month>June</month>
            <day>18</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20131</char-count>
            <page-count>9</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0057</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0055</doc-id>
        <title>Prototypical implementation of the NCP</title>
        <author>
            <name>J. Newkirk</name>
        </author>
        <author>
            <name>M. Kraley</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>June</month>
            <day>19</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48070</char-count>
            <page-count>23</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0056</doc-id>
        <title>Third Level Protocol: Logger Protocol</title>
        <author>
            <name>E. Belove</name>
        </author>
        <author>
            <name>D. Black</name>
        </author>
        <author>
            <name>R. Flegal</name>
        </author>
        <author>
            <name>L.G. Farquar</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13066</char-count>
            <page-count>6</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0057</doc-id>
        <title>Thoughts and Reflections on NWG/RFC 54</title>
        <author>
            <name>M. Kraley</name>
        </author>
        <author>
            <name>J. Newkirk</name>
        </author>
        <date>
            <month>June</month>
            <day>19</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8360</char-count>
            <page-count>5</page-count>
        </format>
        <updates>
            <doc-id>RFC0054</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0058</doc-id>
        <title>Logical Message Synchronization</title>
        <author>
            <name>T.P. Skinner</name>
        </author>
        <date>
            <month>June</month>
            <day>26</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3767</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0059</doc-id>
        <title>Flow Control - Fixed Versus Demand Allocation</title>
        <author>
            <name>E. Meyer</name>
        </author>
        <date>
            <month>June</month>
            <day>27</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17691</char-count>
            <page-count>7</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0060</doc-id>
        <title>Simplified NCP Protocol</title>
        <author>
            <name>R.B. Kalin</name>
        </author>
        <date>
            <month>July</month>
            <day>13</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18941</char-count>
            <page-count>8</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0061</doc-id>
        <title>Note on Interprocess Communication in a Resource Sharing Computer Network</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>July</month>
            <day>17</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43946</char-count>
            <page-count>18</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0062</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0062</doc-id>
        <title>Systems for Interprocess Communication in a Resource Sharing Computer Network</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>August</month>
            <day>03</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>55784</char-count>
            <page-count>20</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0061</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0063</doc-id>
        <title>Belated Network Meeting Report</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <date>
            <month>July</month>
            <day>31</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2961</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0064</doc-id>
        <title>Getting rid of marking</title>
        <author>
            <name>M. Elie</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7556</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0065</doc-id>
        <title>Comments on Host/Host Protocol document #1</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>August</month>
            <day>29</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5628</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0066</doc-id>
        <title>NIC - third level ideas and other noise</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>August</month>
            <day>26</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4575</char-count>
            <page-count>3</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0123</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC0080</doc-id>
            <doc-id>RFC0093</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0067</doc-id>
        <title>Proposed Change to Host/IMP Spec to Eliminate Marking</title>
        <author>
            <name>W.R. Crowther</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1534</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0068</doc-id>
        <title>Comments on Memory Allocation Control Commands: CEASE, ALL, GVB, RET, and RFNM</title>
        <author>
            <name>M. Elie</name>
        </author>
        <date>
            <month>August</month>
            <day>31</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5041</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0069</doc-id>
        <title>Distribution List Change for MIT</title>
        <author>
            <name>A.K. Bhushan</name>
        </author>
        <date>
            <month>September</month>
            <day>22</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>841</char-count>
            <page-count>1</page-count>
        </format>
        <updates>
            <doc-id>RFC0052</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0070</doc-id>
        <title>Note on Padding</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>October</month>
            <day>15</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12790</char-count>
            <page-count>9</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0228</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0071</doc-id>
        <title>Reallocation in Case of Input Error</title>
        <author>
            <name>T. Schipper</name>
        </author>
        <date>
            <month>September</month>
            <day>25</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1265</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0072</doc-id>
        <title>Proposed Moratorium on Changes to Network Protocol</title>
        <author>
            <name>R.D. Bressler</name>
        </author>
        <date>
            <month>September</month>
            <day>28</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4047</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0073</doc-id>
        <title>Response to NWG/RFC 67</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>September</month>
            <day>25</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1268</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0074</doc-id>
        <title>Specifications for network use of the UCSB On-Line System</title>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>October</month>
            <day>16</day>
            <year>1970</year>
        </date>
        <notes>Not Available Online</notes>
        <updated-by>
            <doc-id>RFC0217</doc-id>
            <doc-id>RFC0225</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0075</doc-id>
        <title>Network Meeting</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>October</month>
            <day>14</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1318</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0076</doc-id>
        <title>Connection by name: User oriented protocol</title>
        <author>
            <name>J. Bouknight</name>
        </author>
        <author>
            <name>J. Madden</name>
        </author>
        <author>
            <name>G.R. Grossman</name>
        </author>
        <date>
            <month>October</month>
            <day>28</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26504</char-count>
            <page-count>15</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0077</doc-id>
        <title>Network meeting report</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <day>20</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19196</char-count>
            <page-count>9</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0078</doc-id>
        <title>NCP Status Report: UCSB/Rand</title>
        <author>
            <name>E. Harslem</name>
        </author>
        <author>
            <name>J.F. Heafner</name>
        </author>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1303</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0079</doc-id>
        <title>Logger Protocol error</title>
        <author>
            <name>E. Meyer</name>
        </author>
        <date>
            <month>November</month>
            <day>16</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1515</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0080</doc-id>
        <title>Protocols and Data Formats</title>
        <author>
            <name>E. Harslem</name>
        </author>
        <author>
            <name>J.F. Heafner</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17620</char-count>
            <page-count>9</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0123</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0066</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0093</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0081</doc-id>
        <title>Request for Reference Information</title>
        <author>
            <name>J. Bouknight</name>
        </author>
        <date>
            <month>December</month>
            <day>03</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>956</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0082</doc-id>
        <title>Network Meeting Notes</title>
        <author>
            <name>E. Meyer</name>
        </author>
        <date>
            <month>December</month>
            <day>09</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38023</char-count>
            <page-count>18</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0083</doc-id>
        <title>Language-machine for data reconfiguration</title>
        <author>
            <name>R.H. Anderson</name>
        </author>
        <author>
            <name>E. Harslem</name>
        </author>
        <author>
            <name>J.F. Heafner</name>
        </author>
        <date>
            <month>December</month>
            <day>18</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22253</char-count>
            <page-count>13</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0084</doc-id>
        <title>List of NWG/RFC's 1-80</title>
        <author>
            <name>J.B. North</name>
        </author>
        <date>
            <month>December</month>
            <day>23</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12613</char-count>
            <page-count>8</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0085</doc-id>
        <title>Network Working Group meeting</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>December</month>
            <day>28</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1547</char-count>
            <page-count>1</page-count>
        </format>
        <notes>N</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0086</doc-id>
        <title>Proposal for a Network Standard Format for a Data Stream to Control Graphics Display</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>January</month>
            <day>05</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7117</char-count>
            <page-count>6</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0125</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0087</doc-id>
        <title>Topic for Discussion at the Next Network Working Group Meeting</title>
        <author>
            <name>A. Vezza</name>
        </author>
        <date>
            <month>January</month>
            <day>12</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3593</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0088</doc-id>
        <title>NETRJS: A third level protocol for Remote Job Entry</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <author>
            <name>S.M. Wolfe</name>
        </author>
        <date>
            <month>January</month>
            <day>13</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19691</char-count>
            <page-count>9</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0189</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0089</doc-id>
        <title>Some historic moments in networking</title>
        <author>
            <name>R.M. Metcalfe</name>
        </author>
        <date>
            <month>January</month>
            <day>19</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16832</char-count>
            <page-count>7</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0090</doc-id>
        <title>CCN as a Network Service Center</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>January</month>
            <day>25</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11929</char-count>
            <page-count>6</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0091</doc-id>
        <title>Proposed User-User Protocol</title>
        <author>
            <name>G.H. Mealy</name>
        </author>
        <date>
            <month>December</month>
            <day>27</day>
            <year>1970</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27005</char-count>
            <page-count>12</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0092</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0093</doc-id>
        <title>Initial Connection Protocol</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>January</month>
            <day>27</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1746</char-count>
            <page-count>1</page-count>
        </format>
        <updates>
            <doc-id>RFC0066</doc-id>
            <doc-id>RFC0080</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0094</doc-id>
        <title>Some thoughts on Network Graphics</title>
        <author>
            <name>E. Harslem</name>
        </author>
        <author>
            <name>J.F. Heafner</name>
        </author>
        <date>
            <month>February</month>
            <day>03</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13516</char-count>
            <page-count>6</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0095</doc-id>
        <title>Distribution of NWG/RFC's through the NIC</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>February</month>
            <day>04</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8938</char-count>
            <page-count>5</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0155</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0096</doc-id>
        <title>An Interactive Network Experiment to Study Modes of Access the Network Information Center</title>
        <author>
            <name>R.W. Watson</name>
        </author>
        <date>
            <month>February</month>
            <day>12</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11334</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0097</doc-id>
        <title>First Cut at a Proposed Telnet Protocol</title>
        <author>
            <name>J.T. Melvin</name>
        </author>
        <author>
            <name>R.W. Watson</name>
        </author>
        <date>
            <month>February</month>
            <day>15</day>
            <year>1971</year>
        </date>
        <notes>Not Available Online</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0098</doc-id>
        <title>Logger Protocol Proposal</title>
        <author>
            <name>E. Meyer</name>
        </author>
        <author>
            <name>T. Skinner</name>
        </author>
        <date>
            <month>February</month>
            <day>11</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24536</char-count>
            <page-count>10</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0123</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0099</doc-id>
        <title>Network Meeting</title>
        <author>
            <name>P.M. Karp</name>
        </author>
        <date>
            <month>February</month>
            <day>22</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1010</char-count>
            <page-count>1</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0116</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0100</doc-id>
        <title>Categorization and guide to NWG/RFCs</title>
        <author>
            <name>P.M. Karp</name>
        </author>
        <date>
            <month>February</month>
            <day>26</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>62473</char-count>
            <page-count>37</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0101</doc-id>
        <title>Notes on the Network Working Group meeting, Urbana, Illinois, February 17, 1971</title>
        <author>
            <name>R.W. Watson</name>
        </author>
        <date>
            <month>February</month>
            <day>23</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30343</char-count>
            <page-count>14</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0108</doc-id>
            <doc-id>RFC0123</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0102</doc-id>
        <title>Output of the Host-Host Protocol glitch cleaning committee</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>February</month>
            <day>22</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8511</char-count>
            <page-count>4</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0107</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0103</doc-id>
        <title>Implementation of Interrupt Keys</title>
        <author>
            <name>R.B. Kalin</name>
        </author>
        <date>
            <month>February</month>
            <day>24</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7592</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0104</doc-id>
        <title>Link 191</title>
        <author>
            <name>J.B. Postel</name>
        </author>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>February</month>
            <day>25</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1017</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0105</doc-id>
        <title>Network Specifications for Remote Job Entry and Remote Job Output Retrieval at UCSB</title>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>March</month>
            <day>22</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21938</char-count>
            <page-count>9</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0217</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0106</doc-id>
        <title>User/Server Site Protocol Network Host Questionnaire</title>
        <author>
            <name>T.C. O'Sullivan</name>
        </author>
        <date>
            <month>March</month>
            <day>03</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6946</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0107</doc-id>
        <title>Output of the Host-Host Protocol Glitch Cleaning Committee</title>
        <author>
            <name>R.D. Bressler</name>
        </author>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <author>
            <name>W.R. Crowther</name>
        </author>
        <author>
            <name>G.R. Grossman</name>
        </author>
        <author>
            <name>R.S. Tomlinson</name>
        </author>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>March</month>
            <day>23</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18109</char-count>
            <page-count>12</page-count>
        </format>
        <updates>
            <doc-id>RFC0102</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0111</doc-id>
            <doc-id>RFC0124</doc-id>
            <doc-id>RFC0132</doc-id>
            <doc-id>RFC0154</doc-id>
            <doc-id>RFC0179</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0108</doc-id>
        <title>Attendance list at the Urbana NWG meeting, February 17-19, 1971</title>
        <author>
            <name>R.W. Watson</name>
        </author>
        <date>
            <month>March</month>
            <day>25</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1597</char-count>
            <page-count>2</page-count>
        </format>
        <updates>
            <doc-id>RFC0101</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0109</doc-id>
        <title>Level III Server Protocol for the Lincoln Laboratory NIC 360/67 Host</title>
        <author>
            <name>J.M. Winett</name>
        </author>
        <date>
            <month>March</month>
            <day>24</day>
            <year>1971</year>
        </date>
        <notes>Not Available Online..</notes>
        <see-also>
            <doc-id>RFC0393</doc-id>
        </see-also>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0110</doc-id>
        <title>Conventions for using an IBM 2741 terminal as a user console for access to network server hosts</title>
        <author>
            <name>J.M. Winett</name>
        </author>
        <date>
            <month>March</month>
            <day>25</day>
            <year>1971</year>
        </date>
        <notes>Not Available Online..</notes>
        <updated-by>
            <doc-id>RFC0135</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0111</doc-id>
        <title>Pressure from the Chairman</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>March</month>
            <day>31</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2098</char-count>
            <page-count>2</page-count>
        </format>
        <updates>
            <doc-id>RFC0107</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0130</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0112</doc-id>
        <title>User/Server Site Protocol: Network host questionnaire responses</title>
        <author>
            <name>T.C. O'Sullivan</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1971</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0113</doc-id>
        <title>Network activity report: UCSB Rand</title>
        <author>
            <name>E. Harslem</name>
        </author>
        <author>
            <name>J.F. Heafner</name>
        </author>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>April</month>
            <day>05</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3442</char-count>
            <page-count>2</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0227</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0114</doc-id>
        <title>File Transfer Protocol</title>
        <author>
            <name>A.K. Bhushan</name>
        </author>
        <date>
            <month>April</month>
            <day>10</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38981</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <updated-by>
            <doc-id>RFC0133</doc-id>
            <doc-id>RFC0141</doc-id>
            <doc-id>RFC0171</doc-id>
            <doc-id>RFC0172</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0115</doc-id>
        <title>Some Network Information Center policies on handling documents</title>
        <author>
            <name>R.W. Watson</name>
        </author>
        <author>
            <name>J.B. North</name>
        </author>
        <date>
            <month>April</month>
            <day>16</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16775</char-count>
            <page-count>8</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0116</doc-id>
        <title>Structure of the May NWG Meeting</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>April</month>
            <day>12</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2395</char-count>
            <page-count>1</page-count>
        </format>
        <updates>
            <doc-id>RFC0099</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0131</doc-id>
            <doc-id>RFC0156</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0117</doc-id>
        <title>Some comments on the official protocol</title>
        <author>
            <name>J. Wong</name>
        </author>
        <date>
            <month>April</month>
            <day>07</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7128</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0118</doc-id>
        <title>Recommendations for facility documentation</title>
        <author>
            <name>R.W. Watson</name>
        </author>
        <date>
            <month>April</month>
            <day>16</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4573</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0119</doc-id>
        <title>Network Fortran subprograms</title>
        <author>
            <name>M. Krilanovich</name>
        </author>
        <date>
            <month>April</month>
            <day>21</day>
            <year>1971</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0120</doc-id>
        <title>Network PL1 subprograms</title>
        <author>
            <name>M. Krilanovich</name>
        </author>
        <date>
            <month>April</month>
            <day>21</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37192</char-count>
            <page-count>16</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0121</doc-id>
        <title>Network on-line operators</title>
        <author>
            <name>M. Krilanovich</name>
        </author>
        <date>
            <month>April</month>
            <day>21</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29419</char-count>
            <page-count>13</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0122</doc-id>
        <title>Network specifications for UCSB's Simple-Minded File System</title>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>April</month>
            <day>26</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47638</char-count>
            <page-count>21</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0217</doc-id>
            <doc-id>RFC0269</doc-id>
            <doc-id>RFC0399</doc-id>
            <doc-id>RFC0431</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0123</doc-id>
        <title>Proffered Official ICP</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>April</month>
            <day>20</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4812</char-count>
            <page-count>3</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0066</doc-id>
            <doc-id>RFC0080</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0165</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0098</doc-id>
            <doc-id>RFC0101</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0127</doc-id>
            <doc-id>RFC0143</doc-id>
            <doc-id>RFC0148</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0124</doc-id>
        <title>Typographical error in RFC 107</title>
        <author>
            <name>J.T. Melvin</name>
        </author>
        <date>
            <month>April</month>
            <day>19</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>659</char-count>
            <page-count>1</page-count>
        </format>
        <updates>
            <doc-id>RFC0107</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0125</doc-id>
        <title>Response to RFC 86: Proposal for Network Standard Format for a Graphics Data Stream</title>
        <author>
            <name>J. McConnell</name>
        </author>
        <date>
            <month>April</month>
            <day>18</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8133</char-count>
            <page-count>4</page-count>
        </format>
        <updates>
            <doc-id>RFC0086</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0177</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0126</doc-id>
        <title>Graphics Facilities at Ames Research Center</title>
        <author>
            <name>J. McConnell</name>
        </author>
        <date>
            <month>April</month>
            <day>18</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1974</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0127</doc-id>
        <title>Comments on RFC 123</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>April</month>
            <day>20</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2305</char-count>
            <page-count>2</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0145</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0123</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0151</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0128</doc-id>
        <title>Bytes</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>April</month>
            <day>21</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2745</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0129</doc-id>
        <title>Request for comments on socket name structure</title>
        <author>
            <name>E. Harslem</name>
        </author>
        <author>
            <name>J. Heafner</name>
        </author>
        <author>
            <name>E. Meyer</name>
        </author>
        <date>
            <month>April</month>
            <day>22</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11175</char-count>
            <page-count>6</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0147</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0130</doc-id>
        <title>Response to RFC 111: Pressure from the chairman</title>
        <author>
            <name>J.F. Heafner</name>
        </author>
        <date>
            <month>April</month>
            <day>22</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2580</char-count>
            <page-count>1</page-count>
        </format>
        <updates>
            <doc-id>RFC0111</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0131</doc-id>
        <title>Response to RFC 116: May NWG meeting</title>
        <author>
            <name>E. Harslem</name>
        </author>
        <author>
            <name>J.F. Heafner</name>
        </author>
        <date>
            <month>April</month>
            <day>22</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5375</char-count>
            <page-count>3</page-count>
        </format>
        <updates>
            <doc-id>RFC0116</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0132</doc-id>
        <title>Typographical Error in RFC 107</title>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>April</month>
            <day>28</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1058</char-count>
            <page-count>1</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0154</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0107</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0133</doc-id>
        <title>File Transfer and Error Recovery</title>
        <author>
            <name>R.L. Sunberg</name>
        </author>
        <date>
            <month>April</month>
            <day>27</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8322</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <updates>
            <doc-id>RFC0114</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0134</doc-id>
        <title>Network Graphics meeting</title>
        <author>
            <name>A. Vezza</name>
        </author>
        <date>
            <month>April</month>
            <day>29</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2684</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0135</doc-id>
        <title>Response to NWG/RFC 110</title>
        <author>
            <name>W. Hathaway</name>
        </author>
        <date>
            <month>April</month>
            <day>29</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5282</char-count>
            <page-count>3</page-count>
        </format>
        <updates>
            <doc-id>RFC0110</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0136</doc-id>
        <title>Host accounting and administrative procedures</title>
        <author>
            <name>R.E. Kahn</name>
        </author>
        <date>
            <month>April</month>
            <day>29</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8016</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0137</doc-id>
        <title>Telnet Protocol - a proposed document</title>
        <author>
            <name>T.C. O'Sullivan</name>
        </author>
        <date>
            <month>April</month>
            <day>30</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17606</char-count>
            <page-count>11</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0139</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0138</doc-id>
        <title>Status report on proposed Data Reconfiguration Service</title>
        <author>
            <name>R.H. Anderson</name>
        </author>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <author>
            <name>E. Harslem</name>
        </author>
        <author>
            <name>J.F. Heafner</name>
        </author>
        <author>
            <name>J. Madden</name>
        </author>
        <author>
            <name>R.M. Metcalfe</name>
        </author>
        <author>
            <name>A. Shoshani</name>
        </author>
        <author>
            <name>J.E. White</name>
        </author>
        <author>
            <name>D.C.M. Wood</name>
        </author>
        <date>
            <month>April</month>
            <day>28</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46641</char-count>
            <page-count>23</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0139</doc-id>
        <title>Discussion of Telnet Protocol</title>
        <author>
            <name>T.C. O'Sullivan</name>
        </author>
        <date>
            <month>May</month>
            <day>07</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26085</char-count>
            <page-count>11</page-count>
        </format>
        <updates>
            <doc-id>RFC0137</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0158</doc-id>
        </updated-by>
        <see-also>
            <doc-id>RFC0393</doc-id>
        </see-also>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0140</doc-id>
        <title>Agenda for the May NWG meeting</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>May</month>
            <day>04</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6934</char-count>
            <page-count>4</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0149</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0141</doc-id>
        <title>Comments on RFC 114: A File Transfer Protocol</title>
        <author>
            <name>E. Harslem</name>
        </author>
        <author>
            <name>J.F. Heafner</name>
        </author>
        <date>
            <month>April</month>
            <day>29</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3781</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <updates>
            <doc-id>RFC0114</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0142</doc-id>
        <title>Time-Out Mechanism in the Host-Host Protocol</title>
        <author>
            <name>C. Kline</name>
        </author>
        <author>
            <name>J. Wong</name>
        </author>
        <date>
            <month>May</month>
            <day>03</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4372</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0143</doc-id>
        <title>Regarding proffered official ICP</title>
        <author>
            <name>W. Naylor</name>
        </author>
        <author>
            <name>J. Wong</name>
        </author>
        <author>
            <name>C. Kline</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <day>03</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6963</char-count>
            <page-count>4</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0165</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0123</doc-id>
            <doc-id>RFC0145</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0144</doc-id>
        <title>Data sharing on computer networks</title>
        <author>
            <name>A. Shoshani</name>
        </author>
        <date>
            <month>April</month>
            <day>30</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13744</char-count>
            <page-count>6</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0145</doc-id>
        <title>Initial Connection Protocol Control Commands</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <day>04</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2490</char-count>
            <page-count>2</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>552114</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>15869</char-count>
        </format>
        <obsoletes>
            <doc-id>RFC0127</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0165</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC0143</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0146</doc-id>
        <title>Views on issues relevant to data sharing on computer networks</title>
        <author>
            <name>P.M. Karp</name>
        </author>
        <author>
            <name>D.B. McKay</name>
        </author>
        <author>
            <name>D.C.M. Wood</name>
        </author>
        <date>
            <month>May</month>
            <day>12</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9828</char-count>
            <page-count>6</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0147</doc-id>
        <title>Definition of a socket</title>
        <author>
            <name>J.M. Winett</name>
        </author>
        <date>
            <month>May</month>
            <day>07</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6438</char-count>
            <page-count>3</page-count>
        </format>
        <updates>
            <doc-id>RFC0129</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0148</doc-id>
        <title>Comments on RFC 123</title>
        <author>
            <name>A.K. Bhushan</name>
        </author>
        <date>
            <month>May</month>
            <day>07</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1149</char-count>
            <page-count>1</page-count>
        </format>
        <updates>
            <doc-id>RFC0123</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0149</doc-id>
        <title>Best Laid Plans</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>May</month>
            <day>10</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1057</char-count>
            <page-count>1</page-count>
        </format>
        <updates>
            <doc-id>RFC0140</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0150</doc-id>
        <title>Use of IPC Facilities: A Working Paper</title>
        <author>
            <name>R.B. Kalin</name>
        </author>
        <date>
            <month>May</month>
            <day>05</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28163</char-count>
            <page-count>11</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0151</doc-id>
        <title>Comments on a proffered official ICP: RFCs 123, 127</title>
        <author>
            <name>A. Shoshani</name>
        </author>
        <date>
            <month>May</month>
            <day>10</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3623</char-count>
            <page-count>2</page-count>
        </format>
        <updates>
            <doc-id>RFC0127</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0152</doc-id>
        <title>SRI Artificial Intelligence status report</title>
        <author>
            <name>M. Wilber</name>
        </author>
        <date>
            <month>May</month>
            <day>10</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2726</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0153</doc-id>
        <title>SRI ARC-NIC status</title>
        <author>
            <name>J.T. Melvin</name>
        </author>
        <author>
            <name>R.W. Watson</name>
        </author>
        <date>
            <month>May</month>
            <day>15</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8573</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0154</doc-id>
        <title>Exposition Style</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>May</month>
            <day>12</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1293</char-count>
            <page-count>1</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0132</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC0107</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0155</doc-id>
        <title>ARPA Network mailing lists</title>
        <author>
            <name>J.B. North</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11054</char-count>
            <page-count>13</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0095</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0168</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0156</doc-id>
        <title>Status of the Illinois site: Response to RFC 116</title>
        <author>
            <name>J. Bouknight</name>
        </author>
        <date>
            <month>April</month>
            <day>26</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1171</char-count>
            <page-count>1</page-count>
        </format>
        <updates>
            <doc-id>RFC0116</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0157</doc-id>
        <title>Invitation to the Second Symposium on Problems in the Optimization of Data Communications Systems</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <date>
            <month>May</month>
            <day>12</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3159</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0158</doc-id>
        <title>Telnet Protocol: A Proposed Document</title>
        <author>
            <name>T.C. O'Sullivan</name>
        </author>
        <date>
            <month>May</month>
            <day>19</day>
            <year>1971</year>
        </date>
        <notes>Not Available Online..</notes>
        <obsoleted-by>
            <doc-id>RFC0495</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0139</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0318</doc-id>
        </updated-by>
        <see-also>
            <doc-id>RFC0393</doc-id>
        </see-also>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0159</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0160</doc-id>
        <title>RFC brief list</title>
        <author>
            <name>Network Information Center. Stanford Research Institute </name>
        </author>
        <date>
            <month>May</month>
            <day>18</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12173</char-count>
            <page-count>4</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0200</doc-id>
            <doc-id>RFC0999</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>NIC6716</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0161</doc-id>
        <title>Solution to the race condition in the ICP</title>
        <author>
            <name>A. Shoshani</name>
        </author>
        <date>
            <month>May</month>
            <day>19</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2026</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0162</doc-id>
        <title>NETBUGGER3</title>
        <author>
            <name>M. Kampe</name>
        </author>
        <date>
            <month>May</month>
            <day>22</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3153</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0163</doc-id>
        <title>Data transfer protocols</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <date>
            <month>May</month>
            <day>19</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5465</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
            <kw>DTP</kw>
            <kw>data</kw>
            <kw>manager</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0164</doc-id>
        <title>Minutes of Network Working Group meeting, 5/16 through 5/19/71</title>
        <author>
            <name>J.F. Heafner</name>
        </author>
        <date>
            <month>May</month>
            <day>25</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>58597</char-count>
            <page-count>32</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0165</doc-id>
        <title>Proffered official Initial Connection Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <day>25</day>
            <year>1971</year>
        </date>
        <notes>Not Available Online..</notes>
        <obsoletes>
            <doc-id>RFC0145</doc-id>
            <doc-id>RFC0143</doc-id>
            <doc-id>RFC0123</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>NIC7101</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0166</doc-id>
        <title>Data Reconfiguration Service: An implementation specification</title>
        <author>
            <name>R.H. Anderson</name>
        </author>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <author>
            <name>E. Harslem</name>
        </author>
        <author>
            <name>J.F. Heafner</name>
        </author>
        <author>
            <name>J. Madden</name>
        </author>
        <author>
            <name>R.M. Metcalfe</name>
        </author>
        <author>
            <name>A. Shoshani</name>
        </author>
        <author>
            <name>J.E. White</name>
        </author>
        <author>
            <name>D.C.M. Wood</name>
        </author>
        <date>
            <month>May</month>
            <day>25</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42094</char-count>
            <page-count>20</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0167</doc-id>
        <title>Socket conventions reconsidered</title>
        <author>
            <name>A.K. Bhushan</name>
        </author>
        <author>
            <name>R.M. Metcalfe</name>
        </author>
        <author>
            <name>J.M. Winett</name>
        </author>
        <date>
            <month>May</month>
            <day>24</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7643</char-count>
            <page-count>4</page-count>
        </format>
        <see-also>
            <doc-id>RFC0147</doc-id>
            <doc-id>RFC0129</doc-id>
        </see-also>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0168</doc-id>
        <title>ARPA Network mailing lists</title>
        <author>
            <name>J.B. North</name>
        </author>
        <date>
            <month>May</month>
            <day>26</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13294</char-count>
            <page-count>7</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0155</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0211</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0169</doc-id>
        <title>Computer networks</title>
        <author>
            <name>S.D. Crocker</name>
        </author>
        <date>
            <month>May</month>
            <day>27</day>
            <year>1971</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0170</doc-id>
        <title>RFC List by Number</title>
        <author>
            <name>Network Information Center. Stanford Research Institute </name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17670</char-count>
            <page-count>6</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0200</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0171</doc-id>
        <title>The Data Transfer Protocol</title>
        <author>
            <name>A. Bhushan</name>
        </author>
        <author>
            <name>B. Braden</name>
        </author>
        <author>
            <name>W. Crowther</name>
        </author>
        <author>
            <name>E. Harslem</name>
        </author>
        <author>
            <name>J. Heafner</name>
        </author>
        <author>
            <name>A. McKenize</name>
        </author>
        <author>
            <name>J. Melvin</name>
        </author>
        <author>
            <name>B. Sundberg</name>
        </author>
        <author>
            <name>D. Watson</name>
        </author>
        <author>
            <name>J. White</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20616</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
            <kw>DTP</kw>
        </keywords>
        <obsoleted-by>
            <doc-id>RFC0264</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0114</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0238</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0172</doc-id>
        <title>The File Transfer Protocol</title>
        <author>
            <name>A. Bhushan</name>
        </author>
        <author>
            <name>B. Braden</name>
        </author>
        <author>
            <name>W. Crowther</name>
        </author>
        <author>
            <name>E. Harslem</name>
        </author>
        <author>
            <name>J. Heafner</name>
        </author>
        <author>
            <name>A. McKenzie</name>
        </author>
        <author>
            <name>J. Melvin</name>
        </author>
        <author>
            <name>B. Sundberg</name>
        </author>
        <author>
            <name>D. Watson</name>
        </author>
        <author>
            <name>J. White</name>
        </author>
        <date>
            <month>June</month>
            <day>23</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21328</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <obsoleted-by>
            <doc-id>RFC0265</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0114</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0238</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0173</doc-id>
        <title>Network Data Management Committee Meeting Announcement</title>
        <author>
            <name>P.M. Karp</name>
        </author>
        <author>
            <name>D.B. McKay</name>
        </author>
        <date>
            <month>June</month>
            <day>04</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4239</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0174</doc-id>
        <title>UCLA - Computer Science Graphics Overview</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <date>
            <month>June</month>
            <day>08</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5037</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0175</doc-id>
        <title>Comments on "Socket Conventions Reconsidered"</title>
        <author>
            <name>E. Harslem</name>
        </author>
        <author>
            <name>J.F. Heafner</name>
        </author>
        <date>
            <month>June</month>
            <day>11</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2225</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0176</doc-id>
        <title>Comments on "Byte size for connections"</title>
        <author>
            <name>A.K. Bhushan</name>
        </author>
        <author>
            <name>R. Kanodia</name>
        </author>
        <author>
            <name>R.M. Metcalfe</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>June</month>
            <day>14</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7269</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0177</doc-id>
        <title>Device independent graphical display description</title>
        <author>
            <name>J. McConnell</name>
        </author>
        <date>
            <month>June</month>
            <day>15</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20474</char-count>
            <page-count>9</page-count>
        </format>
        <updates>
            <doc-id>RFC0125</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0181</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0178</doc-id>
        <title>Network graphic attention handling</title>
        <author>
            <name>I.W. Cotton</name>
        </author>
        <date>
            <month>June</month>
            <day>27</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24522</char-count>
            <page-count>11</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0179</doc-id>
        <title>Link Number Assignments</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>June</month>
            <day>22</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1221</char-count>
            <page-count>1</page-count>
        </format>
        <updates>
            <doc-id>RFC0107</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0180</doc-id>
        <title>File system questionnaire</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>June</month>
            <day>25</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8154</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0181</doc-id>
        <title>Modifications to RFC 177</title>
        <author>
            <name>J. McConnell</name>
        </author>
        <date>
            <month>July</month>
            <day>21</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4892</char-count>
            <page-count>3</page-count>
        </format>
        <updates>
            <doc-id>RFC0177</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0182</doc-id>
        <title>Compilation of list of relevant site reports</title>
        <author>
            <name>J.B. North</name>
        </author>
        <date>
            <month>June</month>
            <day>25</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2565</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0183</doc-id>
        <title>EBCDIC codes and their mapping to ASCII</title>
        <author>
            <name>J.M. Winett</name>
        </author>
        <date>
            <month>July</month>
            <day>21</day>
            <year>1971</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0184</doc-id>
        <title>Proposed graphic display modes</title>
        <author>
            <name>K.C. Kelley</name>
        </author>
        <date>
            <month>July</month>
            <day>06</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18678</char-count>
            <page-count>7</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0185</doc-id>
        <title>NIC distribution of manuals and handbooks</title>
        <author>
            <name>J.B. North</name>
        </author>
        <date>
            <month>July</month>
            <day>07</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1406</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0186</doc-id>
        <title>Network graphics loader</title>
        <author>
            <name>J.C. Michener</name>
        </author>
        <date>
            <month>July</month>
            <day>12</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30557</char-count>
            <page-count>17</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0187</doc-id>
        <title>Network/440 Protocol Concept</title>
        <author>
            <name>D.B. McKay</name>
        </author>
        <author>
            <name>D.P. Karp</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25042</char-count>
            <page-count>11</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0188</doc-id>
        <title>Data management meeting announcement</title>
        <author>
            <name>P.M. Karp</name>
        </author>
        <author>
            <name>D.B. McKay</name>
        </author>
        <date>
            <month>January</month>
            <day>28</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3383</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0189</doc-id>
        <title>Interim NETRJS specifications</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>July</month>
            <day>15</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41383</char-count>
            <page-count>19</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0088</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0599</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC0283</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0190</doc-id>
        <title>DEC PDP-10-IMLAC communications system</title>
        <author>
            <name>L.P. Deutsch</name>
        </author>
        <date>
            <month>July</month>
            <day>13</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18752</char-count>
            <page-count>16</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0191</doc-id>
        <title>Graphics implementation and conceptualization at Augmentation Research Center</title>
        <author>
            <name>C.H. Irby</name>
        </author>
        <date>
            <month>July</month>
            <day>13</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8179</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0192</doc-id>
        <title>Some factors which a Network Graphics Protocol must consider</title>
        <author>
            <name>R.W. Watson</name>
        </author>
        <date>
            <month>July</month>
            <day>12</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48540</char-count>
            <page-count>19</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0193</doc-id>
        <title>NETWORK CHECKOUT</title>
        <author>
            <name>E. Harslem</name>
        </author>
        <author>
            <name>J.F. Heafner</name>
        </author>
        <date>
            <month>July</month>
            <day>14</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3622</char-count>
            <page-count>2</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0198</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC0198</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0194</doc-id>
        <title>The Data Reconfiguration Service -- Compiler/Interpreter Implementation Notes</title>
        <author>
            <name>V. Cerf</name>
        </author>
        <author>
            <name>E. Harslem</name>
        </author>
        <author>
            <name>J. Heafner</name>
        </author>
        <author>
            <name>B. Metcalfe</name>
        </author>
        <author>
            <name>J. White</name>
        </author>
        <date>
            <month>July</month>
            <day>14</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32716</char-count>
            <page-count>18</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0195</doc-id>
        <title>Data computers-data descriptions and access language</title>
        <author>
            <name>G.H. Mealy</name>
        </author>
        <date>
            <month>July</month>
            <day>16</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8704</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0196</doc-id>
        <title>Mail Box Protocol</title>
        <author>
            <name>R.W. Watson</name>
        </author>
        <date>
            <month>July</month>
            <day>20</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7016</char-count>
            <page-count>4</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0221</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0197</doc-id>
        <title>Initial Connection Protocol - Reviewed</title>
        <author>
            <name>A. Shoshani</name>
        </author>
        <author>
            <name>E. Harslem</name>
        </author>
        <date>
            <month>July</month>
            <day>14</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7094</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0198</doc-id>
        <title>Site Certification - Lincoln Labs 360/67</title>
        <author>
            <name>J.F. Heafner</name>
        </author>
        <date>
            <month>July</month>
            <day>20</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>855</char-count>
            <page-count>1</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0193</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0214</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0193</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0199</doc-id>
        <title>Suggestions for a network data-tablet graphics protocol</title>
        <author>
            <name>T. Williams</name>
        </author>
        <date>
            <month>July</month>
            <day>15</day>
            <year>1971</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0200</doc-id>
        <title>RFC list by number</title>
        <author>
            <name>J.B. North</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19256</char-count>
            <page-count>7</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0170</doc-id>
            <doc-id>RFC0160</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>NIC7724</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0201</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0202</doc-id>
        <title>Possible Deadlock in ICP</title>
        <author>
            <name>S.M. Wolfe</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>July</month>
            <day>26</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2796</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0203</doc-id>
        <title>Achieving reliable communication</title>
        <author>
            <name>R.B. Kalin</name>
        </author>
        <date>
            <month>August</month>
            <day>10</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9253</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0204</doc-id>
        <title>Sockets in use</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>August</month>
            <day>05</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1379</char-count>
            <page-count>1</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0234</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0205</doc-id>
        <title>NETCRT - a character display protocol</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>August</month>
            <day>06</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28272</char-count>
            <page-count>13</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0206</doc-id>
        <title>User Telnet - description of an initial implementation</title>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>August</month>
            <day>09</day>
            <year>1971</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0207</doc-id>
        <title>September Network Working Group meeting</title>
        <author>
            <name>A. Vezza</name>
        </author>
        <date>
            <month>August</month>
            <day>09</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3356</char-count>
            <page-count>2</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0212</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0208</doc-id>
        <title>Address tables</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>August</month>
            <day>09</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5858</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0209</doc-id>
        <title>Host/IMP interface documentation</title>
        <author>
            <name>B. Cosell</name>
        </author>
        <date>
            <month>August</month>
            <day>13</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2566</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0210</doc-id>
        <title>Improvement of Flow Control</title>
        <author>
            <name>W. Conrad</name>
        </author>
        <date>
            <month>August</month>
            <day>16</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3329</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0211</doc-id>
        <title>ARPA Network mailing lists</title>
        <author>
            <name>J.B. North</name>
        </author>
        <date>
            <month>August</month>
            <day>18</day>
            <year>1971</year>
        </date>
        <notes>Not Available Online..</notes>
        <obsoletes>
            <doc-id>RFC0168</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0300</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0212</doc-id>
        <title>NWG meeting on network usage</title>
        <author>
            <name>Information Sciences Institute University of Southern California</name>
        </author>
        <date>
            <month>August</month>
            <day>23</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4356</char-count>
            <page-count>2</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0207</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC0222</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0213</doc-id>
        <title>IMP System change notification</title>
        <author>
            <name>B. Cosell</name>
        </author>
        <date>
            <month>August</month>
            <day>20</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1589</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0214</doc-id>
        <title>Network checkpoint</title>
        <author>
            <name>E. Harslem</name>
        </author>
        <date>
            <month>August</month>
            <day>21</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3047</char-count>
            <page-count>2</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0198</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0215</doc-id>
        <title>NCP, ICP, and Telnet: The Terminal IMP implementation</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>August</month>
            <day>30</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16645</char-count>
            <page-count>7</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0216</doc-id>
        <title>Telnet access to UCSB's On-Line System</title>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>September</month>
            <day>08</day>
            <year>1971</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0217</doc-id>
        <title>Specifications changes for OLS, RJE/RJOR, and SMFS</title>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>September</month>
            <day>08</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2956</char-count>
            <page-count>2</page-count>
        </format>
        <updates>
            <doc-id>RFC0074</doc-id>
            <doc-id>RFC0105</doc-id>
            <doc-id>RFC0122</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0218</doc-id>
        <title>Changing the IMP status reporting facility</title>
        <author>
            <name>B. Cosell</name>
        </author>
        <date>
            <month>September</month>
            <day>08</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1131</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0219</doc-id>
        <title>User's view of the datacomputer</title>
        <author>
            <name>R. Winter</name>
        </author>
        <date>
            <month>September</month>
            <day>03</day>
            <year>1971</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0220</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0221</doc-id>
        <title>Mail Box Protocol: Version 2</title>
        <author>
            <name>R.W. Watson</name>
        </author>
        <date>
            <month>August</month>
            <day>27</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9805</char-count>
            <page-count>5</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0196</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0278</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0222</doc-id>
        <title>Subject: System programmer's workshop</title>
        <author>
            <name>R.M. Metcalfe</name>
        </author>
        <date>
            <month>September</month>
            <day>13</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4023</char-count>
            <page-count>2</page-count>
        </format>
        <updates>
            <doc-id>RFC0212</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0234</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0223</doc-id>
        <title>Network Information Center schedule for network users</title>
        <author>
            <name>J.T. Melvin</name>
        </author>
        <author>
            <name>R.W. Watson</name>
        </author>
        <date>
            <month>September</month>
            <day>14</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5369</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0224</doc-id>
        <title>Comments on Mailbox Protocol</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>September</month>
            <day>14</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3583</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0225</doc-id>
        <title>Rand/UCSB network graphics experiment</title>
        <author>
            <name>E. Harslem</name>
        </author>
        <author>
            <name>R. Stoughton</name>
        </author>
        <date>
            <month>September</month>
            <day>13</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13573</char-count>
            <page-count>5</page-count>
        </format>
        <updates>
            <doc-id>RFC0074</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0226</doc-id>
        <title>Standardization of host mnemonics</title>
        <author>
            <name>P.M. Karp</name>
        </author>
        <date>
            <month>September</month>
            <day>20</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2012</char-count>
            <page-count>1</page-count>
        </format>
        <notes>a</notes>
        <obsoleted-by>
            <doc-id>RFC0247</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0227</doc-id>
        <title>Data transfer rates (Rand/UCLA)</title>
        <author>
            <name>J.F. Heafner</name>
        </author>
        <author>
            <name>E. Harslem</name>
        </author>
        <date>
            <month>September</month>
            <day>17</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2451</char-count>
            <page-count>2</page-count>
        </format>
        <updates>
            <doc-id>RFC0113</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0228</doc-id>
        <title>Clarification</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>September</month>
            <day>22</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>715</char-count>
            <page-count>1</page-count>
        </format>
        <updates>
            <doc-id>RFC0070</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0229</doc-id>
        <title>Standard host names</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <day>22</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3388</char-count>
            <page-count>3</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0236</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0230</doc-id>
        <title>Toward reliable operation of minicomputer-based terminals on a TIP</title>
        <author>
            <name>T. Pyke</name>
        </author>
        <date>
            <month>September</month>
            <day>24</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7040</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0231</doc-id>
        <title>Service center standards for remote usage: A user's view</title>
        <author>
            <name>J.F. Heafner</name>
        </author>
        <author>
            <name>E. Harslem</name>
        </author>
        <date>
            <month>September</month>
            <day>21</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9692</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0232</doc-id>
        <title>Postponement of network graphics meeting</title>
        <author>
            <name>A. Vezza</name>
        </author>
        <date>
            <month>September</month>
            <day>23</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>899</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0233</doc-id>
        <title>Standardization of host call letters</title>
        <author>
            <name>A. Bhushan</name>
        </author>
        <author>
            <name>R. Metcalfe</name>
        </author>
        <date>
            <month>September</month>
            <day>28</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3206</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0234</doc-id>
        <title>Network Working Group meeting schedule</title>
        <author>
            <name>A. Vezza</name>
        </author>
        <date>
            <month>October</month>
            <day>05</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1634</char-count>
            <page-count>1</page-count>
        </format>
        <updates>
            <doc-id>RFC0222</doc-id>
            <doc-id>RFC0204</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0235</doc-id>
        <title>Site status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>September</month>
            <day>27</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7994</char-count>
            <page-count>5</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0240</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0236</doc-id>
        <title>Standard host names</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <day>27</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5112</char-count>
            <page-count>2</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0229</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0237</doc-id>
        <title>NIC view of standard host names</title>
        <author>
            <name>R.W. Watson</name>
        </author>
        <date>
            <month>October</month>
            <day>05</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2212</char-count>
            <page-count>1</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0273</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0238</doc-id>
        <title>Comments on DTP and FTP proposals</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>September</month>
            <day>29</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2735</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <updates>
            <doc-id>RFC0171</doc-id>
            <doc-id>RFC0172</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0239</doc-id>
        <title>Host mnemonics proposed in RFC 226 (NIC 7625)</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>September</month>
            <day>23</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2236</char-count>
            <page-count>1</page-count>
        </format>
        <see-also>
            <doc-id>RFC0226</doc-id>
            <doc-id>RFC0229</doc-id>
            <doc-id>RFC0236</doc-id>
        </see-also>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0240</doc-id>
        <title>Site Status</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>September</month>
            <day>30</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7948</char-count>
            <page-count>4</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0235</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0252</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0241</doc-id>
        <title>Connecting computers to MLC ports</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>September</month>
            <day>29</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3739</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0242</doc-id>
        <title>Data Descriptive Language for Shared Data</title>
        <author>
            <name>L. Haibt</name>
        </author>
        <author>
            <name>A.P. Mullery</name>
        </author>
        <date>
            <month>July</month>
            <day>19</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18151</char-count>
            <page-count>10</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0243</doc-id>
        <title>Network and data sharing bibliography</title>
        <author>
            <name>A.P. Mullery</name>
        </author>
        <date>
            <month>October</month>
            <day>05</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12432</char-count>
            <page-count>7</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0290</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0244</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0245</doc-id>
        <title>Reservations for Network Group meeting</title>
        <author>
            <name>C. Falls</name>
        </author>
        <date>
            <month>October</month>
            <day>05</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1142</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0246</doc-id>
        <title>Network Graphics meeting</title>
        <author>
            <name>A. Vezza</name>
        </author>
        <date>
            <month>October</month>
            <day>05</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>856</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0247</doc-id>
        <title>Proffered set of standard host names</title>
        <author>
            <name>P.M. Karp</name>
        </author>
        <date>
            <month>October</month>
            <day>12</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7122</char-count>
            <page-count>4</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0226</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0248</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0249</doc-id>
        <title>Coordination of equipment and supplies purchase</title>
        <author>
            <name>R.F. Borelli</name>
        </author>
        <date>
            <month>October</month>
            <day>08</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4561</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0250</doc-id>
        <title>Some thoughts on file transfer</title>
        <author>
            <name>H. Brodie</name>
        </author>
        <date>
            <month>October</month>
            <day>07</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2446</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0251</doc-id>
        <title>Weather data</title>
        <author>
            <name>D. Stern</name>
        </author>
        <date>
            <month>October</month>
            <day>13</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1907</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0252</doc-id>
        <title>Network host status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>October</month>
            <day>08</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5531</char-count>
            <page-count>3</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0240</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0255</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0253</doc-id>
        <title>Second Network Graphics meeting details</title>
        <author>
            <name>J.A. Moorer</name>
        </author>
        <date>
            <month>October</month>
            <day>19</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1981</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0254</doc-id>
        <title>Scenarios for using ARPANET computers</title>
        <author>
            <name>A. Bhushan</name>
        </author>
        <date>
            <month>October</month>
            <day>29</day>
            <year>1971</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0255</doc-id>
        <title>Status of network hosts</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>October</month>
            <day>26</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4002</char-count>
            <page-count>2</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0252</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0266</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0256</doc-id>
        <title>IMPSYS change notification</title>
        <author>
            <name>B. Cosell</name>
        </author>
        <date>
            <month>November</month>
            <day>03</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1240</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0257</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0258</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0259</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0260</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0261</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0262</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0263</doc-id>
        <title>"Very Distant" Host interface</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>December</month>
            <day>17</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3914</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0264</doc-id>
        <title>The Data Transfer Protocol</title>
        <author>
            <name>A. Bhushan</name>
        </author>
        <author>
            <name>B. Braden</name>
        </author>
        <author>
            <name>W. Crowther</name>
        </author>
        <author>
            <name>E. Harslem</name>
        </author>
        <author>
            <name>J. Heafner</name>
        </author>
        <author>
            <name>A. McKenize</name>
        </author>
        <author>
            <name>B. Sundberg</name>
        </author>
        <author>
            <name>D. Watson</name>
        </author>
        <author>
            <name>J. White</name>
        </author>
        <date>
            <month>January</month>
            <day>04</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20907</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
            <kw>DTP</kw>
        </keywords>
        <obsoletes>
            <doc-id>RFC0171</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0354</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC0310</doc-id>
        </updated-by>
        <see-also>
            <doc-id>RFC0265</doc-id>
        </see-also>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0265</doc-id>
        <title>The File Transfer Protocol</title>
        <author>
            <name>A. Bhushan</name>
        </author>
        <author>
            <name>B. Braden</name>
        </author>
        <author>
            <name>W. Crowther</name>
        </author>
        <author>
            <name>E. Harslem</name>
        </author>
        <author>
            <name>J. Heafner</name>
        </author>
        <author>
            <name>A. McKenzie</name>
        </author>
        <author>
            <name>J. Melvin</name>
        </author>
        <author>
            <name>B. Sundberg</name>
        </author>
        <author>
            <name>D. Watson</name>
        </author>
        <author>
            <name>J. White</name>
        </author>
        <date>
            <month>November</month>
            <day>17</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3914</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <obsoletes>
            <doc-id>RFC0172</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0354</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC0281</doc-id>
            <doc-id>RFC0294</doc-id>
            <doc-id>RFC0310</doc-id>
        </updated-by>
        <see-also>
            <doc-id>RFC0264</doc-id>
        </see-also>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0266</doc-id>
        <title>Network host status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>November</month>
            <day>08</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3174</char-count>
            <page-count>2</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0255</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0267</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0267</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>November</month>
            <day>22</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7862</char-count>
            <page-count>4</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0266</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0287</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0268</doc-id>
        <title>Graphics facilities information</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <day>24</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1298</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0269</doc-id>
        <title>Some Experience with File Transfer</title>
        <author>
            <name>H. Brodie</name>
        </author>
        <date>
            <month>December</month>
            <day>06</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5961</char-count>
            <page-count>3</page-count>
        </format>
        <updates>
            <doc-id>RFC0122</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0270</doc-id>
        <title>Correction to BBN Report No. 1822 (NIC NO 7958)</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1371</char-count>
            <page-count>1</page-count>
        </format>
        <updates>
            <doc-id>NIC7959</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0271</doc-id>
        <title>IMP System change notifications</title>
        <author>
            <name>B. Cosell</name>
        </author>
        <date>
            <month>January</month>
            <day>03</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4022</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0272</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0273</doc-id>
        <title>More on standard host names</title>
        <author>
            <name>R.W. Watson</name>
        </author>
        <date>
            <month>October</month>
            <day>18</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4589</char-count>
            <page-count>3</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0237</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0274</doc-id>
        <title>Establishing a local guide for network usage</title>
        <author>
            <name>E. Forman</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7114</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0275</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0276</doc-id>
        <title>NIC course</title>
        <author>
            <name>R.W. Watson</name>
        </author>
        <date>
            <month>November</month>
            <day>08</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1183</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0277</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0278</doc-id>
        <title>Revision of the Mail Box Protocol</title>
        <author>
            <name>A.K. Bhushan</name>
        </author>
        <author>
            <name>R.T. Braden</name>
        </author>
        <author>
            <name>E. Harslem</name>
        </author>
        <author>
            <name>J.F. Heafner</name>
        </author>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <author>
            <name>J.T. Melvin</name>
        </author>
        <author>
            <name>R.L. Sundberg</name>
        </author>
        <author>
            <name>R.W. Watson</name>
        </author>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>November</month>
            <day>17</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7526</char-count>
            <page-count>4</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0221</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0279</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0280</doc-id>
        <title>A Draft of Host Names</title>
        <author>
            <name>R.W. Watson</name>
        </author>
        <date>
            <month>November</month>
            <day>17</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3629</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0281</doc-id>
        <title>Suggested addition to File Transfer Protocol</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>December</month>
            <day>08</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12006</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <updates>
            <doc-id>RFC0265</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0282</doc-id>
        <title>Graphics meeting report</title>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>December</month>
            <day>08</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18100</char-count>
            <page-count>8</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0283</doc-id>
        <title>NETRJT: Remote Job Service Protocol for TIPS</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>December</month>
            <day>20</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18771</char-count>
            <page-count>9</page-count>
        </format>
        <updates>
            <doc-id>RFC0189</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0284</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0285</doc-id>
        <title>Network graphics</title>
        <author>
            <name>D. Huff</name>
        </author>
        <date>
            <month>December</month>
            <day>15</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18076</char-count>
            <page-count>8</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0286</doc-id>
        <title>Network Library Information System</title>
        <author>
            <name>E. Forman</name>
        </author>
        <date>
            <month>December</month>
            <day>21</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2079</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0287</doc-id>
        <title>Status of Network Hosts</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>December</month>
            <day>22</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9217</char-count>
            <page-count>5</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0267</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0288</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0288</doc-id>
        <title>Network host status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>January</month>
            <day>06</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8501</char-count>
            <page-count>4</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0287</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0293</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC0293</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0289</doc-id>
        <title>What we hope is an official list of host names</title>
        <author>
            <name>R.W. Watson</name>
        </author>
        <date>
            <month>December</month>
            <day>21</day>
            <year>1971</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5069</char-count>
            <page-count>3</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0384</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0290</doc-id>
        <title>Computer networks and data sharing: A bibliography</title>
        <author>
            <name>A.P. Mullery</name>
        </author>
        <date>
            <month>January</month>
            <day>11</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34329</char-count>
            <page-count>15</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0243</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0291</doc-id>
        <title>Data Management Meeting Announcement</title>
        <author>
            <name>D.B. McKay</name>
        </author>
        <date>
            <month>January</month>
            <day>14</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3375</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0292</doc-id>
        <title>Graphics Protocol: Level 0 only</title>
        <author>
            <name>J.C. Michener</name>
        </author>
        <author>
            <name>I.W. Cotton</name>
        </author>
        <author>
            <name>K.C. Kelley</name>
        </author>
        <author>
            <name>D.E. Liddle</name>
        </author>
        <author>
            <name>E. Meyer</name>
        </author>
        <date>
            <month>January</month>
            <day>12</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22342</char-count>
            <page-count>10</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0293</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>January</month>
            <day>18</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7639</char-count>
            <page-count>4</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0288</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0298</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0288</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0294</doc-id>
        <title>The Use of "Set Data Type" Transaction in File Transfer Protocol</title>
        <author>
            <name>A.K. Bhushan</name>
        </author>
        <date>
            <month>January</month>
            <day>25</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3924</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <updates>
            <doc-id>RFC0265</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0295</doc-id>
        <title>Report of the Protocol Workshop, 12 October 1971</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>January</month>
            <day>02</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5432</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0296</doc-id>
        <title>DS-1 display system</title>
        <author>
            <name>D.E. Liddle</name>
        </author>
        <date>
            <month>January</month>
            <day>27</day>
            <year>1972</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0297</doc-id>
        <title>TIP Message Buffers</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>January</month>
            <day>31</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3517</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0298</doc-id>
        <title>Network host status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>February</month>
            <day>11</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8770</char-count>
            <page-count>4</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0293</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0306</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0299</doc-id>
        <title>Information Management System</title>
        <author>
            <name>D. Hopkin</name>
        </author>
        <date>
            <month>February</month>
            <day>11</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1825</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0300</doc-id>
        <title>ARPA Network mailing lists</title>
        <author>
            <name>J.B. North</name>
        </author>
        <date>
            <month>January</month>
            <day>25</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16357</char-count>
            <page-count>9</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0211</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0303</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0301</doc-id>
        <title>BBN IMP (#5) and NCC Schedule March 4, 1971</title>
        <author>
            <name>R. Alter</name>
        </author>
        <date>
            <month>February</month>
            <day>11</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1487</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0302</doc-id>
        <title>Exercising The ARPANET</title>
        <author>
            <name>R.F. Bryan</name>
        </author>
        <date>
            <month>February</month>
            <day>08</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5452</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0303</doc-id>
        <title>ARPA Network mailing lists</title>
        <author>
            <name>Network Information Center. Stanford Research Institute</name>
        </author>
        <date>
            <month>March</month>
            <day>03</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18193</char-count>
            <page-count>11</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0300</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0329</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0304</doc-id>
        <title>Data management system proposal for the ARPA network</title>
        <author>
            <name>D.B. McKay</name>
        </author>
        <date>
            <month>February</month>
            <day>17</day>
            <year>1972</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0305</doc-id>
        <title>Unknown Host Numbers</title>
        <author>
            <name>R. Alter</name>
        </author>
        <date>
            <month>February</month>
            <day>23</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1998</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0306</doc-id>
        <title>Network host status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>February</month>
            <day>15</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7485</char-count>
            <page-count>4</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0298</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0315</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0307</doc-id>
        <title>Using network Remote Job Entry</title>
        <author>
            <name>E. Harslem</name>
        </author>
        <date>
            <month>February</month>
            <day>24</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12032</char-count>
            <page-count>6</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0308</doc-id>
        <title>ARPANET host availability data</title>
        <author>
            <name>M. Seriff</name>
        </author>
        <date>
            <month>March</month>
            <day>13</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5948</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0309</doc-id>
        <title>Data and File Transfer Workshop Announcement</title>
        <author>
            <name>A.K. Bhushan</name>
        </author>
        <date>
            <month>March</month>
            <day>17</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9404</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
            <kw>DTP</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0310</doc-id>
        <title>Another Look at Data and File Transfer Protocols</title>
        <author>
            <name>A.K. Bhushan</name>
        </author>
        <date>
            <month>April</month>
            <day>03</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18593</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <updates>
            <doc-id>RFC0264</doc-id>
            <doc-id>RFC0265</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0311</doc-id>
        <title>New Console Attachments to the USCB Host</title>
        <author>
            <name>R.F. Bryan</name>
        </author>
        <date>
            <month>February</month>
            <day>29</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3141</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0312</doc-id>
        <title>Proposed Change in IMP-to-Host Protocol</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>March</month>
            <day>22</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3562</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0313</doc-id>
        <title>Computer based instruction</title>
        <author>
            <name>T.C. O'Sullivan</name>
        </author>
        <date>
            <month>March</month>
            <day>06</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19880</char-count>
            <page-count>8</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0314</doc-id>
        <title>Network Graphics Working Group Meeting</title>
        <author>
            <name>I.W. Cotton</name>
        </author>
        <date>
            <month>March</month>
            <day>14</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1836</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0315</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>March</month>
            <day>08</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7818</char-count>
            <page-count>4</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0306</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0319</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0316</doc-id>
        <title>ARPA Network Data Management Working Group</title>
        <author>
            <name>D.B. McKay</name>
        </author>
        <author>
            <name>A.P. Mullery</name>
        </author>
        <date>
            <month>February</month>
            <day>23</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15494</char-count>
            <page-count>7</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0317</doc-id>
        <title>Official Host-Host Protocol Modification: Assigned Link Numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>March</month>
            <day>20</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1593</char-count>
            <page-count>1</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0604</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0318</doc-id>
        <title>Telnet Protocols</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>April</month>
            <day>03</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34928</char-count>
            <page-count>16</page-count>
        </format>
        <updates>
            <doc-id>RFC0158</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0435</doc-id>
        </updated-by>
        <see-also>
            <doc-id>RFC0139</doc-id>
            <doc-id>RFC0158</doc-id>
        </see-also>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0319</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>March</month>
            <day>21</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8955</char-count>
            <page-count>4</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0315</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC0326</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0320</doc-id>
        <title>Workshop on Hard Copy Line Printers</title>
        <author>
            <name>R. Reddy</name>
        </author>
        <date>
            <month>March</month>
            <day>27</day>
            <year>1972</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0321</doc-id>
        <title>CBI Networking Activity at MITRE</title>
        <author>
            <name>P.M. Karp</name>
        </author>
        <date>
            <month>March</month>
            <day>24</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20500</char-count>
            <page-count>13</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0322</doc-id>
        <title>Well known socket numbers</title>
        <author>
            <name>V. Cerf</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>March</month>
            <day>26</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1735</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0323</doc-id>
        <title>Formation of Network Measurement Group (NMG)</title>
        <author>
            <name>V. Cerf</name>
        </author>
        <date>
            <month>March</month>
            <day>23</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15777</char-count>
            <page-count>9</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0388</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0324</doc-id>
        <title>RJE Protocol meeting</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>April</month>
            <day>03</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1176</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0325</doc-id>
        <title>Network Remote Job Entry program - NETRJS</title>
        <author>
            <name>G. Hicks</name>
        </author>
        <date>
            <month>April</month>
            <day>06</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17499</char-count>
            <page-count>9</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0326</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>April</month>
            <day>03</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7944</char-count>
            <page-count>4</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0330</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0319</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0327</doc-id>
        <title>Data and File Transfer workshop notes</title>
        <author>
            <name>A.K. Bhushan</name>
        </author>
        <date>
            <month>April</month>
            <day>27</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11792</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0328</doc-id>
        <title>Suggested Telnet Protocol Changes</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>April</month>
            <day>29</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2685</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0329</doc-id>
        <title>ARPA Network Mailing Lists</title>
        <author>
            <name>Network Information Center. Stanford Research Institute </name>
        </author>
        <date>
            <month>May</month>
            <day>17</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23861</char-count>
            <page-count>13</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0303</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0363</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0330</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>April</month>
            <day>13</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8085</char-count>
            <page-count>3</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0326</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC0332</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0331</doc-id>
        <title>IMP System Change Notification</title>
        <author>
            <name>J.M. McQuillan</name>
        </author>
        <date>
            <month>April</month>
            <day>19</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2339</char-count>
            <page-count>1</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0343</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0332</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>April</month>
            <day>25</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8427</char-count>
            <page-count>4</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0342</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0330</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0333</doc-id>
        <title>Proposed experiment with a Message Switching Protocol</title>
        <author>
            <name>R.D. Bressler</name>
        </author>
        <author>
            <name>D. Murphy</name>
        </author>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>May</month>
            <day>15</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>62507</char-count>
            <page-count>26</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0334</doc-id>
        <title>Network Use on May 8</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1376</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0335</doc-id>
        <title>New Interface - IMP/360</title>
        <author>
            <name>R.F. Bryan</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>934</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0336</doc-id>
        <title>Level 0 Graphic Input Protocol</title>
        <author>
            <name>I.W. Cotton</name>
        </author>
        <date>
            <month>May</month>
            <day>05</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3787</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0337</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0338</doc-id>
        <title>EBCDIC/ASCII Mapping for Network RJE</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>May</month>
            <day>17</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11494</char-count>
            <page-count>6</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>2386987</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>1871020</char-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0339</doc-id>
        <title>MLTNET: A "Multi Telnet" Subsystem for Tenex</title>
        <author>
            <name>R. Thomas</name>
        </author>
        <date>
            <month>May</month>
            <day>05</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7941</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0340</doc-id>
        <title>Proposed Telnet Changes</title>
        <author>
            <name>T.C. O'Sullivan</name>
        </author>
        <date>
            <month>May</month>
            <day>15</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2656</char-count>
            <page-count>2</page-count>
        </format>
        <see-also>
            <doc-id>RFC0328</doc-id>
        </see-also>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0341</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0342</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>May</month>
            <day>15</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8382</char-count>
            <page-count>4</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0332</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0344</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0343</doc-id>
        <title>IMP System change notification</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>May</month>
            <day>19</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3370</char-count>
            <page-count>2</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0331</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0359</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0344</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>May</month>
            <day>22</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8221</char-count>
            <page-count>4</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0342</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0353</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0345</doc-id>
        <title>Interest in Mixed Integer Programming (MPSX on NIC 360/91 at CCN)</title>
        <author>
            <name>K.C. Kelley</name>
        </author>
        <date>
            <month>May</month>
            <day>26</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1999</char-count>
            <page-count>1</page-count>
        </format>
        <keywords>
            <kw>MIP</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0346</doc-id>
        <title>Satellite Considerations</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <day>30</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2778</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0347</doc-id>
        <title>Echo process</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <day>30</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1377</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0348</doc-id>
        <title>Discard Process</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <day>30</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1181</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0349</doc-id>
        <title>Proposed Standard Socket Numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <day>30</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1663</char-count>
            <page-count>1</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0433</doc-id>
        </obsoleted-by>
        <see-also>
            <doc-id>RFC0322</doc-id>
            <doc-id>RFC0204</doc-id>
        </see-also>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0350</doc-id>
        <title>User Accounts for UCSB On-Line System</title>
        <author>
            <name>R. Stoughton</name>
        </author>
        <date>
            <month>May</month>
            <day>18</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5117</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0351</doc-id>
        <title>Graphics information form for the ARPANET graphics resources notebook</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>June</month>
            <day>05</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2150</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0352</doc-id>
        <title>TIP Site Information Form</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>June</month>
            <day>05</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2266</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0353</doc-id>
        <title>Network host status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>June</month>
            <day>12</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8747</char-count>
            <page-count>5</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0344</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0362</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0354</doc-id>
        <title>File Transfer Protocol</title>
        <author>
            <name>A.K. Bhushan</name>
        </author>
        <date>
            <month>July</month>
            <day>08</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>58074</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <obsoletes>
            <doc-id>RFC0264</doc-id>
            <doc-id>RFC0265</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0542</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC0385</doc-id>
            <doc-id>RFC0454</doc-id>
            <doc-id>RFC0683</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0355</doc-id>
        <title>Response to NWG/RFC 346</title>
        <author>
            <name>J. Davidson</name>
        </author>
        <date>
            <month>June</month>
            <day>09</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3717</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0356</doc-id>
        <title>ARPA Network Control Center</title>
        <author>
            <name>R. Alter</name>
        </author>
        <date>
            <month>June</month>
            <day>21</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1963</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0357</doc-id>
        <title>Echoing strategy for satellite links</title>
        <author>
            <name>J. Davidson</name>
        </author>
        <date>
            <month>June</month>
            <day>26</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30103</char-count>
            <page-count>13</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0358</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0359</doc-id>
        <title>Status of the Release of the New IMP System (2600)</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>June</month>
            <day>22</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2015</char-count>
            <page-count>1</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0343</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0360</doc-id>
        <title>Proposed Remote Job Entry Protocol</title>
        <author>
            <name>C. Holland</name>
        </author>
        <date>
            <month>June</month>
            <day>24</day>
            <year>1972</year>
        </date>
        <notes>Not Available Online..</notes>
        <obsoleted-by>
            <doc-id>RFC0407</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0361</doc-id>
        <title>Deamon Processes on Host 106</title>
        <author>
            <name>R.D. Bressler</name>
        </author>
        <date>
            <month>July</month>
            <day>05</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1480</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0362</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>June</month>
            <day>28</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8631</char-count>
            <page-count>4</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0353</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0366</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0363</doc-id>
        <title>ARPA Network mailing lists</title>
        <author>
            <name>Network Information Center. Stanford Research Institute </name>
        </author>
        <date>
            <month>August</month>
            <day>08</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25356</char-count>
            <page-count>13</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0329</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0402</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0364</doc-id>
        <title>Serving remote users on the ARPANET</title>
        <author>
            <name>M.D. Abrams</name>
        </author>
        <date>
            <month>July</month>
            <day>11</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11253</char-count>
            <page-count>6</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0365</doc-id>
        <title>Letter to All TIP Users</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>July</month>
            <day>11</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10331</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0366</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>July</month>
            <day>11</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8278</char-count>
            <page-count>4</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0362</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0367</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0367</doc-id>
        <title>Network host status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>July</month>
            <day>19</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8057</char-count>
            <page-count>4</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0366</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0370</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0368</doc-id>
        <title>Comments on "Proposed Remote Job Entry Protocol"</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>July</month>
            <day>21</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3883</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0369</doc-id>
        <title>Evaluation of ARPANET services January-March, 1972</title>
        <author>
            <name>J.R. Pickens</name>
        </author>
        <date>
            <month>July</month>
            <day>25</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24414</char-count>
            <page-count>11</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0370</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>July</month>
            <day>31</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8389</char-count>
            <page-count>5</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0367</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC0376</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0371</doc-id>
        <title>Demonstration at International Computer Communications Conference</title>
        <author>
            <name>R.E. Kahn</name>
        </author>
        <date>
            <month>July</month>
            <day>12</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3728</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0372</doc-id>
        <title>Notes on a Conversation with Bob Kahn on the ICCC</title>
        <author>
            <name>R.W. Watson</name>
        </author>
        <date>
            <month>July</month>
            <day>12</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6040</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0373</doc-id>
        <title>Arbitrary Character Sets</title>
        <author>
            <name>J. McCarthy</name>
        </author>
        <date>
            <month>July</month>
            <day>14</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7783</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0374</doc-id>
        <title>IMP System Announcement</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>July</month>
            <day>19</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3963</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0375</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0376</doc-id>
        <title>Network Host Status</title>
        <author>
            <name>E. Westheimer</name>
        </author>
        <date>
            <month>August</month>
            <day>08</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8861</char-count>
            <page-count>5</page-count>
        </format>
        <updates>
            <doc-id>RFC0370</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0377</doc-id>
        <title>Using TSO via ARPA Network Virtual Terminal</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>August</month>
            <day>10</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7093</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0378</doc-id>
        <title>Traffic statistics (July 1972)</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>August</month>
            <day>10</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5730</char-count>
            <page-count>3</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0391</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0379</doc-id>
        <title>Using TSO at CCN</title>
        <author>
            <name>R.. Braden</name>
        </author>
        <date>
            <month>August</month>
            <day>11</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8674</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0380</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0381</doc-id>
        <title>Three aids to improved network operation</title>
        <author>
            <name>J.M. McQuillan</name>
        </author>
        <date>
            <month>July</month>
            <day>26</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9305</char-count>
            <page-count>4</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0394</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0382</doc-id>
        <title>Mathematical Software on the ARPA Network</title>
        <author>
            <name>L. McDaniel</name>
        </author>
        <date>
            <month>August</month>
            <day>03</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2041</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0383</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0384</doc-id>
        <title>Official site idents for organizations in the ARPA Network</title>
        <author>
            <name>J.B. North</name>
        </author>
        <date>
            <month>August</month>
            <day>28</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10401</char-count>
            <page-count>4</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0289</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0385</doc-id>
        <title>Comments on the File Transfer Protocol</title>
        <author>
            <name>A.K. Bhushan</name>
        </author>
        <date>
            <month>August</month>
            <day>18</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13030</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <updates>
            <doc-id>RFC0354</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0414</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0386</doc-id>
        <title>Letter to TIP users-2</title>
        <author>
            <name>B. Cosell</name>
        </author>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>August</month>
            <day>16</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12475</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0387</doc-id>
        <title>Some experiences in implementing Network Graphics Protocol Level 0</title>
        <author>
            <name>K.C. Kelley</name>
        </author>
        <author>
            <name>J. Meir</name>
        </author>
        <date>
            <month>August</month>
            <day>10</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9059</char-count>
            <page-count>5</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0401</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0388</doc-id>
        <title>NCP statistics</title>
        <author>
            <name>V. Cerf</name>
        </author>
        <date>
            <month>August</month>
            <day>23</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8458</char-count>
            <page-count>5</page-count>
        </format>
        <updates>
            <doc-id>RFC0323</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0389</doc-id>
        <title>UCLA Campus Computing Network Liaison Staff for ARPA Network</title>
        <author>
            <name>B. Noble</name>
        </author>
        <date>
            <month>August</month>
            <day>30</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2819</char-count>
            <page-count>2</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0423</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0390</doc-id>
        <title>TSO Scenario</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>September</month>
            <day>12</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6103</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0391</doc-id>
        <title>Traffic statistics (August 1972)</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>September</month>
            <day>15</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4695</char-count>
            <page-count>3</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0378</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0392</doc-id>
        <title>Measurement of host costs for transmitting network data</title>
        <author>
            <name>G. Hicks</name>
        </author>
        <author>
            <name>B.D. Wessler</name>
        </author>
        <date>
            <month>September</month>
            <day>20</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14462</char-count>
            <page-count>6</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0393</doc-id>
        <title>Comments on Telnet Protocol Changes</title>
        <author>
            <name>J.M. Winett</name>
        </author>
        <date>
            <month>October</month>
            <day>03</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9435</char-count>
            <page-count>4</page-count>
        </format>
        <see-also>
            <doc-id>RFC0109</doc-id>
            <doc-id>RFC0139</doc-id>
            <doc-id>RFC0158</doc-id>
            <doc-id>RFC0318</doc-id>
            <doc-id>RFC0328</doc-id>
        </see-also>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0394</doc-id>
        <title>Two Proposed Changes to the IMP-Host Protocol</title>
        <author>
            <name>J.M. McQuillan</name>
        </author>
        <date>
            <month>September</month>
            <day>27</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5780</char-count>
            <page-count>3</page-count>
        </format>
        <updates>
            <doc-id>RFC0381</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0395</doc-id>
        <title>Switch Settings on IMPs and TIPs</title>
        <author>
            <name>J.M. McQuillan</name>
        </author>
        <date>
            <month>October</month>
            <day>03</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1827</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0396</doc-id>
        <title>Network Graphics Working Group Meeting - Second Iteration</title>
        <author>
            <name>S. Bunch</name>
        </author>
        <date>
            <month>November</month>
            <day>13</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2224</char-count>
            <page-count>1</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0474</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0397</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0398</doc-id>
        <title>ICP Sockets</title>
        <author>
            <name>J.R. Pickens</name>
        </author>
        <author>
            <name>E. Faeh</name>
        </author>
        <date>
            <month>September</month>
            <day>22</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3846</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0399</doc-id>
        <title>SMFS Login and Logout</title>
        <author>
            <name>M. Krilanovich</name>
        </author>
        <date>
            <month>September</month>
            <day>26</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3024</char-count>
            <page-count>2</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0431</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0122</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0400</doc-id>
        <title>Traffic Statistics (September 1972)</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>October</month>
            <day>18</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5435</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0401</doc-id>
        <title>Conversion of NGP-0 Coordinates to Device Specific Coordinates</title>
        <author>
            <name>J. Hansen</name>
        </author>
        <date>
            <month>October</month>
            <day>23</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3894</char-count>
            <page-count>2</page-count>
        </format>
        <updates>
            <doc-id>RFC0387</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0402</doc-id>
        <title>ARPA Network Mailing Lists</title>
        <author>
            <name>J.B. North</name>
        </author>
        <date>
            <month>October</month>
            <day>26</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28162</char-count>
            <page-count>16</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0363</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0403</doc-id>
        <title>Desirability of a network 1108 service</title>
        <author>
            <name>G. Hicks</name>
        </author>
        <date>
            <month>January</month>
            <day>10</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0404</doc-id>
        <title>Host Address Changes Involving Rand and ISI</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>October</month>
            <day>05</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>944</char-count>
            <page-count>1</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0405</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0405</doc-id>
        <title>Correction to RFC 404</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>October</month>
            <day>10</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1103</char-count>
            <page-count>1</page-count>
        </format>
        <updates>
            <doc-id>RFC0404</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0406</doc-id>
        <title>Scheduled IMP Software Releases</title>
        <author>
            <name>J.M. McQuillan</name>
        </author>
        <date>
            <month>October</month>
            <day>10</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2468</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0407</doc-id>
        <title>Remote Job Entry Protocol</title>
        <author>
            <name>R.D. Bressler</name>
        </author>
        <author>
            <name>R. Guida</name>
        </author>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>October</month>
            <day>16</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47556</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>RJE</kw>
        </keywords>
        <obsoletes>
            <doc-id>RFC0360</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0408</doc-id>
        <title>NETBANK</title>
        <author>
            <name>A.D. Owen</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>October</month>
            <day>25</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1645</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0409</doc-id>
        <title>Tenex interface to UCSB's Simple-Minded File System</title>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>December</month>
            <day>08</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14231</char-count>
            <page-count>8</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0410</doc-id>
        <title>Removal of the 30-Second Delay When Hosts Come Up</title>
        <author>
            <name>J.M. McQuillan</name>
        </author>
        <date>
            <month>November</month>
            <day>10</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3964</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0411</doc-id>
        <title>New MULTICS Network Software Features</title>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>November</month>
            <day>14</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3024</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0412</doc-id>
        <title>User FTP Documentation</title>
        <author>
            <name>G. Hicks</name>
        </author>
        <date>
            <month>November</month>
            <day>27</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17510</char-count>
            <page-count>10</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0413</doc-id>
        <title>Traffic statistics (October 1972)</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>November</month>
            <day>13</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16145</char-count>
            <page-count>10</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0414</doc-id>
        <title>File Transfer Protocol (FTP) status and further comments</title>
        <author>
            <name>A.K. Bhushan</name>
        </author>
        <date>
            <month>December</month>
            <day>29</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12845</char-count>
            <page-count>5</page-count>
        </format>
        <updates>
            <doc-id>RFC0385</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0415</doc-id>
        <title>Tenex bandwidth</title>
        <author>
            <name>H. Murray</name>
        </author>
        <date>
            <month>November</month>
            <day>29</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3456</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0416</doc-id>
        <title>ARC System Will Be Unavailable for Use During Thanksgiving Week</title>
        <author>
            <name>J.C. Norton</name>
        </author>
        <date>
            <month>November</month>
            <day>07</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2205</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0417</doc-id>
        <title>Link usage violation</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>C. Kline</name>
        </author>
        <date>
            <month>December</month>
            <day>06</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>901</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0418</doc-id>
        <title>Server file transfer under TSS/360 at NASA Ames</title>
        <author>
            <name>W. Hathaway</name>
        </author>
        <date>
            <month>November</month>
            <day>27</day>
            <year>1972</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0419</doc-id>
        <title>To: Network liaisons and station agents</title>
        <author>
            <name>A. Vezza</name>
        </author>
        <date>
            <month>December</month>
            <day>12</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1252</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0420</doc-id>
        <title>CCA ICCC weather demo</title>
        <author>
            <name>H. Murray</name>
        </author>
        <date>
            <month>January</month>
            <day>04</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14752</char-count>
            <page-count>8</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0421</doc-id>
        <title>Software Consulting Service for Network Users</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>November</month>
            <day>27</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2483</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0422</doc-id>
        <title>Traffic statistics (November 1972)</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>December</month>
            <day>11</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5494</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0423</doc-id>
        <title>UCLA Campus Computing Network Liaison Staff for ARPANET</title>
        <author>
            <name>B. Noble</name>
        </author>
        <date>
            <month>December</month>
            <day>12</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2890</char-count>
            <page-count>2</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0389</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0424</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0425</doc-id>
        <title>"But my NCP costs $500 a day"</title>
        <author>
            <name>R.D. Bressler</name>
        </author>
        <date>
            <month>December</month>
            <day>19</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1763</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0426</doc-id>
        <title>Reconnection Protocol</title>
        <author>
            <name>R. Thomas</name>
        </author>
        <date>
            <month>January</month>
            <day>26</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26548</char-count>
            <page-count>12</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0427</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0428</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0429</doc-id>
        <title>Character Generator Process</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>December</month>
            <day>12</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1319</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0430</doc-id>
        <title>Comments on File Transfer Protocol</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>February</month>
            <day>07</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18696</char-count>
            <page-count>8</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0431</doc-id>
        <title>Update on SMFS Login and Logout</title>
        <author>
            <name>M. Krilanovich</name>
        </author>
        <date>
            <month>December</month>
            <day>15</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4196</char-count>
            <page-count>3</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0399</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC0122</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0432</doc-id>
        <title>Network logical map</title>
        <author>
            <name>N. Neigus</name>
        </author>
        <date>
            <month>December</month>
            <day>29</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1291</char-count>
            <page-count>1</page-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>148880</char-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>1344571</char-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0433</doc-id>
        <title>Socket number list</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>December</month>
            <day>22</day>
            <year>1972</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6834</char-count>
            <page-count>5</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0349</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0503</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0434</doc-id>
        <title>IMP/TIP memory retrofit schedule</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>January</month>
            <day>04</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2242</char-count>
            <page-count>2</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0447</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0435</doc-id>
        <title>Telnet issues</title>
        <author>
            <name>B. Cosell</name>
        </author>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>January</month>
            <day>05</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23019</char-count>
            <page-count>10</page-count>
        </format>
        <updates>
            <doc-id>RFC0318</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0436</doc-id>
        <title>Announcement of RJS at UCSB</title>
        <author>
            <name>M. Krilanovich</name>
        </author>
        <date>
            <month>January</month>
            <day>10</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2579</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0437</doc-id>
        <title>Data Reconfiguration Service at UCSB</title>
        <author>
            <name>E. Faeh</name>
        </author>
        <date>
            <month>June</month>
            <day>30</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21562</char-count>
            <page-count>10</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0438</doc-id>
        <title>FTP server-server interaction</title>
        <author>
            <name>R. Thomas</name>
        </author>
        <author>
            <name>R. Clements</name>
        </author>
        <date>
            <month>January</month>
            <day>15</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6514</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0439</doc-id>
        <title>PARRY encounters the DOCTOR</title>
        <author>
            <name>V. Cerf</name>
        </author>
        <date>
            <month>January</month>
            <day>21</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7066</char-count>
            <page-count>7</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0440</doc-id>
        <title>Scheduled network software maintenance</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1870</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0441</doc-id>
        <title>Inter-Entity Communication - an experiment</title>
        <author>
            <name>R.D. Bressler</name>
        </author>
        <author>
            <name>R. Thomas</name>
        </author>
        <date>
            <month>January</month>
            <day>19</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12876</char-count>
            <page-count>7</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0442</doc-id>
        <title>Current flow-control scheme for IMPSYS</title>
        <author>
            <name>V. Cerf</name>
        </author>
        <date>
            <month>January</month>
            <day>24</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16315</char-count>
            <page-count>7</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0449</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0443</doc-id>
        <title>Traffic statistics (December 1972)</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>January</month>
            <day>18</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5664</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0444</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0445</doc-id>
        <title>IMP/TIP preventive maintenance schedule</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>January</month>
            <day>22</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2668</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0446</doc-id>
        <title>Proposal to consider a network program resource notebook</title>
        <author>
            <name>L.P. Deutsch</name>
        </author>
        <date>
            <month>January</month>
            <day>25</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3053</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0447</doc-id>
        <title>IMP/TIP memory retrofit schedule</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>January</month>
            <day>29</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2332</char-count>
            <page-count>2</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0434</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0476</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0448</doc-id>
        <title>Print files in FTP</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>February</month>
            <day>27</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6838</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0449</doc-id>
        <title>Current flow-control scheme for IMPSYS</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>January</month>
            <day>06</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1662</char-count>
            <page-count>1</page-count>
        </format>
        <updates>
            <doc-id>RFC0442</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0450</doc-id>
        <title>MULTICS sampling timeout change</title>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>February</month>
            <day>08</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>924</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0451</doc-id>
        <title>Tentative proposal for a Unified User Level Protocol</title>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>February</month>
            <day>22</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8114</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0452</doc-id>
        <title>TELENET Command at Host LL</title>
        <author>
            <name>J. Winett</name>
        </author>
        <date>
            <month>February</month>
            <day>08</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0453</doc-id>
        <title>Meeting announcement to discuss a network mail system</title>
        <author>
            <name>M.D. Kudlick</name>
        </author>
        <date>
            <month>February</month>
            <day>07</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4572</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0454</doc-id>
        <title>File Transfer Protocol - meeting announcement and a new proposed document</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>February</month>
            <day>16</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>78966</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <updates>
            <doc-id>RFC0354</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0455</doc-id>
        <title>Traffic statistics (January 1973)</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>February</month>
            <day>12</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5746</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0456</doc-id>
        <title>Memorandum: Date change of mail meeting</title>
        <author>
            <name>M.D. Kudlick</name>
        </author>
        <date>
            <month>February</month>
            <day>13</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>950</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0457</doc-id>
        <title>TIPUG</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>February</month>
            <day>15</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>845</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0458</doc-id>
        <title>Mail retrieval via FTP</title>
        <author>
            <name>R.D. Bressler</name>
        </author>
        <author>
            <name>R. Thomas</name>
        </author>
        <date>
            <month>February</month>
            <day>20</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2705</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0459</doc-id>
        <title>Network questionnaires</title>
        <author>
            <name>W. Kantrowitz</name>
        </author>
        <date>
            <month>February</month>
            <day>26</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1950</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0460</doc-id>
        <title>NCP survey</title>
        <author>
            <name>C. Kline</name>
        </author>
        <date>
            <month>February</month>
            <day>13</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10324</char-count>
            <page-count>7</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0461</doc-id>
        <title>Telnet Protocol meeting announcement</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>February</month>
            <day>14</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1966</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0462</doc-id>
        <title>Responding to user needs</title>
        <author>
            <name>J. Iseli</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>February</month>
            <day>22</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2808</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0463</doc-id>
        <title>FTP comments and response to RFC 430</title>
        <author>
            <name>A.K. Bhushan</name>
        </author>
        <date>
            <month>February</month>
            <day>21</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5729</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0464</doc-id>
        <title>Resource notebook framework</title>
        <author>
            <name>M.D. Kudlick</name>
        </author>
        <date>
            <month>February</month>
            <day>27</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3684</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0465</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0466</doc-id>
        <title>Telnet logger/server for host LL-67</title>
        <author>
            <name>J.M. Winett</name>
        </author>
        <date>
            <month>February</month>
            <day>27</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17595</char-count>
            <page-count>9</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0467</doc-id>
        <title>Proposed change to Host-Host Protocol: Resynchronization of connection status</title>
        <author>
            <name>J.D. Burchfiel</name>
        </author>
        <author>
            <name>R.S. Tomlinson</name>
        </author>
        <date>
            <month>February</month>
            <day>20</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14325</char-count>
            <page-count>7</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0492</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0468</doc-id>
        <title>FTP data compression</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>March</month>
            <day>08</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14909</char-count>
            <page-count>7</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0469</doc-id>
        <title>Network mail meeting summary</title>
        <author>
            <name>M.D. Kudlick</name>
        </author>
        <date>
            <month>March</month>
            <day>08</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17774</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>network</kw>
            <kw>mail</kw>
            <kw>meeting</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0470</doc-id>
        <title>Change in socket for TIP news facility</title>
        <author>
            <name>R. Thomas</name>
        </author>
        <date>
            <month>March</month>
            <day>13</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1014</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0471</doc-id>
        <title>Workshop on multi-site executive programs</title>
        <author>
            <name>R. Thomas</name>
        </author>
        <date>
            <month>March</month>
            <day>13</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3339</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0472</doc-id>
        <title>Illinois' reply to Maxwell's request for graphics information (NIC 14925)</title>
        <author>
            <name>S. Bunch</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4780</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0473</doc-id>
        <title>MIX and MIXAL?</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>February</month>
            <day>28</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>868</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0474</doc-id>
        <title>Announcement of NGWG meeting: Call for papers</title>
        <author>
            <name>S. Bunch</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1170</char-count>
            <page-count>2</page-count>
        </format>
        <updates>
            <doc-id>RFC0396</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0475</doc-id>
        <title>FTP and network mail system</title>
        <author>
            <name>A.K. Bhushan</name>
        </author>
        <date>
            <month>March</month>
            <day>06</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0476</doc-id>
        <title>IMP/TIP memory retrofit schedule (rev 2)</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>March</month>
            <day>07</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2281</char-count>
            <page-count>2</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0447</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0477</doc-id>
        <title>Remote Job Service at UCSB</title>
        <author>
            <name>M. Krilanovich</name>
        </author>
        <date>
            <month>May</month>
            <day>23</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40535</char-count>
            <page-count>19</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0478</doc-id>
        <title>FTP server-server interaction - II</title>
        <author>
            <name>R.D. Bressler</name>
        </author>
        <author>
            <name>R. Thomas</name>
        </author>
        <date>
            <month>March</month>
            <day>26</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4199</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0479</doc-id>
        <title>Use of FTP by the NIC Journal</title>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>March</month>
            <day>08</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11183</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0480</doc-id>
        <title>Host-dependent FTP parameters</title>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>March</month>
            <day>08</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2084</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0481</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0482</doc-id>
        <title>Traffic statistics (February 1973)</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>March</month>
            <day>12</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6162</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0483</doc-id>
        <title>Cancellation of the resource notebook framework meeting</title>
        <author>
            <name>M.D. Kudlick</name>
        </author>
        <date>
            <month>March</month>
            <day>14</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1021</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0484</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0485</doc-id>
        <title>MIX and MIXAL at UCSB</title>
        <author>
            <name>J.R. Pickens</name>
        </author>
        <date>
            <month>March</month>
            <day>19</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2226</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0486</doc-id>
        <title>Data transfer revisited</title>
        <author>
            <name>R.D. Bressler</name>
        </author>
        <date>
            <month>March</month>
            <day>20</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4664</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>RJE</kw>
            <kw>FTP</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0487</doc-id>
        <title>Free file transfer</title>
        <author>
            <name>R.D. Bressler</name>
        </author>
        <date>
            <month>April</month>
            <day>06</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3249</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0488</doc-id>
        <title>NLS classes at network sites</title>
        <author>
            <name>M.F. Auerbach</name>
        </author>
        <date>
            <month>March</month>
            <day>23</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3806</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0489</doc-id>
        <title>Comment on resynchronization of connection status proposal</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>March</month>
            <day>26</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2010</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0490</doc-id>
        <title>Surrogate RJS for UCLA-CCN</title>
        <author>
            <name>J.R. Pickens</name>
        </author>
        <date>
            <month>March</month>
            <day>06</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9858</char-count>
            <page-count>6</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0491</doc-id>
        <title>What is "Free"?</title>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>April</month>
            <day>12</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5872</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0492</doc-id>
        <title>Response to RFC 467</title>
        <author>
            <name>E. Meyer</name>
        </author>
        <date>
            <month>April</month>
            <day>18</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18791</char-count>
            <page-count>7</page-count>
        </format>
        <updates>
            <doc-id>RFC0467</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0493</doc-id>
        <title>Graphics Protocol</title>
        <author>
            <name>J.C. Michener</name>
        </author>
        <author>
            <name>I.W. Cotton</name>
        </author>
        <author>
            <name>K.C. Kelley</name>
        </author>
        <author>
            <name>D.E. Liddle</name>
        </author>
        <author>
            <name>E. Meyer</name>
        </author>
        <date>
            <month>April</month>
            <day>26</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0494</doc-id>
        <title>Availability of MIX and MIXAL in the Network</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>April</month>
            <day>20</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2007</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0495</doc-id>
        <title>Telnet Protocol specifications</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4260</char-count>
            <page-count>2</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0158</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0496</doc-id>
        <title>TNLS quick reference card is available</title>
        <author>
            <name>M.F. Auerbach</name>
        </author>
        <date>
            <month>April</month>
            <day>05</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1110</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0497</doc-id>
        <title>Traffic statistics (March 1973)</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>April</month>
            <day>10</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0498</doc-id>
        <title>On mail service to CCN</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>April</month>
            <day>17</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5315</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0499</doc-id>
        <title>Harvard's network RJE</title>
        <author>
            <name>B.R. Reussow</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12584</char-count>
            <page-count>6</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0500</doc-id>
        <title>Integration of data management systems on a computer network</title>
        <author>
            <name>A. Shoshani</name>
        </author>
        <author>
            <name>I. Spiegler</name>
        </author>
        <date>
            <month>April</month>
            <day>16</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0501</doc-id>
        <title>Un-muddling "free file transfer"</title>
        <author>
            <name>K.T. Pogran</name>
        </author>
        <date>
            <month>May</month>
            <day>11</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13177</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0502</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0503</doc-id>
        <title>Socket number list</title>
        <author>
            <name>N. Neigus</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>April</month>
            <day>12</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8690</char-count>
            <page-count>8</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0433</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0739</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0504</doc-id>
        <title>Distributed resources workshop announcement</title>
        <author>
            <name>R. Thomas</name>
        </author>
        <date>
            <month>April</month>
            <day>30</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9061</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0505</doc-id>
        <title>Two solutions to a file transfer access problem</title>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>June</month>
            <day>25</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7476</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
            <kw>free</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0506</doc-id>
        <title>FTP command naming problem</title>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>June</month>
            <day>26</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1974</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0507</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0508</doc-id>
        <title>Real-time data transmission on the ARPANET</title>
        <author>
            <name>L. Pfeifer</name>
        </author>
        <author>
            <name>J. McAfee</name>
        </author>
        <date>
            <month>May</month>
            <day>07</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25002</char-count>
            <page-count>10</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0509</doc-id>
        <title>Traffic statistics (April 1973)</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>April</month>
            <day>07</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6538</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0510</doc-id>
        <title>Request for network mailbox addresses</title>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>May</month>
            <day>30</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4150</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0511</doc-id>
        <title>Enterprise phone service to NIC from ARPANET sites</title>
        <author>
            <name>J.B. North</name>
        </author>
        <date>
            <month>May</month>
            <day>23</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4664</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0512</doc-id>
        <title>More on lost message detection</title>
        <author>
            <name>W. Hathaway</name>
        </author>
        <date>
            <month>May</month>
            <day>23</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3641</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0513</doc-id>
        <title>Comments on the new Telnet specifications</title>
        <author>
            <name>W. Hathaway</name>
        </author>
        <date>
            <month>May</month>
            <day>30</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7980</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0514</doc-id>
        <title>Network make-work</title>
        <author>
            <name>W. Kantrowitz</name>
        </author>
        <date>
            <month>June</month>
            <day>05</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8734</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0515</doc-id>
        <title>Specifications for datalanguage: Version 0/9</title>
        <author>
            <name>R. Winter</name>
        </author>
        <date>
            <month>June</month>
            <day>06</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0516</doc-id>
        <title>Lost message detection</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <day>18</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4086</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0517</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0518</doc-id>
        <title>ARPANET accounts</title>
        <author>
            <name>N. Vaughan</name>
        </author>
        <author>
            <name>E.J. Feinler</name>
        </author>
        <date>
            <month>June</month>
            <day>19</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12880</char-count>
            <page-count>9</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0519</doc-id>
        <title>Resource evaluation</title>
        <author>
            <name>J.R. Pickens</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0520</doc-id>
        <title>Memo to FTP group: Proposal for File Access Protocol</title>
        <author>
            <name>J.D. Day</name>
        </author>
        <date>
            <month>June</month>
            <day>25</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16825</char-count>
            <page-count>8</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0521</doc-id>
        <title>Restricted use of IMP DDT</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>May</month>
            <day>30</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3724</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0522</doc-id>
        <title>Traffic statistics (May 1973)</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>June</month>
            <day>05</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0523</doc-id>
        <title>SURVEY is in operation again</title>
        <author>
            <name>A.K. Bhushan</name>
        </author>
        <date>
            <month>June</month>
            <day>05</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2852</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0524</doc-id>
        <title>Proposed Mail Protocol</title>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>June</month>
            <day>13</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>75385</char-count>
            <page-count>40</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0525</doc-id>
        <title>MIT-MATHLAB meets UCSB-OLS -an example of resource sharing</title>
        <author>
            <name>W. Parrish</name>
        </author>
        <author>
            <name>J.R. Pickens</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18501</char-count>
            <page-count>9</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>304440</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>228274</char-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0526</doc-id>
        <title>Technical meeting: Digital image processing software systems</title>
        <author>
            <name>W.K. Pratt</name>
        </author>
        <date>
            <month>June</month>
            <day>25</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4062</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0527</doc-id>
        <title>ARPAWOCKY</title>
        <author>
            <name>R. Merryman</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1857</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0528</doc-id>
        <title>Software checksumming in the IMP and network reliability</title>
        <author>
            <name>J.M. McQuillan</name>
        </author>
        <date>
            <month>June</month>
            <day>20</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23152</char-count>
            <page-count>9</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0529</doc-id>
        <title>Note on protocol synch sequences</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <author>
            <name>R. Thomas</name>
        </author>
        <author>
            <name>R.S. Tomlinson</name>
        </author>
        <author>
            <name>K.T. Pogran</name>
        </author>
        <date>
            <month>June</month>
            <day>29</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9068</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0530</doc-id>
        <title>Report on the Survey project</title>
        <author>
            <name>A.K. Bhushan</name>
        </author>
        <date>
            <month>June</month>
            <day>22</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0531</doc-id>
        <title>Feast or famine? A response to two recent RFC's about network information</title>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>June</month>
            <day>26</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5070</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0532</doc-id>
        <title>UCSD-CC Server-FTP facility</title>
        <author>
            <name>R.G. Merryman</name>
        </author>
        <date>
            <month>July</month>
            <day>12</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7298</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
            <kw>server</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0533</doc-id>
        <title>Message-ID numbers</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>July</month>
            <day>17</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2102</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0534</doc-id>
        <title>Lost message detection</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>July</month>
            <day>17</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3227</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0535</doc-id>
        <title>Comments on File Access Protocol</title>
        <author>
            <name>R. Thomas</name>
        </author>
        <date>
            <month>July</month>
            <day>25</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0536</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0537</doc-id>
        <title>Announcement of NGG meeting July 16-17</title>
        <author>
            <name>S. Bunch</name>
        </author>
        <date>
            <month>June</month>
            <day>27</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2695</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0538</doc-id>
        <title>Traffic statistics (June 1973)</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>July</month>
            <day>05</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6389</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0539</doc-id>
        <title>Thoughts on the mail protocol proposed in RFC 524</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>July</month>
            <day>07</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6213</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0540</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0541</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0542</doc-id>
        <title>File Transfer Protocol</title>
        <author>
            <name>N. Neigus</name>
        </author>
        <date>
            <month>August</month>
            <day>12</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>100666</char-count>
            <page-count>40</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <obsoletes>
            <doc-id>RFC0354</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0765</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC0614</doc-id>
            <doc-id>RFC0640</doc-id>
        </updated-by>
        <see-also>
            <doc-id>RFC0454</doc-id>
            <doc-id>RFC0495</doc-id>
        </see-also>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0543</doc-id>
        <title>Network journal submission and delivery</title>
        <author>
            <name>N.D. Meyer</name>
        </author>
        <date>
            <month>July</month>
            <day>24</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15621</char-count>
            <page-count>8</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0544</doc-id>
        <title>Locating on-line documentation at SRI-ARC</title>
        <author>
            <name>N.D. Meyer</name>
        </author>
        <author>
            <name>K. Kelley</name>
        </author>
        <date>
            <month>July</month>
            <day>13</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1541</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0545</doc-id>
        <title>Of what quality be the UCSB resources evaluators?</title>
        <author>
            <name>J.R. Pickens</name>
        </author>
        <date>
            <month>July</month>
            <day>23</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3754</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0546</doc-id>
        <title>Tenex load averages for July 1973</title>
        <author>
            <name>R. Thomas</name>
        </author>
        <date>
            <month>August</month>
            <day>10</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6632</char-count>
            <page-count>4</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>356023</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>268918</char-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0547</doc-id>
        <title>Change to the Very Distant Host specification</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>August</month>
            <day>13</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6236</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0548</doc-id>
        <title>Hosts using the IMP Going Down message</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>August</month>
            <day>16</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1435</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0549</doc-id>
        <title>Minutes of Network Graphics Group meeting, 15-17 July 1973</title>
        <author>
            <name>J.C. Michener</name>
        </author>
        <date>
            <month>July</month>
            <day>17</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23367</char-count>
            <page-count>12</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0550</doc-id>
        <title>NIC NCP experiment</title>
        <author>
            <name>L.P. Deutsch</name>
        </author>
        <date>
            <month>August</month>
            <day>24</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3688</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0551</doc-id>
        <title>NYU, ANL, and LBL Joining the Net</title>
        <author>
            <name>Feinroth</name>
        </author>
        <date>
            <month>August</month>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0552</doc-id>
        <title>Single access to standard protocols</title>
        <author>
            <name>A.D. Owen</name>
        </author>
        <date>
            <month>July</month>
            <day>13</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1404</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0553</doc-id>
        <title>Draft design for a text/graphics protocol</title>
        <author>
            <name>C.H. Irby</name>
        </author>
        <author>
            <name>K. Victor</name>
        </author>
        <date>
            <month>July</month>
            <day>14</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35414</char-count>
            <page-count>19</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0554</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0555</doc-id>
        <title>Responses to critiques of the proposed mail protocol</title>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>July</month>
            <day>27</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21521</char-count>
            <page-count>11</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0556</doc-id>
        <title>Traffic statistics (July 1973)</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>August</month>
            <day>13</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0557</doc-id>
        <title>Revelations in network host measurements</title>
        <author>
            <name>B.D. Wessler</name>
        </author>
        <date>
            <month>August</month>
            <day>30</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0558</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0559</doc-id>
        <title>Comments on The New Telnet Protocol and its Implementation</title>
        <author>
            <name>A.K. Bushan</name>
        </author>
        <date>
            <month>August</month>
            <day>15</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10643</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0560</doc-id>
        <title>Remote Controlled Transmission and Echoing Telnet option</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>August</month>
            <day>18</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0561</doc-id>
        <title>Standardizing Network Mail Headers</title>
        <author>
            <name>A.K. Bhushan</name>
        </author>
        <author>
            <name>K.T. Pogran</name>
        </author>
        <author>
            <name>R.S. Tomlinson</name>
        </author>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>September</month>
            <day>05</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6159</char-count>
            <page-count>3</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0680</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0562</doc-id>
        <title>Modifications to the Telnet specification</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>August</month>
            <day>28</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0563</doc-id>
        <title>Comments on the RCTE Telnet option</title>
        <author>
            <name>J. Davidson</name>
        </author>
        <date>
            <month>August</month>
            <day>28</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10788</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0564</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0565</doc-id>
        <title>Storing network survey data at the datacomputer</title>
        <author>
            <name>D. Cantor</name>
        </author>
        <date>
            <month>August</month>
            <day>28</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9307</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0566</doc-id>
        <title>Traffic statistics (August 1973)</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>September</month>
            <day>04</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6674</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0567</doc-id>
        <title>Cross Country Network Bandwidth</title>
        <author>
            <name>L.P. Deutsch</name>
        </author>
        <date>
            <month>September</month>
            <day>06</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1529</char-count>
            <page-count>1</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0568</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0568</doc-id>
        <title>Response to RFC 567 - cross country network bandwidth</title>
        <author>
            <name>J.M. McQuillan</name>
        </author>
        <date>
            <month>September</month>
            <day>18</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3244</char-count>
            <page-count>3</page-count>
        </format>
        <updates>
            <doc-id>RFC0567</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0569</doc-id>
        <title>NETED: A Common Editor for the ARPA Network</title>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>October</month>
            <day>15</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17717</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>NETED</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0570</doc-id>
        <title>Experimental input mapping between NVT ASCII and UCSB On Line System</title>
        <author>
            <name>J.R. Pickens</name>
        </author>
        <date>
            <month>October</month>
            <day>30</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>177</char-count>
            <page-count>1</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>488023</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>375635</char-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0571</doc-id>
        <title>Tenex FTP problem</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>November</month>
            <day>15</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0572</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0573</doc-id>
        <title>Data and file transfer: Some measurement results</title>
        <author>
            <name>A.K. Bhushan</name>
        </author>
        <date>
            <month>September</month>
            <day>14</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0574</doc-id>
        <title>Announcement of a mail facility at UCSB</title>
        <author>
            <name>M. Krilanovich</name>
        </author>
        <date>
            <month>September</month>
            <day>26</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0575</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0576</doc-id>
        <title>Proposal for modifying linking</title>
        <author>
            <name>K. Victor</name>
        </author>
        <date>
            <month>September</month>
            <day>26</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0577</doc-id>
        <title>Mail priority</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>October</month>
            <day>18</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0578</doc-id>
        <title>Using MIT-Mathlab MACSYMA from MIT-DMS Muddle</title>
        <author>
            <name>A.K. Bhushan</name>
        </author>
        <author>
            <name>N.D. Ryan</name>
        </author>
        <date>
            <month>October</month>
            <day>29</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0579</doc-id>
        <title>Traffic statistics (September 1973)</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>November</month>
            <day>26</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0580</doc-id>
        <title>Note to Protocol Designers and Implementers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>October</month>
            <day>25</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1451</char-count>
            <page-count>1</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0582</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0581</doc-id>
        <title>Corrections to RFC 560: Remote Controlled Transmission and Echoing Telnet Option</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <day>02</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0582</doc-id>
        <title>Comments on RFC 580: Machine readable protocols</title>
        <author>
            <name>R. Clements</name>
        </author>
        <date>
            <month>November</month>
            <day>05</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1635</char-count>
            <page-count>1</page-count>
        </format>
        <updates>
            <doc-id>RFC0580</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0583</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0584</doc-id>
        <title>Charter for ARPANET Users Interest Working Group</title>
        <author>
            <name>J. Iseli</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <author>
            <name>N. Neigus</name>
        </author>
        <date>
            <month>November</month>
            <day>06</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3461</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0585</doc-id>
        <title>ARPANET users interest working group meeting</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <author>
            <name>N. Neigus</name>
        </author>
        <author>
            <name>E.J. Feinler</name>
        </author>
        <author>
            <name>J. Iseli</name>
        </author>
        <date>
            <month>November</month>
            <day>06</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18243</char-count>
            <page-count>9</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0586</doc-id>
        <title>Traffic statistics (October 1973)</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>November</month>
            <day>08</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0587</doc-id>
        <title>Announcing new Telnet options</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <day>13</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0588</doc-id>
        <title>London node is now up</title>
        <author>
            <name>A.V. Stokes</name>
        </author>
        <date>
            <month>October</month>
            <day>29</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0589</doc-id>
        <title>CCN NETRJS server messages to remote user</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>November</month>
            <day>26</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7998</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0590</doc-id>
        <title>MULTICS address change</title>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>November</month>
            <day>19</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1436</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0591</doc-id>
        <title>Addition to the Very Distant Host specifications</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>November</month>
            <day>29</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>901</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0592</doc-id>
        <title>Some thoughts on system design to facilitate resource sharing</title>
        <author>
            <name>R.W. Watson</name>
        </author>
        <date>
            <month>November</month>
            <day>20</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0593</doc-id>
        <title>Telnet and FTP implementation schedule change</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <day>29</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2506</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0594</doc-id>
        <title>Speedup of Host-IMP interface</title>
        <author>
            <name>J.D. Burchfiel</name>
        </author>
        <date>
            <month>December</month>
            <day>10</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0595</doc-id>
        <title>Second thoughts in defense of the Telnet Go-Ahead</title>
        <author>
            <name>W. Hathaway</name>
        </author>
        <date>
            <month>December</month>
            <day>12</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13507</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0596</doc-id>
        <title>Second thoughts on Telnet Go-Ahead</title>
        <author>
            <name>E.A. Taft</name>
        </author>
        <date>
            <month>December</month>
            <day>08</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11919</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0597</doc-id>
        <title>Host status</title>
        <author>
            <name>N. Neigus</name>
        </author>
        <author>
            <name>E.J. Feinler</name>
        </author>
        <date>
            <month>December</month>
            <day>12</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11678</char-count>
            <page-count>6</page-count>
        </format>
        <updated-by>
            <doc-id>RFC0603</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0598</doc-id>
        <title>RFC index - December 5, 1973</title>
        <author>
            <name>Network Information Center. Stanford Research Institute </name>
        </author>
        <date>
            <month>December</month>
            <day>05</day>
            <year>1973</year>
        </date>
        <notes>Not Available Online</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0599</doc-id>
        <title>Update on NETRJS</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>December</month>
            <day>13</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16590</char-count>
            <page-count>9</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0189</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0740</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0600</doc-id>
        <title>Interfacing an Illinois plasma terminal to the ARPANET</title>
        <author>
            <name>A. Berggreen</name>
        </author>
        <date>
            <month>November</month>
            <day>26</day>
            <year>1973</year>
        </date>
        <abstract>Discusses some unusual interface issues for the Plato terminal. </abstract>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0601</doc-id>
        <title>Traffic statistics (November 1973)</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>December</month>
            <day>14</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9100</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0602</doc-id>
        <title>"The stockings were hung by the chimney with care"</title>
        <author>
            <name>R.M. Metcalfe</name>
        </author>
        <date>
            <month>December</month>
            <day>27</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1988</char-count>
            <page-count>1</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>violations</kw>
            <kw>TIP</kw>
            <kw>arpanet</kw>
        </keywords>
        <abstract>Susceptibility of ARPANET to security violations. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0603</doc-id>
        <title>Response to RFC 597: Host status</title>
        <author>
            <name>J.D. Burchfiel</name>
        </author>
        <date>
            <month>December</month>
            <day>31</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1482</char-count>
            <page-count>1</page-count>
        </format>
        <abstract>Questions about the ARPANET topology described in RFC 597. </abstract>
        <updates>
            <doc-id>RFC0597</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0613</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0604</doc-id>
        <title>Assigned link numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>December</month>
            <day>26</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2758</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>Modifies official host-host protocol. Replaces RFC 377. </abstract>
        <obsoletes>
            <doc-id>RFC0317</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0739</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0605</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0606</doc-id>
        <title>Host names on-line</title>
        <author>
            <name>L.P. Deutsch</name>
        </author>
        <date>
            <month>December</month>
            <day>29</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6855</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>lists</kw>
            <kw>names</kw>
            <kw>host</kw>
            <kw>addresses</kw>
        </keywords>
        <abstract>Resolving differences in hostname-address mappings; see also RFCs 627, 625, 623 and 608. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0607</doc-id>
        <title>Comments on the File Transfer Protocol</title>
        <author>
            <name>M. Krilanovich</name>
        </author>
        <author>
            <name>G. Gregg</name>
        </author>
        <date>
            <month>January</month>
            <day>07</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8652</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>solutions</kw>
            <kw>weakness</kw>
            <kw>ftp</kw>
        </keywords>
        <abstract>An old version; see RFC 624; see also RFCs 614, 542 and 640. </abstract>
        <obsoleted-by>
            <doc-id>RFC0624</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC0614</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0608</doc-id>
        <title>Host names on-line</title>
        <author>
            <name>M.D. Kudlick</name>
        </author>
        <date>
            <month>January</month>
            <day>10</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7010</char-count>
            <page-count>4</page-count>
        </format>
        <abstract>Response to RFC 606; see also RFCs 627, 625 and 623. </abstract>
        <obsoleted-by>
            <doc-id>RFC0810</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0609</doc-id>
        <title>Statement of upcoming move of NIC/NLS service</title>
        <author>
            <name>B. Ferguson</name>
        </author>
        <date>
            <month>January</month>
            <day>10</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1260</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>See also RFCs 621 and 620. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0610</doc-id>
        <title>Further datalanguage design concepts</title>
        <author>
            <name>R. Winter</name>
        </author>
        <author>
            <name>J. Hill</name>
        </author>
        <author>
            <name>W. Greiff</name>
        </author>
        <date>
            <month>December</month>
            <day>15</day>
            <year>1973</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>198692</char-count>
            <page-count>88</page-count>
        </format>
        <abstract>Preliminary results of the language design; a model for data languagea semantics; future considerations. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0611</doc-id>
        <title>Two changes to the IMP/Host Protocol to improve user/network communications</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>February</month>
            <day>14</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7481</char-count>
            <page-count>4</page-count>
        </format>
        <abstract>Expansion of Host-Going-Down and addition of Dead-Host-Status Message. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0612</doc-id>
        <title>Traffic statistics (December 1973)</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>January</month>
            <day>16</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9667</char-count>
            <page-count>6</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0613</doc-id>
        <title>Network connectivity: A response to RFC 603</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>January</month>
            <day>21</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2557</char-count>
            <page-count>1</page-count>
        </format>
        <updates>
            <doc-id>RFC0603</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0614</doc-id>
        <title>Response to RFC 607: "Comments on the File Transfer Protocol"</title>
        <author>
            <name>K.T. Pogran</name>
        </author>
        <author>
            <name>N. Neigus</name>
        </author>
        <date>
            <month>January</month>
            <day>28</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11409</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>ftp</kw>
            <kw>weakness</kw>
            <kw>solutions</kw>
        </keywords>
        <abstract>See also RFCs 624, 542 and 640. </abstract>
        <updates>
            <doc-id>RFC0542</doc-id>
            <doc-id>RFC0607</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0615</doc-id>
        <title>Proposed Network Standard Data Pathname syntax</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9448</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0616</doc-id>
        <title>Latest network maps</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>February</month>
            <day>11</day>
            <year>1973</year>
        </date>
        <keywords>
            <kw>Network</kw>
            <kw>maps</kw>
        </keywords>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0617</doc-id>
        <title>Note on socket number assignment</title>
        <author>
            <name>E.A. Taft</name>
        </author>
        <date>
            <month>February</month>
            <day>19</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8062</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>telnet</kw>
        </keywords>
        <abstract>Danger of imposing more fixed socket number requirements; see also RFCs 542, 503 and 451. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0618</doc-id>
        <title>Few observations on NCP statistics</title>
        <author>
            <name>E.A. Taft</name>
        </author>
        <date>
            <month>February</month>
            <day>19</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4929</char-count>
            <page-count>3</page-count>
        </format>
        <abstract>Distribution of NCP and IMP message types by actual measurement. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0619</doc-id>
        <title>Mean round-trip times in the ARPANET</title>
        <author>
            <name>W. Naylor</name>
        </author>
        <author>
            <name>H. Opderbeck</name>
        </author>
        <date>
            <month>March</month>
            <day>07</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30946</char-count>
            <page-count>14</page-count>
        </format>
        <abstract>Actual measurements of round-trip times. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0620</doc-id>
        <title>Request for monitor host table updates</title>
        <author>
            <name>B. Ferguson</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1950</char-count>
            <page-count>1</page-count>
        </format>
        <keywords>
            <kw>tenex  </kw>
        </keywords>
        <abstract>In conjunction with moving NIC users to OFFICE-1; see also RFCs 621 and 609. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0621</doc-id>
        <title>NIC user directories at SRI ARC</title>
        <author>
            <name>M.D. Kudlick</name>
        </author>
        <date>
            <month>March</month>
            <day>06</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1351</char-count>
            <page-count>1</page-count>
        </format>
        <abstract>See also RFCs 620 and 609. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0622</doc-id>
        <title>Scheduling IMP/TIP down time</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>March</month>
            <day>13</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4367</char-count>
            <page-count>3</page-count>
        </format>
        <abstract>Modification of previous policy. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0623</doc-id>
        <title>Comments on on-line host name service</title>
        <author>
            <name>M. Krilanovich</name>
        </author>
        <date>
            <month>February</month>
            <day>22</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3740</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>See also RFCs 627, 625, 608 and 606. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0624</doc-id>
        <title>Comments on the File Transfer Protocol</title>
        <author>
            <name>M. Krilanovich</name>
        </author>
        <author>
            <name>G. Gregg</name>
        </author>
        <author>
            <name>W. Hathaway</name>
        </author>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>February</month>
            <day>28</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10105</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>ftp</kw>
            <kw>telnet</kw>
        </keywords>
        <abstract>Design changes and slight modifications. Replaces RFC 607; see also RFCs 614, 542 and 640. </abstract>
        <obsoletes>
            <doc-id>RFC0607</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0625</doc-id>
        <title>On-line hostnames service</title>
        <author>
            <name>M.D. Kudlick</name>
        </author>
        <author>
            <name>E.J. Feinler</name>
        </author>
        <date>
            <month>March</month>
            <day>07</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2172</char-count>
            <page-count>1</page-count>
        </format>
        <abstract>See also RFCs 606, 608, 623 and 627. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0626</doc-id>
        <title>On a possible lockup condition in IMP subnet due to message sequencing</title>
        <author>
            <name>L. Kleinrock</name>
        </author>
        <author>
            <name>H. Opderbeck</name>
        </author>
        <date>
            <month>March</month>
            <day>14</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13150</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0627</doc-id>
        <title>ASCII text file of hostnames</title>
        <author>
            <name>M.D. Kudlick</name>
        </author>
        <author>
            <name>E.J. Feinler</name>
        </author>
        <date>
            <month>March</month>
            <day>25</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2007</char-count>
            <page-count>1</page-count>
        </format>
        <abstract>See also RFCs 606, 608, 623 and 625. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0628</doc-id>
        <title>Status of RFC numbers and a note on pre-assigned journal numbers</title>
        <author>
            <name>M.L. Keeney</name>
        </author>
        <date>
            <month>March</month>
            <day>27</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1036</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0629</doc-id>
        <title>Scenario for using the Network Journal</title>
        <author>
            <name>J.B. North</name>
        </author>
        <date>
            <month>March</month>
            <day>27</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4504</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0630</doc-id>
        <title>FTP error code usage for more reliable mail service</title>
        <author>
            <name>J. Sussman</name>
        </author>
        <date>
            <month>April</month>
            <day>10</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4070</char-count>
            <page-count>3</page-count>
        </format>
        <abstract>Describes FTP reply-code usage in TENEX mail processing. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0631</doc-id>
        <title>International meeting on minicomputers and data communication: Call for papers</title>
        <author>
            <name>A. Danthine</name>
        </author>
        <date>
            <month>April</month>
            <day>17</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2707</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0632</doc-id>
        <title>Throughput degradations for single packet messages</title>
        <author>
            <name>H. Opderbeck</name>
        </author>
        <date>
            <month>May</month>
            <day>20</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14563</char-count>
            <page-count>6</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0633</doc-id>
        <title>IMP/TIP preventive maintenance schedule</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>March</month>
            <day>18</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3733</char-count>
            <page-count>4</page-count>
        </format>
        <abstract>An old version; see RFC 638. </abstract>
        <obsoleted-by>
            <doc-id>RFC0638</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0634</doc-id>
        <title>Change in network address for Haskins Lab</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>April</month>
            <day>10</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1098</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0635</doc-id>
        <title>Assessment of ARPANET protocols</title>
        <author>
            <name>V. Cerf</name>
        </author>
        <date>
            <month>April</month>
            <day>22</day>
            <year>1974</year>
        </date>
        <abstract>Theoretical and practical motivation for redesign. Multipacket messages; host retransmission; duplicate detection; sequencing; acknowledgement. </abstract>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0636</doc-id>
        <title>TIP/Tenex reliability improvements</title>
        <author>
            <name>J.D. Burchfiel</name>
        </author>
        <author>
            <name>B. Cosell</name>
        </author>
        <author>
            <name>R.S. Tomlinson</name>
        </author>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>June</month>
            <day>10</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19914</char-count>
            <page-count>8</page-count>
        </format>
        <abstract>Obtaining/maintaining connections; recovery from lost connections; connection-state changes. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0637</doc-id>
        <title>Change of network address for SU-DSL</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>April</month>
            <day>23</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>916</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0638</doc-id>
        <title>IMP/TIP preventive maintenance schedule</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>April</month>
            <day>25</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4088</char-count>
            <page-count>4</page-count>
        </format>
        <abstract>Corrects RFC 633. </abstract>
        <obsoletes>
            <doc-id>RFC0633</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0639</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0640</doc-id>
        <title>Revised FTP reply codes</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>June</month>
            <day>19</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39670</char-count>
            <page-count>17</page-count>
        </format>
        <abstract>Updates RFC 542. </abstract>
        <updates>
            <doc-id>RFC0542</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0641</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0642</doc-id>
        <title>Ready line philosophy and implementation</title>
        <author>
            <name>J.D. Burchfiel</name>
        </author>
        <date>
            <month>July</month>
            <day>05</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8414</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0643</doc-id>
        <title>Network Debugging Protocol</title>
        <author>
            <name>E. Mader</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12563</char-count>
            <page-count>7</page-count>
        </format>
        <abstract>To be used in an implementation of a PDP-11 network bootstrap device and a cross-network debugger. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0644</doc-id>
        <title>On the problem of signature authentication for network mail</title>
        <author>
            <name>R. Thomas</name>
        </author>
        <date>
            <month>July</month>
            <day>22</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9501</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0645</doc-id>
        <title>Network Standard Data Specification syntax</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>June</month>
            <day>26</day>
            <year>1974</year>
        </date>
        <abstract>Providing a mechanism for specifying all attributes of a collection of bits; see also RFC 615. </abstract>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0646</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0647</doc-id>
        <title>Proposed protocol for connecting host computers to ARPA-like networks via front end processors</title>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>November</month>
            <day>12</day>
            <year>1974</year>
        </date>
        <abstract>Approaches to Front-End protocol processing using available hardware and software. </abstract>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0648</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0649</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0650</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0651</doc-id>
        <title>Revised Telnet status option</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>October</month>
            <day>25</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4360</char-count>
            <page-count>2</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0859</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0652</doc-id>
        <title>Telnet output carriage-return disposition option</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>October</month>
            <day>25</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7003</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>TOPT-OCRD</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0653</doc-id>
        <title>Telnet output horizontal tabstops option</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>October</month>
            <day>25</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4694</char-count>
            <page-count>1</page-count>
        </format>
        <keywords>
            <kw>TOPT-OHT</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0654</doc-id>
        <title>Telnet output horizontal tab disposition option</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>October</month>
            <day>25</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6158</char-count>
            <page-count>1</page-count>
        </format>
        <keywords>
            <kw>TOPT-OHTD</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0655</doc-id>
        <title>Telnet output formfeed disposition option</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>October</month>
            <day>25</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5991</char-count>
            <page-count>1</page-count>
        </format>
        <keywords>
            <kw>TOPT-OFD</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0656</doc-id>
        <title>Telnet output vertical tabstops option</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>October</month>
            <day>25</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4858</char-count>
            <page-count>1</page-count>
        </format>
        <keywords>
            <kw>TOPT-OVT</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0657</doc-id>
        <title>Telnet output vertical tab disposition option</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>October</month>
            <day>25</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5759</char-count>
            <page-count>1</page-count>
        </format>
        <keywords>
            <kw>TOPT-OVTD</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0658</doc-id>
        <title>Telnet output linefeed disposition</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>October</month>
            <day>25</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6484</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>TOPT-OLD</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0659</doc-id>
        <title>Announcing additional Telnet options</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>October</month>
            <day>18</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2016</char-count>
            <page-count>1</page-count>
        </format>
        <abstract>Options defined in RFCs 651-658. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0660</doc-id>
        <title>Some changes to the IMP and the IMP/Host interface</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>October</month>
            <day>23</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4991</char-count>
            <page-count>1</page-count>
        </format>
        <abstract>Decoupling of message number sequences of hosts; host-host access control; message number window; messages outside normal mechanism; see also BBN 1822. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0661</doc-id>
        <title>Protocol information</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <day>23</day>
            <year>1974</year>
        </date>
        <abstract>An old version; see RFC 694. </abstract>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0662</doc-id>
        <title>Performance improvement in ARPANET file transfers from Multics</title>
        <author>
            <name>R. Kanodia</name>
        </author>
        <date>
            <month>November</month>
            <day>26</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8872</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>Experimenting with host output buffers to improve throughput. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0663</doc-id>
        <title>Lost message detection and recovery protocol</title>
        <author>
            <name>R. Kanodia</name>
        </author>
        <date>
            <month>November</month>
            <day>29</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44702</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>ARPANET</kw>
            <kw>Host</kw>
        </keywords>
        <abstract>Proposed extension of host-host protocol; see also RFCs 534, 516, 512, 492 and 467. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0664</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0665</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0666</doc-id>
        <title>Specification of the Unified User-Level Protocol</title>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>November</month>
            <day>26</day>
            <year>1974</year>
        </date>
        <abstract>Discusses and proposes a common command language. </abstract>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0667</doc-id>
        <title>BBN host ports</title>
        <author>
            <name>S.G. Chipman</name>
        </author>
        <date>
            <month>December</month>
            <day>17</day>
            <year>1974</year>
        </date>
        <abstract>Approved scheme to connect host ports to the network. </abstract>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0668</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0669</doc-id>
        <title>November, 1974, survey of New-Protocol Telnet servers</title>
        <author>
            <name>D.W. Dodds</name>
        </author>
        <date>
            <month>December</month>
            <day>04</day>
            <year>1974</year>
        </date>
        <abstract>An earlier poll of Telnet server implementation status. Updates RFC 702; see also RFCs 703 and 679. </abstract>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0670</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0671</doc-id>
        <title>Note on Reconnection Protocol</title>
        <author>
            <name>R. Schantz</name>
        </author>
        <date>
            <month>December</month>
            <day>06</day>
            <year>1974</year>
        </date>
        <abstract>Experience with implementation in RSEXEC context. </abstract>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0672</doc-id>
        <title>Multi-site data collection facility</title>
        <author>
            <name>R. Schantz</name>
        </author>
        <date>
            <month>December</month>
            <day>06</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25736</char-count>
            <page-count>9</page-count>
        </format>
        <abstract>Applicability of TIP/TENEX protocols beyond TIP accounting. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0673</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0674</doc-id>
        <title>Procedure call documents: Version 2</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>December</month>
            <day>12</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12178</char-count>
            <page-count>6</page-count>
        </format>
        <abstract>Host level protocol used in the NSW--a slightly constrained version of ARPANET Host-to-Host protocol, affecting allocation, RFNM wait, and retransmission; see also RFC 684. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0675</doc-id>
        <title>Specification of Internet Transmission Control Program</title>
        <author>
            <name>V. Cerf</name>
        </author>
        <author>
            <name>Y. Dalal</name>
        </author>
        <author>
            <name>C. Sunshine</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>156874</char-count>
            <page-count>70</page-count>
        </format>
        <abstract>The first detailed specification of TCP; see RFC 793. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0676</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0677</doc-id>
        <title>Maintenance of duplicate databases</title>
        <author>
            <name>P.R. Johnson</name>
        </author>
        <author>
            <name>R. Thomas</name>
        </author>
        <date>
            <month>January</month>
            <day>27</day>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22990</char-count>
            <page-count>10</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0678</doc-id>
        <title>Standard file formats</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>December</month>
            <day>19</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12393</char-count>
            <page-count>9</page-count>
        </format>
        <abstract>For transmission of documents across different environments. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0679</doc-id>
        <title>February, 1975, survey of New-Protocol Telnet servers</title>
        <author>
            <name>D.W. Dodds</name>
        </author>
        <date>
            <month>February</month>
            <day>21</day>
            <year>1975</year>
        </date>
        <abstract>An earlier poll of Telnet server implementation status. Updates RFCs 701, 702 and 669; see also RFC 703. </abstract>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0680</doc-id>
        <title>Message Transmission Protocol</title>
        <author>
            <name>T.H. Myer</name>
        </author>
        <author>
            <name>D.A. Henderson</name>
        </author>
        <date>
            <month>April</month>
            <day>30</day>
            <year>1975</year>
        </date>
        <abstract>Extends message field definition beyond RFC 561 attempts to establish syntactic and semantic standards for ARPANET; see also RFCs 733 and 822. </abstract>
        <notes>Not Available Online..</notes>
        <updates>
            <doc-id>RFC0561</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0681</doc-id>
        <title>Network UNIX</title>
        <author>
            <name>S. Holmgren</name>
        </author>
        <date>
            <month>March</month>
            <day>18</day>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18874</char-count>
            <page-count>8</page-count>
        </format>
        <abstract>Capabilities as an ARPANET Mini-Host: standard I/O, Telnet, NCP, Hardware/Software requirements, reliability, availability. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0682</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0683</doc-id>
        <title>FTPSRV - Tenex extension for paged files</title>
        <author>
            <name>R. Clements</name>
        </author>
        <date>
            <month>April</month>
            <day>03</day>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8806</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
            <kw>paged</kw>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>Tenex</kw>
        </keywords>
        <abstract>Defines an extension to FTP for page-mode transfers between TENEX systems; also discusses file transfer reliability. </abstract>
        <updates>
            <doc-id>RFC0354</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0684</doc-id>
        <title>Commentary on procedure calling as a network protocol</title>
        <author>
            <name>R. Schantz</name>
        </author>
        <date>
            <month>April</month>
            <day>15</day>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21164</char-count>
            <page-count>9</page-count>
        </format>
        <abstract>Issues in designing distributed computing systems. Shortcomings of RFC 674; see also RFCs 542 and 354. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0685</doc-id>
        <title>Response time in cross network debugging</title>
        <author>
            <name>M. Beeler</name>
        </author>
        <date>
            <month>April</month>
            <day>16</day>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6914</char-count>
            <page-count>3</page-count>
        </format>
        <abstract>The contribution of ARPANET communication to response time. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0686</doc-id>
        <title>Leaving well enough alone</title>
        <author>
            <name>B. Harvey</name>
        </author>
        <date>
            <month>May</month>
            <day>10</day>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24605</char-count>
            <page-count>9</page-count>
        </format>
        <abstract>Discusses difference between early and later versions of FTP; see also RFCs 691, 640, 630, 542, 454, 448, 414, 385 and 354. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0687</doc-id>
        <title>IMP/Host and Host/IMP Protocol changes</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>June</month>
            <day>02</day>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6013</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>Addressing hosts on more than 63 IMPs, and other backwards compatible expansions; see also RFCs 690 and 692. </abstract>
        <obsoleted-by>
            <doc-id>RFC0704</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC0690</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0688</doc-id>
        <title>Tentative schedule for the new Telnet implementation for the TIP</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <date>
            <month>June</month>
            <day>04</day>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1593</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0689</doc-id>
        <title>Tenex NCP finite state machine for connections</title>
        <author>
            <name>R. Clements</name>
        </author>
        <date>
            <month>May</month>
            <day>23</day>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13101</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>Describes the internal states of an NCP connection in the TENEX implementation. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0690</doc-id>
        <title>Comments on the proposed Host/IMP Protocol changes</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>June</month>
            <day>06</day>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7215</char-count>
            <page-count>3</page-count>
        </format>
        <abstract>Comments on suggestions in RFC 687; see also RFCs 692 and 696. </abstract>
        <updates>
            <doc-id>RFC0687</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0692</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0691</doc-id>
        <title>One more try on the FTP</title>
        <author>
            <name>B. Harvey</name>
        </author>
        <date>
            <month>June</month>
            <day>06</day>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32821</char-count>
            <page-count>14</page-count>
        </format>
        <abstract>Slight revision of RFC 686, on the subject of print files; see also RFCs 640, 630, 542, 454, 448, 414, 385 and 354. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0692</doc-id>
        <title>Comments on IMP/Host Protocol changes (RFCs 687 and 690)</title>
        <author>
            <name>S.M. Wolfe</name>
        </author>
        <date>
            <month>June</month>
            <day>20</day>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2681</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>A proposed solution to the problem of combined length of IMP and Host leaders; see also RFCs 696, 690 and 687. </abstract>
        <updates>
            <doc-id>RFC0690</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0693</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0694</doc-id>
        <title>Protocol information</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>June</month>
            <day>18</day>
            <year>1975</year>
        </date>
        <abstract>References to documents and contacts concerning the various protocols used in the ARPANET, as well as recent developments; updates RFC 661. </abstract>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0695</doc-id>
        <title>Official change in Host-Host Protocol</title>
        <author>
            <name>M. Krilanovich</name>
        </author>
        <date>
            <month>July</month>
            <day>05</day>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3425</char-count>
            <page-count>3</page-count>
        </format>
        <abstract>Corrects ambiguity concerning the ERR command; changes NIC 8246 and NIC 7104. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0696</doc-id>
        <title>Comments on the IMP/Host and Host/IMP Protocol changes</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <date>
            <month>July</month>
            <day>13</day>
            <year>1975</year>
        </date>
        <abstract>Observations on current international standards recommendations from IFIP working group 6.1; see also RFCs 692, 690 687. </abstract>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0697</doc-id>
        <title>CWD command of FTP</title>
        <author>
            <name>J. Lieb</name>
        </author>
        <date>
            <month>July</month>
            <day>14</day>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3047</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>Discusses FTP login access to "files only" directories. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0698</doc-id>
        <title>Telnet extended ASCII option</title>
        <author>
            <name>T. Mock</name>
        </author>
        <date>
            <month>July</month>
            <day>23</day>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5086</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>TOPT-EXT</kw>
        </keywords>
        <abstract>Describes an option to allow transmission of a special kind of extended ASCII used at the Stanford AI and MIT AI Labs. </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0699</doc-id>
        <title>Request For Comments summary notes: 600-699</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J. Vernon</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14688</char-count>
            <page-count>9</page-count>
        </format>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0700</doc-id>
        <title>Protocol experiment</title>
        <author>
            <name>E. Mader</name>
        </author>
        <author>
            <name>W.W. Plummer</name>
        </author>
        <author>
            <name>R.S. Tomlinson</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14600</char-count>
            <page-count>7</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0701</doc-id>
        <title>August, 1974, survey of New-Protocol Telnet servers</title>
        <author>
            <name>D.W. Dodds</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3549</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0702</doc-id>
        <title>September, 1974, survey of New-Protocol Telnet servers</title>
        <author>
            <name>D.W. Dodds</name>
        </author>
        <date>
            <month>September</month>
            <day>25</day>
            <year>1974</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5386</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0703</doc-id>
        <title>July, 1975, survey of New-Protocol Telnet Servers</title>
        <author>
            <name>D.W. Dodds</name>
        </author>
        <date>
            <month>July</month>
            <day>11</day>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5691</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0704</doc-id>
        <title>IMP/Host and Host/IMP Protocol change</title>
        <author>
            <name>P.J. Santos</name>
        </author>
        <date>
            <month>September</month>
            <day>15</day>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7504</char-count>
            <page-count>2</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0687</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0705</doc-id>
        <title>Front-end Protocol B6700 version</title>
        <author>
            <name>R.F. Bryan</name>
        </author>
        <date>
            <month>November</month>
            <day>05</day>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>70998</char-count>
            <page-count>39</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0706</doc-id>
        <title>On the junk mail problem</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <day>08</day>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2085</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0707</doc-id>
        <title>High-level framework for network-based resource sharing</title>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>December</month>
            <day>23</day>
            <year>1975</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>57254</char-count>
            <page-count>29</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0708</doc-id>
        <title>Elements of a Distributed Programming System</title>
        <author>
            <name>J.E. White</name>
        </author>
        <date>
            <month>January</month>
            <day>28</day>
            <year>1976</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>57888</char-count>
            <page-count>30</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0709</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0710</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0711</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0712</doc-id>
        <title>Distributed Capability Computing System (DCCS)</title>
        <author>
            <name>J.E. Donnelley</name>
        </author>
        <date>
            <month>February</month>
            <day>05</day>
            <year>1976</year>
        </date>
        <notes>Not Available Online..</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0713</doc-id>
        <title>MSDTP-Message Services Data Transmission Protocol</title>
        <author>
            <name>J. Haverty</name>
        </author>
        <date>
            <month>April</month>
            <day>06</day>
            <year>1976</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41175</char-count>
            <page-count>21</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0714</doc-id>
        <title>Host-Host Protocol for an ARPANET-Type Network</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>April</month>
            <day>21</day>
            <year>1976</year>
        </date>
        <notes>Not Available Online.</notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0715</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0716</doc-id>
        <title>Interim Revision to Appendix F of BBN 1822</title>
        <author>
            <name>D.C. Walden</name>
        </author>
        <author>
            <name>J. Levin</name>
        </author>
        <date>
            <month>May</month>
            <day>24</day>
            <year>1976</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3345</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0717</doc-id>
        <title>Assigned Network Numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1976</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2322</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0718</doc-id>
        <title>Comments on RCTE from the Tenex Implementation Experience</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>June</month>
            <day>30</day>
            <year>1976</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3829</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0719</doc-id>
        <title>Discussion on RCTE</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>July</month>
            <day>22</day>
            <year>1976</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4708</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0720</doc-id>
        <title>Address Specification Syntax for Network Mail</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>August</month>
            <day>05</day>
            <year>1976</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6602</char-count>
            <page-count>3</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0721</doc-id>
        <title>Out-of-Band Control Signals in a Host-to-Host Protocol</title>
        <author>
            <name>L.L. Garlick</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1976</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13566</char-count>
            <page-count>7</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0722</doc-id>
        <title>Thoughts on Interactions in Distributed Services</title>
        <author>
            <name>J. Haverty</name>
        </author>
        <date>
            <month>September</month>
            <day>16</day>
            <year>1976</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29478</char-count>
            <page-count>13</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0723</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0724</doc-id>
        <title>Proposed official standard for the format of ARPA Network messages</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <author>
            <name>K.T. Pogran</name>
        </author>
        <author>
            <name>J. Vittal</name>
        </author>
        <author>
            <name>D.A. Henderson</name>
        </author>
        <date>
            <month>May</month>
            <day>12</day>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>75554</char-count>
            <page-count>36</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0733</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0725</doc-id>
        <title>RJE protocol for a resource sharing network</title>
        <author>
            <name>J.D. Day</name>
        </author>
        <author>
            <name>G.R. Grossman</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44025</char-count>
            <page-count>27</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0726</doc-id>
        <title>Remote Controlled Transmission and Echoing Telnet option</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>March</month>
            <day>08</day>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38651</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>TOPT-REM</kw>
        </keywords>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0727</doc-id>
        <title>Telnet logout option</title>
        <author>
            <name>M.R. Crispin</name>
        </author>
        <date>
            <month>April</month>
            <day>27</day>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5674</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>TOPT-LOGO</kw>
        </keywords>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0728</doc-id>
        <title>Minor pitfall in the Telnet Protocol</title>
        <author>
            <name>J.D. Day</name>
        </author>
        <date>
            <month>April</month>
            <day>27</day>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2224</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0729</doc-id>
        <title>Telnet byte macro option</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>May</month>
            <day>13</day>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6509</char-count>
            <page-count>3</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0735</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0730</doc-id>
        <title>Extensible field addressing</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <day>20</day>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9519</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0731</doc-id>
        <title>Telnet Data Entry Terminal option</title>
        <author>
            <name>J.D. Day</name>
        </author>
        <date>
            <month>June</month>
            <day>27</day>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>61648</char-count>
            <page-count>28</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0732</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0732</doc-id>
        <title>Telnet Data Entry Terminal option</title>
        <author>
            <name>J.D. Day</name>
        </author>
        <date>
            <month>September</month>
            <day>12</day>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>57160</char-count>
            <page-count>30</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0731</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC1043</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0733</doc-id>
        <title>Standard for the format of ARPA network text messages</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <author>
            <name>J. Vittal</name>
        </author>
        <author>
            <name>K.T. Pogran</name>
        </author>
        <author>
            <name>D.A. Henderson</name>
        </author>
        <date>
            <month>November</month>
            <day>21</day>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>73006</char-count>
            <page-count>38</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0724</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0822</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0734</doc-id>
        <title>SUPDUP Protocol</title>
        <author>
            <name>M.R. Crispin</name>
        </author>
        <date>
            <month>October</month>
            <day>07</day>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33256</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>SUPDUP</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0735</doc-id>
        <title>Revised Telnet byte macro option</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <author>
            <name>R.H. Gumpertz</name>
        </author>
        <date>
            <month>November</month>
            <day>03</day>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10585</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>TOPT-BYTE</kw>
        </keywords>
        <obsoletes>
            <doc-id>RFC0729</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0736</doc-id>
        <title>Telnet SUPDUP option</title>
        <author>
            <name>M.R. Crispin</name>
        </author>
        <date>
            <month>October</month>
            <day>31</day>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3081</char-count>
            <page-count>1</page-count>
        </format>
        <keywords>
            <kw>TOPT-SUP</kw>
        </keywords>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0737</doc-id>
        <title>FTP extension: XSEN</title>
        <author>
            <name>K. Harrenstien</name>
        </author>
        <date>
            <month>October</month>
            <day>31</day>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2127</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0738</doc-id>
        <title>Time server</title>
        <author>
            <name>K. Harrenstien</name>
        </author>
        <date>
            <month>October</month>
            <day>31</day>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1851</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0739</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <day>11</day>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16346</char-count>
            <page-count>11</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0604</doc-id>
            <doc-id>RFC0503</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0750</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0740</doc-id>
        <title>NETRJS Protocol</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>November</month>
            <day>22</day>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38833</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>NETRJS</kw>
        </keywords>
        <obsoletes>
            <doc-id>RFC0599</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0741</doc-id>
        <title>Specifications for the Network Voice Protocol (NVP)</title>
        <author>
            <name>D. Cohen</name>
        </author>
        <date>
            <month>November</month>
            <day>22</day>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>57581</char-count>
            <page-count>34</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0742</doc-id>
        <title>NAME/FINGER Protocol</title>
        <author>
            <name>K. Harrenstien</name>
        </author>
        <date>
            <month>December</month>
            <day>30</day>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12321</char-count>
            <page-count>7</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC1288</doc-id>
            <doc-id>RFC1196</doc-id>
            <doc-id>RFC1194</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0743</doc-id>
        <title>FTP extension: XRSQ/XRCP</title>
        <author>
            <name>K. Harrenstien</name>
        </author>
        <date>
            <month>December</month>
            <day>30</day>
            <year>1977</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16249</char-count>
            <page-count>8</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0744</doc-id>
        <title>MARS - a Message Archiving and Retrieval Service</title>
        <author>
            <name>J. Sattley</name>
        </author>
        <date>
            <month>January</month>
            <day>08</day>
            <year>1978</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10984</char-count>
            <page-count>6</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0745</doc-id>
        <title>JANUS interface specifications</title>
        <author>
            <name>M. Beeler</name>
        </author>
        <date>
            <month>March</month>
            <day>30</day>
            <year>1978</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21453</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>JANUS</kw>
            <kw>interface</kw>
            <kw>specifications</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0746</doc-id>
        <title>SUPDUP graphics extension</title>
        <author>
            <name>R. Stallman</name>
        </author>
        <date>
            <month>March</month>
            <day>17</day>
            <year>1978</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30197</char-count>
            <page-count>15</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0747</doc-id>
        <title>Recent extensions to the SUPDUP Protocol</title>
        <author>
            <name>M.R. Crispin</name>
        </author>
        <date>
            <month>March</month>
            <day>21</day>
            <year>1978</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2870</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0748</doc-id>
        <title>Telnet randomly-lose option</title>
        <author>
            <name>M.R. Crispin</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1978</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2741</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0749</doc-id>
        <title>Telnet SUPDUP-Output option</title>
        <author>
            <name>B. Greenberg</name>
        </author>
        <date>
            <month>September</month>
            <day>18</day>
            <year>1978</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8933</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>TOPT-SUPO</kw>
        </keywords>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0750</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <day>26</day>
            <year>1978</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19979</char-count>
            <page-count>12</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0739</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0755</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0751</doc-id>
        <title>Survey of FTP mail and MLFL</title>
        <author>
            <name>P.D. Lebling</name>
        </author>
        <date>
            <month>December</month>
            <day>10</day>
            <year>1978</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10069</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0752</doc-id>
        <title>Universal host table</title>
        <author>
            <name>M.R. Crispin</name>
        </author>
        <date>
            <month>January</month>
            <day>02</day>
            <year>1979</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33793</char-count>
            <page-count>12</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0753</doc-id>
        <title>Internet Message Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1979</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>93363</char-count>
            <page-count>62</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0754</doc-id>
        <title>Out-of-net host addresses for mail</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>April</month>
            <day>06</day>
            <year>1979</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19212</char-count>
            <page-count>10</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0755</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <day>03</day>
            <year>1979</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22039</char-count>
            <page-count>12</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0750</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0758</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0756</doc-id>
        <title>NIC name server - a datagram-based information utility</title>
        <author>
            <name>J.R. Pickens</name>
        </author>
        <author>
            <name>E.J. Feinler</name>
        </author>
        <author>
            <name>J.E. Mathis</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1979</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23491</char-count>
            <page-count>12</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0757</doc-id>
        <title>Suggested solution to the naming, addressing, and delivery problem for ARPANET message systems</title>
        <author>
            <name>D.P. Deutsch</name>
        </author>
        <date>
            <month>September</month>
            <day>10</day>
            <year>1979</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35618</char-count>
            <page-count>19</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0758</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1979</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22911</char-count>
            <page-count>12</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0755</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0762</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0759</doc-id>
        <title>Internet Message Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>123606</char-count>
            <page-count>77</page-count>
        </format>
        <keywords>
            <kw>MPM</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0760</doc-id>
        <title>DoD standard Internet Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>81507</char-count>
            <page-count>46</page-count>
        </format>
        <obsoletes>
            <doc-id>IEN123</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0791</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC0777</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0761</doc-id>
        <title>DoD standard Transmission Control Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>167049</char-count>
            <page-count>88</page-count>
        </format>
        <keywords>
            <kw>TCP</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0762</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24668</char-count>
            <page-count>13</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0758</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0770</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0763</doc-id>
        <title>Role mailboxes</title>
        <author>
            <name>M.D. Abrams</name>
        </author>
        <date>
            <month>May</month>
            <day>07</day>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>942</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0764</doc-id>
        <title>Telnet Protocol specification</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40005</char-count>
            <page-count>15</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0854</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0765</doc-id>
        <title>File Transfer Protocol specification</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>146641</char-count>
            <page-count>70</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0542</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0959</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0766</doc-id>
        <title>Internet Protocol Handbook: Table of contents</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3465</char-count>
            <page-count>2</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0774</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0767</doc-id>
        <title>Structured format for transmission of multi-media documents</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59971</char-count>
            <page-count>40</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0768</doc-id>
        <title>User Datagram Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>August</month>
            <day>28</day>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5896</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>UDP</kw>
            <kw>UDP</kw>
        </keywords>
        <is-also>
            <doc-id>STD0006</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0769</doc-id>
        <title>Rapicom 450 facsimile file format</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <day>26</day>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4079</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0770</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26248</char-count>
            <page-count>15</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0762</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0776</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0771</doc-id>
        <title>Mail transition plan</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18623</char-count>
            <page-count>9</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0772</doc-id>
        <title>Mail Transfer Protocol</title>
        <author>
            <name>S. Sluizer</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>61061</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>MTP</kw>
            <kw>email</kw>
        </keywords>
        <obsoleted-by>
            <doc-id>RFC0780</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0773</doc-id>
        <title>Comments on NCP/TCP mail service transition strategy</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22181</char-count>
            <page-count>11</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0774</doc-id>
        <title>Internet Protocol Handbook: Table of contents</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3452</char-count>
            <page-count>3</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0766</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0775</doc-id>
        <title>Directory oriented FTP commands</title>
        <author>
            <name>D. Mankins</name>
        </author>
        <author>
            <name>D. Franklin</name>
        </author>
        <author>
            <name>A.D. Owen</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1980</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9511</char-count>
            <page-count>6</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0776</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30311</char-count>
            <page-count>13</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0770</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0790</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0777</doc-id>
        <title>Internet Control Message Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19407</char-count>
            <page-count>14</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC0792</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0760</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0778</doc-id>
        <title>DCNET Internet Clock Service</title>
        <author>
            <name>D.L. Mills</name>
        </author>
        <date>
            <month>April</month>
            <day>18</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9464</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>CLOCK</kw>
        </keywords>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0779</doc-id>
        <title>Telnet send-location option</title>
        <author>
            <name>E. Killian</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2564</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>TOPT-SNDL</kw>
        </keywords>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0780</doc-id>
        <title>Mail Transfer Protocol</title>
        <author>
            <name>S. Sluizer</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>80352</char-count>
            <page-count>47</page-count>
        </format>
        <keywords>
            <kw>MTP</kw>
            <kw>email</kw>
        </keywords>
        <obsoletes>
            <doc-id>RFC0772</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0788</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0781</doc-id>
        <title>Specification of the Internet Protocol (IP) timestamp option</title>
        <author>
            <name>Z. Su</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4002</char-count>
            <page-count>1</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0782</doc-id>
        <title>Virtual Terminal management model</title>
        <author>
            <name>J. Nabielsky</name>
        </author>
        <author>
            <name>A.P. Skelton</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43589</char-count>
            <page-count>23</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0783</doc-id>
        <title>TFTP Protocol (revision 2)</title>
        <author>
            <name>K.R. Sollins</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23522</char-count>
            <page-count>18</page-count>
        </format>
        <obsoletes>
            <doc-id>IEN133</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1350</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0784</doc-id>
        <title>Mail Transfer Protocol: ISI TOPS20 implementation</title>
        <author>
            <name>S. Sluizer</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5856</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>MTP</kw>
            <kw>email</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0785</doc-id>
        <title>Mail Transfer Protocol: ISI TOPS20 file definitions</title>
        <author>
            <name>S. Sluizer</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7032</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>MTP</kw>
            <kw>email</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0786</doc-id>
        <title>Mail Transfer Protocol: ISI TOPS20 MTP-NIMAIL interface</title>
        <author>
            <name>S. Sluizer</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3129</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>MTP</kw>
            <kw>NIMAIL</kw>
            <kw>TOPS20</kw>
        </keywords>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0787</doc-id>
        <title>Connectionless data transmission survey/tutorial</title>
        <author>
            <name>A.L. Chapin</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>84265</char-count>
            <page-count>40</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0788</doc-id>
        <title>Simple Mail Transfer Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>109001</char-count>
            <page-count>64</page-count>
        </format>
        <keywords>
            <kw>SMTP</kw>
            <kw>email</kw>
        </keywords>
        <obsoletes>
            <doc-id>RFC0780</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0821</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0789</doc-id>
        <title>Vulnerabilities of network control protocols: An example</title>
        <author>
            <name>E.C. Rosen</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25541</char-count>
            <page-count>16</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0790</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35316</char-count>
            <page-count>15</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0776</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0820</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0791</doc-id>
        <title>Internet Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>97779</char-count>
            <page-count>51</page-count>
        </format>
        <keywords>
            <kw>IP</kw>
        </keywords>
        <obsoletes>
            <doc-id>RFC0760</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC1349</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0005</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0792</doc-id>
        <title>Internet Control Message Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30404</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>ICMP</kw>
        </keywords>
        <obsoletes>
            <doc-id>RFC0777</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC0950</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0005</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0793</doc-id>
        <title>Transmission Control Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>172710</char-count>
            <page-count>91</page-count>
        </format>
        <keywords>
            <kw>TCP</kw>
            <kw>TCP</kw>
        </keywords>
        <updated-by>
            <doc-id>RFC3168</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0007</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0794</doc-id>
        <title>Pre-emption</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5906</char-count>
            <page-count>2</page-count>
        </format>
        <updates>
            <doc-id>IEN125</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0795</doc-id>
        <title>Service mappings</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5228</char-count>
            <page-count>4</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0796</doc-id>
        <title>Address mappings</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11239</char-count>
            <page-count>7</page-count>
        </format>
        <obsoletes>
            <doc-id>IEN115</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0797</doc-id>
        <title>Format for Bitmap files</title>
        <author>
            <name>A.R. Katz</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3067</char-count>
            <page-count>2</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0798</doc-id>
        <title>Decoding facsimile data from the Rapicom 450</title>
        <author>
            <name>A.R. Katz</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38867</char-count>
            <page-count>17</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0799</doc-id>
        <title>Internet name domains</title>
        <author>
            <name>D.L. Mills</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13896</char-count>
            <page-count>5</page-count>
        </format>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0800</doc-id>
        <title>Request For Comments summary notes: 700-799</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J. Vernon</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18354</char-count>
            <page-count>10</page-count>
        </format>
        <abstract>This RFC is a slightly annotated list of the 100 RFCs from RFC 700 through RFC 799. This is a status report on these RFCs. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0801</doc-id>
        <title>NCP/TCP transition plan</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42041</char-count>
            <page-count>21</page-count>
        </format>
        <abstract>This RFC discusses the conversion of hosts from NCP to TCP. And making available the principle services: Telnet, File Transfer, and Mail. These protocols allow all hosts in the ARPA community to share a common interprocess communication environment. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0802</doc-id>
        <title>ARPANET 1822L Host Access Protocol</title>
        <author>
            <name>A.G. Malis</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>62470</char-count>
            <page-count>45</page-count>
        </format>
        <abstract>This document proposed two major changes to the current ARPANET host access protocol. The first change will allow hosts to use logical addressing (i.e., host addresses that are independent of their physical location on the ARPANET) to communicate with each other, and the second will allow a host to shorten the amount of time that it may be blocked by its IMP after it presents a message to the network (currently, the IMP can block further input from a host for up to 15 seconds). See RFCs 852 and 851. </abstract>
        <obsoleted-by>
            <doc-id>RFC0851</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0803</doc-id>
        <title>Dacom 450/500 facsimile data transcoding</title>
        <author>
            <name>A. Agarwal</name>
        </author>
        <author>
            <name>M.J. O'Connor</name>
        </author>
        <author>
            <name>D.L. Mills</name>
        </author>
        <date>
            <month>November</month>
            <day>02</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33826</char-count>
            <page-count>14</page-count>
        </format>
        <abstract>The first part of this RFC describes in detail the Dacom 450 data compression algorithms and is an update and correction to an earlier memorandum. The second part of this RFC describes briefly the Dacom 500 data compression algorithm as used by the INTELPOST electronic-mail network under development by the US Postal Service and several foreign administrators. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0804</doc-id>
        <title>CCITT draft recommendation T.4 </title>
        <author>
            <name>International Telegraph and Telephone Consultative Committee of the International Telecommunication Union </name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17025</char-count>
            <page-count>12</page-count>
        </format>
        <abstract>This is the CCITT standard for group 3 facsimile encoding. This is useful for data compression of bit map data. </abstract>
        <notes>Standardization of Group 3 facsimile apparatus for document transmission.  </notes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0805</doc-id>
        <title>Computer mail meeting notes</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>February</month>
            <day>08</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12522</char-count>
            <page-count>6</page-count>
        </format>
        <abstract>This RFC consists of notes from a meeting that was held at USC Information Sciences Institute on 11 January 1982, to discuss addressing issues in computer mail. The major conclusion reached at the meeting is to extend the "username@hostname" mailbox format to "username@host.domain", where the domain itself can be further strutured. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0806</doc-id>
        <title>Proposed Federal Information Processing Standard: Specification for message format for computer based message systems</title>
        <author>
            <name>National Bureau of Standards </name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1981</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>216377</char-count>
            <page-count>107</page-count>
        </format>
        <abstract>This RFC deals with Computer Based Message systems which provides a basis for interaction between different CBMS by defining the format of messages passed between them. This RFC is replaced by RFC 841. </abstract>
        <obsoleted-by>
            <doc-id>RFC0841</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0807</doc-id>
        <title>Multimedia mail meeting notes</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>February</month>
            <day>09</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11633</char-count>
            <page-count>6</page-count>
        </format>
        <abstract>This RFC consists of notes from a meeting held at USC Information Sciences Institute on the 12th of January to discuss common interests in multimedia computer mail issues and to agree on some specific initial experiments. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0808</doc-id>
        <title>Summary of computer mail services meeting held at BBN on 10 January 1979</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15930</char-count>
            <page-count>8</page-count>
        </format>
        <abstract>This RFC is a very belated attempt to document a meeting that was held three years earlier to discuss the state of computer mail in the ARPA community and to reach some conclusions to guide the further development of computer mail systems such that a coherent total mail service would continue to be provided. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0809</doc-id>
        <title>UCL facsimile system</title>
        <author>
            <name>T. Chang</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>171153</char-count>
            <page-count>99</page-count>
        </format>
        <abstract>This RFC describes the features of the computerised facsimile system developed in the Department of Computer Science at UCL. First its functions are considered and the related experimental work are reported. Then the disciplines for system design are discussed. Finally, the implementation of the system are described, while detailed description are given as appendices. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0810</doc-id>
        <title>DoD Internet host table specification</title>
        <author>
            <name>E.J. Feinler</name>
        </author>
        <author>
            <name>K. Harrenstien</name>
        </author>
        <author>
            <name>Z. Su</name>
        </author>
        <author>
            <name>V. White</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14196</char-count>
            <page-count>8</page-count>
        </format>
        <abstract>This RFC specifies a new host table format applicable to both ARPANET and Internet needs. In addition to host name to host address translation and selected protocol information, we have also included network and gateway name to address correspondence, and host operating system information. This RFC obsoletes the host table described in RFC 608. </abstract>
        <obsoletes>
            <doc-id>RFC0608</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0952</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0811</doc-id>
        <title>Hostnames Server</title>
        <author>
            <name>K. Harrenstien</name>
        </author>
        <author>
            <name>V. White</name>
        </author>
        <author>
            <name>E.J. Feinler</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7771</char-count>
            <page-count>4</page-count>
        </format>
        <abstract>This RFC gives a description of what the Hostnames Server is and how to access it. The function of this particular server is to deliver machine-readable name/address information describing networks, gateways, hosts, and eventually domains, within the internet environment. </abstract>
        <obsoleted-by>
            <doc-id>RFC0953</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0812</doc-id>
        <title>NICNAME/WHOIS</title>
        <author>
            <name>K. Harrenstien</name>
        </author>
        <author>
            <name>V. White</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5389</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>This RFC gives a description of what the NICNAME/WHOIS Server is and how to access it. This server together with the corresponding Identification Data Base provides online directory look-up equivalent to the ARPANET Directory. </abstract>
        <obsoleted-by>
            <doc-id>RFC0954</doc-id>
            <doc-id>RFC3912</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0813</doc-id>
        <title>Window and Acknowledgement Strategy in TCP</title>
        <author>
            <name>D.D. Clark</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38110</char-count>
            <page-count>21</page-count>
        </format>
        <abstract>This RFC describes implementation strategies to deal with two mechanisms in TCP, the window and the acknowledgement. It also presents a particular set of algorithms which have received testing in the field, and which appear to work properly with each other. With more experience, these algorithms may become part of the formal specification, until such time their use is recommended. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0814</doc-id>
        <title>Name, addresses, ports, and routes</title>
        <author>
            <name>D.D. Clark</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24663</char-count>
            <page-count>13</page-count>
        </format>
        <abstract>This RFC gives suggestions and guidance for the design of the tables and algorithms necessary to keep track of these various sorts of identifiers inside a host implementation of TCP/IP. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0815</doc-id>
        <title>IP datagram reassembly algorithms</title>
        <author>
            <name>D.D. Clark</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14575</char-count>
            <page-count>8</page-count>
        </format>
        <abstract>This RFC describes an alternate approach of dealing with reassembly which reduces the bookkeeping problem to a minimum, and requires only one buffer for storage equal in size to the final datagram being reassembled, which can reassemble a datagram from any number of fragments arriving in any order with any possible pattern of overlap and duplication, and which is appropriate for almost any sort of operating system. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0816</doc-id>
        <title>Fault isolation and recovery</title>
        <author>
            <name>D.D. Clark</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20106</char-count>
            <page-count>11</page-count>
        </format>
        <abstract>This RFC describes the portion of fault isolation and recovery which is the responsibility of the host. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0817</doc-id>
        <title>Modularity and efficiency in protocol implementation</title>
        <author>
            <name>D.D. Clark</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45931</char-count>
            <page-count>25</page-count>
        </format>
        <abstract>This RFC will discuss some of the commonly encountered reasons why protocol implementations seem to run slowly. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0818</doc-id>
        <title>Remote User Telnet service</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3693</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>RTELNET</kw>
        </keywords>
        <abstract>This RFC is the specification of an application protocol. Any host that implements this application level service must follow this protocol. </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0819</doc-id>
        <title>Domain naming convention for Internet user applications</title>
        <author>
            <name>Z. Su</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35314</char-count>
            <page-count>18</page-count>
        </format>
        <abstract>This RFC is an attempt to clarify the generalization of the Domain Naming Convention, the Internet Naming Convention, and to explore the implications of its adoption for Internet name service and user applications. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0820</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>August</month>
            <day>14</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54213</char-count>
            <page-count>22</page-count>
        </format>
        <abstract>This RFC is an old version, see RFC 870. </abstract>
        <obsoletes>
            <doc-id>RFC0790</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0870</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0821</doc-id>
        <title>Simple Mail Transfer Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>124482</char-count>
            <page-count>72</page-count>
        </format>
        <keywords>
            <kw>SMTP</kw>
        </keywords>
        <abstract>The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. Obsoletes RFC 788, 780, and 772. </abstract>
        <obsoletes>
            <doc-id>RFC0788</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2821</doc-id>
        </obsoleted-by>
        <is-also>
            <doc-id>STD0010</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0822</doc-id>
        <title>Standard for the format of ARPA Internet text messages</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>August</month>
            <day>13</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>109200</char-count>
            <page-count>49</page-count>
        </format>
        <keywords>
            <kw>MAIL</kw>
        </keywords>
        <abstract>This document revises the specifications in RFC 733, in order to serve the needs of the larger and more complex ARPA Internet. Some of RFC 733's features failed to gain adequate acceptance. In order to simplify the standard and the software that follows it, these features have been removed. A different addressing scheme is used, to handle the case of internetwork mail; and the concept of re-transmission has been introduced. Obsoletes RFC 733, NIC 41952. </abstract>
        <obsoletes>
            <doc-id>RFC0733</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2822</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC1123</doc-id>
            <doc-id>RFC1138</doc-id>
            <doc-id>RFC1148</doc-id>
            <doc-id>RFC1327</doc-id>
            <doc-id>RFC2156</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0011</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0823</doc-id>
        <title>DARPA Internet gateway</title>
        <author>
            <name>R.M. Hinden</name>
        </author>
        <author>
            <name>A. Sheltzer</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>62620</char-count>
            <page-count>45</page-count>
        </format>
        <keywords>
            <kw>GGP</kw>
        </keywords>
        <abstract>This RFC is a status report on the Internet Gateway developed by BBN. It describes the Internet Gateway as of September 1982. This memo presents detailed descriptions of message formats and gateway procedures, however, this is not an implementation specification, and such details are subject to change. </abstract>
        <updates>
            <doc-id>IEN109</doc-id>
            <doc-id>IEN30</doc-id>
        </updates>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0824</doc-id>
        <title>CRONUS Virtual Local Network</title>
        <author>
            <name>W.I. MacGregor</name>
        </author>
        <author>
            <name>D.C. Tappan</name>
        </author>
        <date>
            <month>August</month>
            <day>25</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>58732</char-count>
            <page-count>41</page-count>
        </format>
        <abstract>The purpose of this note is to describe the CRONUS Virtual Local Network, especially the addressing related features. These features include a method for mapping between Internet Addresses and Local Network addresses. This is a topic of current concern in the ARPA Internet community. This note is intended to stimulate discussion. This is not a specification of an Internet Standard. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0825</doc-id>
        <title>Request for comments on Requests For Comments</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4255</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>This RFC is intended to clarify the status of RFCs and to provide some guidance for the authors of RFCs in the future. It is in a sense a specification for RFCs. </abstract>
        <obsoleted-by>
            <doc-id>RFC1111</doc-id>
            <doc-id>RFC1543</doc-id>
            <doc-id>RFC2223</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0826</doc-id>
        <title>Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware</title>
        <author>
            <name>D.C. Plummer</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22026</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>ARP</kw>
        </keywords>
        <abstract>The purpose of this RFC is to present a method of Converting Protocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet addresses). This is an issue of general concern in the ARPA Internet Community at this time. The method proposed here is presented for your consideration and comment. This is not the specification of an Internet Standard. </abstract>
        <is-also>
            <doc-id>STD0037</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0827</doc-id>
        <title>Exterior Gateway Protocol (EGP)</title>
        <author>
            <name>E.C. Rosen</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>68436</char-count>
            <page-count>46</page-count>
        </format>
        <abstract>This RFC is proposed to establish a standard for Gateway to Gateway procedures that allow the Gateways to be mutually suspicious. This document is a DRAFT for that standard. Your comments are strongly encouraged. </abstract>
        <updated-by>
            <doc-id>RFC0904</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0828</doc-id>
        <title>Data communications: IFIP's international "network" of experts</title>
        <author>
            <name>K. Owen</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29922</char-count>
            <page-count>11</page-count>
        </format>
        <abstract>This RFC is distributed to inform the ARPA Internet community of the activities of the IFIP technical committee on Data Communications, and to encourage participation in those activities. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0829</doc-id>
        <title>Packet satellite technology reference sources</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10919</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>This RFC describes briefly the packet satellite technology developed by the Defense Advanced Research Projects Agency and several other participating organizations in the U.K. and Norway and provides a bibliography of relevant papers for researchers interested in experimental and operational experience with this dynamic satellite-sharing technique. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0830</doc-id>
        <title>Distributed system for Internet name service</title>
        <author>
            <name>Z. Su</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31597</char-count>
            <page-count>18</page-count>
        </format>
        <abstract>This RFC proposes a distributed name service for DARPA Internet. Its purpose is to focus discussion on the subject. It is hoped that a general consensus will emerge leading eventually to the adoption of standards. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0831</doc-id>
        <title>Backup access to the European side of SATNET</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11735</char-count>
            <page-count>6</page-count>
        </format>
        <abstract>The purpose of this RFC is to focus discussion on a particular Internet problem: a backup path for software maintenance of the European sector of the Internet, for use when SATNET is partitioned. We propose a mechanism, based upon the Source Routing option of IP, to reach European Internet sites via the VAN Gateway and UCL. This proposal is not intended as a standard at this time. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0832</doc-id>
        <title>Who talks TCP?</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>December</month>
            <day>07</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42751</char-count>
            <page-count>13</page-count>
        </format>
        <abstract>This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 7-Dec-82. </abstract>
        <obsoleted-by>
            <doc-id>RFC0833</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0833</doc-id>
        <title>Who talks TCP?</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>December</month>
            <day>14</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42973</char-count>
            <page-count>13</page-count>
        </format>
        <abstract>This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 14-Dec-82. </abstract>
        <obsoletes>
            <doc-id>RFC0832</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0834</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0834</doc-id>
        <title>Who talks TCP?</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>December</month>
            <day>22</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42764</char-count>
            <page-count>13</page-count>
        </format>
        <abstract>This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 22-Dec-82. </abstract>
        <obsoletes>
            <doc-id>RFC0833</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0835</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0835</doc-id>
        <title>Who talks TCP?</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>December</month>
            <day>29</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42959</char-count>
            <page-count>13</page-count>
        </format>
        <abstract>This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 28-Dec-82 through 5-Jan-83. </abstract>
        <obsoletes>
            <doc-id>RFC0834</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0836</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0836</doc-id>
        <title>Who talks TCP?</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>January</month>
            <day>05</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43643</char-count>
            <page-count>13</page-count>
        </format>
        <abstract>This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 20-Dec-82. The tests were run on 4-Jan-83 through 5-Jan-83. </abstract>
        <obsoletes>
            <doc-id>RFC0835</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0837</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0837</doc-id>
        <title>Who talks TCP?</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>January</month>
            <day>12</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44864</char-count>
            <page-count>13</page-count>
        </format>
        <abstract>This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 11-Jan-83. </abstract>
        <obsoletes>
            <doc-id>RFC0836</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0838</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0838</doc-id>
        <title>Who talks TCP?</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>January</month>
            <day>20</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45033</char-count>
            <page-count>13</page-count>
        </format>
        <abstract>This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 18-Jan-83. </abstract>
        <obsoletes>
            <doc-id>RFC0837</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0839</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0839</doc-id>
        <title>Who talks TCP?</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>January</month>
            <day>26</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45175</char-count>
            <page-count>14</page-count>
        </format>
        <abstract>This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 25-Jan-83. </abstract>
        <obsoletes>
            <doc-id>RFC0838</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0842</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0840</doc-id>
        <title>Official protocols</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>April</month>
            <day>13</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33534</char-count>
            <page-count>23</page-count>
        </format>
        <abstract>This RFC has been revised, see RFC 880. </abstract>
        <obsoleted-by>
            <doc-id>RFC0880</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0841</doc-id>
        <title>Specification for message format for Computer Based Message Systems</title>
        <author>
            <name>National Bureau of Standards</name>
        </author>
        <date>
            <month>January</month>
            <day>27</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>231871</char-count>
            <page-count>117</page-count>
        </format>
        <abstract>This RFC is FIPS 98. The purpose of distributing this document as an RFC is to make it easily accessible to the ARPA research community. This RFC does not specify a standard for the ARPA Internet. Obsoletes RFC 806. </abstract>
        <obsoletes>
            <doc-id>RFC0806</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0842</doc-id>
        <title>Who talks TCP? - survey of 1 February 83</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>February</month>
            <day>03</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45962</char-count>
            <page-count>12</page-count>
        </format>
        <abstract>This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 28-Jan-83. The tests were run on 1-Feb-83 and on 2-Feb-83 ISI-VAXA.ARPA. </abstract>
        <obsoletes>
            <doc-id>RFC0839</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0843</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0843</doc-id>
        <title>Who talks TCP? - survey of 8 February 83</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>February</month>
            <day>09</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46193</char-count>
            <page-count>13</page-count>
        </format>
        <abstract>This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 3-Feb-83. The tests were run on 8-Feb-83 and on 9-Feb-83 from ISI-VAXA.ARPA. </abstract>
        <obsoletes>
            <doc-id>RFC0842</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0845</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC0844</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0844</doc-id>
        <title>Who talks ICMP, too? - Survey of 18 February 1983</title>
        <author>
            <name>R. Clements</name>
        </author>
        <date>
            <month>February</month>
            <day>18</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9078</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>This survey determines how many hosts are able to respond to TELENET connections from a user at a class C site. This requires, in addition to IP and TCP, participation in gateway routing via ICMP and handling of Class C addresses. The list of hosts was taken from RFC 843, extracting only those hosts which are listed there as accepting TELNET connection. The tests were run on 18-Feb-83. </abstract>
        <updates>
            <doc-id>RFC0843</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0845</doc-id>
        <title>Who talks TCP? - survey of 15 February 1983</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>February</month>
            <day>17</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45983</char-count>
            <page-count>14</page-count>
        </format>
        <abstract>This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 3-Feb-83. The tests were run on 15-Feb-83 from ISI-VAXA.ARPA. </abstract>
        <obsoletes>
            <doc-id>RFC0843</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0846</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0846</doc-id>
        <title>Who talks TCP? - survey of 22 February 1983</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>February</month>
            <day>23</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45597</char-count>
            <page-count>14</page-count>
        </format>
        <abstract>This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 18-Feb-83. The tests were run on 22-Feb-83 from ISI-VAXA.ARPA. </abstract>
        <obsoletes>
            <doc-id>RFC0845</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0847</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0847</doc-id>
        <title>Summary of Smallberg surveys</title>
        <author>
            <name>A. Westine</name>
        </author>
        <author>
            <name>D. Smallberg</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3789</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>This is a summary of the surveys of Telnet, FTP and Mail (SMTP) servers conducted by David Smallberg in December 1982, January and February 1983 as reported in RFC 832-843, 845-846. This memo extracts the number of hosts that accepted the connection to their server for each of Telnet, FTP, and SMTP, and compares it to the total host in the Internet (not counting TACs or ECHOS). </abstract>
        <obsoletes>
            <doc-id>RFC0846</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0848</doc-id>
        <title>Who provides the "little" TCP services?</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>March</month>
            <day>14</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10985</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>This RFC lists those hosts which provide any of these "little" TCP services: The list of hosts were taken from the NIC hostname table of 24-Feb-83. The tests were run on February 23 and 24, and March 3 and 5 from ISI-VAXA.ARPA. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0849</doc-id>
        <title>Suggestions for improved host table distribution</title>
        <author>
            <name>M.R. Crispin</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5178</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>This RFC actually is a request for comments. The issue dealt with is that of a naming registry update procedure, both as exists currently and what could exist in the future. None of the proposed solutions are intended as standards at this time; rather it is hoped that a general consensus will emerge as the appropriate solution, leaving eventually to the adoption of standards. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0850</doc-id>
        <title>Standard for interchange of USENET messages</title>
        <author>
            <name>M.R. Horton</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43871</char-count>
            <page-count>17</page-count>
        </format>
        <abstract>This memo is distributed as an RFC only to make this information easily accessible to researchers in the ARPA community. It does not specify an Internet standard. This RFC defines the standard format for interchange of Network News articles among USENET sites. It describes the format for articles themselves, and gives partial standards for transmission of news. The news transmission is not entirely standardized in order to give a good deal of flexibility to the individual hosts to choose transmission hardware and software, whether to batch news and so on. </abstract>
        <obsoleted-by>
            <doc-id>RFC1036</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0851</doc-id>
        <title>ARPANET 1822L Host Access Protocol</title>
        <author>
            <name>A.G. Malis</name>
        </author>
        <date>
            <month>April</month>
            <day>18</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>72042</char-count>
            <page-count>47</page-count>
        </format>
        <abstract>This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. 1822L allows ARPANET hosts to use logical names as well as 1822's physical port locations to address each other. This RFC is also being presented as a solicitation of comments on 1822L, especially from host network software implementers and maintainers. Obsoletes RFC 802. </abstract>
        <obsoletes>
            <doc-id>RFC0802</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0878</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0852</doc-id>
        <title>ARPANET short blocking feature</title>
        <author>
            <name>A.G. Malis</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17151</char-count>
            <page-count>13</page-count>
        </format>
        <abstract>This RFC specifies the ARPANET Short Blocking Feature, which will allow ARPANET hosts to optionally shorten the IMP's host blocking timer. This Feature is a replacement of the ARPANET non-blocking host interface, which was never implemented, and will be available to hosts using either the 1822 or 1822L Host Access Protocol. This RFC is also being presented as a solicitation of comments on the Short Blocking Feature, especially from host network software implementers and maintainers. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC0853</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC0854</doc-id>
        <title>Telnet Protocol Specification</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39371</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>TELNET</kw>
        </keywords>
        <abstract>This is the specification of the Telnet protocol used for remote terminal access in the ARPA Internet. The purpose of the TELNET Protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communications facility. Its primary goal is to allow a standard method of interfacing terminal devices and terminal-oriented processes to each other. It is envisioned that the protocol may also be used for terminal-terminal communication ("linking") and process-process communication (distributed computation). This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 18639. </abstract>
        <obsoletes>
            <doc-id>RFC0764</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0008</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0855</doc-id>
        <title>Telnet Option Specifications</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6218</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>TELNET</kw>
        </keywords>
        <abstract>This memo specifies the general form for Telnet options and the directions for their specification. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes RFC 651, NIC 18640. </abstract>
        <obsoletes>
            <doc-id>NIC18640</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0008</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0856</doc-id>
        <title>Telnet Binary Transmission</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9192</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>TOPT-BIN</kw>
        </keywords>
        <abstract>This Telnet Option enables a binary data mode between the Telnet modules. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 15389. </abstract>
        <obsoletes>
            <doc-id>NIC15389</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0027</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0857</doc-id>
        <title>Telnet Echo Option</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11143</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>TOPT-ECHO</kw>
        </keywords>
        <abstract>This Telnet Option enables remote echoing by the other Telnet module. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 15390. </abstract>
        <obsoletes>
            <doc-id>NIC15390</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0028</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0858</doc-id>
        <title>Telnet Suppress Go Ahead Option</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3825</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>TOPT-SUPP</kw>
        </keywords>
        <abstract>This Telnet Option disables the exchange of go-ahead signals between the Telnet modules. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 15392. </abstract>
        <obsoletes>
            <doc-id>NIC15392</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0029</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0859</doc-id>
        <title>Telnet Status Option</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4443</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>TOPT-STAT</kw>
        </keywords>
        <abstract>This Telnet Option provides a way to determine the other Telnet module's view of the status of options. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes RFC 651 (NIC 31154). </abstract>
        <obsoletes>
            <doc-id>RFC0651</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0030</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0860</doc-id>
        <title>Telnet Timing Mark Option</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8108</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>TOPT-TIM</kw>
        </keywords>
        <abstract>This Telnet Option provides a way to check the roundtrip path between two Telnet modules. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 16238. </abstract>
        <obsoletes>
            <doc-id>NIC16238</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0031</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0861</doc-id>
        <title>Telnet Extended Options: List Option</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3181</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>TOPT-EXTOP</kw>
        </keywords>
        <abstract>This Telnet Option provides a mechanism for extending the set of possible options. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 16239. </abstract>
        <obsoletes>
            <doc-id>NIC16239</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0032</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0862</doc-id>
        <title>Echo Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1294</char-count>
            <page-count>1</page-count>
        </format>
        <keywords>
            <kw>ECHO</kw>
        </keywords>
        <abstract>This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Echo Protocol are expected to adopt and implement this standard. The Echo service simply sends back to the originating source any data it receives. </abstract>
        <is-also>
            <doc-id>STD0020</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0863</doc-id>
        <title>Discard Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1297</char-count>
            <page-count>1</page-count>
        </format>
        <keywords>
            <kw>DISCARD</kw>
        </keywords>
        <abstract>This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Discard Protocol are expected to adopt and implement this standard. The Discard service simply throws away any data it receives. </abstract>
        <is-also>
            <doc-id>STD0021</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0864</doc-id>
        <title>Character Generator Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7016</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>CHARGEN</kw>
        </keywords>
        <abstract>This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Character Generator Protocol are expected to adopt and implement this standard. The Character Generator service simply sends data without regard to the input. </abstract>
        <is-also>
            <doc-id>STD0022</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0865</doc-id>
        <title>Quote of the Day Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1734</char-count>
            <page-count>1</page-count>
        </format>
        <keywords>
            <kw>QUOTE</kw>
        </keywords>
        <abstract>This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Quote of the Day Protocol are expected to adopt and implement this standard. The Quote of the Day service simply sends a short message without regard to the input. </abstract>
        <is-also>
            <doc-id>STD0023</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0866</doc-id>
        <title>Active users</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2087</char-count>
            <page-count>1</page-count>
        </format>
        <keywords>
            <kw>USERS</kw>
        </keywords>
        <abstract>This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement an Active Users Protocol are expected to adopt and implement this standard. The Active Users service simply sends a list of the currently active users on the host without regard to the input. </abstract>
        <is-also>
            <doc-id>STD0024</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0867</doc-id>
        <title>Daytime Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2405</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>DAYTIME</kw>
        </keywords>
        <abstract>This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Daytime Protocol are expected to adopt and implement this standard. The Daytime service simply sends the current date and time as a character string without regard to the input. </abstract>
        <is-also>
            <doc-id>STD0025</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0868</doc-id>
        <title>Time Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>K. Harrenstien</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3140</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>TIME</kw>
        </keywords>
        <abstract>This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Time Protocol are expected to adopt and implement this standard. This protocol provides a site-independent, machine readable date and time. The Time service sends back to the originating source the time in seconds since midnight on January first 1900. </abstract>
        <is-also>
            <doc-id>STD0026</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0869</doc-id>
        <title>Host Monitoring Protocol</title>
        <author>
            <name>R. Hinden</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>94550</char-count>
            <page-count>72</page-count>
        </format>
        <keywords>
            <kw>HMP</kw>
            <kw>HMP</kw>
        </keywords>
        <abstract>This RFC specifies the Host Monitoring Protocol used to collect information from various types of hosts in the Internet. Designers of Internet communications software are encouraged to consider this protocol as a means of monitoring the behavior of their creations. </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0870</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>56055</char-count>
            <page-count>26</page-count>
        </format>
        <abstract>This RFC documents the list of numbers assigned for networks, protocols, etc. Obsoletes RFCs 820, 790, 776, 770, 762, 758, 755, 750, 739, 604. </abstract>
        <obsoletes>
            <doc-id>RFC0820</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0900</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0871</doc-id>
        <title>Perspective on the ARPANET reference model</title>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>74455</char-count>
            <page-count>29</page-count>
        </format>
        <abstract>This RFC is primarily intended as a perspective on the ARM and points out some of the differences between the ARM and the ISORM which were expressed by members in NWG general meetings, NWG protocol design committee meetings, the ARPA Internet Working Group, and private conversations over the intervening years. Originally published as M82-47 by the MITRE Corporation, Bedford, Massachusetts. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0872</doc-id>
        <title>TCP-on-a-LAN</title>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22446</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>TCP LAN</kw>
        </keywords>
        <abstract>This memo attacks the notion that TCP cannot be appropriate for use on a Local Area Network. Originally published as M82-48 by the MITRE Corporation, Bedford Massachusetts. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0873</doc-id>
        <title>Illusion of vendor support</title>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23095</char-count>
            <page-count>12</page-count>
        </format>
        <abstract>This memo takes issue with the claim that international standards in computer protocols presently provide a basis for low cost vendor supported protocol implementations. Originally published as M82-49 by the MITRE Corporation, Bedford, Massachusetts. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0874</doc-id>
        <title>Critique of X.25</title>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36386</char-count>
            <page-count>17</page-count>
        </format>
        <abstract>This RFC is an analysis of X.25 pointing out some problems in the conceptual model, particularly the conflict between the interface aspects and the end-to-end aspects. The memo also touches on security, and implementation issues. Originally published as M82-50 by the MITRE Corporation, Bedford, Massachusetts. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0875</doc-id>
        <title>Gateways, architectures, and heffalumps</title>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1982</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22816</char-count>
            <page-count>10</page-count>
        </format>
        <abstract>This RFC is a discussion about the role of gateways in an internetwork, especially the problems of translating or mapping protocols between different protocol suites. The discussion notes possible functionality mis-matches, undesirable routing "singularity points", flow control issues, and high cost of translating gateways. Originally published as M82-51 by the MITRE Corporation, Bedford, Massachusetts. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0876</doc-id>
        <title>Survey of SMTP implementations</title>
        <author>
            <name>D. Smallberg</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37775</char-count>
            <page-count>13</page-count>
        </format>
        <abstract>This RFC is a survey of implementation status. It does not specify an official protocol, but rather notes the status of implementation of aspects of a protocol. It is expected that the status of the hosts reported on will change. This information must be treated as a snapshot of the state of these implemetations. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0877</doc-id>
        <title>Standard for the transmission of IP datagrams over public data networks</title>
        <author>
            <name>J.T. Korb</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3272</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>This RFC specifies a standard adopted by CSNET, the VAN gateway, and other organizations for the transmission of IP datagrams over the X.25-based public data networks. </abstract>
        <obsoleted-by>
            <doc-id>RFC1356</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0878</doc-id>
        <title>ARPANET 1822L Host Access Protocol</title>
        <author>
            <name>A.G. Malis</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>74774</char-count>
            <page-count>51</page-count>
        </format>
        <abstract>This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. The 1822L procedure allows ARPANET hosts to use logical identifiers as well as 1822 physical interface identifiers to address each other. </abstract>
        <obsoletes>
            <doc-id>RFC0851</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0879</doc-id>
        <title>TCP maximum segment size and related topics</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22024</char-count>
            <page-count>11</page-count>
        </format>
        <abstract>This RFC discusses the TCP Maximum Segment Size Option and related topics. The purposes is to clarify some aspects of TCP and its interaction with IP. This memo is a clarification to the TCP specification, and contains information that may be considered as "advice to implementers". </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0880</doc-id>
        <title>Official protocols</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37332</char-count>
            <page-count>26</page-count>
        </format>
        <abstract>This RFC identifies the documents specifying the official protocols used in the ARPA Internet. Annotations identify any revisions or changes planned. Obsoletes RFC 840. </abstract>
        <obsoletes>
            <doc-id>RFC0840</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0901</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0881</doc-id>
        <title>Domain names plan and schedule</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23490</char-count>
            <page-count>10</page-count>
        </format>
        <abstract>This RFC outlines a plan and schedule for the implementation of domain style names throughout the DDN/ARPA Internet community. The introduction of domain style names will impact all hosts on the DDN/ARPA Internet. </abstract>
        <updated-by>
            <doc-id>RFC0897</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0882</doc-id>
        <title>Domain names: Concepts and facilities</title>
        <author>
            <name>P.V. Mockapetris</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>79776</char-count>
            <page-count>31</page-count>
        </format>
        <abstract>This RFC introduces domain style names, their use for ARPA Internet mail and host address support, and the protocol and servers used to implement domain name facilities. </abstract>
        <obsoleted-by>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC0973</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0883</doc-id>
        <title>Domain names: Implementation specification</title>
        <author>
            <name>P.V. Mockapetris</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>175067</char-count>
            <page-count>74</page-count>
        </format>
        <abstract>This RFC discusses the implementation of domain name servers and resolvers, specifies the format of transactions, and discusses the use of domain names in the context of existing mail systems and other network software. </abstract>
        <obsoleted-by>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC0973</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0884</doc-id>
        <title>Telnet terminal type option</title>
        <author>
            <name>M. Solomon</name>
        </author>
        <author>
            <name>E. Wimmers</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7881</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>This RFC specifies a standard for the ARPA Internet community. It specifies a method for exchanging terminal type information in the Telnet protocol. </abstract>
        <obsoleted-by>
            <doc-id>RFC0930</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0885</doc-id>
        <title>Telnet end of record option</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3232</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>TOPT-EOR</kw>
        </keywords>
        <abstract>This RFC specifies a standard for the ARPA Internet community. It specifies a method for marking the end of records in data transmitted on Telnet connections. </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0886</doc-id>
        <title>Proposed standard for message header munging</title>
        <author>
            <name>M.T. Rose</name>
        </author>
        <date>
            <month>December</month>
            <day>15</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30566</char-count>
            <page-count>16</page-count>
        </format>
        <abstract>This RFC specifies a draft standard for the ARPA Internet community. It describes the rules to be used when transforming mail from the conventions of one message system to those of another message system. In particular, the treatment of header fields, and recipient addresses is specified. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0887</doc-id>
        <title>Resource Location Protocol</title>
        <author>
            <name>M. Accetta</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36770</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>RLP</kw>
        </keywords>
        <abstract>This RFC specifies a draft standard for the ARPA Internet community. It describes a resource location protocol for use in the ARPA Internet. It is most useful on networks employing technologies which support some method of broadcast addressing, however it may also be used on other types of networks. For maximum benefit, all hosts which provide significant resources or services to other hosts on the Internet should implement this protocol. Hosts failing to implement the Resource Location Protocol risk being ignored by other hosts which are attempting to locate resources on the Internet. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0888</doc-id>
        <title>"STUB" Exterior Gateway Protocol</title>
        <author>
            <name>L. Seamonson</name>
        </author>
        <author>
            <name>E.C. Rosen</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53227</char-count>
            <page-count>39</page-count>
        </format>
        <abstract>This RFC describes the Exterior Gateway Protocol used to connect Stub Gateways to an Autonomous System of core Gateways. This document specifies the working protocol, and defines an ARPA official protocol. All implementers of Gateways should carefully review this document. </abstract>
        <updated-by>
            <doc-id>RFC0904</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0889</doc-id>
        <title>Internet delay experiments</title>
        <author>
            <name>D.L. Mills</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27128</char-count>
            <page-count>12</page-count>
        </format>
        <abstract>This memo reports on some measurements of round-trip times in the Internet and suggests some possible improvements to the TCP retransmission timeout calculation. This memo is both a status report on the Internet and advice to TCP implementers. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0890</doc-id>
        <title>Exterior Gateway Protocol implementation schedule</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5899</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>EGP</kw>
        </keywords>
        <abstract>This memo is a policy statement on the implementation of the Exterior Gateway Protocol in the Internet. This is an official policy statement of ICCB and DARPA. After 1-Aug-84 there shall be no dumb gateways in the Internet. Every gateway must be a member of some autonomous system. Some gateway of each autonomous system must exchange routing information with some gateway of the core autonomous system using the Exterior Gateway Protocol. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0891</doc-id>
        <title>DCN local-network protocols</title>
        <author>
            <name>D.L. Mills</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>66769</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>IP-DC</kw>
        </keywords>
        <abstract>This RFC provides a description of the DCN protocols for maintaining connectivity, routing, and clock information in a local network. These procedures may be of interest to the designers and implementers of other local networks. </abstract>
        <is-also>
            <doc-id>STD0044</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0892</doc-id>
        <title>ISO Transport Protocol specification </title>
        <author>
            <name>International Organization for Standardization</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1983</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>158151</char-count>
            <page-count>82</page-count>
        </format>
        <abstract>This is a draft version of the transport protocol being standardized by the ISO. This version also appeared in the ACM SIGCOMM Computer Communication Review (V.12, N.3-4) July-October 1982. This version is now out of date. </abstract>
        <notes>Draft.  </notes>
        <obsoleted-by>
            <doc-id>RFC0905</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0893</doc-id>
        <title>Trailer encapsulations</title>
        <author>
            <name>S. Leffler</name>
        </author>
        <author>
            <name>M.J. Karels</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13353</char-count>
            <page-count>6</page-count>
        </format>
        <abstract>This RFC discusses the motivation for use of "trailer encapsulations" on local-area networks and describes the implementation of such an encapsulation on various media. This document is for information only. This is NOT an official protocol for the ARPA Internet community. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0894</doc-id>
        <title>Standard for the transmission of IP datagrams over Ethernet networks</title>
        <author>
            <name>C. Hornig</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5697</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>IP-E</kw>
        </keywords>
        <abstract>This RFC specifies a standard method of encapsulating Internet Protocol (IP) datagrams on an Ethernet. This RFC specifies a standard protocol for the ARPA-Internet community. </abstract>
        <is-also>
            <doc-id>STD0041</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0895</doc-id>
        <title>Standard for the transmission of IP datagrams over experimental Ethernet networks</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4985</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>IP-EE</kw>
        </keywords>
        <abstract>This RFC specifies a standard method of encapsulating Internet Protocol (IP) datagrams on an Experimental Ethernet. This RFC specifies a standard protocol for the ARPA Internet community. </abstract>
        <is-also>
            <doc-id>STD0042</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0896</doc-id>
        <title>Congestion control in IP/TCP internetworks</title>
        <author>
            <name>J. Nagle</name>
        </author>
        <date>
            <month>January</month>
            <day>06</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26782</char-count>
            <page-count>9</page-count>
        </format>
        <abstract>This memo discusses some aspects of congestion control in IP/TCP Internetworks. It is intended to stimulate thought and further discussion of this topic. While some specific suggestions are made for improved congestion control implementation, this memo does not specify any standards. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0897</doc-id>
        <title>Domain name system implementation schedule</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15683</char-count>
            <page-count>8</page-count>
        </format>
        <abstract>This memo is a policy statement on the implementation of the Domain Style Naming System in the Internet. This memo is a partial update of RFC 881. The intent of this memo is to detail the schedule for the implementation for the Domain Style Naming System. The names of hosts will be changed to domain style names. Hosts will begin to use domain style names on 14-Mar-84, and the use of old style names will be completely phased out before 2-May-84. This applies to both the ARPA research hosts and the DDN operational hosts. This is an official policy statement of the ICCB and the DARPA. </abstract>
        <updates>
            <doc-id>RFC0881</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC0921</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0898</doc-id>
        <title>Gateway special interest group meeting notes</title>
        <author>
            <name>R.M. Hinden</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>M. Muuss</name>
        </author>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42112</char-count>
            <page-count>24</page-count>
        </format>
        <abstract>This memo is a report on the Gateway Special Interest Group Meeting that was held at ISI on 28 and 29 February 1984. Robert Hinden of BBNCC chaired, and Jon Postel of ISI hosted the meeting. Approximately 35 gateway designers and implementors attended. These notes are based on the recollections of Jon Postel and Mike Muuss. Under each topic area are Jon Postel's brief notes, and additional details from Mike Muuss. This memo is a report on a meeting. No conclusions, decisions, or policy statements are documented in this note. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0899</doc-id>
        <title>Request For Comments summary notes: 800-899</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>A. Westine</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39996</char-count>
            <page-count>18</page-count>
        </format>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0900</doc-id>
        <title>Assigned Numbers</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>82116</char-count>
            <page-count>43</page-count>
        </format>
        <abstract>This RFC specifies parameter values use in the Internet family of protocols, such as network numbers, well known ports, protocol types, and version numbers. This memo is an official status report on the protocol parameters used in the Internet protocol system. See RFC-990 and 997. </abstract>
        <obsoletes>
            <doc-id>RFC0870</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0923</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0901</doc-id>
        <title>Official ARPA-Internet protocols</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41058</char-count>
            <page-count>28</page-count>
        </format>
        <abstract>This RFC identifies the documents specifying the official protocols used in the ARPA-Internet. Annotations identify any revisions or changes planned. This memo is an official status report on the protocols used in the DARPA research community. See RFC-991. </abstract>
        <obsoletes>
            <doc-id>RFC0880</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0924</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0902</doc-id>
        <title>ARPA Internet Protocol policy</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11027</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>The purpose of this memo is to explain how protocol standards are adopted for the ARPA-Internet and the DARPA research community. There are three important aspects to be discussed: the process, the authority, and the complex relationship between the DARPA community and the DDN community. This memo is a policy statement on how protocols become official standards for the ARPA-Internet and the DARPA research community. This is an official policy statement of the ICCB and the DARPA. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0903</doc-id>
        <title>Reverse Address Resolution Protocol</title>
        <author>
            <name>R. Finlayson</name>
        </author>
        <author>
            <name>T. Mann</name>
        </author>
        <author>
            <name>J.C. Mogul</name>
        </author>
        <author>
            <name>M. Theimer</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9345</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>RARP</kw>
        </keywords>
        <abstract>This RFC suggests a method for workstations to dynamically find their protocol address (e.g., their Internet Address), when they know only their hardware address (e.g., their attached physical network address). This RFC specifies a proposed protocol for the ARPA Internet community, and requests discussion and suggestions for improvements. </abstract>
        <is-also>
            <doc-id>STD0038</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0904</doc-id>
        <title>Exterior Gateway Protocol formal specification</title>
        <author>
            <name>D.L. Mills</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>65226</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>EGP</kw>
        </keywords>
        <abstract>RFC-904 is the specification of the Exterior Gateway Protocol (EGP). This memo updates portions of RFC-888 and RFC-827. This RFC specifies an official protocol of the DARPA community for use between gateways of different autonomous systems in the ARPA-Internet. </abstract>
        <updates>
            <doc-id>RFC0827</doc-id>
            <doc-id>RFC0888</doc-id>
        </updates>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0905</doc-id>
        <title>ISO Transport Protocol specification ISO DP 8073</title>
        <author>
            <name>ISO</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>249214</char-count>
            <page-count>164</page-count>
        </format>
        <abstract>This is the current specification of the ISO Transport Protocol. This document is the text of ISO/TC97/SC16/N1576 as corrected by ISO/TC97/SC16/N1695. This is the specification currently being voted on in ISO as a Draft International Standard (DIS). This document is distributed as an RFC for your information only, it does not specify a standard for the ARPA-Internet or DARPA research community. Our thanks to Alex McKenzie of BBN for making this online version available. Please note the size of this document, the file contains 258,729 characters. </abstract>
        <obsoletes>
            <doc-id>RFC0892</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0906</doc-id>
        <title>Bootstrap loading using TFTP</title>
        <author>
            <name>R. Finlayson</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10102</char-count>
            <page-count>4</page-count>
        </format>
        <abstract>It is often convenient to be able to bootstrap a computer system from a communications network. This RFC proposes the use of the IP TFTP protocol for bootstrap loading in this case. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0907</doc-id>
        <title>Host Access Protocol specification</title>
        <author>
            <name>Bolt Beranek and Newman Inc.</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>129985</char-count>
            <page-count>78</page-count>
        </format>
        <keywords>
            <kw>IP-WB</kw>
        </keywords>
        <abstract>This document specifies the Host Access Protocol (HAP). Although HAP was originally designed as the network-access level protocol for the DARPA/DCA sponsored Wideband Packet Satellite Network, it is intended that it evolve into a standard interface SATNET and TACNET (aka MATNET) as well as the Wideband Network. HAP is an experimental protocol, and will undergo further revision as new capabilities are added and/or different satellite networks are suported. Implementations of HAP should be performed in coordination with satellite network development and operations personnel. </abstract>
        <updated-by>
            <doc-id>RFC1221</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0040</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0908</doc-id>
        <title>Reliable Data Protocol</title>
        <author>
            <name>D. Velten</name>
        </author>
        <author>
            <name>R.M. Hinden</name>
        </author>
        <author>
            <name>J. Sax</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>97646</char-count>
            <page-count>62</page-count>
        </format>
        <keywords>
            <kw>RDP</kw>
        </keywords>
        <abstract>The Reliable Data Protocol (RDP) is designed to provide a reliable data transport service for packet-based applications. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts. </abstract>
        <updated-by>
            <doc-id>RFC1151</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0909</doc-id>
        <title>Loader Debugger Protocol</title>
        <author>
            <name>C. Welles</name>
        </author>
        <author>
            <name>W. Milliken</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>209813</char-count>
            <page-count>135</page-count>
        </format>
        <keywords>
            <kw>LDP</kw>
        </keywords>
        <abstract>The Loader Debugger Protocol (LDP) is an application layer protocol for loading, dumping, and debugging target machines from hosts in a network environment. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0910</doc-id>
        <title>Multimedia mail meeting notes</title>
        <author>
            <name>H.C. Forsdick</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24915</char-count>
            <page-count>11</page-count>
        </format>
        <abstract>This memo is a report on a meeting about the experimental multimedia mail system (and in a sense a status report on that experiment). The meeting was held at Bolt Beranek and Newman on 23-24 July 1984 to discuss recent progress by groups who are building multimedia mail systems and to discuss a variety of issues related to the further development of multimedia systems. Representatives were present from BBN, ISI, SRI and Linkabit. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0911</doc-id>
        <title>EGP Gateway under Berkeley UNIX 4.2</title>
        <author>
            <name>P. Kirton</name>
        </author>
        <date>
            <month>August</month>
            <day>22</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>55908</char-count>
            <page-count>23</page-count>
        </format>
        <abstract>This memo describes an implementation of the Exterior Gateway Protocol (EGP) (in that sense it is a status report). The memo also discusses some possible extentions and some design issues (in that sense it is an invitation for further discussion). </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0912</doc-id>
        <title>Authentication service</title>
        <author>
            <name>M. St. Johns</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4544</char-count>
            <page-count>3</page-count>
        </format>
        <abstract>This memo describes a proposed authentication protocol for verifying the identity of a user of a TCP connection. Given a TCP port number pair, it returns a character string which identifies the owner of that connection on the server's system. Suggested uses include automatic identification and verification of a user during an FTP session, additional verification of a TAC dial up user, and access verification for a generalized network file server. </abstract>
        <obsoleted-by>
            <doc-id>RFC0931</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0913</doc-id>
        <title>Simple File Transfer Protocol</title>
        <author>
            <name>M. Lottor</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20929</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>SFTP</kw>
            <kw>FTP</kw>
        </keywords>
        <abstract>This memo describes a proposed Simple File Transfer Protocol (SFTP). It fills the need of people wanting a protocol that is more useful than TFTP but easier to implement (and less powerful) than FTP. SFTP supports user access control, file transfers, directory listing, directory changing, file renaming and deleting. Discussion of this proposal is encouraged, and suggestions for improvements may be sent to the author. </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0914</doc-id>
        <title>Thinwire protocol for connecting personal computers to the Internet</title>
        <author>
            <name>D.J. Farber</name>
        </author>
        <author>
            <name>G. Delp</name>
        </author>
        <author>
            <name>T.M. Conte</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>57288</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>THINWIRE</kw>
        </keywords>
        <abstract>This RFC focuses discussion on the particular problems in the ARPA-Internet of low speed network interconnection with personal computers, and possible methods of solution. None of the proposed solutions in this document are intended as standards for the ARPA-Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to the problems, leading eventually to the adoption of standards. </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0915</doc-id>
        <title>Network mail path service</title>
        <author>
            <name>M.A. Elvy</name>
        </author>
        <author>
            <name>R. Nedved</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21635</char-count>
            <page-count>11</page-count>
        </format>
        <abstract>This RFC proposed a new service for the ARPA-Internet community and requests discussion and suggestions for improvements. The network mail path service fills the current need of people to determine mailbox addresses for hosts that are not part of the ARPA-Internet but can be reached by one or more relay hosts that have Unix to Unix Copy (UUCP) mail, CSNET mail, MAILNET mail, BITNET mail, etc. Anyone can use the service if they have TCP/TELENET to one of the hosts with a mail path server. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0916</doc-id>
        <title>Reliable Asynchronous Transfer Protocol (RATP)</title>
        <author>
            <name>G.G. Finn</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>110737</char-count>
            <page-count>54</page-count>
        </format>
        <keywords>
            <kw>RATP</kw>
        </keywords>
        <abstract>This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This paper proposes and specifies a protocol which allows two programs to reliably communicate over a communication link. It ensures that the data entering one end of the link if received arrives at the other end intact and unaltered. The protocol, named RATP, is designed to operate over a full duplex point-to-point connection. It contains some features which tailor it to the RS-232 links now in common use. </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0917</doc-id>
        <title>Internet subnets</title>
        <author>
            <name>J.C. Mogul</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47072</char-count>
            <page-count>22</page-count>
        </format>
        <abstract>This memo discusses subnets and proposes procedures for the use of subnets, including approaches to solving the problems that arise, particularly that of routing. A subnet of an Internet network is a logically visible sub-section of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0918</doc-id>
        <title>Post Office Protocol</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9876</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. The intent of the Post Office Protocol (POP) is to allow a user's workstation to access mail from a mailbox server. It is expected that mail will be posted from the workstation to the mailbox server via the Simple Mail Transfer Protocol (SMTP). This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. The status of this protocol is experimental, and this protocol is dependent upon TCP. </abstract>
        <obsoleted-by>
            <doc-id>RFC0937</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0919</doc-id>
        <title>Broadcasting Internet Datagrams</title>
        <author>
            <name>J.C. Mogul</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16382</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This RFC proposes simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. </abstract>
        <is-also>
            <doc-id>STD0005</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0920</doc-id>
        <title>Domain requirements</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27823</char-count>
            <page-count>14</page-count>
        </format>
        <abstract>This memo states the requirements on establishing a Domain, and introduces the limited set of top level domains. This memo is a policy statement on the requirements of establishing a new domain in the ARPA-Internet and the DARPA research community. This is an official policy statement of the IAB and the DARPA. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0921</doc-id>
        <title>Domain name system implementation schedule - revised</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23318</char-count>
            <page-count>13</page-count>
        </format>
        <abstract>This memo is a policy statement on the implementation of the Domain Style Naming System in the Internet. This memo is an update of RFC-881, and RFC-897. This is an official policy statement of the IAB and the DARPA. The intent of this memo is to detail the schedule for the implementation for the Domain Style Naming System. The explanation of how this system works is to be found in the references. </abstract>
        <updates>
            <doc-id>RFC0897</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0922</doc-id>
        <title>Broadcasting Internet datagrams in the presence of subnets</title>
        <author>
            <name>J.C. Mogul</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24147</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>We propose simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. </abstract>
        <is-also>
            <doc-id>STD0005</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0923</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>96467</char-count>
            <page-count>47</page-count>
        </format>
        <abstract>This RFC documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers obsoletes RFC-900 and earlier editions. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990, and 997. </abstract>
        <obsoletes>
            <doc-id>RFC0900</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0943</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0924</doc-id>
        <title>Official ARPA-Internet protocols for connecting personal computers to the Internet</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48513</char-count>
            <page-count>35</page-count>
        </format>
        <abstract>This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-900 and earlier editions. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991. </abstract>
        <obsoletes>
            <doc-id>RFC0901</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0944</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0925</doc-id>
        <title>Multi-LAN address resolution</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31137</char-count>
            <page-count>15</page-count>
        </format>
        <abstract>The problem of treating a set of local area networks (LANs) as one Internet network has generated some interest and concern. It is inappropriate to give each LAN within an site a distinct Internet network number. It is desirable to hide the details of the interconnections between the LANs within an site from people, gateways, and hosts outside the site. The question arises on how to best do this, and even how to do it at all. In RFC-917 Jeffery Mogul makes a case for the use of "explicit subnets" in a multi-LAN environment. The explicit subnet scheme is a call to recursively apply the mechanisms the Internet uses to manage networks to the problem of managing LANs within one network. In this note I urge another approach: the use of "transparent subnets" supported by a multi-LAN extension of the Address Resolution Protocol. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0926</doc-id>
        <title>Protocol for providing the connectionless mode network services</title>
        <author>
            <name>International Organization for Standardization</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>165895</char-count>
            <page-count>107</page-count>
        </format>
        <abstract>This note is the draft ISO protocol roughly similar to the DOD Internet Protocol. This document has been prepared by retyping the text of ISO DIS 8473 of May 1984, which is currently undergoing voting within ISO as a Draft International Standard (DIS). This document is distributred as an RFC for information only. It does not specify a standard for the ARPA-Internet. </abstract>
        <obsoleted-by>
            <doc-id>RFC0994</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0927</doc-id>
        <title>TACACS user identification Telnet option</title>
        <author>
            <name>B.A. Anderson</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5474</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>TOPT-TACACS</kw>
        </keywords>
        <abstract>The following is the description of a TELNET option designed to facilitate double login avoidance. It is intended primarily for TAC connections to target hosts on behalf of TAC users, but it can be used between any two consenting hosts. For example, all hosts at one site (e.g., BBN) can use this option to avoid double login when TELNETing to one another. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0928</doc-id>
        <title>Introduction to proposed DoD standard H-FP</title>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>60461</char-count>
            <page-count>21</page-count>
        </format>
        <abstract>The broad outline of the Host-Front End Protocol introduced here and described in RFC-929 is the result of the deliberations of a number of experienced H-FP designers, who sat as a committee of the DoD Protocol Standards Technical Panel. It is the intent of the designers that the protocol be subjected to multiple test implementations and probable iteration before being agreed upon as any sort of "standard". Therefore, the first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0929</doc-id>
        <title>Proposed Host-Front End Protocol</title>
        <author>
            <name>J. Lilienkamp</name>
        </author>
        <author>
            <name>R. Mandell</name>
        </author>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1984</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>135042</char-count>
            <page-count>56</page-count>
        </format>
        <keywords>
            <kw>HFEP</kw>
        </keywords>
        <abstract>The Host-Front End Protocol introduced in RFC-928 is described in detail in this memo. The first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0930</doc-id>
        <title>Telnet terminal type option</title>
        <author>
            <name>M. Solomon</name>
        </author>
        <author>
            <name>E. Wimmers</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6583</char-count>
            <page-count>4</page-count>
        </format>
        <abstract>This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard. This standard supersedes RFC-884. The only change is to specify that the TERMINAL-TYPE IS sub-negotiation should be sent only in response to the TERMINAL-TYPE SEND sub-negotiation. </abstract>
        <obsoletes>
            <doc-id>RFC0884</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1091</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0931</doc-id>
        <title>Authentication server</title>
        <author>
            <name>M. St. Johns</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8982</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is the second draft of this proposal (superseding RFC-912) and incorporates a more formal description of the syntax for the request and response dialog, as well as a change to specify the type of user identification returned. </abstract>
        <obsoletes>
            <doc-id>RFC0912</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1413</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0932</doc-id>
        <title>Subnetwork addressing scheme</title>
        <author>
            <name>D.D. Clark</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9283</char-count>
            <page-count>4</page-count>
        </format>
        <abstract>This RFC proposes an alternative addressing scheme for subnets which, in most cases, requires no modification to host software whatsoever. The drawbacks of this scheme are that the total number of subnets in any one network are limited, and that modification is required to all gateways. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0933</doc-id>
        <title>Output marking Telnet option</title>
        <author>
            <name>S. Silverman</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6715</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>TOPT-OM</kw>
        </keywords>
        <abstract>This proposed option would allow a Server-Telnet to send a banner to a User-Telnet so that this banner would be displayed on the workstation screen independently of the application software running in the Server-Telnet. </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0934</doc-id>
        <title>Proposed standard for message encapsulation</title>
        <author>
            <name>M.T. Rose</name>
        </author>
        <author>
            <name>E.A. Stefferud</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21770</char-count>
            <page-count>10</page-count>
        </format>
        <abstract>This memo concerns itself with message forwarding. Forwarding can be thought of as encapsulating one or more messages inside another. Although this is useful for transfer of past correspondence to new recipients, without a decapsulation process (which this memo terms "bursting"), the forwarded messages are of little use to the recipients because they can not be distributed, forwarded, replied-to, or otherwise processed as separate individual messages. In order to burst a message it is necessary to know how the component messages were encapsulated in the draft. At present there is no unambiguous standard for interest group digests. This RFC proposes a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0935</doc-id>
        <title>Reliable link layer protocols</title>
        <author>
            <name>J.G. Robinson</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31625</char-count>
            <page-count>12</page-count>
        </format>
        <abstract>This RFC discusses protocols proposed recently in RFCs 914 and 916, and suggests a proposed protocol that could meet the same needs addressed in those memos. The stated need is reliable communication between two programs over a full-duplex, point-to-point communication link, and in particular the RFCs address the need for such communication over an asynchronous link at relatively low speeds. The suggested protocol uses the methods of existing national and international data link layer standards. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0936</doc-id>
        <title>Another Internet subnet addressing scheme</title>
        <author>
            <name>M.J. Karels</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10179</char-count>
            <page-count>4</page-count>
        </format>
        <abstract>There have been several proposals for schemes to allow the use of a single Internet network number to refer to a collection of physical networks under common administration which are reachable from the rest of the Internet by a common route. Such schemes allow a simplified view of an otherwise complicated topology from hosts and gateways outside of this collection. They allow the complexity of the number and type of these networks, and routing to them, to be localized. Additions and changes in configuration thus cause no detectable change, and no interruption of service, due to slow propagation of routing and other information outside of the local environment. These schemes also simplify the administration of the network, as changes do not require allocation of new network numbers for each new cable installed. This proposal discusses an alternative scheme, one that has been in use at the University of California, Berkeley since April 1984. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0937</doc-id>
        <title>Post Office Protocol: Version 2</title>
        <author>
            <name>M. Butler</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>D. Chase</name>
        </author>
        <author>
            <name>J. Goldberger</name>
        </author>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42370</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>POP2</kw>
            <kw>Post Office Protocol</kw>
            <kw>Version 2</kw>
        </keywords>
        <abstract>This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. This memo is a revision of RFC-918. </abstract>
        <obsoletes>
            <doc-id>RFC0918</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0938</doc-id>
        <title>Internet Reliable Transaction Protocol functional and interface specification</title>
        <author>
            <name>T. Miller</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39478</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>IRTP</kw>
        </keywords>
        <abstract>This RFC is being distributed to members of the DARPA research community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the DARPA community, they may be interesting to a number of researchers and implementors. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0939</doc-id>
        <title>Executive summary of the NRC report on transport protocols for Department of Defense data networks</title>
        <author>
            <name>National Research Council </name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42345</char-count>
            <page-count>20</page-count>
        </format>
        <abstract>This RFC reproduces the material from the "front pages" of the National Research Council report resulting from a study of the DOD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4). The point of this RFC is to make the text of the Executive Summary widely available in a timely way. The order of presentation has been altered, and the pagination changed. This RFC is distributed for information only. This RFC does not establish any policy for the DARPA research community or the DDN operational community. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0940</doc-id>
        <title>Toward an Internet standard scheme for subnetting</title>
        <author>
            <name>Gateway Algorithms and Data Structures Task Force</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6881</char-count>
            <page-count>3</page-count>
        </format>
        <abstract>Several sites now contain a complex of local links connected to the Internet via a gateway. The details of the internal connectivity are of little interest to the rest of the Internet. One way of organizing these local complexes of links is to use the same strategy as the Internet uses to organize networks, that is, to declare each link to be an entity (like a network) and to interconnect the links with devices that perform routing functions (like gateways). This general scheme is called subnetting, the individual links are called subnets, and the connecting devices are called subgateways (or bridges, or gateways). This RFC discusses standardizing the protocol used in subnetted environments in the ARPA-Internet. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0941</doc-id>
        <title>Addendum to the network service definition covering network layer addressing</title>
        <author>
            <name>International Organization for Standardization </name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>68733</char-count>
            <page-count>34</page-count>
        </format>
        <abstract>This Addendum to the Network Service Definition Standard, ISO 8348, defines the abstract syntax and semantics of the Network Address (Network Service Access Point Address). The Network Address defined in this Addendum is the address that appears in the primitives of the connection-mode Network Service as the calling address, called address, and responding address parameters, and in the primitives of the connectionless-mode Network Service as the source address and destination address parameters. This document is distributed as an RFC for information only. It does not specify a standard for the ARPA-Internet. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0942</doc-id>
        <title>Transport protocols for Department of Defense data networks</title>
        <author>
            <name>National Research Council</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>217284</char-count>
            <page-count>88</page-count>
        </format>
        <abstract>This RFC reproduces the National Research Council report resulting from a study of the DoD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4). </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0943</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>105234</char-count>
            <page-count>50</page-count>
        </format>
        <abstract>This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This RFC will be updated periodically, and in any case current information can be obtained from Joyce Reynolds. The assignment of numbers is also handled by Joyce. If you are developing a protocol or application that will require the use of a link, socket, port, protocol, network number, etc., please contact Joyce to receive a number assignment. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997. </abstract>
        <obsoletes>
            <doc-id>RFC0923</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0960</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0944</doc-id>
        <title>Official ARPA-Internet protocols</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>61373</char-count>
            <page-count>40</page-count>
        </format>
        <abstract>This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-924 and earlier editions. This RFC will be updated periodically, and current information can be obtained from Joyce Reynolds. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991. </abstract>
        <obsoletes>
            <doc-id>RFC0924</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0961</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0945</doc-id>
        <title>DoD statement on the NRC report</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5017</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>In May 1983 the National Research Council (NRC) was asked jointly by DoD and NBS to study the issues and recommend a course of action. The final report of the NRC committee was published in February 1985 (see RFC-942). The enclosed letter is from Donald C. Latham (ASDC3I) to DCA transmitting the NRC report and requesting specific actions relative to the recommendations of the report. This RFC reproduces a letter from the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASDC3I) to the Director of the Defense Communications Agency (DCA). This letter is distributed for information only. </abstract>
        <obsoleted-by>
            <doc-id>RFC1039</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0946</doc-id>
        <title>Telnet terminal location number option</title>
        <author>
            <name>R. Nedved</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6285</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>TOPT-TLN</kw>
        </keywords>
        <abstract>Many systems provide a mechanism for finding out where a user is logged in from usually including information about telephone extension and office occupants names. The information is useful for physically locating people and/or calling them on the phone. In 1982 CMU designed and implemented a terminal location database and modified existing network software to handle a 64-bit number called the Terminal Location Number (or TTYLOC). It now seems appropriate to incorporate this mechanism into the TCP-based network protocol family. The mechanism is not viewed as a replacement for the Terminal Location Telnet Option (SEND-LOCATION) but as a shorthand mechansim for communicating terminal location information between hosts in a localized community. This RFC proposes a new option for Telnet for the ARPA-Internet community, and requests discussion and suggestions for improvements. </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0947</doc-id>
        <title>Multi-network broadcasting within the Internet</title>
        <author>
            <name>K. Lebowitz</name>
        </author>
        <author>
            <name>D. Mankins</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12569</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>This RFC describes the extension of a network's broadcast domain to include more than one physical network through the use of a broadcast packet repeater. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0948</doc-id>
        <title>Two methods for the transmission of IP datagrams over IEEE 802.3 networks</title>
        <author>
            <name>I. Winston</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11495</char-count>
            <page-count>7</page-count>
        </format>
        <abstract>This RFC describes two methods of encapsulating Internet Protocol (IP) datagrams on an IEEE 802.3 network. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. </abstract>
        <obsoleted-by>
            <doc-id>RFC1042</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0949</doc-id>
        <title>FTP unique-named store command</title>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4017</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>There are various contexts in which it would be desirable to have an FTP command that had the effect of the present STOR but rather than requiring the sender to specify a file name istead caused the resultant file to have a unique name relative to the current directory. This RFC proposes an extension to the File Transfer Protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. See RFC-959. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0950</doc-id>
        <title>Internet Standard Subnetting Procedure</title>
        <author>
            <name>J.C. Mogul</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37985</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>Address</kw>
        </keywords>
        <abstract>This memo discusses the utility of "subnets" of Internet networks, which are logically visible sub-sections of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. This memo specifies procedures for the use of subnets. These procedures are for hosts (e.g., workstations). The procedures used in and between subnet gateways are not fully described. Important motivation and background information for a subnetting standard is provided in RFC-940. This RFC specifies a protocol for the ARPA-Internet community. If subnetting is implemented it is strongly recommended that these procedures be followed. </abstract>
        <updates>
            <doc-id>RFC0792</doc-id>
        </updates>
        <is-also>
            <doc-id>STD0005</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0951</doc-id>
        <title>Bootstrap Protocol</title>
        <author>
            <name>W.J. Croft</name>
        </author>
        <author>
            <name>J. Gilmore</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28354</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>BOOTP</kw>
        </keywords>
        <abstract>This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. The bootstrap operation can be thought of as consisting of TWO PHASES. This RFC describes the first phase, which could be labeled `address determination and bootfile selection'. After this address and filename information is obtained, control passes to the second phase of the bootstrap where a file transfer occurs. The file transfer will typically use the TFTP protocol, since it is intended that both phases reside in PROM on the client. However BOOTP could also work with other protocols such as SFTP or FTP. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. </abstract>
        <updated-by>
            <doc-id>RFC1395</doc-id>
            <doc-id>RFC1497</doc-id>
            <doc-id>RFC1532</doc-id>
            <doc-id>RFC1542</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0952</doc-id>
        <title>DoD Internet host table specification</title>
        <author>
            <name>K. Harrenstien</name>
        </author>
        <author>
            <name>M.K. Stahl</name>
        </author>
        <author>
            <name>E.J. Feinler</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12388</char-count>
            <page-count>6</page-count>
        </format>
        <abstract>This RFC is the official specification of the format of the Internet Host Table. This edition of the specification includes minor revisions to RFC-810 which brings it up to date. </abstract>
        <obsoletes>
            <doc-id>RFC0810</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0953</doc-id>
        <title>Hostname Server</title>
        <author>
            <name>K. Harrenstien</name>
        </author>
        <author>
            <name>M.K. Stahl</name>
        </author>
        <author>
            <name>E.J. Feinler</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8305</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>HOSTNAME</kw>
        </keywords>
        <abstract>This RFC is the official specification of the Hostname Server Protocol. This edition of the specification includes minor revisions to RFC-811 which brings it up to date. </abstract>
        <obsoletes>
            <doc-id>RFC0811</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0954</doc-id>
        <title>NICNAME/WHOIS</title>
        <author>
            <name>K. Harrenstien</name>
        </author>
        <author>
            <name>M.K. Stahl</name>
        </author>
        <author>
            <name>E.J. Feinler</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7397</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>NICNAME</kw>
        </keywords>
        <abstract>This RFC is the official specification of the NICNAME/WHOIS protocol. This memo describes the protocol and the service. This is an update of RFC-812. </abstract>
        <obsoletes>
            <doc-id>RFC0812</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3912</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0955</doc-id>
        <title>Towards a transport service for transaction processing applications</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22497</char-count>
            <page-count>10</page-count>
        </format>
        <abstract>The DoD Internet protocol suite includes two alternative transport service protocols, TCP and UDP, which provide virtual circuit and datagram service, respectively. These two protocols represent points in the space of possible transport service attributes which are quite "far apart". We want to examine an important class of applications, those which perform what is often called "transaction processing". We will see that the communication needs for these applications fall into the gap "between" TCP and UDP -- neither protocol is very appropriate. This RFC is concerned with the possible design of one or more new protocols for the ARPA-Internet, to support kinds of applications which are not well supported at present. The RFC is intended to spur discussion in the Internet research community towards the development of new protocols and/or concepts, in order to meet these unmet application requirements. It does not represent a standard, nor even a concrete protocol proposal. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0956</doc-id>
        <title>Algorithms for synchronizing network clocks</title>
        <author>
            <name>D.L. Mills</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>67387</char-count>
            <page-count>26</page-count>
        </format>
        <abstract>This RFC discussed clock synchronization algorithms for the ARPA-Internet community, and requests discussion and suggestions for improvements. The recent interest within the Internet community in determining accurate time from a set of mutually suspicious network clocks has been prompted by several occasions in which errors were found in usually reliable, accurate clock servers after thunderstorms which disrupted their power supply. To these sources of error should be added those due to malfunctioning hardware, defective software and operator mistakes, as well as random errors in the mechanism used to set and synchronize clocks. This report suggests a stochastic model and algorithms for computing a good estimator from time-offset samples measured between clocks connected via network links. Included in this report are descriptions of certain experiments which give an indication of the effectiveness of the algorithms. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0957</doc-id>
        <title>Experiments in network clock synchronization</title>
        <author>
            <name>D.L. Mills</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>68952</char-count>
            <page-count>27</page-count>
        </format>
        <abstract>This RFC discusses some experiments in clock synchronization in the ARPA-Internet community, and requests discussion and suggestions for improvements. One of the services frequently neglected in computer network design is a high-quality, time-of-day clock capable of generating accurate timestamps with small errors compared to one-way network delays. Such a service would be useful for tracing the progress of complex transactions, synchronizing cached data bases, monitoring network performance and isolating problems. In this memo one such clock service design will be described and its performance assessed. This design has been incorporated as an integral part of the network routing and control protocols of the Distributed Computer Network (DCnet) architecture. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0958</doc-id>
        <title>Network Time Protocol (NTP)</title>
        <author>
            <name>D.L. Mills</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30723</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>NTP</kw>
            <kw>time</kw>
            <kw>clock</kw>
            <kw>synchronization</kw>
        </keywords>
        <abstract>This document describes the Network Time Protocol (NTP), a protocol for synchronizing a set of network clocks using a set of distributed clients and servers. NTP is built on the User Datagram Protocol (UDP), which provides a connectionless transport mechanism. It is evolved from the Time Protocol and the ICMP Timestamp message and is a suitable replacement for both. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. </abstract>
        <obsoleted-by>
            <doc-id>RFC1059</doc-id>
            <doc-id>RFC1119</doc-id>
            <doc-id>RFC1305</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0959</doc-id>
        <title>File Transfer Protocol</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>147316</char-count>
            <page-count>69</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <abstract>This memo is the official specification of the File Transfer Protocol (FTP) for the DARPA Internet community. The primary intent is to clarify and correct the documentation of the FTP specification, not to change the protocol. The following new optional commands are included in this edition of the specification: Change to Parent Directory (CDUP), Structure Mount (SMNT), Store Unique (STOU), Remove Directory (RMD), Make Directory (MKD), Print Directory (PWD), and System (SYST). Note that this specification is compatible with the previous edition. </abstract>
        <obsoletes>
            <doc-id>RFC0765</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC2228</doc-id>
            <doc-id>RFC2640</doc-id>
            <doc-id>RFC2773</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0009</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0960</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>125814</char-count>
            <page-count>60</page-count>
        </format>
        <abstract>This memo documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers updates and obsoletes RFC-943. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997. </abstract>
        <obsoletes>
            <doc-id>RFC0943</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0990</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0961</doc-id>
        <title>Official ARPA-Internet protocols</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52672</char-count>
            <page-count>38</page-count>
        </format>
        <abstract>This memo identifies the documents specifying the official protocols used in the Internet, and comments on any revisions or changes planned. This edition of the Official Protocols updates and obsoletes RFC-944. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991. </abstract>
        <obsoletes>
            <doc-id>RFC0944</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC0991</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0962</doc-id>
        <title>TCP-4 prime</title>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2773</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>This memo is in response to Bob Braden's call for a transaction oriented protocol (RFC-955), and continues the discussion of a possible transaction oriented transport protocol. This memo does not propose a standard. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0963</doc-id>
        <title>Some problems with the specification of the Military Standard Internet Protocol</title>
        <author>
            <name>D.P. Sidhu</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44019</char-count>
            <page-count>19</page-count>
        </format>
        <abstract>The purpose of this RFC is to provide helpful information on the Military Standard Internet Protocol (MIL-STD-1777) so that one can obtain a reliable implementation of this protocol. This paper points out several problems in this specification. This note also proposes solutions to these problems. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0964</doc-id>
        <title>Some problems with the specification of the Military Standard Transmission Control Protocol</title>
        <author>
            <name>D.P. Sidhu</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20972</char-count>
            <page-count>10</page-count>
        </format>
        <abstract>The purpose of this RFC is to provide helpful information on the Military Standard Transmission Control Protocol (MIL-STD-1778) so that one can obtain a reliable implementation of this protocol standard. This note points out three errors with this specification. This note also proposes solutions to these problems. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0965</doc-id>
        <title>Format for a graphical communication protocol</title>
        <author>
            <name>L. Aguilar</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>105456</char-count>
            <page-count>51</page-count>
        </format>
        <abstract>This RFC describes the requirements for a graphical format on which to base a graphical on-line communication protocol, and proposes an Interactive Graphical Communication Format using the GKSM session metafile. We hope this contribution will encourage the discussion of multimedia data exchange and the proposal of solutions. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0966</doc-id>
        <title>Host groups: A multicast extension to the Internet Protocol</title>
        <author>
            <name>S.E. Deering</name>
        </author>
        <author>
            <name>D.R. Cheriton</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59469</char-count>
            <page-count>27</page-count>
        </format>
        <abstract>This RFC defines a model of service for Internet multicasting and proposes an extension to the Internet Protocol (IP) to support such a multicast service. Discussion and suggestions for improvements are requested. See RFC-988. </abstract>
        <obsoleted-by>
            <doc-id>RFC0988</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0967</doc-id>
        <title>All victims together</title>
        <author>
            <name>M.A. Padlipsky</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4706</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>This RFC proposes a new set of RFCs on how the networking code is integrated with various operating systems. It appears that this topic has not received enough exposure in the literature. Comments and suggestions are encouraged. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0968</doc-id>
        <title>Twas the night before start-up</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2459</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>This memo discusses problems that arise and debugging techniques used in bringing a new network into operation. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0969</doc-id>
        <title>NETBLT: A bulk data transfer protocol</title>
        <author>
            <name>D.D. Clark</name>
        </author>
        <author>
            <name>M.L. Lambert</name>
        </author>
        <author>
            <name>L. Zhang</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40040</char-count>
            <page-count>15</page-count>
        </format>
        <abstract>This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is a preliminary discussion of the Network Block Transfer (NETBLT) protocol. NETBLT is intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is structured to provide maximum throughput over a wide variety of networks. This description is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. See RFC-998. </abstract>
        <obsoleted-by>
            <doc-id>RFC0998</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0970</doc-id>
        <title>On packet switches with infinite storage</title>
        <author>
            <name>J. Nagle</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1985</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35316</char-count>
            <page-count>9</page-count>
        </format>
        <abstract>The purpose of this RFC is to focus discussion on a particular problem in the ARPA-Internet and possible methods of solution. Most prior work on congestion in datagram systems focuses on buffer management. In this memo the case of a packet switch with infinite storage is considered. Such a packet switch can never run out of buffers. It can, however, still become congested. The meaning of congestion in an infinite-storage system is explored. An unexpected result is found that shows a datagram network with infinite storage, first-in-first-out queuing, at least two packet switches, and a finite packet lifetime will, under overload, drop all packets. By attacking the problem of congestion for the infinite-storage case, new solutions applicable to switches with finite storage may be found. No proposed solutions this document are intended as standards for the ARPA-Internet at this time. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0971</doc-id>
        <title>Survey of data representation standards</title>
        <author>
            <name>A.L. DeSchon</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22883</char-count>
            <page-count>9</page-count>
        </format>
        <abstract>This RFC is a comparison of several data representation standards that are currently in use. The standards discussed are the CCITT X.409 recommendation, the NBS Computer Based Message System (CBMS) standard, DARPA Multimedia Mail system, the Courier remote procedure call protocol, and the SUN Remote Procedure Call package. No proposals in this document are intended as standards for the ARPA-Internet at this time. Rather, it is hoped that a general consensus will emerge as to the appropriate approach to a data representation standard, leading eventually to the adoption of an ARPA-Internet standard. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0972</doc-id>
        <title>Password Generator Protocol</title>
        <author>
            <name>F.J. Wancho</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3890</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>This RFC specifies a standard for the ARPA Internet community. The Password Generator Service (PWDGEN) provides a set of six randomly generated eight-character "words" with a reasonable level of pronounceability, using a multi-level algorithm. Hosts on the ARPA Internet that choose to implement a password generator service are expected to adopt and implement this standard. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0973</doc-id>
        <title>Domain system changes and observations</title>
        <author>
            <name>P.V. Mockapetris</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22364</char-count>
            <page-count>10</page-count>
        </format>
        <abstract>This RFC documents updates to Domain Name System specifications RFC-882 and RFC-883, suggests some operational guidelines, and discusses some experiences and problem areas in the present system. </abstract>
        <obsoleted-by>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0882</doc-id>
            <doc-id>RFC0883</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0974</doc-id>
        <title>Mail routing and the domain system</title>
        <author>
            <name>C. Partridge</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18581</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>DNS-MX</kw>
        </keywords>
        <abstract>This RFC presents a description of how mail systems on the Internet are expected to route messages based on information from the domain system. This involves a discussion of how mailers interpret MX RRs, which are used for message routing. </abstract>
        <obsoleted-by>
            <doc-id>RFC2821</doc-id>
        </obsoleted-by>
        <is-also>
            <doc-id>STD0010</doc-id>
        </is-also>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0975</doc-id>
        <title>Autonomous confederations</title>
        <author>
            <name>D.L. Mills</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28010</char-count>
            <page-count>10</page-count>
        </format>
        <abstract>This RFC proposes enhancements to the Exterior Gateway Protocol (EGP) to support a simple, multiple-level routing capability while preserving the robustness features of the current EGP model. The enhancements generalize the concept of core system to include multiple communities of autonomous systems, called autonomous confederations. Discussion and suggestions for improvement are requested. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0976</doc-id>
        <title>UUCP mail interchange format standard</title>
        <author>
            <name>M.R. Horton</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26814</char-count>
            <page-count>12</page-count>
        </format>
        <abstract>This document defines the standard format for the transmission of mail messages between computers in the UUCP Project. It does not however, address the format for storage of messages on one machine, nor the lower level transport mechanisms used to get the date from one machine to the next. It represents a standard for conformance by hosts in the UUCP zone. </abstract>
        <updated-by>
            <doc-id>RFC1137</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0977</doc-id>
        <title>Network News Transfer Protocol</title>
        <author>
            <name>B. Kantor</name>
        </author>
        <author>
            <name>P. Lapsley</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>55062</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>NNTP</kw>
        </keywords>
        <abstract>NNTP specifies a protocol for the distribution, inquiry, retrieval, and posting of news articles using a reliable stream-based transmission of news among the ARPA-Internet community. NNTP is designed so that news articles are stored in a central database allowing a subscriber to select only those items he wishes to read. Indexing, cross-referencing, and expiration of aged messages are also provided. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0978</doc-id>
        <title>Voice File Interchange Protocol (VFIP)</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <author>
            <name>R. Gillman</name>
        </author>
        <author>
            <name>W.A. Brackenridge</name>
        </author>
        <author>
            <name>A. Witkowski</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9223</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>The purpose of the Voice File Interchange Protocol (VFIP) is to permit the interchange of various types of speech files between different systems in the ARPA-Internet community. Suggestions for improvement are encouraged. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0979</doc-id>
        <title>PSN End-to-End functional specification</title>
        <author>
            <name>A.G. Malis</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39472</char-count>
            <page-count>15</page-count>
        </format>
        <abstract>This memo is an updated version of BBN Report 5775, "End-to-End Functional Specification and describes important changes to the functionality of the interface between a Host and the PSN, and should be carefully reviewed by anyone involved in supporting a host on either the ARPANET or MILNET". The new End-to-End protocol (EE) is being developed in order to correct a number of deficiencies in the old EE, to improve its performance and overall throughput, and to better equip the Packet Switch Node (PSN, also known as the IMP) to support its current and anticipated host population. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0980</doc-id>
        <title>Protocol document order information</title>
        <author>
            <name>O.J. Jacobsen</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24416</char-count>
            <page-count>12</page-count>
        </format>
        <abstract>This RFC indicates how to obtain various protocol documents used in the DARPA research community. Included is an overview of the new 1985 DDN Protocol Handbook and available sources for obtaining related documents (such as DOD, ISO, and CCITT). </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0981</doc-id>
        <title>Experimental multiple-path routing algorithm</title>
        <author>
            <name>D.L. Mills</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59069</char-count>
            <page-count>22</page-count>
        </format>
        <abstract>This document introduces wiretap algorithms, a class of experimental, multiple routing algorithms that compute quasi-optimum routes for stations sharing a packet-radio broadcast channel. The primary route (a minimum-distance path), and additional paths ordered by distance, which serve as alternate routes should the primary route fail, are computed. This prototype is presented as an example of a class of routing algorithms and data-base management techniques that may find wider application in the Internet community. Discussions and suggestions for improvements are welcomed. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0982</doc-id>
        <title>Guidelines for the specification of the structure of the Domain Specific Part (DSP) of the ISO standard NSAP address</title>
        <author>
            <name>H.W. Braun</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22595</char-count>
            <page-count>11</page-count>
        </format>
        <abstract>This RFC is a draft working document of the ANSI "Guidelines for the Specification of the Structure of the Domain Specific Part (DSP) of the ISO Standard NSAP Address". It provides guidance to private address administration authorities on preferred formats and semantics for the Domain Specific Part (DSP) of an NSAP address. This RFC specifies the way in which the DSP may be constructed so as to facilitate efficient address assignment. This RFC is for informational purposes only and its distribution is unlimited and does not specify a standard of the ARPA-Internet. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0983</doc-id>
        <title>ISO transport arrives on top of the TCP</title>
        <author>
            <name>D.E. Cass</name>
        </author>
        <author>
            <name>M.T. Rose</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59819</char-count>
            <page-count>27</page-count>
        </format>
        <abstract>This memo describes a proposed protocol standard for the ARPA Internet community. The CCITT and the ISO have defined various session, presentation, and application recommendations which have been adopted by the international community and numerous vendors. To the largest extent possible, it is desirable to offer these higher level services directly in the ARPA Internet, without disrupting existing facilities. This permits users to develop expertise with ISO and CCITT applications which previously were not available in the ARPA Internet. The intention is that hosts in the ARPA-Internet that choose to implement ISO TSAP services on top of the TCP be expected to adopt and implement this standard. Suggestions for improvement are encouraged. </abstract>
        <obsoleted-by>
            <doc-id>RFC1006</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0984</doc-id>
        <title>PCMAIL: A distributed mail system for personal computers</title>
        <author>
            <name>D.D. Clark</name>
        </author>
        <author>
            <name>M.L. Lambert</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>69333</char-count>
            <page-count>31</page-count>
        </format>
        <abstract>This document is a preliminary discussion of the design of a personal-computer-based distributed mail system. Pcmail is a distributed mail system that provides mail service to an arbitrary number of users, each of which owns one or more personal computers (PCs). The system is divided into two halves. The first consists of a single entity called the "repository". The repository is a storage center for incoming mail. Mail for a Pcmail user can arrive externally from the Internet or internally from other repository users. The repository also maintains a stable copy of each user's mail state. The repository is therefore typically a computer with a large amount of disk storage. It is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. See RFC-993. </abstract>
        <obsoleted-by>
            <doc-id>RFC0993</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0985</doc-id>
        <title>Requirements for Internet gateways - draft</title>
        <author>
            <name>National Science Foundation</name>
        </author>
        <author>
            <name>Network Technical Advisory Group</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59221</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>Requirements</kw>
            <kw>Internet</kw>
            <kw>gateways</kw>
        </keywords>
        <abstract>This RFC summarizes the requirements for gateways to be used on networks supporting the DARPA Internet protocols. While it applies specifically to National Science Foundation research programs, the requirements are stated in a general context and are believed applicable throughout the Internet community. The purpose of this document is to present guidance for vendors offering products that might be used or adapted for use in an Internet application. It enumerates the protocols required and gives references to RFCs and other documents describing the current specification. </abstract>
        <notes>Draft.</notes>
        <obsoleted-by>
            <doc-id>RFC1009</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0986</doc-id>
        <title>Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol </title>
        <author>
            <name>R.W. Callon</name>
        </author>
        <author>
            <name>H.W. Braun</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13950</char-count>
            <page-count>7</page-count>
        </format>
        <abstract>This RFC suggests a method to allow the existing IP addressing, including the IP protocol field, to be used for the ISO Connectionless Network Protocol (CLNP). This is a draft solution to one of the problems inherent in the use of "ISO-grams" in the DOD Internet. Related issues will be discussed in subsequent RFCs. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. </abstract>
        <notes>Working draft.  </notes>
        <obsoleted-by>
            <doc-id>RFC1069</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0987</doc-id>
        <title>Mapping between X.400 and RFC 822</title>
        <author>
            <name>S.E. Kille</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>127540</char-count>
            <page-count>69</page-count>
        </format>
        <abstract>The X.400 series protocols have been defined by CCITT to provide an Interpersonal Messaging Service (IPMS), making use of a store and forward Message Transfer Service. It is expected that this standard will be implemented very widely. This document describes a set of mappings which will enable interworking between systems operating the X.400 protocols and systems using RFC-822 mail protocol or protocols derived from RFC-822. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. </abstract>
        <obsoleted-by>
            <doc-id>RFC1327</doc-id>
            <doc-id>RFC2156</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC1026</doc-id>
            <doc-id>RFC1138</doc-id>
            <doc-id>RFC1148</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0988</doc-id>
        <title>Host extensions for IP multicasting</title>
        <author>
            <name>S.E. Deering</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45220</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>multicast</kw>
            <kw>Internet</kw>
        </keywords>
        <abstract>This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support internetwork multicasting. This specification supersedes that given in RFC-966, and constitutes a proposed protocol standard for IP multicasting in the ARPA-Internet. The reader is directed to RFC-966 for a discussion of the motivation and rationale behind the multicasting extension specified here. </abstract>
        <obsoletes>
            <doc-id>RFC0966</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1054</doc-id>
            <doc-id>RFC1112</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0989</doc-id>
        <title>Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures</title>
        <author>
            <name>J. Linn</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63934</char-count>
            <page-count>23</page-count>
        </format>
        <abstract>This RFC suggests a proposed protocol for the Internet community and requests discussion and suggestions for improvements. This RFC is the outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. This RFC defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. It is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or authentication is anticipated. </abstract>
        <obsoleted-by>
            <doc-id>RFC1040</doc-id>
            <doc-id>RFC1113</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0990</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>174784</char-count>
            <page-count>75</page-count>
        </format>
        <abstract>This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-997. Obsoletes RFC-960, 943, 923 and 900. </abstract>
        <obsoletes>
            <doc-id>RFC0960</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1010</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC0997</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0991</doc-id>
        <title>Official ARPA-Internet protocols</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>65205</char-count>
            <page-count>46</page-count>
        </format>
        <abstract>This RFC identifies the documents specifying the official protocols used in the Internet. Comments indicate any revisions or changes planned. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. Obsoletes RFC-961, 944 and 924. </abstract>
        <obsoletes>
            <doc-id>RFC0961</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1011</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0992</doc-id>
        <title>On communication support for fault tolerant process groups</title>
        <author>
            <name>K.P. Birman</name>
        </author>
        <author>
            <name>T.A. Joseph</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52313</char-count>
            <page-count>18</page-count>
        </format>
        <abstract>This memo describes a collection of multicast communication primitives integrated with a mechanism for handling process failure and recovery. These primitives facilitate the implementation of fault-tolerant process groups, which can be used to provide distributed services in an environment subject to non-malicious crash failures. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0993</doc-id>
        <title>PCMAIL: A distributed mail system for personal computers</title>
        <author>
            <name>D.D. Clark</name>
        </author>
        <author>
            <name>M.L. Lambert</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>71725</char-count>
            <page-count>28</page-count>
        </format>
        <abstract>This document is a discussion of the Pcmail workstation-based distributed mail system. It is a revision of the design published in NIC RFC-984. The revision is based on discussion and comment fromm a variety of sources, as well as further research into the design of interactive Pcmail clients and the use of client code on machines other than IBM PCs. As this design may change, implementation of this document is not advised. Obsoletes RFC-984. </abstract>
        <obsoletes>
            <doc-id>RFC0984</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1056</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0994</doc-id>
        <title>Final text of DIS 8473, Protocol for Providing the Connectionless-mode Network Service</title>
        <author>
            <name>International Organization for Standardization</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>129006</char-count>
            <page-count>52</page-count>
        </format>
        <abstract>This Protocol Standard is one of a set of International Standards produced to facilitate the interconnection of open systems. The set of standards covers the services and protocols required to achieve such interconnection. This Protocol Standard is positioned with respect to other related standards by the layers defined in the Reference Model for Open Systems Interconnection (ISO 7498). In particular, it is a protocol of the Network Layer. This Protocol may be used between network-entities in end systems or in Network Layer relay systems (or both). It provides the Connectionless-mode Network Service as defined in Addendum 1 to the Network Service Definition Covering Connectionless-mode Transmission (ISO 8348/AD1). </abstract>
        <obsoletes>
            <doc-id>RFC0926</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0995</doc-id>
        <title>End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473</title>
        <author>
            <name>International Organization for Standardization</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1986</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>94069</char-count>
            <page-count>41</page-count>
        </format>
        <abstract>This Protocol is one of a set of International Standards produced to facilitate the interconnection of open systems. The set of standards covers the services and protocols required to achieve such interconnection. This Protocol is positioned with respect to other related standards by the layers defined in the Reference Model for Open Systems Interconnection (ISO 7498) and by the structure defined in the Internal Organization of the Network Layer (DIS 8648). In particular, it is a protocol of the Network Layer. This Protocol permits End Systems and Intermediate Systems to exchange configuration and routing information to facilitate the operation of the routing and relaying functions of the Network Layer. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0996</doc-id>
        <title>Statistics server</title>
        <author>
            <name>D.L. Mills</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6127</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>STATSRV</kw>
        </keywords>
        <abstract>This RFC specifies a standard for the ARPA Internet community. Hosts and gateways on the DARPA Internet that choose to implement a remote statistics monitoring facility may use this protocol to send statistics data upon request to a monitoring center or debugging host. </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0997</doc-id>
        <title>Internet numbers</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>123919</char-count>
            <page-count>42</page-count>
        </format>
        <abstract>This memo is an official status report on the network numbers used in the Internet community. As of 1-Mar-87 the Network Information Center (NIC) at SRI International has assumed responsibility for assignment of Network Numbers and Autonomous System Numbers. This RFC documents the current assignments of these numbers at the time of this transfer of responsibility. Obsoletes RFC-990, 960, 943, 923 and 900. </abstract>
        <obsoleted-by>
            <doc-id>RFC1020</doc-id>
            <doc-id>RFC1117</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0990</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0998</doc-id>
        <title>NETBLT: A bulk data transfer protocol</title>
        <author>
            <name>D.D. Clark</name>
        </author>
        <author>
            <name>M.L. Lambert</name>
        </author>
        <author>
            <name>L. Zhang</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>57147</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>NETBLT</kw>
        </keywords>
        <abstract>This document is a description of, and a specification for, the NETBLT protocol. It is a revision of the specification published in RFC-969. NETBLT (NETwork BLock Transfer) is a transport level protocol intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is designed to provide maximum throughput over a wide variety of networks. Although NETBLT currently runs on top of the Internet Protocol (IP), it should be able to operate on top of any datagram protocol similar in function to IP. This document is published for discussion and comment, and does not constitute a standard. The proposal may change and certain parts of the protocol have not yet been specified; implementation of this document is therefore not advised. Obsoletes RFC-969. </abstract>
        <obsoletes>
            <doc-id>RFC0969</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC0999</doc-id>
        <title>Requests For Comments summary notes: 900-999</title>
        <author>
            <name>A. Westine</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>62877</char-count>
            <page-count>22</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC0160</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1000</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1000</doc-id>
        <title>Request For Comments reference guide</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>323960</char-count>
            <page-count>149</page-count>
        </format>
        <abstract>This RFC Reference Guide is intended to provide a historical account by categorizing and summarizing of the Request for Comments numbers 1 through 999 issued between the years 1969-1987. These documents have been crossed referenced to indicate which RFCs are current, obsolete, or revised. </abstract>
        <obsoletes>
            <doc-id>RFC0999</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1001</doc-id>
        <title>Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods</title>
        <author>
            <name>NetBIOS Working Group in the Defense Advanced Research Projects Agency</name>
        </author>
        <author>
            <name>Internet Activities Board</name>
        </author>
        <author>
            <name>End-to-End Services Task Force</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>158437</char-count>
            <page-count>68</page-count>
        </format>
        <keywords>
            <kw>NETBIOS</kw>
        </keywords>
        <abstract>This RFC defines a proposed standard protocol to support NetBIOS services in a TCP/IP environment. Both local network and internet operation are supported. Various node types are defined to accommodate local and internet topologies and to allow operation with or without the use of IP broadcast. This RFC describes the NetBIOS-over-TCP protocols in a general manner, emphasizing the underlying ideas and techniques. Detailed specifications are found in a companion RFC, "Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications". </abstract>
        <is-also>
            <doc-id>STD0019</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1002</doc-id>
        <title>Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications</title>
        <author>
            <name>NetBIOS Working Group in the Defense Advanced Research Projects Agency</name>
        </author>
        <author>
            <name>Internet Activities Board</name>
        </author>
        <author>
            <name>End-to-End Services Task Force</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>170262</char-count>
            <page-count>84</page-count>
        </format>
        <keywords>
            <kw>NETBIOS</kw>
        </keywords>
        <abstract>This RFC defines a proposed standard protocol to support NetBIOS services in a TCP/IP environment. Both local network and internet operation are supported. Various node types are defined to accommodate local and internet topologies and to allow operation with or without the use of IP broadcast. This RFC gives the detailed specifications of the netBIOS-over-TCP packets, protocols, and defined constants and variables. A more general overview is found in a companion RFC, "Protocol Standard For NetBIOS Service on TCP/UDP Transport: Concepts and Methods". </abstract>
        <is-also>
            <doc-id>STD0019</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1003</doc-id>
        <title>Issues in defining an equations representation standard</title>
        <author>
            <name>A.R. Katz</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19816</char-count>
            <page-count>7</page-count>
        </format>
        <abstract>This memo is intended to identify and explore issues in defining a standard for the exchange of mathematical equations. No attempt is made at a complete definition and more questions are asked than are answered. Questions about the user interface are only addressed to the extent that they affect interchange issues. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1004</doc-id>
        <title>Distributed-protocol authentication scheme</title>
        <author>
            <name>D.L. Mills</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21402</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>COOKIE-JAR</kw>
        </keywords>
        <abstract>The purpose of this RFC is to focus discussion on authentication problems in the Internet and possible methods of solution. The proposed solutions this document are not intended as standards for the Internet at this time. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to authentication problems, leading eventually to the adoption of standards. This document suggests mediated access-control and authentication procedures suitable for those cases when an association is to be set up between users belonging to different trust environments. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1005</doc-id>
        <title>ARPANET AHIP-E Host Access Protocol (enhanced AHIP)</title>
        <author>
            <name>A. Khanna</name>
        </author>
        <author>
            <name>A.G. Malis</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>69957</char-count>
            <page-count>34</page-count>
        </format>
        <abstract>This RFC is a proposed specification for the encoding of Class A IP addresses for use on ARPANET-style networks such as the Milnet and Arpanet, and for enhancements to the ARPANET AHIP Host Access Protocol (AHIP; formerly known as 1822). These enhancements increase the size of the PSN field, allow ARPANET hosts to use logical names to address each other, allow for the communication of type-of-service information from the host to the PSN and enable the PSN to provide congestion feedback to the host on a connection basis. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1006</doc-id>
        <title>ISO transport services on top of the TCP: Version 3</title>
        <author>
            <name>M.T. Rose</name>
        </author>
        <author>
            <name>D.E. Cass</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31935</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>TP-TCP</kw>
        </keywords>
        <abstract>This memo specifies a standard for the Internet community. Hosts on the Internet that choose to implement ISO transport services on top of the TCP are expected to adopt and implement this standard. TCP port 102 is reserved for hosts which implement this standard. This memo specifies version 3 of the protocol and supersedes RFC-983. Changes between the protocol is described in RFC-983 and this memo are minor, but unfortunately incompatible. </abstract>
        <obsoletes>
            <doc-id>RFC0983</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC2126</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0035</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1007</doc-id>
        <title>Military supplement to the ISO Transport Protocol</title>
        <author>
            <name>W. McCoy</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51280</char-count>
            <page-count>23</page-count>
        </format>
        <abstract>This document supplements the Transport Service and Protocol of the International Standards Organization (ISO), IS 8072 and IS 8073, respectively, and their formal descriptions by providing conventions, option selections and parameter values. This RFC is being distributed to members of the Internet community in order to solicit comments on the Draft Military Supplement. While this document may not be directly relevant to the research problems of the Internet, it may be of some interest to a number of researchers and implementors. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1008</doc-id>
        <title>Implementation guide for the ISO Transport Protocol</title>
        <author>
            <name>W. McCoy</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>204664</char-count>
            <page-count>73</page-count>
        </format>
        <abstract>This RFC is being distributed to members of the Internet community in order to solicit comments on the Implementors Guide. While this document may not be directly relevant to the research problems of the Internet, it may be of some interest to a number of researchers and implementors. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1009</doc-id>
        <title>Requirements for Internet gateways</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>128173</char-count>
            <page-count>54</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This RFC summarizes the requirements for gateways to be used between networks supporting the Internet protocols. This document is a formal statement of the requirements to be met by gateways used in the Internet system. As such, it is an official specification for the Internet community. </abstract>
        <obsoletes>
            <doc-id>RFC0985</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1812</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1010</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>78179</char-count>
            <page-count>44</page-count>
        </format>
        <abstract>This memo is an official status report on the numbers used in protocols in the Internet community. It documents the currently assigned values from several series of numbers including link, socket, port, and protocol, used in network protocol implementations. </abstract>
        <obsoletes>
            <doc-id>RFC0990</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1060</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1011</doc-id>
        <title>Official Internet protocols</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>74593</char-count>
            <page-count>52</page-count>
        </format>
        <abstract>This memo is an official status report on the protocols used in the Internet community. It identifies the documents specifying the official protocols used in the Internet. Comments indicate any revisions or changes planned. </abstract>
        <obsoletes>
            <doc-id>RFC0991</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1012</doc-id>
        <title>Bibliography of Request For Comments 1 through 999</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>129194</char-count>
            <page-count>64</page-count>
        </format>
        <abstract>This RFC is a reference guide for the Internet community which provides a bibliographic summary of the Request for Comments numbers 1 through 999 issued between the years 1969-1987. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1013</doc-id>
        <title>X Window System Protocol, version 11: Alpha update April 1987</title>
        <author>
            <name>R.W. Scheifler</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>244905</char-count>
            <page-count>101</page-count>
        </format>
        <abstract>This RFC is distributed to the Internet community for information only. It does not establish an Internet standard. The X window system has been widely reviewed and tested. The Internet community is encouraged to experiment with it. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1014</doc-id>
        <title>XDR: External Data Representation standard</title>
        <author>
            <name>Sun Microsystems</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39316</char-count>
            <page-count>20</page-count>
        </format>
        <abstract>XDR is a standard for the description and encoding of data. It is useful for transferring data between different computer architectures. XDR fits into ISO presentation layer, and is roughly analogous in purpose to X.409, ISO Abstract Syntax Notation. The major difference between these two is that XDR uses implicit typing, while X.409 uses explicit typing. This RFC is distributed for information only, it does not establish a Internet standard. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1015</doc-id>
        <title>Implementation plan for interagency research Internet</title>
        <author>
            <name>B.M. Leiner</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63159</char-count>
            <page-count>24</page-count>
        </format>
        <abstract>This RFC proposes an Interagency Research Internet as the natural outgrowth of the current Internet. This is an "idea paper" and discussion is strongly encouraged. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1016</doc-id>
        <title>Something a host could do with source quench: The Source Quench Introduced Delay (SQuID)</title>
        <author>
            <name>W. Prue</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47922</char-count>
            <page-count>18</page-count>
        </format>
        <abstract>The memo is intended to explore the issue of what a host could do with a source quench. The proposal is for each source host IP module to introduce some delay between datagrams sent to the same destination host. This is a "crazy idea paper" and discussion is essential. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1017</doc-id>
        <title>Network requirements for scientific research: Internet task force on scientific computing</title>
        <author>
            <name>B.M. Leiner</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49512</char-count>
            <page-count>19</page-count>
        </format>
        <abstract>This RFC identifies the requirements on communication networks for supporting scientific research. It proposes some specific areas for near term work, as well as some long term goals. This is an "idea" paper and discussion is strongly encouraged. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1018</doc-id>
        <title>Some comments on SQuID</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7931</char-count>
            <page-count>3</page-count>
        </format>
        <abstract>This memo is a discussion of some of the ideas expressed in RFC-1016 on Source Quench. This memo introduces the distinction of the cause of congestion in a gateway between the effects of "Funneling" and Mismatch". It is offered in the same spirit as RFC-1016; to stimulate discussion. The opinions offered are personal, not corporate, opinions. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1019</doc-id>
        <title>Report of the Workshop on Environments for Computational Mathematics</title>
        <author>
            <name>D. Arnon</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21151</char-count>
            <page-count>8</page-count>
        </format>
        <abstract>This memo is a report on the discussion of the representation of equations in a workshop at the ACM SIGGRAPH Conference held in Anaheim, California on 30 July 1987. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1020</doc-id>
        <title>Internet numbers</title>
        <author>
            <name>S. Romano</name>
        </author>
        <author>
            <name>M.K. Stahl</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>146864</char-count>
            <page-count>51</page-count>
        </format>
        <abstract>This RFC is a list of the Assigned IP Network Numbers and EGP Autonomous System Numbers. This RFC obsoletes RFC-997. </abstract>
        <obsoletes>
            <doc-id>RFC0997</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1062</doc-id>
            <doc-id>RFC1117</doc-id>
            <doc-id>RFC1166</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1021</doc-id>
        <title>High-level Entity Management System (HEMS)</title>
        <author>
            <name>C. Partridge</name>
        </author>
        <author>
            <name>G. Trewitt</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12993</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>HEMS</kw>
        </keywords>
        <abstract>This memo provides a general overview of the High-level Entity management system (HEMS). This system is experimental, and is currently being tested in portions of the Internet. </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1022</doc-id>
        <title>High-level Entity Management Protocol (HEMP)</title>
        <author>
            <name>C. Partridge</name>
        </author>
        <author>
            <name>G. Trewitt</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25348</char-count>
            <page-count>12</page-count>
        </format>
        <abstract>This memo presents an application protocol for managing network entities such as hosts, gateways, and front end machines. This protocol is a component of the High-level Entity Management System HEMS), described is RFC-1021. This memo also assumes a knowledge of the ISO data encoding standard, ASN.1. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1023</doc-id>
        <title>HEMS monitoring and control language</title>
        <author>
            <name>G. Trewitt</name>
        </author>
        <author>
            <name>C. Partridge</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40992</char-count>
            <page-count>17</page-count>
        </format>
        <abstract>This RFC specifies the High-Level Entity Management System (HEMS) Monitoring and Control Language. This language defines the requests and replies used in HEMS. This memo assumes knowledge of the HEMS system described in RFC-1021, and of the ISO data encoding standard, ASN.1. </abstract>
        <obsoleted-by>
            <doc-id>RFC1076</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1024</doc-id>
        <title>HEMS variable definitions</title>
        <author>
            <name>C. Partridge</name>
        </author>
        <author>
            <name>G. Trewitt</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>126536</char-count>
            <page-count>74</page-count>
        </format>
        <abstract>This memo assigns instruction codes, defines object formats and object semantics for use with the High-Level Monitoring and Control Language, defined in RFC-1023. A general system has been described in previous memos (RFC-1021, RFC-1022). This system is called the High-Level Entity Management System (HEMS). This memo is provisional and the definitions are subject to change. Readers should confirm with the authors that they have the most recent version. This RFC assumes a working knowledge of the ISO data encoding standard, ASN.1, and a general understanding of the IP protocol suite. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1025</doc-id>
        <title>TCP and IP bake off</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11648</char-count>
            <page-count>6</page-count>
        </format>
        <abstract>This memo describes some of the procedures, scoring and tests used in the TCP and IP bake offs held in the early development of these protocols. These procedures and tests may still be of use in testing newly implemented TCP and IP modules. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1026</doc-id>
        <title>Addendum to RFC 987: (Mapping between X.400 and RFC-822)</title>
        <author>
            <name>S.E. Kille</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7117</char-count>
            <page-count>4</page-count>
        </format>
        <abstract>This memo suggest a proposed protocol for the Internet community, and request discussion and suggestions for improvements. </abstract>
        <obsoleted-by>
            <doc-id>RFC1327</doc-id>
            <doc-id>RFC2156</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0987</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC1138</doc-id>
            <doc-id>RFC1148</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1027</doc-id>
        <title>Using ARP to implement transparent subnet gateways</title>
        <author>
            <name>S. Carl-Mitchell</name>
        </author>
        <author>
            <name>J.S. Quarterman</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21297</char-count>
            <page-count>8</page-count>
        </format>
        <abstract>This RFC describes the use of the Address Resolution Protocol (ARP) by subnet gateways to permit hosts on the connected subnets to communicate without being aware of the existence of subnets, using the technique of "Proxy ARP". </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1028</doc-id>
        <title>Simple Gateway Monitoring Protocol</title>
        <author>
            <name>J. Davin</name>
        </author>
        <author>
            <name>J.D. Case</name>
        </author>
        <author>
            <name>M. Fedor</name>
        </author>
        <author>
            <name>M.L. Schoffstall</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>82440</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
            <kw>SGMP</kw>
        </keywords>
        <abstract>This memo defines a simple application-layer protocol by which management information for a gateway may be inspected or altered by remote users. This proposal is intended only as an interim response to immediate gateway monitoring needs. </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1029</doc-id>
        <title>More fault tolerant approach to address resolution for a Multi-LAN system of Ethernets</title>
        <author>
            <name>G. Parr</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44019</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>arp</kw>
        </keywords>
        <abstract>This memo discusses an extension to a Bridge Protocol to detect and disclose changes in heighbouring host address parameters in a Multi-Lan system of Ethernets. The problem is one which is appearing more and more regularly as the interconnected systems grow larger on Campuses and in Commercial Institutions. This RFC suggests a protocol enhancement for the Internet community, and requests discussion and suggestions for improvements. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1030</doc-id>
        <title>On testing the NETBLT Protocol over divers networks</title>
        <author>
            <name>M.L. Lambert</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40964</char-count>
            <page-count>16</page-count>
        </format>
        <abstract>This memo describes the results gathered from testing NETBLT over three networks of different bandwidths and round-trip delays. The results are not complete, but the information gathered so far has not been promising. The NETBLT protocol is specified in RFC-998; this document assumes an understanding of the specification as described in RFC-998. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1031</doc-id>
        <title>MILNET name domain transition</title>
        <author>
            <name>W.D. Lazear</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20137</char-count>
            <page-count>10</page-count>
        </format>
        <abstract>This RFC consolidates information necessary for the implementation of domain style names throughout the DDN/MILNET Internet community. The introduction of domain style names will impact all hosts in the DDN/MILNET Internet. This RFC is designed as an aid to implementors and administrators by providing: 1) an overview of the transition process from host tables to domains, 2) a timetable for the transition, and 3) references to documentation and software relating to the domain system. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1032</doc-id>
        <title>Domain administrators guide</title>
        <author>
            <name>M.K. Stahl</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29454</char-count>
            <page-count>14</page-count>
        </format>
        <abstract>Domains are administrative entities that provide decentralized management of host naming and addressing. The domain-naming system is distributed and hierarchical. This memo describes procedures for registering a domain with the Network Information Center (NIC) of Defense Data Network (DDN), and offers guidelines on the establishment and administration of a domain in accordance with the requirements specified in RFC-920. It is recommended that the guidelines described in this document be used by domain administrators in the establishment and control of second-level domains. The role of the domain administrator (DA) is that of coordinator, manager, and technician. If his domain is established at the second level or lower in the tree, the domain administrator must register by interacting with the management of the domain directly above this. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1033</doc-id>
        <title>Domain administrators operations guide</title>
        <author>
            <name>M. Lottor</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37263</char-count>
            <page-count>22</page-count>
        </format>
        <abstract>This RFC provides guidelines for domain administrators in operating a domain server and maintaining their portion of the hierarchical database. Familiarity with the domain system is assumed (see RFCs 1031, 1032, 1034, and 1035). </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1034</doc-id>
        <title>Domain names - concepts and facilities</title>
        <author>
            <name>P.V. Mockapetris</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>129180</char-count>
            <page-count>55</page-count>
        </format>
        <keywords>
            <kw>DOMAIN</kw>
        </keywords>
        <abstract>This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. </abstract>
        <obsoletes>
            <doc-id>RFC0973</doc-id>
            <doc-id>RFC0882</doc-id>
            <doc-id>RFC0883</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC1101</doc-id>
            <doc-id>RFC1183</doc-id>
            <doc-id>RFC1348</doc-id>
            <doc-id>RFC1876</doc-id>
            <doc-id>RFC1982</doc-id>
            <doc-id>RFC2065</doc-id>
            <doc-id>RFC2181</doc-id>
            <doc-id>RFC2308</doc-id>
            <doc-id>RFC2535</doc-id>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4035</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0013</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1035</doc-id>
        <title>Domain names - implementation and specification</title>
        <author>
            <name>P.V. Mockapetris</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>125626</char-count>
            <page-count>55</page-count>
        </format>
        <keywords>
            <kw>DOMAIN</kw>
        </keywords>
        <abstract>This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. </abstract>
        <obsoletes>
            <doc-id>RFC0973</doc-id>
            <doc-id>RFC0882</doc-id>
            <doc-id>RFC0883</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC1101</doc-id>
            <doc-id>RFC1183</doc-id>
            <doc-id>RFC1348</doc-id>
            <doc-id>RFC1876</doc-id>
            <doc-id>RFC1982</doc-id>
            <doc-id>RFC1995</doc-id>
            <doc-id>RFC1996</doc-id>
            <doc-id>RFC2065</doc-id>
            <doc-id>RFC2136</doc-id>
            <doc-id>RFC2181</doc-id>
            <doc-id>RFC2137</doc-id>
            <doc-id>RFC2308</doc-id>
            <doc-id>RFC2535</doc-id>
            <doc-id>RFC2845</doc-id>
            <doc-id>RFC3425</doc-id>
            <doc-id>RFC3658</doc-id>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4035</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0013</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1036</doc-id>
        <title>Standard for interchange of USENET messages</title>
        <author>
            <name>M.R. Horton</name>
        </author>
        <author>
            <name>R. Adams</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46891</char-count>
            <page-count>19</page-count>
        </format>
        <abstract>This RFC defines the standard format for the interchange of network News messages among USENET hosts. It updates and replaces RFC-850, reflecting version B2.11 of the News program. This memo is distributed as an RFC to make this information easily accessible to the Internet community. It does not specify an Internet standard. </abstract>
        <obsoletes>
            <doc-id>RFC0850</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1037</doc-id>
        <title>NFILE - a file access protocol</title>
        <author>
            <name>B. Greenberg</name>
        </author>
        <author>
            <name>S. Keene</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1987</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>197312</char-count>
            <page-count>86</page-count>
        </format>
        <keywords>
            <kw>NFILE</kw>
        </keywords>
        <abstract>This document includes a specification of the NFILE file access protocol and its underlying levels of protocol, the Token List Transport Layer and Byte Stream with Mark. The goal of this specification is to promote discussion of the ideas described here, and to encourage designers of future file protocols to take advantage of these ideas. A secondary goal is to make the specification available to sites that might benefit from implementing NFILE. </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1038</doc-id>
        <title>Draft revised IP security option</title>
        <author>
            <name>M. St. Johns</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15879</char-count>
            <page-count>7</page-count>
        </format>
        <abstract>This memo is a pre-publication draft of the revised Internet Protocol Security Option. This RFC reflects the version as approved by the Protocol Standards Steering group, and is provided for informational purposes only. The final version of this document will be available from Navy publications and should not differ from this document in any major fashion. This document will be published as a change to the MIL- STD 1777, "Internet Protocol". </abstract>
        <obsoleted-by>
            <doc-id>RFC1108</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1039</doc-id>
        <title>DoD statement on Open Systems Interconnection protocols</title>
        <author>
            <name>D. Latham</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6194</char-count>
            <page-count>3</page-count>
        </format>
        <abstract>This RFC reproduces a memorandum issued on 2-JUL-87 from the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASDC31) to the Director of the Defense Communications Agency (DCA). This memo is distributed for information only. </abstract>
        <obsoletes>
            <doc-id>RFC0945</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1040</doc-id>
        <title>Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures</title>
        <author>
            <name>J. Linn</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>76276</char-count>
            <page-count>29</page-count>
        </format>
        <abstract>This RFC is the Outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. This memo defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. Detailed key management mechanisms to support these procedures will be defined in a subsequent RFC. As a goal of this initial phase, it is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or integrity check computation is anticipated. </abstract>
        <obsoletes>
            <doc-id>RFC0989</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1113</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1041</doc-id>
        <title>Telnet 3270 regime option</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11608</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>TOPT-3270</kw>
        </keywords>
        <abstract>This RFC specifies a proposed standard for the Internet community. Hosts on the Internet that want to support 3270 data stream within the Telnet protocol, are expected to adopt and implement this standard. </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1042</doc-id>
        <title>Standard for the transmission of IP datagrams over IEEE 802 networks</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34359</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>IP-IEEE</kw>
        </keywords>
        <abstract>This RFC specifies a standard method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on IEEE 802 Networks to allow compatible and interoperable implementations. This RFC specifies a protocol standard for the Internet community. </abstract>
        <obsoletes>
            <doc-id>RFC0948</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0043</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1043</doc-id>
        <title>Telnet Data Entry Terminal option: DODIIS implementation</title>
        <author>
            <name>A. Yasuda</name>
        </author>
        <author>
            <name>T. Thompson</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59478</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>TOPT-DATA</kw>
        </keywords>
        <abstract>This RFC suggests a proposed protocol on the TELNET Data Entry Terminal (DET) Option - DODIIS Implementation for the Internet community. It is intended that this specification be capatible with the specification of DET Option in RFC-732. Discussion and suggests for improvements are encouraged. </abstract>
        <updates>
            <doc-id>RFC0732</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1044</doc-id>
        <title>Internet Protocol on Network System's HYPERchannel: Protocol specification</title>
        <author>
            <name>K. Hardwick</name>
        </author>
        <author>
            <name>J. Lekashman</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>103241</char-count>
            <page-count>43</page-count>
        </format>
        <keywords>
            <kw>IP-HC</kw>
        </keywords>
        <abstract>This memo intends to provide a complete discussion of the protocols and techniques used to embed DoD standard Internet Protocol datagrams (and its associated higher level protocols) on Network Systems Corporation's HYPERchannel equipment. This document is directed toward network planners and implementors who are already familiar with the TCP/IP protocol suite and the techniques used to carry TCP/IP traffic on common networks such as the DDN or the Ethernet. No great familiarity with NSC products is assumed; an appendix is devoted to a review of NSC technologies and protocols. </abstract>
        <is-also>
            <doc-id>STD0045</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1045</doc-id>
        <title>VMTP: Versatile Message Transaction Protocol: Protocol specification</title>
        <author>
            <name>D.R. Cheriton</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>272058</char-count>
            <page-count>128</page-count>
        </format>
        <keywords>
            <kw>VMTP</kw>
        </keywords>
        <abstract>This memo specifies the Versatile Message Transaction Protocol (VMTP) [Version 0.7 of 19-Feb-88], a transport protocol specifically designed to support the transaction model of communication, as exemplified by remote procedure call (RPC). The full function of VMTP, including support for security, real-time, asynchronous message exchanges, streaming, multicast and idempotency, provides a rich selection to the VMTP user level. Subsettability allows the VMTP module for particular clients and servers to be specialized and simplified to the services actually required. Examples of such simple clients and servers include PROM network bootload programs, network boot servers, data sensors and simple controllers, to mention but a few examples. This RFC describes a protocol proposed as a standard for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1046</doc-id>
        <title>Queuing algorithm to provide type-of-service for IP links</title>
        <author>
            <name>W. Prue</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30106</char-count>
            <page-count>11</page-count>
        </format>
        <abstract>This memo is intended to explore how Type-of-Service might be implemented in the Internet. The proposal describes a method of queuing which can provide the different classes of service. The technique also prohibits one class of service from consuming excessive resources or excluding other classes of service. This is an "idea paper" and discussion is strongly encouraged. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1047</doc-id>
        <title>Duplicate messages and SMTP</title>
        <author>
            <name>C. Partridge</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5888</char-count>
            <page-count>3</page-count>
        </format>
        <abstract>An examination of a synchronization problem in the Simple Mail Transfer Protocol (SMTP) is presented. This synchronization problem can cause a message to be delivered multiple times. A method for avoiding this problem is suggested. Nodding familiarity with the SMTP specification, RFC-821, is required. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1048</doc-id>
        <title>BOOTP vendor information extensions</title>
        <author>
            <name>P.A. Prindeville</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15423</char-count>
            <page-count>7</page-count>
        </format>
        <abstract>This memo proposes an addition to the Bootstrap Protocol (BOOTP). Comments and suggestions for improvements are sought. </abstract>
        <obsoleted-by>
            <doc-id>RFC1084</doc-id>
            <doc-id>RFC1395</doc-id>
            <doc-id>RFC1497</doc-id>
            <doc-id>RFC1533</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1049</doc-id>
        <title>Content-type header field for Internet messages</title>
        <author>
            <name>M.A. Sirbu</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18923</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>CONTENT</kw>
        </keywords>
        <abstract>This memo suggests proposed additions to the Internet Mail Protocol, RFC-822, for the Internet community, and requests discussion and suggestions for improvements. </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1050</doc-id>
        <title>RPC: Remote Procedure Call Protocol specification</title>
        <author>
            <name>Sun Microsystems</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51540</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>SUN-RPC</kw>
        </keywords>
        <abstract>This memo specifies a message protocol used in implementing Sun's Remote Procedure Call (RPC) package. This RFC describes a standard that Sun Microsystems and others are using and is one they wish to propose for the Internet's consideration. It is not an Internet standard at this time. </abstract>
        <obsoleted-by>
            <doc-id>RFC1057</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1051</doc-id>
        <title>Standard for the transmission of IP datagrams and ARP packets over ARCNET networks</title>
        <author>
            <name>P.A. Prindeville</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7779</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This memo specifies a standard method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams on an ARCNET. This RFC is a standard protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC1201</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1052</doc-id>
        <title>IAB recommendations for the development of Internet network management standards</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30569</char-count>
            <page-count>14</page-count>
        </format>
        <abstract>This RFC is intended to convey to the Internet community and other interested parties the recommendations of the Internet Activities Board (IAB) for the development of network management protocols for use in the TCP/IP environment. This memo does NOT, in and of itself, define or propose an Official Internet Protocol. It does reflect, however, the policy of the IAB with respect to further network management development in the short and long term. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1053</doc-id>
        <title>Telnet X.3 PAD option</title>
        <author>
            <name>S. Levy</name>
        </author>
        <author>
            <name>T. Jacobson</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48952</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>TOPT-X.3</kw>
        </keywords>
        <abstract>This RFC proposes a new option to Telnet for the Internet community, and requests discussion and suggestions for improvements. </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1054</doc-id>
        <title>Host extensions for IP multicasting</title>
        <author>
            <name>S.E. Deering</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45465</char-count>
            <page-count>19</page-count>
        </format>
        <abstract>This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. IP multicasting is the transmission of an IP datagram to a "host group", a set hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same "best-efforts" reliability as regular unicast IP datagrams. It is proposed as a standard for IP multicasting in the Internet. This specification is a major revision of RFC-988. </abstract>
        <obsoletes>
            <doc-id>RFC0988</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1112</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1055</doc-id>
        <title>Nonstandard for transmission of IP datagrams over serial lines: SLIP</title>
        <author>
            <name>J.L. Romkey</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12911</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>IP-SLIP</kw>
        </keywords>
        <abstract>The TCP/IP protocol family runs over a variety of network media: IEEE 802.3 (ethernet) and 802.5 (token ring) LAN's, X.25 lines, satellite links, and serial lines. There are standard encapsulations for IP packets defined for many of these networks, but there is no standard for serial lines. SLIP, Serial Line IP, is a currently a de facto standard, commonly used for point-to-point serial connections running TCP/IP. It is not an Internet standard. </abstract>
        <is-also>
            <doc-id>STD0047</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1056</doc-id>
        <title>PCMAIL: A distributed mail system for personal computers</title>
        <author>
            <name>M.L. Lambert</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>85368</char-count>
            <page-count>38</page-count>
        </format>
        <keywords>
            <kw>PCMAIL</kw>
        </keywords>
        <abstract>This memo is a discussion of the Pcmail workstation based distributed mail system. It is identical to the discussion in RFC-993, save that a new, much simpler mail transport protocol is described. The new transport protocol is the result of continued research into ease of protocol implementation and use issues. </abstract>
        <obsoletes>
            <doc-id>RFC0993</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1057</doc-id>
        <title>RPC: Remote Procedure Call Protocol specification: Version 2</title>
        <author>
            <name>Sun Microsystems</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52462</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>SUN-RPC</kw>
        </keywords>
        <abstract>This RFC describes a standard that Sun Microsystems and others are using, and is one we wish to propose for the Internet's consideration. This memo is not an Internet standard at this time. </abstract>
        <obsoletes>
            <doc-id>RFC1050</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1058</doc-id>
        <title>Routing Information Protocol</title>
        <author>
            <name>C.L. Hedrick</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>93285</char-count>
            <page-count>33</page-count>
        </format>
        <keywords>
            <kw>RIP</kw>
        </keywords>
        <abstract>This RFC describes an existing protocol for exchanging routing information among gateways and other hosts. It is intended to be used as a basis for developing gateway software for use in the Internet community. </abstract>
        <updated-by>
            <doc-id>RFC1388</doc-id>
            <doc-id>RFC1723</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1059</doc-id>
        <title>Network Time Protocol (version 1) specification and implementation</title>
        <author>
            <name>D.L. Mills</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>140890</char-count>
            <page-count>58</page-count>
        </format>
        <keywords>
            <kw>NTP</kw>
            <kw>NTPv1</kw>
            <kw>time</kw>
            <kw>clock</kw>
            <kw>synchronization</kw>
        </keywords>
        <abstract>This memo describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave. It uses a returnable-time design in which a distributed subnet of time servers operating in a self- organizing, hierarchical master-slave configuration synchronizes logical clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute reference time via local routing algorithms and time daemons. The NTP architectures, algorithms and protocols which have evolved over several years of implementation and refinement are described in this document. The prototype system, which has been in regular operation in the Internet for the last two years, is described in an Appendix along with performance data which shows that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even the cases of failure or disruption of clocks, time servers or nets. This is a Draft Standard for an Elective protocol. </abstract>
        <obsoletes>
            <doc-id>RFC0958</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1119</doc-id>
            <doc-id>RFC1305</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1060</doc-id>
        <title>Assigned numbers</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>177923</char-count>
            <page-count>86</page-count>
        </format>
        <abstract>This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community. Distribution of this memo is unlimited. </abstract>
        <obsoletes>
            <doc-id>RFC1010</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1340</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC1349</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC1061</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC1062</doc-id>
        <title>Internet numbers</title>
        <author>
            <name>S. Romano</name>
        </author>
        <author>
            <name>M.K. Stahl</name>
        </author>
        <author>
            <name>M. Recker</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>198729</char-count>
            <page-count>65</page-count>
        </format>
        <abstract>This memo is an official status report on the network numbers and gateway autonomous system numbers used in the Internet community. </abstract>
        <obsoletes>
            <doc-id>RFC1020</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1117</doc-id>
            <doc-id>RFC1166</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1063</doc-id>
        <title>IP MTU discovery options</title>
        <author>
            <name>J.C. Mogul</name>
        </author>
        <author>
            <name>C.A. Kent</name>
        </author>
        <author>
            <name>C. Partridge</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27121</char-count>
            <page-count>11</page-count>
        </format>
        <abstract>A pair of IP options that can be used to learn the minimum MTU of a path through an internet is described, along with its possible uses. This is a proposal for an Experimental protocol. </abstract>
        <obsoleted-by>
            <doc-id>RFC1191</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1064</doc-id>
        <title>Interactive Mail Access Protocol: Version 2</title>
        <author>
            <name>M.R. Crispin</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>57813</char-count>
            <page-count>26</page-count>
        </format>
        <abstract>This memo suggests a method for workstations to dynamically access mail from a mailbox server ("respository"). This RFC specifies a standard for the SUMEX-AIM community and a proposed experimental protocol for the Internet community. Discussion and suggestions for improvement are requested. </abstract>
        <obsoleted-by>
            <doc-id>RFC1176</doc-id>
            <doc-id>RFC1203</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1065</doc-id>
        <title>Structure and identification of management information for TCP/IP-based internets</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M.T. Rose</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38858</char-count>
            <page-count>21</page-count>
        </format>
        <abstract>This RFC provides the common definitions for the structure and identification of management information for TCP/IP-based internets. In particular, together with its companion memos, which describe the initial management information base along with the initial network management protocol, these documents provide a simple, working architecture and system for managing TCP/IP-based internets and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementation in the Internet which are network manageable are expected to adopt and implement this specification. </abstract>
        <obsoleted-by>
            <doc-id>RFC1155</doc-id>
        </obsoleted-by>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1066</doc-id>
        <title>Management Information Base for network management of TCP/IP-based internets</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M.T. Rose</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>135177</char-count>
            <page-count>90</page-count>
        </format>
        <abstract>This RFC provides the initial version of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets in the short-term. In particular, together with its companion memos which describe the structure of management information along with the initial network management protocol, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets, and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification. </abstract>
        <obsoleted-by>
            <doc-id>RFC1156</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1067</doc-id>
        <title>Simple Network Management Protocol</title>
        <author>
            <name>J.D. Case</name>
        </author>
        <author>
            <name>M. Fedor</name>
        </author>
        <author>
            <name>M.L. Schoffstall</name>
        </author>
        <author>
            <name>J. Davin</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>69592</char-count>
            <page-count>33</page-count>
        </format>
        <abstract>This RFC defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. In particular, together with its companion memos which describe the structure of management information along with the initial management information base, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification. </abstract>
        <obsoleted-by>
            <doc-id>RFC1098</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1068</doc-id>
        <title>Background File Transfer Program (BFTP)</title>
        <author>
            <name>A.L. DeSchon</name>
        </author>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51004</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
        </keywords>
        <abstract>This RFC describes an Internet background file transfer service that is built upon the third-party transfer model of FTP. No new protocols are involved. The purpose of this memo is to stimulate discussions on new Internet service modes. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1069</doc-id>
        <title>Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol</title>
        <author>
            <name>R.W. Callon</name>
        </author>
        <author>
            <name>H.W. Braun</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24268</char-count>
            <page-count>10</page-count>
        </format>
        <abstract>This RFC suggests an addressing scheme for use with the ISO Connectionless Network Protocol (CLNP) in the Internet. This is a solution to one of the problems inherent in the use of "ISO-grams" in the Internet. This memo is a revision of RFC 986. This RFC suggests a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. </abstract>
        <obsoletes>
            <doc-id>RFC0986</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1070</doc-id>
        <title>Use of the Internet as a subnetwork for experimentation with the OSI network layer</title>
        <author>
            <name>R.A. Hagens</name>
        </author>
        <author>
            <name>N.E. Hall</name>
        </author>
        <author>
            <name>M.T. Rose</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37354</char-count>
            <page-count>17</page-count>
        </format>
        <abstract>This RFC proposes a scenario for experimentation with the International Organization for Standardization (ISO) Open Systems Interconnection (OSI) network layer protocols over the Internet and requests discussion and suggestions for improvements to this scenario. This RFC also proposes the creation of an experimental OSI internet. To participate in the experimental OSI internet, a system must abide by the agreements set forth in this RFC. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1071</doc-id>
        <title>Computing the Internet checksum</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <author>
            <name>D.A. Borman</name>
        </author>
        <author>
            <name>C. Partridge</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54941</char-count>
            <page-count>24</page-count>
        </format>
        <abstract>This RFC summarizes techniques and algorithms for efficiently computing the Internet checksum. It is not a standard, but a set of useful implementation techniques. </abstract>
        <updated-by>
            <doc-id>RFC1141</doc-id>
        </updated-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1072</doc-id>
        <title>TCP extensions for long-delay paths</title>
        <author>
            <name>V. Jacobson</name>
        </author>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36000</char-count>
            <page-count>16</page-count>
        </format>
        <abstract>This RFC proposes a set of extensions to the TCP protocol to provide efficient operation over a path with a high bandwidth*delay product. These extensions are not proposed as an Internet standard at this time. Instead, they are intended as a basis for further experimentation and research on transport protocol performance. </abstract>
        <obsoleted-by>
            <doc-id>RFC1323</doc-id>
            <doc-id>RFC2018</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1073</doc-id>
        <title>Telnet window size option</title>
        <author>
            <name>D. Waitzman</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7639</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>TOPT-NAWS</kw>
        </keywords>
        <abstract>This RFC describes a proposed Telnet option to allow a client to convey window size to a Telnet server. </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1074</doc-id>
        <title>NSFNET backbone SPF based Interior Gateway Protocol</title>
        <author>
            <name>J. Rekhter</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10872</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>This RFC is an implementation description of the standard ANSI IS-IS and ISO ES-IS routing protocols within the NSFNET backbone network. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1075</doc-id>
        <title>Distance Vector Multicast Routing Protocol</title>
        <author>
            <name>D. Waitzman</name>
        </author>
        <author>
            <name>C. Partridge</name>
        </author>
        <author>
            <name>S.E. Deering</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54731</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>IP-DVMRP</kw>
        </keywords>
        <abstract>This RFC describes a distance-vector-style routing protocol for routing multicast datagrams through an internet. It is derived from the Routing Information Protocol (RIP), and implements multicasting as described in RFC-1054. This is an experimental protocol, and its implementation is not recommended at this time. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1076</doc-id>
        <title>HEMS monitoring and control language</title>
        <author>
            <name>G. Trewitt</name>
        </author>
        <author>
            <name>C. Partridge</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>98774</char-count>
            <page-count>42</page-count>
        </format>
        <abstract>This RFC specifies a query language for monitoring and control of network entities. This RFC supercedes RFC 1023, extending the query language and providing more discussion of the underlying issues. This language is a component of the High-Level Entity Monitoring System (HEMS) described in RFC 1021 and RFC 1022. Readers may wish to consult these RFCs when reading this memo. RFC 1024 contains detailed assignments of numbers and structures used in this system. Portions of RFC 1024 that define query language structures are superceded by definitions in this memo. This memo assumes a knowledge of the ISO data encoding standard, ASN.1. </abstract>
        <obsoletes>
            <doc-id>RFC1023</doc-id>
        </obsoletes>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1077</doc-id>
        <title>Critical issues in high bandwidth networking</title>
        <author>
            <name>B.M. Leiner</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>116464</char-count>
            <page-count>46</page-count>
        </format>
        <abstract>This memo presents the results of a working group on High Bandwidth Networking. This RFC is for your information and you are encouraged to comment on the issues presented. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1078</doc-id>
        <title>TCP port service Multiplexer (TCPMUX)</title>
        <author>
            <name>M. Lottor</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3248</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>This RFC proposes an Internet standard which can be used by future TCP services instead of using 'well-known ports'. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1079</doc-id>
        <title>Telnet terminal speed option</title>
        <author>
            <name>C.L. Hedrick</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4942</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>TOPT-TS</kw>
        </keywords>
        <abstract>This RFC specifies a standard for the Internet community. Hosts on the Internet that exchange terminal speed information within the Telnet protocol are expected to adopt and implement this standard. </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1080</doc-id>
        <title>Telnet remote flow control option</title>
        <author>
            <name>C.L. Hedrick</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6688</char-count>
            <page-count>4</page-count>
        </format>
        <abstract>This RFC specifies a standard for the Internet community. Hosts on the Internet that do remote flow control within the Telnet protocol are expected to adopt and implement this standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1372</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1081</doc-id>
        <title>Post Office Protocol: Version 3</title>
        <author>
            <name>M.T. Rose</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37009</char-count>
            <page-count>16</page-count>
        </format>
        <abstract>This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. </abstract>
        <obsoleted-by>
            <doc-id>RFC1225</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1082</doc-id>
        <title>Post Office Protocol: Version 3: Extended service offerings</title>
        <author>
            <name>M.T. Rose</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25423</char-count>
            <page-count>11</page-count>
        </format>
        <abstract>This memo suggests a simple method for workstations to dynamically access mail from a discussion group server, as an extension to an earlier memo which dealt with dynamically accessing mail from a mailbox server using the Post Office Protocol - Version 3 (POP3). This RFC specifies a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. All of the extensions described in this memo to the POP3 are OPTIONAL. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1083</doc-id>
        <title>IAB official protocol standards</title>
        <author>
            <name>Defense Advanced Research Projects Agency</name>
        </author>
        <author>
            <name>Internet Activities Board</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27128</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>IAB</kw>
            <kw>official</kw>
            <kw>protocol</kw>
            <kw>standards</kw>
        </keywords>
        <abstract>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information. This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months. </abstract>
        <obsoleted-by>
            <doc-id>RFC1100</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1084</doc-id>
        <title>BOOTP vendor information extensions</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16327</char-count>
            <page-count>8</page-count>
        </format>
        <abstract>This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville. This memo will be updated as additional tags are are defined. This edition introduces Tag 13 for Boot File Size. Comments and suggestions for improvements are sought. </abstract>
        <obsoletes>
            <doc-id>RFC1048</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1395</doc-id>
            <doc-id>RFC1497</doc-id>
            <doc-id>RFC1533</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1085</doc-id>
        <title>ISO presentation services on top of TCP/IP based internets</title>
        <author>
            <name>M.T. Rose</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>64643</char-count>
            <page-count>32</page-count>
        </format>
        <abstract>RFC 1006 describes a mechanism for providing the ISO transport service on top of TCP/IP. Once this method is applied, one may implement "real" ISO applications on top of TCP/IP-based internets, by simply implementing OSI session, presentation, and application services on top of the transport service access point which is provided on top of the TCP. Although straight-forward, there are some environments in which the richness provided by the OSI application layer is desired, but it is nonetheless impractical to implement the underlying OSI infrastructure (i.e., the presentation, session, and transport services on top of the TCP). This memo describes an approach for providing "stream-lined" support of OSI application services on top of TCP/IP-based internets for such constrained environments. This memo proposes a standard for the Internet community. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1086</doc-id>
        <title>ISO-TP0 bridge between TCP and X.25</title>
        <author>
            <name>J.P. Onions</name>
        </author>
        <author>
            <name>M.T. Rose</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1988</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19934</char-count>
            <page-count>9</page-count>
        </format>
        <abstract>This memo proposes a standard for the Internet community. Hosts on the Internet that choose to implement ISO TP0 transport connectivity between TCP and X.25 based hosts are expected to experiment with this proposal. TCP port 146 is reserved for this proposal. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1087</doc-id>
        <title>Ethics and the Internet</title>
        <author>
            <name>Defense Advanced Research Projects Agency</name>
        </author>
        <author>
            <name>Internet Activities Board</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4582</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>Ethics</kw>
            <kw>Internet</kw>
        </keywords>
        <abstract>This memo is a statement of policy by the Internet Activities Board (IAB) concerning the proper use of the resources of the Internet. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1088</doc-id>
        <title>Standard for the transmission of IP datagrams over NetBIOS networks</title>
        <author>
            <name>L.J. McLaughlin</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5749</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>IP-NETBIOS</kw>
        </keywords>
        <abstract>This document specifies a standard method of encapsulating the Internet Protocol (IP) datagrams on NetBIOS networks. </abstract>
        <is-also>
            <doc-id>STD0048</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1089</doc-id>
        <title>SNMP over Ethernet</title>
        <author>
            <name>M.L. Schoffstall</name>
        </author>
        <author>
            <name>J. Davin</name>
        </author>
        <author>
            <name>M. Fedor</name>
        </author>
        <author>
            <name>J.D. Case</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4458</char-count>
            <page-count>3</page-count>
        </format>
        <abstract>This memo describes an experimental method by which the Simple Network Management Protocol (SNMP) can be used over Ethernet MAC layer framing instead of the Internet UDP/IP protocol stack. This specification is useful for LAN based network elements that support no higher layer protocols beyond the MAC sub-layer. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1090</doc-id>
        <title>SMTP on X.25</title>
        <author>
            <name>R. Ullmann</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6141</char-count>
            <page-count>4</page-count>
        </format>
        <abstract>This memo proposes a standard for SMTP on the virtual circuit facility provided by the X.25 standard of the CCITT. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1091</doc-id>
        <title>Telnet terminal-type option</title>
        <author>
            <name>J. VanBokkelen</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13439</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>TOPT-TERM</kw>
        </keywords>
        <abstract>This RFC specifies a standard for the Internet community. Hosts on the Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard. This standard supersedes RFC 930. A change is made to permit cycling through a list of possible terminal types and selecting the most appropriate </abstract>
        <obsoletes>
            <doc-id>RFC0930</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1092</doc-id>
        <title>EGP and policy based routing in the new NSFNET backbone</title>
        <author>
            <name>J. Rekhter</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11865</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>This memo discusses implementation decisions for routing issues in the NSFNET, especially in the NSFNET Backbone. Of special concern is the restriction of routing information to advertize the best route as established by a policy decision. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1093</doc-id>
        <title>NSFNET routing architecture</title>
        <author>
            <name>H.W. Braun</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20629</char-count>
            <page-count>9</page-count>
        </format>
        <abstract>This document describes the routing architecture for the NSFNET centered around the new NSFNET Backbone, with specific emphasis on the interface between the backbone and its attached networks. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1094</doc-id>
        <title>NFS: Network File System Protocol specification</title>
        <author>
            <name>Sun Microsystems</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51454</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>SUN-NFS</kw>
        </keywords>
        <abstract>This RFC describes a protocol that Sun Microsystems, Inc., and others are using. A new version of the protocol is under development, but others may benefit from the descriptions of the current protocol, and discussion of some of the design issues. </abstract>
        <notes>10/29/03 - back in June 2002, Matthew Wilcox sent an email stating that RFC 3010 is listed as erronously obsoleting RFCs 1813 and 1094.  This was confirmed by Scott Bradner in October  2003.  I have removed the Obsoleted by tag for for this entry.</notes>
        <see-also>
            <doc-id>RFC1813</doc-id>
        </see-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1095</doc-id>
        <title>Common Management Information Services and Protocol over TCP/IP (CMOT)</title>
        <author>
            <name>U.S. Warrier</name>
        </author>
        <author>
            <name>L. Besaw</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>157506</char-count>
            <page-count>67</page-count>
        </format>
        <abstract>This memo defines a network management architecture that uses the International Organization for Standardization's (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP) in a TCP/IP environment. This architecture provides a means by which control and monitoring information can be exchanged between a manager and a remote network element. In particular, this memo defines the means for implementing the Draft International Standard (DIS) version of CMIS/CMIP on top of Internet transport protocols for the purpose of carrying management information defined in the Internet-standard management information base. DIS CMIS/CMIP is suitable for deployment in TCP/IP networks while CMIS/CMIP moves toward becoming an International Standard. Together with the relevant ISO standards and the companion RFCs that describe the initial structure of management information and management information base, these documents provide the basis for a comprehensive architecture and system for managing TCP/IP- based internets, and in particular the Internet. </abstract>
        <obsoleted-by>
            <doc-id>RFC1189</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1096</doc-id>
        <title>Telnet X display location option</title>
        <author>
            <name>G.A. Marcy</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4634</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>TOPT-XDL</kw>
        </keywords>
        <abstract>This RFC specifies a standard for the Internet community. Hosts on the Internet that transmit the X display location within the Telnet protocol are expected to adopt and implement this standard. </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1097</doc-id>
        <title>Telnet subliminal-message option</title>
        <author>
            <name>B. Miller</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5490</char-count>
            <page-count>3</page-count>
        </format>
        <abstract>This RFC specifies a standard for the Internet community. Hosts on the Internet that display subliminal messages within the Telnet protocol are expected to adopt and implement this standard. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1098</doc-id>
        <title>Simple Network Management Protocol (SNMP)</title>
        <author>
            <name>J.D. Case</name>
        </author>
        <author>
            <name>M. Fedor</name>
        </author>
        <author>
            <name>M.L. Schoffstall</name>
        </author>
        <author>
            <name>J. Davin</name>
        </author>
        <date>
            <month>April</month>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>71563</char-count>
            <page-count>34</page-count>
        </format>
        <abstract>This RFC is a re-release of RFC 1067, with a changed "Status of this Memo" section. This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. In particular, together with its companion memos which describe the structure of management information along with the initial management information base, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet. </abstract>
        <obsoletes>
            <doc-id>RFC1067</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1157</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1099</doc-id>
        <title>Request for Comments Summary: RFC Numbers 1000-1099</title>
        <author>
            <name>J. Reynolds</name>
        </author>
        <date>
            <month>December</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49108</char-count>
            <page-count>22</page-count>
        </format>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1100</doc-id>
        <title>IAB official protocol standards</title>
        <author>
            <name>Defense Advanced Research Projects Agency</name>
        </author>
        <author>
            <name>Internet Activities Board</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30101</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>IAB</kw>
            <kw>official</kw>
            <kw>protocol</kw>
            <kw>standards</kw>
        </keywords>
        <abstract>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information. This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months. Current copies may be obtained from the Network Information Center or from the Internet Assigned Numbers Authority (see the contact information at the end of this memo). Do not use this memo after 31-July-89. </abstract>
        <obsoletes>
            <doc-id>RFC1083</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1130</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1101</doc-id>
        <title>DNS encoding of network names and other types</title>
        <author>
            <name>P.V. Mockapetris</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28677</char-count>
            <page-count>14</page-count>
        </format>
        <abstract>This RFC proposes two extensions to the Domain Name System: - A specific method for entering and retrieving RRs which map between network names and numbers. - Ideas for a general method for describing mappings between arbitrary identifiers and numbers. The method for mapping between network names and addresses is a proposed standard, the ideas for a general method are experimental. </abstract>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
        </updates>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1102</doc-id>
        <title>Policy routing in Internet protocols</title>
        <author>
            <name>D.D. Clark</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59664</char-count>
            <page-count>22</page-count>
        </format>
        <abstract>The purpose of this RFC is to focus discussion on particular problems in the Internet and possible methods of solution. No proposed solutions in this document are intended as standards for the Internet. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1103</doc-id>
        <title>Proposed standard for the transmission of IP datagrams over FDDI Networks</title>
        <author>
            <name>D. Katz</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19439</char-count>
            <page-count>9</page-count>
        </format>
        <abstract>This RFC specifies a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1188</doc-id>
        </obsoleted-by>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1104</doc-id>
        <title>Models of policy based routing</title>
        <author>
            <name>H.W. Braun</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25468</char-count>
            <page-count>10</page-count>
        </format>
        <abstract>The purpose of this RFC is to outline a variety of models for policy based routing. The relative benefits of the different approaches are reviewed. Discussions and comments are explicitly encouraged to move toward the best policy based routing model that scales well within a large internetworking environment. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1105</doc-id>
        <title>Border Gateway Protocol (BGP)</title>
        <author>
            <name>K. Lougheed</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37644</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>BGP</kw>
        </keywords>
        <abstract>This RFC outlines a specific approach for the exchange of network reachability information between Autonomous Systems. Updated by RFCs 1163 and 1164. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1163</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1106</doc-id>
        <title>TCP big window and NAK options</title>
        <author>
            <name>R. Fox</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37105</char-count>
            <page-count>13</page-count>
        </format>
        <abstract>This memo discusses two extensions to the TCP protocol to provide a more efficient operation over a network with a high bandwidth*delay product. The extensions described in this document have been implemented and shown to work using resources at NASA. This memo describes an Experimental Protocol, these extensions are not proposed as an Internet standard, but as a starting point for further research. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1107</doc-id>
        <title>Plan for Internet directory services</title>
        <author>
            <name>K.R. Sollins</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51773</char-count>
            <page-count>19</page-count>
        </format>
        <abstract>This memo proposes a program to develop a directory service for the Internet. It reports the results of a meeting held in February 1989, which was convened to review requirements and options for such a service. This proposal is offered for comment, and does not represent a committed research activity of the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1108</doc-id>
        <title>U.S. Department of Defense Security Options for the Internet Protocol</title>
        <author>
            <name>S. Kent</name>
        </author>
        <date>
            <month>November</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41791</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>IPSO</kw>
        </keywords>
        <abstract>This RFC specifies the U.S. Department of Defense Basic Security Option and the top-level description of the Extended Security Option for use with the Internet Protocol. This RFC obsoletes RFC 1038, "Revised IP Security Option", dated January 1988. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1038</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1109</doc-id>
        <title>Report of the second Ad Hoc Network Management Review Group</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20642</char-count>
            <page-count>8</page-count>
        </format>
        <abstract>This RFC reports an official Internet Activities Board (IAB) policy position on the treatment of Network Management in the Internet. This RFC presents the results and recommendations of the second Ad Hoc Network Management Review on June 12, 1989. The results of the first such meeting were reported in RFC 1052. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1110</doc-id>
        <title>Problem with the TCP big window option</title>
        <author>
            <name>A.M. McKenzie</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5778</char-count>
            <page-count>3</page-count>
        </format>
        <abstract>This memo comments on the TCP Big Window option described in RFC 1106. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1111</doc-id>
        <title>Request for comments on Request for Comments: Instructions to RFC authors</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11793</char-count>
            <page-count>6</page-count>
        </format>
        <abstract>This RFC specifies a standard for the Internet community. Authors of RFCs are expected to adopt and implement this standard. </abstract>
        <obsoletes>
            <doc-id>RFC0825</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1543</doc-id>
            <doc-id>RFC2223</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1112</doc-id>
        <title>Host extensions for IP multicasting</title>
        <author>
            <name>S.E. Deering</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39904</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>IGMP</kw>
            <kw>multicast</kw>
        </keywords>
        <abstract>This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. Recommended procedure for IP multicasting in the Internet. This RFC obsoletes RFCs 998 and 1054. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC0988</doc-id>
            <doc-id>RFC1054</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC2236</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0005</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1113</doc-id>
        <title>Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures </title>
        <author>
            <name>J. Linn</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>89293</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This RFC specifies features for private electronic mail based on encryption technology. [STANDARDS-TRACK] </abstract>
        <notes>Draft.  </notes>
        <obsoletes>
            <doc-id>RFC0989</doc-id>
            <doc-id>RFC1040</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1421</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1114</doc-id>
        <title>Privacy enhancement for Internet electronic mail: Part II - certificate-based key management </title>
        <author>
            <name>S.T. Kent</name>
        </author>
        <author>
            <name>J. Linn</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>69661</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This RFC specifies the key management aspects of Privacy Enhanced Mail. [STANDARDS-TRACK] </abstract>
        <notes>Draft.  </notes>
        <obsoleted-by>
            <doc-id>RFC1422</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1115</doc-id>
        <title>Privacy enhancement for Internet electronic mail: Part III - algorithms, modes, and identifiers </title>
        <author>
            <name>J. Linn</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18226</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This RFC provides definitions, references, and citations for algorithms, usage modes, and associated identifiers used in RFC-1113 and RFC-1114 in support of privacy-enhanced electronic mail. [STANDARDS-TRACK] </abstract>
        <notes>Draft.  </notes>
        <obsoleted-by>
            <doc-id>RFC1423</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1116</doc-id>
        <title>Telnet Linemode option</title>
        <author>
            <name>D.A. Borman</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47473</char-count>
            <page-count>21</page-count>
        </format>
        <abstract>Hosts on the Internet that support Linemode within the Telnet protocol are expected to adopt and implement this protocol. Obsoleted by RFC 1184. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1184</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1117</doc-id>
        <title>Internet numbers</title>
        <author>
            <name>S. Romano</name>
        </author>
        <author>
            <name>M.K. Stahl</name>
        </author>
        <author>
            <name>M. Recker</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>324666</char-count>
            <page-count>109</page-count>
        </format>
        <abstract>This memo is an official status report on the network numbers and the autonomous system numbers used in the Internet community. </abstract>
        <obsoletes>
            <doc-id>RFC1062</doc-id>
            <doc-id>RFC1020</doc-id>
            <doc-id>RFC0997</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1166</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1118</doc-id>
        <title>Hitchhikers guide to the Internet</title>
        <author>
            <name>E. Krol</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>62757</char-count>
            <page-count>24</page-count>
        </format>
        <abstract>This RFC is being distributed to members of the Internet community in order to make available some "hints" which will allow new network participants to understand how the direction of the Internet is set, how to acquire online information and how to be a good Internet neighbor. While the information discussed may not be relevant to the research problems of the Internet, it may be interesting to a number of researchers and implementors. No standards are defined or specified in this memo. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1119</doc-id>
        <title>Network Time Protocol (version 2) specification and implementation</title>
        <author>
            <name>D.L. Mills</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>143</char-count>
            <page-count>1</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>518020</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>187940</char-count>
        </format>
        <keywords>
            <kw>NTP</kw>
            <kw>NTPv2</kw>
            <kw>time</kw>
            <kw>clock</kw>
            <kw>synchronization</kw>
        </keywords>
        <abstract>This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave. It uses a returnable-time design in which a distributed subnet of time servers operating in a self- organizing, hierarchical-master-slave configuration synchronizes local clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute reference time via local routing algorithms and time daemons. [STANDARDS-TRACK] </abstract>
        <notes>See also RFC1129</notes>
        <obsoletes>
            <doc-id>RFC0958</doc-id>
            <doc-id>RFC1059</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1305</doc-id>
        </obsoleted-by>
        <is-also>
            <doc-id>STD0012</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1120</doc-id>
        <title>Internet Activities Board</title>
        <author>
            <name>V. Cerf</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26123</char-count>
            <page-count>11</page-count>
        </format>
        <abstract>This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations. This memo is for informational use and does not constitute a standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1160</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1121</doc-id>
        <title>Act one - the poems</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>L. Kleinrock</name>
        </author>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <author>
            <name>B. Boehm</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10644</char-count>
            <page-count>6</page-count>
        </format>
        <abstract>This RFC presents a collection of poems that were presented at "Act One", a symposium held partially in celebration of the 20th anniversary of the ARPANET. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1122</doc-id>
        <title>Requirements for Internet Hosts - Communication Layers</title>
        <author>
            <name>R. Braden</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>295992</char-count>
            <page-count>116</page-count>
        </format>
        <keywords>
            <kw>applicability</kw>
        </keywords>
        <abstract>This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] </abstract>
        <updated-by>
            <doc-id>RFC1349</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0003</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1123</doc-id>
        <title>Requirements for Internet Hosts - Application and Support</title>
        <author>
            <name>R. Braden</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>245503</char-count>
            <page-count>98</page-count>
        </format>
        <keywords>
            <kw>applicability</kw>
        </keywords>
        <abstract>This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] </abstract>
        <updates>
            <doc-id>RFC0822</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC1349</doc-id>
            <doc-id>RFC2181</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0003</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1124</doc-id>
        <title>Policy issues in interconnecting networks</title>
        <author>
            <name>B.M. Leiner</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>118</char-count>
            <page-count>1</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>315692</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>143819</char-count>
        </format>
        <abstract>To support the activities of the Federal Research Internet Coordinating Committee (FRICC) in creating an interconnected set of networks to serve the research community, two workshops were held to address the technical support of policy issues that arise when interconnecting such networks. Held under the suspices of the Internet Activities Board at the request of the FRICC, and sponsored by NASA through RIACS, the workshops addressed the required and feasible technologies and architectures that could be used to satisfy the desired policies for interconnection. The purpose of this RFC is to report the results of these workshops. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1125</doc-id>
        <title>Policy requirements for inter Administrative Domain routing</title>
        <author>
            <name>D. Estrin</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>55248</char-count>
            <page-count>21</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>282123</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>289862</char-count>
        </format>
        <abstract>The purpose of this memo is to focus discussion on particular problems in the Internet and possible methods of solution. No proposed solutions in this document are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, leading eventually to the development and adoption of standards. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1126</doc-id>
        <title>Goals and functional requirements for inter-autonomous system routing</title>
        <author>
            <name>M. Little</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>62725</char-count>
            <page-count>25</page-count>
        </format>
        <abstract>This document describes the functional requirements for a routing protocol to be used between autonomous systems. This document is intended as a necessary precursor to the design of a new inter- autonomous system routing protocol and specifies requirements for the Internet applicable for use with the current DoD IP, the ISO IP, and future Internet Protocols. It is intended that these requirements will form the basis for the future development of a new inter-autonomous systems routing architecture and protocol. This memo does not specify a standard. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1127</doc-id>
        <title>Perspective on the Host Requirements RFCs</title>
        <author>
            <name>R.T. Braden</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41267</char-count>
            <page-count>20</page-count>
        </format>
        <abstract>This RFC is for information only; it does not constitute a standard, draft standard, or proposed standard, and it does not define a protocol. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1128</doc-id>
        <title>Measured performance of the Network Time Protocol in the Internet system</title>
        <author>
            <name>D.L. Mills</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>314</char-count>
            <page-count>1</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>633742</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>197897</char-count>
        </format>
        <abstract>This paper describes a series of experiments involving over 100,000 hosts of the Internet system and located in the U.S., Europe and the Pacific. The experiments are designed to evaluate the availability, accuracy and reliability of international standard time distribution using the DARPA/NSF Internet and the Network Time Protocol (NTP), which is specified in RFC-1119. NTP is designed specifically for use in a large, diverse internet system operating at speeds from mundane to lightwave. In NTP a distributed subnet of time servers operating in a self-organizing, hierarchical, master-slave configuration exchange precision timestamps in order to synchronize subnet clocks to each other and national time standards via wire or radio. The experiments are designed to locate Internet hosts and gateways that provide time by one of three time distribution protocols and evaluate the accuracy of their indications. For those hosts that support NTP, the experiments determine the distribution of errors and other statistics over paths spanning major portions of the globe. Finally, the experiments evaluate the accuracy and reliability of precision timekeeping using NTP and typical Internet paths involving DARPA, NSFNET and other agency networks. The experiments demonstrate that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even in cases of failure or disruption of clocks, time servers or networks. This memo does not specify a standard. </abstract>
        <current-status>UNKNOWN</current-status>
        <publication-status>UNKNOWN</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1129</doc-id>
        <title>Internet Time Synchronization: The Network Time Protocol</title>
        <author>
            <name>D.L. Mills</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>298</char-count>
            <page-count>1</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>551697</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>197036</char-count>
        </format>
        <keywords>
            <kw>NTP</kw>
        </keywords>
        <abstract>This memo describes the Network Time Protocol (NTP) designed to distribute time information in a large, diverse internet system operating at speeds from mundane to lightwave. It uses a returnable- time architecture in which a distributed subnet of time servers operating in a self-organizing, hierarchical, master-slave configuration synchronizes local clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute time information within a network via local routing algorithms and time daemons. The architectures, algorithms and protocols which have evolved to NTP over several years of implementation and refinement are described in this paper. The synchronization subnet which has been in regular operation in the Internet for the last several years is described along with performance data which shows that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even in cases of failure or disruption of clocks, time servers or networks. This memo describes the Network Time Protocol in RFC-1119. </abstract>
        <see-also>
            <doc-id>RFC1119</doc-id>
        </see-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1130</doc-id>
        <title>IAB official protocol standards</title>
        <author>
            <name>Defense Advanced Research Projects Agency</name>
        </author>
        <author>
            <name>Internet Activities Board</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33858</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>IAB</kw>
            <kw>official</kw>
            <kw>protocol</kw>
            <kw>standards</kw>
        </keywords>
        <abstract>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). </abstract>
        <obsoletes>
            <doc-id>RFC1100</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1140</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1131</doc-id>
        <title>OSPF specification</title>
        <author>
            <name>J. Moy</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>268</char-count>
            <page-count>1</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>857280</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>398863</char-count>
        </format>
        <abstract>This RFC is the specification of the Open Shortest Path First (OSPF) Internet routing protocol. OSPF is in the class of Internal Gateway Protocols (IGPs) for distributing routing information between gateways of a single Autonomous System. This routing protocol is based on the link-state approach (in contrast to the distance-vector approach). This specification was developed by the OSPF Working Group of the Internet Engineering Task Force. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1247</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1132</doc-id>
        <title>Standard for the transmission of 802.2 packets over IPX networks</title>
        <author>
            <name>L.J. McLaughlin</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8128</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>IP-IPX</kw>
        </keywords>
        <abstract>This document specifies a standard method of encapsulating 802.2 packets on networks supporting Novell's Internet Packet Exchange Protocol (IPX). It obsoletes earlier documents detailing the transmission of Internet packets over IPX networks. It differs from these earlier documents in that it allows for the transmission of multiple network protocols over IPX and for the transmission of packets through IPX bridges. </abstract>
        <is-also>
            <doc-id>STD0049</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1133</doc-id>
        <title>Routing between the NSFNET and the DDN</title>
        <author>
            <name>J.Y. Yu</name>
        </author>
        <author>
            <name>H.W. Braun</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23169</char-count>
            <page-count>10</page-count>
        </format>
        <abstract>This document is a case study of the implementation of routing between the NSFNET and the DDN components (the MILNET and the ARPANET). We hope that it can be used to expand towards interconnection of other Administrative Domains. We would welcome discussion and suggestions about the methods employed for the interconnections. No standards are specified in this memo. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1134</doc-id>
        <title>Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links</title>
        <author>
            <name>D. Perkins</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>87352</char-count>
            <page-count>38</page-count>
        </format>
        <abstract>This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the IETF Point-to-Point Protocol Working Group chair by January 15, 1990. Comments will be reviewed at the February 1990 IETF meeting, with the goal of advancing PPP to draft standard status. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1171</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1135</doc-id>
        <title>Helminthiasis of the Internet</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>77033</char-count>
            <page-count>33</page-count>
        </format>
        <abstract>This memo takes a look back at the helminthiasis (infestation with, or disease caused by parasitic worms) of the Internet that was unleashed the evening of 2 November 1988. This RFC provides information about an event that occurred in the life of the Internet. This memo does not specify any standard. This document provides a glimpse at the infection, its festering, and cure. The impact of the worm on the Internet community, ethics statements, the role of the news media, crime in the computer world, and future prevention is discussed. A documentation review presents four publications that describe in detail this particular parasitic computer program. Reference and bibliography sections are also included. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1136</doc-id>
        <title>Administrative Domains and Routing Domains: A model for routing in the Internet</title>
        <author>
            <name>S. Hares</name>
        </author>
        <author>
            <name>D. Katz</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22158</char-count>
            <page-count>10</page-count>
        </format>
        <abstract>This RFC proposes a model for describing routing within the Internet. The model is an adaptation of the "OSI Routeing Framework". This memo does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1137</doc-id>
        <title>Mapping between full RFC 822 and RFC 822 with restricted encoding</title>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6266</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. </abstract>
        <updates>
            <doc-id>RFC0976</doc-id>
        </updates>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1138</doc-id>
        <title>Mapping between X.400(1988) / ISO 10021 and RFC 822</title>
        <author>
            <name>S.E. Kille</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1989</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>191029</char-count>
            <page-count>92</page-count>
        </format>
        <abstract>Ths RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This memo updates RFCs 822, 987, and 1026. </abstract>
        <obsoleted-by>
            <doc-id>RFC1327</doc-id>
            <doc-id>RFC2156</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0822</doc-id>
            <doc-id>RFC0987</doc-id>
            <doc-id>RFC1026</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC1148</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1139</doc-id>
        <title>Echo function for ISO 8473</title>
        <author>
            <name>R.A. Hagens</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14229</char-count>
            <page-count>6</page-count>
        </format>
        <abstract>This memo defines an echo function for the connection-less network layer protocol. Two mechanisms are introduced that may be used to implement the echo function. The first mechanism is recommended as an interim solution for the Internet community. The second mechanism will be progressed to the ANSI X3S3.3 working group for consideration as a work item. When an ISO standard is adopted that provides functionality similar to that described by this memo, then this memo will become obsolete and superceded by the ISO standard. This memo is not intended to compete with an ISO standard. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1574</doc-id>
            <doc-id>RFC1575</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1140</doc-id>
        <title>IAB official protocol standards</title>
        <author>
            <name>Defense Advanced Research Projects Agency</name>
        </author>
        <author>
            <name>Internet Activities Board</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>60501</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>IAB</kw>
            <kw>official</kw>
            <kw>protocol</kw>
            <kw>standards</kw>
        </keywords>
        <abstract>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months. Current copies may be obtained from the Network Information Center or from the Internet Assigned Numbers Authority. Do not use this edition after 31-Aug-90. </abstract>
        <obsoletes>
            <doc-id>RFC1130</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1200</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1141</doc-id>
        <title>Incremental updating of the Internet checksum</title>
        <author>
            <name>T. Mallory</name>
        </author>
        <author>
            <name>A. Kullberg</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3587</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>This memo correctly describes the incremental update procedure for use with the standard Internet checksum. It is intended to replace the description of Incremental Update in RFC 1071. This is not a standard but rather, an implementation technique. </abstract>
        <updates>
            <doc-id>RFC1071</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC1624</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1142</doc-id>
        <title>OSI IS-IS Intra-domain Routing Protocol</title>
        <author>
            <name>D. Oran</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>425379</char-count>
            <page-count>517</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>1440951</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>490300</char-count>
        </format>
        <keywords>
            <kw>Domain</kw>
            <kw>Routing</kw>
            <kw>ISO</kw>
        </keywords>
        <abstract>This RFC is a republication of ISO DP 10589 as a service to the Internet community. This is not an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1143</doc-id>
        <title>The Q Method of Implementing TELNET Option Negotiation</title>
        <author>
            <name>D.J. Bernstein</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23331</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This is RFC discusses an implementation approach to option negotiation in the Telnet protocol (RFC 854). It does not propose any changes to the TELNET protocol. Rather, it discusses the implementation of the protocol of one feature, only. This is not a protocol specification. This is an experimental method of implementing a protocol. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1144</doc-id>
        <title>Compressing TCP/IP headers for low-speed serial links</title>
        <author>
            <name>V. Jacobson</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>120959</char-count>
            <page-count>49</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>534729</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>255616</char-count>
        </format>
        <keywords>
            <kw>IP-CMPRS</kw>
        </keywords>
        <abstract>This RFC describes a method for compressing the headers of TCP/IP datagrams to improve performance over low speed serial links. The motivation, implementation and performance of the method are described. C code for a sample implementation is given for reference. [STANDARDS- TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1145</doc-id>
        <title>TCP alternate checksum options</title>
        <author>
            <name>J. Zweig</name>
        </author>
        <author>
            <name>C. Partridge</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11052</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header. The use of these options is experimental, and not recommended for production use. </abstract>
        <obsoleted-by>
            <doc-id>RFC1146</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1146</doc-id>
        <title>TCP alternate checksum options</title>
        <author>
            <name>J. Zweig</name>
        </author>
        <author>
            <name>C. Partridge</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10955</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>TCP-ACO</kw>
        </keywords>
        <abstract>This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header. The use of these options is experimental, and not recommended for production use. Note: This RFC corrects errors introduced in the editing process in RFC 1145. </abstract>
        <obsoletes>
            <doc-id>RFC1145</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1147</doc-id>
        <title>FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices</title>
        <author>
            <name>R.H. Stine</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>336906</char-count>
            <page-count>177</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>555225</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>308602</char-count>
        </format>
        <abstract>The goal of this FYI memo is to provide practical information to site administrators and network managers. This memo provides information for the Internet community. It does not specify any standard. It is not a statement of IAB policy or recommendations. [Also FYI 2.] This catalog contains descriptions of several tools available to assist network managers in debugging and maintaining TCP/IP internets and interconnected communications resources. Entries in the catalog tell what a tool does, how it works, and how it can be obtained. </abstract>
        <obsoleted-by>
            <doc-id>RFC1470</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1148</doc-id>
        <title>Mapping between X.400(1988) / ISO 10021 and RFC 822</title>
        <author>
            <name>S.E. Kille</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>194292</char-count>
            <page-count>94</page-count>
        </format>
        <abstract>This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This edition includes material lost in editing. </abstract>
        <obsoleted-by>
            <doc-id>RFC1327</doc-id>
            <doc-id>RFC2156</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0822</doc-id>
            <doc-id>RFC0987</doc-id>
            <doc-id>RFC1026</doc-id>
            <doc-id>RFC1138</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1149</doc-id>
        <title>Standard for the transmission of IP datagrams on avian carriers</title>
        <author>
            <name>D. Waitzman</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3329</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>avian</kw>
            <kw>carrier</kw>
            <kw>april</kw>
            <kw>fools</kw>
        </keywords>
        <abstract>This memo describes an experimental method for the encapsulation of IP datagrams in avian carriers. This specification is primarily useful in Metropolitan Area Networks. This is an experimental, not recommended standard. </abstract>
        <updated-by>
            <doc-id>RFC2549</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1150</doc-id>
        <title>FYI on FYI: Introduction to the FYI Notes</title>
        <author>
            <name>G.S. Malkin</name>
        </author>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7867</char-count>
            <page-count>4</page-count>
        </format>
        <abstract>This memo is the first in a new sub-series of RFCs called FYIs (For Your Information). This memo provides information for the Internet community. It does not specify any standard. [Also FYI 1.] </abstract>
        <is-also>
            <doc-id>FYI0001</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1151</doc-id>
        <title>Version 2 of the Reliable Data Protocol (RDP)</title>
        <author>
            <name>C. Partridge</name>
        </author>
        <author>
            <name>R.M. Hinden</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8293</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>RDP</kw>
        </keywords>
        <abstract>This RFC suggests several updates to the specification of the Reliable Data Protocol (RDP) in RFC-908 based on experience with the protocol. This revised version of the protocol is experimental. </abstract>
        <updates>
            <doc-id>RFC0908</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1152</doc-id>
        <title>Workshop report: Internet research steering group workshop on very-high-speed networks</title>
        <author>
            <name>C. Partridge</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>64003</char-count>
            <page-count>23</page-count>
        </format>
        <abstract>This memo is a report on a workshop sponsored by the Internet Research Steering Group. This memo is for information only. This RFC does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1153</doc-id>
        <title>Digest message format</title>
        <author>
            <name>F.J. Wancho</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6632</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>DMF-MAIL</kw>
        </keywords>
        <abstract>This memo describes the de facto standard Digest Message Format. This is an elective experimental protocol. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1154</doc-id>
        <title>Encoding header field for internet messages</title>
        <author>
            <name>D. Robinson</name>
        </author>
        <author>
            <name>R. Ullmann</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12214</char-count>
            <page-count>7</page-count>
        </format>
        <abstract>This RFC proposes an elective experimental Encoding header field to permit the mailing of multi-part, multi-structured messages. The use of Encoding updates RFC 1049 (Content-Type), and is a suggested update to RFCs 1113, 1114, and 1115 (Privacy Enhancement). </abstract>
        <obsoleted-by>
            <doc-id>RFC1505</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1155</doc-id>
        <title>Structure and identification of management information for TCP/IP-based internets</title>
        <author>
            <name>M.T. Rose</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40927</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>SMI</kw>
        </keywords>
        <abstract>This RFC is a re-release of RFC 1065, with a changed "Status of this Memo", plus a few minor typographical corrections. The technical content of the document is unchanged from RFC 1065. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1065</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0016</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1156</doc-id>
        <title>Management Information Base for network management of TCP/IP-based internets</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M.T. Rose</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>138781</char-count>
            <page-count>91</page-count>
        </format>
        <keywords>
            <kw>MIB-I</kw>
        </keywords>
        <abstract>This RFC is a re-release of RFC 1066, with a changed "Status of this Memo", "IAB Policy Statement", and "Introduction" sections plus a few minor typographical corrections. The technical content of the document is unchanged from RFC 1066. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1066</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1157</doc-id>
        <title>Simple Network Management Protocol (SNMP)</title>
        <author>
            <name>J.D. Case</name>
        </author>
        <author>
            <name>M. Fedor</name>
        </author>
        <author>
            <name>M.L. Schoffstall</name>
        </author>
        <author>
            <name>J. Davin</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>74894</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
        </keywords>
        <abstract>This RFC is a re-release of RFC 1098, with a changed "Status of this Memo" section plus a few minor typographical corrections. This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1098</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0015</doc-id>
        </is-also>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1158</doc-id>
        <title>Management Information Base for network management of TCP/IP-based internets: MIB-II</title>
        <author>
            <name>M.T. Rose</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>212152</char-count>
            <page-count>133</page-count>
        </format>
        <abstract>This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP- based internets. In particular, together with its companion memos which describe the structure of management information (RFC 1155) along with the network management protocol (RFC 1157) for TCP/IP- based internets, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet community. This document on MIB-II incorporates all of the technical content of RFC 1156 on MIB-I and extends it, without loss of compatibilty. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1213</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1159</doc-id>
        <title>Message Send Protocol</title>
        <author>
            <name>R. Nelson</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3957</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>This RFC suggests an Experimental Protocol for the Internet community. Hosts on the Internet that choose to implement a Message Send Protocol may experiment with this protocol. </abstract>
        <obsoleted-by>
            <doc-id>RFC1312</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1160</doc-id>
        <title>Internet Activities Board</title>
        <author>
            <name>V. Cerf</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28182</char-count>
            <page-count>11</page-count>
        </format>
        <abstract>This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations. This memo is for informational use and does not constitute a standard. This is a revision of RFC 1120. </abstract>
        <obsoletes>
            <doc-id>RFC1120</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1161</doc-id>
        <title>SNMP over OSI</title>
        <author>
            <name>M.T. Rose</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16036</char-count>
            <page-count>8</page-count>
        </format>
        <abstract>This memo defines an experimental means for running the Simple Network Management Protocol (SNMP) over OSI transports. This memo does not specify a standard for the Internet community, </abstract>
        <obsoleted-by>
            <doc-id>RFC1418</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1162</doc-id>
        <title>Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base</title>
        <author>
            <name>G. Satz</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>109893</char-count>
            <page-count>70</page-count>
        </format>
        <abstract>This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This memo does not specify a standard for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC1238</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1163</doc-id>
        <title>Border Gateway Protocol (BGP)</title>
        <author>
            <name>K. Lougheed</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>69404</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>BGP</kw>
        </keywords>
        <abstract>This RFC, together with its companion RFC-1164, "Application of the Border Gateway Protocol in the Internet", specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1105</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1267</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1164</doc-id>
        <title>Application of the Border Gateway Protocol in the Internet</title>
        <author>
            <name>J.C. Honig</name>
        </author>
        <author>
            <name>D. Katz</name>
        </author>
        <author>
            <name>M. Mathis</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>J.Y. Yu</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>56278</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>BGP</kw>
        </keywords>
        <abstract>This RFC, together with its companion RFC-1163, "A Border Gateway Protocol (BGP)", specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1268</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1165</doc-id>
        <title>Network Time Protocol (NTP) over the OSI Remote Operations Service</title>
        <author>
            <name>J. Crowcroft</name>
        </author>
        <author>
            <name>J.P. Onions</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18277</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>NTP-OSI</kw>
        </keywords>
        <abstract>This memo suggests an Experimental Protocol for the OSI and Internet communities. Hosts in either community, and in particular those on both are encouraged to experiment with this mechanism. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1166</doc-id>
        <title>Internet numbers</title>
        <author>
            <name>S. Kirkpatrick</name>
        </author>
        <author>
            <name>M.K. Stahl</name>
        </author>
        <author>
            <name>M. Recker</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>566778</char-count>
            <page-count>182</page-count>
        </format>
        <abstract>This memo is a status report on the network numbers and autonomous system numbers used in the Internet community. </abstract>
        <obsoletes>
            <doc-id>RFC1117</doc-id>
            <doc-id>RFC1062</doc-id>
            <doc-id>RFC1020</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1167</doc-id>
        <title>Thoughts on the National Research and Education Network</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20682</char-count>
            <page-count>8</page-count>
        </format>
        <abstract>The memo provides a brief outline of a National Research and Education Network (NREN). This memo provides information for the Internet community. It does not specify any standard. It is not a statement of IAB policy or recommendations. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1168</doc-id>
        <title>Intermail and Commercial Mail Relay services</title>
        <author>
            <name>A. Westine</name>
        </author>
        <author>
            <name>A.L. DeSchon</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>C.E. Ward</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40306</char-count>
            <page-count>18</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>149816</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>55890</char-count>
        </format>
        <abstract>This RFC discusses the history and evolution of the Intermail and Commercial mail systems. The problems encountered in operating a store-and-forward mail relay between commercial systems such as Telemail, MCI Mail and Dialcom are also discussed. This RFC provides information for the Internet community, and does not specify any standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1169</doc-id>
        <title>Explaining the role of GOSIP</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <author>
            <name>K.L. Mills</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30255</char-count>
            <page-count>15</page-count>
        </format>
        <abstract>This informational RFC represents the official view of the Internet Activities Board (IAB), after coordination with the Federal Networking Council (FNC). This RFC does not specify a standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1170</doc-id>
        <title>Public key standards and licenses</title>
        <author>
            <name>R.B. Fougner</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3144</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>This RFC is a public statement by Public Key Partners regarding Public Key Standards and Licenses. This memo is for informational use only, and does not constitute an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1171</doc-id>
        <title>Point-to-Point Protocol for the transmission of multi-protocol datagrams over Point-to-Point links</title>
        <author>
            <name>D. Perkins</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>92321</char-count>
            <page-count>51</page-count>
        </format>
        <abstract>This memo specifies the Point-to-Point Protocol (PPP) as a Draft Standard Protocol for the Internet community. When it becomes a full Standard, this protocol will be recommended for all TCP/IP implementations that communicate over serial links. </abstract>
        <obsoletes>
            <doc-id>RFC1134</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1331</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1172</doc-id>
        <title>Point-to-Point Protocol (PPP) initial configuration options</title>
        <author>
            <name>D. Perkins</name>
        </author>
        <author>
            <name>R. Hobby</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>76132</char-count>
            <page-count>40</page-count>
        </format>
        <abstract>This memo specifies the Point-to-Point Protocol (PPP) Initial Configuration Options as a Proposed Standard Protocol for the Internet community. When it becomes a full Standard, this protocol will be recommended for all TCP/IP implementations that communicate over serial links. </abstract>
        <obsoleted-by>
            <doc-id>RFC1331</doc-id>
            <doc-id>RFC1332</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1173</doc-id>
        <title>Responsibilities of host and network managers: A summary of the "oral tradition" of the Internet</title>
        <author>
            <name>J. VanBokkelen</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12527</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>This informational RFC describes the conventions to be followed by those in charge of networks and hosts in the Internet. It is a summary of the "oral tradition" of the Internet on this subject. [RFC Editor's note: This memo is a contribution by the author of his view of these conventions. It is expected that this RFC will provide a basis for the development of official policies in the future.] These conventions may be supplemented or amended by the policies of specific local and regional components of the Internet. This RFC does not specify a standard, or a policy of the IAB. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1174</doc-id>
        <title>IAB recommended policy on distributing internet identifier assignment and IAB recommended policy change to internet "connected" status</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21321</char-count>
            <page-count>9</page-count>
        </format>
        <abstract>This informational RFC represents the official view of the Internet Activities Board (IAB), and describes the recommended policies and procedures on distributing Internet identifier assignments and dropping the connected status requirement. This RFC does not specify a standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1175</doc-id>
        <title>FYI on where to start: A bibliography of internetworking information</title>
        <author>
            <name>K.L. Bowers</name>
        </author>
        <author>
            <name>T.L. LaQuey</name>
        </author>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <author>
            <name>K. Roubicek</name>
        </author>
        <author>
            <name>M.K. Stahl</name>
        </author>
        <author>
            <name>A. Yuan</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>67330</char-count>
            <page-count>43</page-count>
        </format>
        <abstract>This FYI RFC is a bibliography of information about TCP/IP internetworking, prepared by the User Services Working Group (USWG) of the Internet Engineering Task Force (IETF). This memo provides information for the Internet community. It does not specify any standard. [Also FYI 3.] </abstract>
        <is-also>
            <doc-id>FYI0003</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1176</doc-id>
        <title>Interactive Mail Access Protocol: Version 2</title>
        <author>
            <name>M.R. Crispin</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>67330</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>IMAP2</kw>
        </keywords>
        <abstract>This RFC suggests a method for personal computers and workstations to dynamically access mail from a mailbox server ("repository"). It obosoletes RFC 1064. This RFC specifies an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. </abstract>
        <obsoletes>
            <doc-id>RFC1064</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1177</doc-id>
        <title>FYI on Questions and Answers: Answers to commonly asked "new internet user" questions</title>
        <author>
            <name>G.S. Malkin</name>
        </author>
        <author>
            <name>A.N. Marine</name>
        </author>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52852</char-count>
            <page-count>24</page-count>
        </format>
        <abstract>This FYI RFC is one of three FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group (USWG) of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [Also FYI 4.] </abstract>
        <obsoleted-by>
            <doc-id>RFC1206</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1178</doc-id>
        <title>Choosing a name for your computer</title>
        <author>
            <name>D. Libes</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18472</char-count>
            <page-count>8</page-count>
        </format>
        <abstract>This FYI RFC is a republication of a Communications of the ACM article on guidelines on what to do and what not to do when naming your computer. This memo provides information for the Internet community. It does not specify any standard. [Also FYI 5.] </abstract>
        <is-also>
            <doc-id>FYI0005</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1179</doc-id>
        <title>Line printer daemon protocol</title>
        <author>
            <name>L. McLaughlin</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24324</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>LPDP</kw>
        </keywords>
        <abstract>This RFC describes an existing print server protocol widely used on the Internet for communicating between line printer daemons (both clients and servers). This memo is for informational purposes only, and does not specify an Internet standard. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1180</doc-id>
        <title>TCP/IP tutorial</title>
        <author>
            <name>T.J. Socolofsky</name>
        </author>
        <author>
            <name>C.J. Kale</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>65494</char-count>
            <page-count>28</page-count>
        </format>
        <abstract>This RFC is a tutorial on the TCP-IP protocol suite, focusing particularly on the steps in forwarding an IP datagram from source host to destination host through a router. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1181</doc-id>
        <title>RIPE Terms of Reference</title>
        <author>
            <name>R. Blokzijl</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2523</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>This RFC describes the Terms of Reference of RIPE (Reseaux IP Europeens), the cooperation of European IP networks. This memo provides information for the Internet community. It does not specify any standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC1182</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC1183</doc-id>
        <title>New DNS RR Definitions</title>
        <author>
            <name>C.F. Everhart</name>
        </author>
        <author>
            <name>L.A. Mamakos</name>
        </author>
        <author>
            <name>R. Ullmann</name>
        </author>
        <author>
            <name>P.V. Mockapetris</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23788</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>DNS-RR</kw>
        </keywords>
        <abstract>This memo defines five new DNS types for experimental purposes. This RFC describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements. </abstract>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1184</doc-id>
        <title>Telnet Linemode Option</title>
        <author>
            <name>D.A. Borman</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53085</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>TOPT-LINE</kw>
        </keywords>
        <abstract>This RFC specifies a procedure for line at a time terminal interaction based on the Telnet Protocol. It obsoletes RFC 1116. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1116</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1185</doc-id>
        <title>TCP Extension for High-Speed Paths</title>
        <author>
            <name>V. Jacobson</name>
        </author>
        <author>
            <name>R.T. Braden</name>
        </author>
        <author>
            <name>L. Zhang</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49508</char-count>
            <page-count>21</page-count>
        </format>
        <abstract>This memo describes an Experimental Protocol extension to TCP for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. </abstract>
        <obsoleted-by>
            <doc-id>RFC1323</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1186</doc-id>
        <title>MD4 Message Digest Algorithm</title>
        <author>
            <name>R.L. Rivest</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35391</char-count>
            <page-count>18</page-count>
        </format>
        <abstract>This RFC is the specification of the MD4 Digest Algorithm. If you are going to implement MD4, it is suggested you do it this way. This memo is for informational use and does not constitute a standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1320</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1187</doc-id>
        <title>Bulk Table Retrieval with the SNMP</title>
        <author>
            <name>M.T. Rose</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>J.R. Davin</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27220</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>SNMP-BULK</kw>
        </keywords>
        <abstract>This memo reports an interesting family of algorithms for bulk table retrieval using the Simple Network Management Protocol (SNMP). This memo describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements. This memo does not specify a standard for the Internet community. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1188</doc-id>
        <title>Proposed Standard for the Transmission of IP Datagrams over FDDI Networks</title>
        <author>
            <name>D. Katz</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22424</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This memo defines a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1103</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1189</doc-id>
        <title>Common Management Information Services and Protocols for the Internet (CMOT and CMIP)</title>
        <author>
            <name>U.S. Warrier</name>
        </author>
        <author>
            <name>L. Besaw</name>
        </author>
        <author>
            <name>L. LaBarre</name>
        </author>
        <author>
            <name>B.D. Handspicker</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32928</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>CMOT</kw>
        </keywords>
        <abstract>This memo defines a network management architecture that uses the International Organization for Standardization's (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP) in the Internet. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1095</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1190</doc-id>
        <title>Experimental Internet Stream Protocol: Version 2 (ST-II)</title>
        <author>
            <name>C. Topolcic</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>386909</char-count>
            <page-count>148</page-count>
        </format>
        <abstract>This memo defines a revised version of the Internet Stream Protocol, originally defined in IEN-119 [8], based on results from experiments with the original version, and subsequent requests, discussion, and suggestions for improvements. This is a Limited-Use Experimental Protocol. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. </abstract>
        <obsoletes>
            <doc-id>IEN119</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1819</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1191</doc-id>
        <title>Path MTU discovery</title>
        <author>
            <name>J.C. Mogul</name>
        </author>
        <author>
            <name>S.E. Deering</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47936</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>IP-MTU</kw>
        </keywords>
        <abstract>This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice. [STANDARDS- TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1063</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1192</doc-id>
        <title>Commercialization of the Internet summary report</title>
        <author>
            <name>B. Kahin</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35253</char-count>
            <page-count>13</page-count>
        </format>
        <abstract>This memo is based on a workshop held by the Science, Technology and Public Policy Program of the John F. Kennedy School of Government, Harvard University, March 1-3, 1990. This memo provides information for the Internet community. It does not specify any standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1193</doc-id>
        <title>Client requirements for real-time communication services</title>
        <author>
            <name>D. Ferrari</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>61540</char-count>
            <page-count>24</page-count>
        </format>
        <abstract>This memo describes client requirements for real-time communication services. This memo provides information for the Internet community, and requests discussion and suggestions for improvements. It does not specify any standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1194</doc-id>
        <title>Finger User Information Protocol</title>
        <author>
            <name>D.P. Zimmerman</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24626</char-count>
            <page-count>12</page-count>
        </format>
        <abstract>This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program. Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC0742</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1196</doc-id>
            <doc-id>RFC1288</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1195</doc-id>
        <title>Use of OSI IS-IS for routing in TCP/IP and dual environments</title>
        <author>
            <name>R.W. Callon</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>187866</char-count>
            <page-count>85</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>362052</char-count>
        </format>
        <keywords>
            <kw>IS-IS</kw>
        </keywords>
        <abstract>This memo specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering Task Force. [STANDARDS-TRACK] </abstract>
        <updated-by>
            <doc-id>RFC1349</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1196</doc-id>
        <title>Finger User Information Protocol</title>
        <author>
            <name>D.P. Zimmerman</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24799</char-count>
            <page-count>12</page-count>
        </format>
        <abstract>This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program. Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. This edition corrects and clarifies in a minor way, RFC 1194. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1194</doc-id>
            <doc-id>RFC0742</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1288</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1197</doc-id>
        <title>Using ODA for translating multimedia information</title>
        <author>
            <name>M. Sherman</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1990</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3620</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>The purpose of this RFC is to inform implementors of multimedia systems about our experiences using ISO 8613: Office Document Architecture (ODA). Because ODA is being proposed as an encoding format for use in multimedia mail and file exchange, implementors wishing to use ODA in an open systems environment may profit from our experiences. This memo provides information for the Internet community. It does not specify any standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1198</doc-id>
        <title>FYI on the X window system</title>
        <author>
            <name>R.W. Scheifler</name>
        </author>
        <date>
            <month>January</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3629</char-count>
            <page-count>3</page-count>
        </format>
        <abstract>This FYI RFC provides pointers to the published standards of the MIT X Consortium. This memo provides information for the Internet community. It does not specify any Internet standard. </abstract>
        <is-also>
            <doc-id>FYI0006</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1199</doc-id>
        <title>Request for Comments Summary Notes: 1100-1199</title>
        <author>
            <name>J. Reynolds</name>
        </author>
        <date>
            <month>December</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46443</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>Summary</kw>
            <kw>RFC</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1200</doc-id>
        <title>IAB official protocol standards</title>
        <author>
            <name>Defense Advanced Research Projects Agency</name>
        </author>
        <author>
            <name>Internet Activities Board</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>67069</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>IAB</kw>
            <kw>official</kw>
            <kw>protocol</kw>
            <kw>standards</kw>
        </keywords>
        <abstract>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information. </abstract>
        <obsoletes>
            <doc-id>RFC1140</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1250</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1201</doc-id>
        <title>Transmitting IP traffic over ARCNET networks</title>
        <author>
            <name>D. Provan</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16959</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>IP-ARC</kw>
        </keywords>
        <abstract>This memo defines a protocol for the transmission of IP and ARP packets over the ARCnet Local Area Network.This memo specifies a method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams for transmission across ARCNET using the "ARCNET Packet Header Definition Standard". [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1051</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0046</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1202</doc-id>
        <title>Directory Assistance service</title>
        <author>
            <name>M.T. Rose</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21645</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>DAS</kw>
        </keywords>
        <abstract>This document defines a mechanism by which a user-interface may access a textual DAP-like interface over a TCP/IP connection. This is a local mechanism. This memo provides information for the Internet community. It does not specify any standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1203</doc-id>
        <title>Interactive Mail Access Protocol: Version 3</title>
        <author>
            <name>J. Rice</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>123325</char-count>
            <page-count>49</page-count>
        </format>
        <keywords>
            <kw>IMAP3</kw>
        </keywords>
        <abstract>This RFC suggests a method for workstations to access mail dynamically from a mailbox server ("repository"). The following document is a modified version of RFC 1064, the definition of the IMAP2 protocol. This RFC specifies an Experimental Protocol for the Internet community. It does not specify any standard. </abstract>
        <obsoletes>
            <doc-id>RFC1064</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1204</doc-id>
        <title>Message Posting Protocol (MPP)</title>
        <author>
            <name>S. Yeh</name>
        </author>
        <author>
            <name>D. Lee</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11371</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>MPP</kw>
        </keywords>
        <abstract>This memo describes a protocol for posting messages from workstations (e.g., PCs) to a mail service host. This RFC specifies an Experimental Protocol for the Internet community. It does not specify any standard. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1205</doc-id>
        <title>5250 Telnet interface</title>
        <author>
            <name>P. Chmielewski</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27179</char-count>
            <page-count>12</page-count>
        </format>
        <abstract>This RFC is being distributed in order to document the interface to the IBM 5250 Telnet implementation. This memo provides information for the Internet community. It does not specify any standard. </abstract>
        <updated-by>
            <doc-id>RFC2877</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1206</doc-id>
        <title>FYI on Questions and Answers: Answers to commonly asked "new Internet user" questions</title>
        <author>
            <name>G.S. Malkin</name>
        </author>
        <author>
            <name>A.N. Marine</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>72479</char-count>
            <page-count>32</page-count>
        </format>
        <abstract>This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [FYI 4] </abstract>
        <obsoletes>
            <doc-id>RFC1177</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1325</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1207</doc-id>
        <title>FYI on Questions and Answers: Answers to commonly asked "experienced Internet user" questions</title>
        <author>
            <name>G.S. Malkin</name>
        </author>
        <author>
            <name>A.N. Marine</name>
        </author>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <date>
            <month>February</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33385</char-count>
            <page-count>15</page-count>
        </format>
        <abstract>This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. </abstract>
        <is-also>
            <doc-id>FYI0007</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1208</doc-id>
        <title>Glossary of networking terms</title>
        <author>
            <name>O.J. Jacobsen</name>
        </author>
        <author>
            <name>D.C. Lynch</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41156</char-count>
            <page-count>18</page-count>
        </format>
        <abstract>This RFC is a glossary adapted from "The INTEROP Pocket Glossary of Networking Terms" distributed at Interop '90. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1209</doc-id>
        <title>Transmission of IP datagrams over the SMDS Service</title>
        <author>
            <name>D.M. Piscitello</name>
        </author>
        <author>
            <name>J. Lawrence</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25280</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>IP-SMDS</kw>
        </keywords>
        <abstract>This memo defines a protocol for the transmission of IP and ARP packets over a Switched Multi-megabit Data Service Network configured as a logical IP subnetwork. [STANDARDS-TRACK] </abstract>
        <is-also>
            <doc-id>STD0052</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1210</doc-id>
        <title>Network and infrastructure user requirements for transatlantic research collaboration: Brussels, July 16-18, and Washington July 24-25, 1990</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <author>
            <name>P.T. Kirstein</name>
        </author>
        <author>
            <name>B. Randell</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>79048</char-count>
            <page-count>36</page-count>
        </format>
        <abstract>This report complements a shorter printed version which appeared in a summary report of all the committees which met in Brussels and Washington last July, 1990. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1211</doc-id>
        <title>Problems with the maintenance of large mailing lists</title>
        <author>
            <name>A. Westine</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>96167</char-count>
            <page-count>54</page-count>
        </format>
        <abstract>This RFC discusses problems with maintaining large mailing lists, especially the processing of error reports. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1212</doc-id>
        <title>Concise MIB definitions</title>
        <author>
            <name>M.T. Rose</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43579</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>Concise-MIB</kw>
        </keywords>
        <abstract>This memo describes a straight-forward approach toward producing concise, yet descriptive, MIB modules. This memo defines a format for producing MIB modules. [STANDARDS-TRACK] </abstract>
        <is-also>
            <doc-id>STD0016</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1213</doc-id>
        <title>Management Information Base for Network Management of TCP/IP-based internets:MIB-II</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M.T. Rose</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>146080</char-count>
            <page-count>70</page-count>
        </format>
        <keywords>
            <kw>MIB-II</kw>
        </keywords>
        <abstract>This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1158</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC2011</doc-id>
            <doc-id>RFC2012</doc-id>
            <doc-id>RFC2013</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0017</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1214</doc-id>
        <title>OSI internet management: Management Information Base</title>
        <author>
            <name>L. LaBarre</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>172564</char-count>
            <page-count>83</page-count>
        </format>
        <keywords>
            <kw>OIM-MIB-II</kw>
        </keywords>
        <abstract>This RFC documents a MIB for use with CMIP, either over pure OSI stacks or with the CMIP over TCP specification. It redefines objects comprised by the second revision of the Management Information Base for Network Management of TCP/IP-based internets: MIB-II so as to conform to the OSI structure of management information. [STANDARDS-TRACK] </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1215</doc-id>
        <title>Convention for defining traps for use with the SNMP</title>
        <author>
            <name>M.T. Rose</name>
        </author>
        <date>
            <month>March</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19336</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>SNMP-TRAPS</kw>
        </keywords>
        <abstract>This memo suggests a straight-forward approach towards defining traps used with the SNMP. This memo provides information for the Internet community. It does not specify any standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1216</doc-id>
        <title>Gigabit network economics and paradigm shifts</title>
        <author>
            <name>P. Richard</name>
        </author>
        <author>
            <name>P. Kynikos</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8130</char-count>
            <page-count>4</page-count>
        </format>
        <abstract>This memo proposes a new standard paradigm for the Internet Activities Board (IAB) standardization track. [STANDARDS-TRACK] </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1217</doc-id>
        <title>Memo from the Consortium for Slow Commotion Research (CSCR)</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11079</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>This RFC is in response to RFC 1216, "Gigabit Network Economics and Paradigm Shifts". This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1218</doc-id>
        <title>Naming scheme for c=US</title>
        <author>
            <name>North American Directory Forum</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42698</char-count>
            <page-count>23</page-count>
        </format>
        <abstract>This RFC is a near-verbatim copy of a document, known as NADF-123, which has been produced by the North American Directory Forum (NADF). As a part of its charter, the NADF must reach agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1255</doc-id>
            <doc-id>RFC1417</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1219</doc-id>
        <title>On the assignment of subnet numbers</title>
        <author>
            <name>P.F. Tsuchiya</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30609</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>SUBNETASGN</kw>
        </keywords>
        <abstract>This memo suggests a new procedure for assigning subnet numbers. Use of this assignment technique within a network would be a purely local matter, and would not effect other networks. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1220</doc-id>
        <title>Point-to-Point Protocol extensions for bridging</title>
        <author>
            <name>F. Baker</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38165</char-count>
            <page-count>18</page-count>
        </format>
        <abstract>This document defines an extension of the Internet Point-to-Point Protocol (PPP) described in RFC 1171, targeting the use of Point-to- Point lines for Remote Bridging. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1638</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1221</doc-id>
        <title>Host Access Protocol (HAP) specification: Version 2</title>
        <author>
            <name>W. Edmond</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>152740</char-count>
            <page-count>68</page-count>
        </format>
        <keywords>
            <kw>HAP2</kw>
        </keywords>
        <abstract>This memo describes the Host Access Protocol implemented in the Terrestrial Wideband Network (TWBNET). This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <updates>
            <doc-id>RFC0907</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1222</doc-id>
        <title>Advancing the NSFNET routing architecture</title>
        <author>
            <name>H.W. Braun</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15067</char-count>
            <page-count>6</page-count>
        </format>
        <abstract>This RFC suggests improvements in the NSFNET routing architecture to accommodate a more flexible interface to the Backbone clients. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1223</doc-id>
        <title>OSI CLNS and LLC1 protocols on Network Systems HYPERchannel</title>
        <author>
            <name>J.M. Halpern</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29601</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>OSI-HYPER</kw>
        </keywords>
        <abstract>The intent of this document is to provide a complete discussion of the protocols and techniques used to transmit OSI CLNS and LLC1 datagrams (and any associated higher level protocols) on Network Systems Corporation's HYPERchannel equipment.This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1224</doc-id>
        <title>Techniques for managing asynchronously generated alerts</title>
        <author>
            <name>L. Steinberg</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54303</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>ALERTS</kw>
        </keywords>
        <abstract>This memo defines common mechanisms for managing asynchronously produced alerts in a manner consistent with current network management protocols. This memo specifies an Experimental Protocol for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1225</doc-id>
        <title>Post Office Protocol: Version 3</title>
        <author>
            <name>M.T. Rose</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37340</char-count>
            <page-count>16</page-count>
        </format>
        <abstract>This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1081</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1460</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1226</doc-id>
        <title>Internet protocol encapsulation of AX.25 frames</title>
        <author>
            <name>B. Kantor</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2573</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>IP-AX.25</kw>
        </keywords>
        <abstract>This memo describes a method for the encapsulation of AX.25 (the Amateur Packet-Radio Link-Layer Protocol) frames within IP packets. This technique is an Experimental Protocol for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1227</doc-id>
        <title>SNMP MUX protocol and MIB</title>
        <author>
            <name>M.T. Rose</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25868</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>SNMP-MUX</kw>
        </keywords>
        <abstract>This memo suggests a mechanism by which a user process may associate itself with the local SNMP agent on a host, in order to implement portions of the MIB. This mechanism would be local to the host.This is an Experimental Protocol for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1228</doc-id>
        <title>SNMP-DPI: Simple Network Management Protocol Distributed Program Interface</title>
        <author>
            <name>G. Carpenter</name>
        </author>
        <author>
            <name>B. Wijnen</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>96972</char-count>
            <page-count>50</page-count>
        </format>
        <abstract>This RFC describes a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This is an Experimental Protocol for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1592</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1229</doc-id>
        <title>Extensions to the generic-interface MIB</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36022</char-count>
            <page-count>16</page-count>
        </format>
        <abstract>This RFC contains definitions of managed objects used as experimental extensions to the generic interfaces structure of MIB-II. [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1573</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC1239</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1230</doc-id>
        <title>IEEE 802.4 Token Bus MIB</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>R. Fox</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53100</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>802.4-MIP</kw>
        </keywords>
        <abstract>This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.4 Token Bus technology described in 802.4 Token-Passing Bus Access Method and Physical Layer Specifications, IEEE Standard 802.4. [STANDARDS-TRACK] </abstract>
        <updated-by>
            <doc-id>RFC1239</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1231</doc-id>
        <title>IEEE 802.5 Token Ring MIB</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>R. Fox</name>
        </author>
        <author>
            <name>E. Decker</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53542</char-count>
            <page-count>23</page-count>
        </format>
        <abstract>This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1743</doc-id>
            <doc-id>RFC1748</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC1239</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1232</doc-id>
        <title>Definitions of managed objects for the DS1 Interface type</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>C.P. Kolb</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>60757</char-count>
            <page-count>28</page-count>
        </format>
        <obsoleted-by>
            <doc-id>RFC1406</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC1239</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1233</doc-id>
        <title>Definitions of managed objects for the DS3 Interface type</title>
        <author>
            <name>T.A. Cox</name>
        </author>
        <author>
            <name>K. Tesink</name>
        </author>
        <date>
            <month>May</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49559</char-count>
            <page-count>23</page-count>
        </format>
        <abstract>This memo defines objects for managing DS3 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1407</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC1239</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1234</doc-id>
        <title>Tunneling IPX traffic through IP networks</title>
        <author>
            <name>D. Provan</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12333</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>IPX-IP</kw>
        </keywords>
        <abstract>This memo describes a method of encapsulating IPX datagrams within UDP packets so that IPX traffic can travel across an IP internet. [STANDARDS-TRACK] This memo defines objects for managing DS1 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1235</doc-id>
        <title>Coherent File Distribution Protocol</title>
        <author>
            <name>J. Ioannidis</name>
        </author>
        <author>
            <name>G. Maguire</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29345</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>CFDP</kw>
        </keywords>
        <abstract>This memo describes the Coherent File Distribution Protocol (CFDP). This is an Experimental Protocol for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1236</doc-id>
        <title>IP to X.121 address mapping for DDN</title>
        <author>
            <name>L. Morales</name>
        </author>
        <author>
            <name>P. Hasse</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12626</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>IP-X.121</kw>
        </keywords>
        <abstract>This memo defines a standard way of converting IP addresses to CCITT X.121 addresses and is the recommended standard for use on the Internet, specifically for the Defense Data Network (DDN). This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1237</doc-id>
        <title>Guidelines for OSI NSAP Allocation in the Internet</title>
        <author>
            <name>R. Colella</name>
        </author>
        <author>
            <name>E. Gardner</name>
        </author>
        <author>
            <name>R. Callon</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>116989</char-count>
            <page-count>48</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>160478</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>171423</char-count>
        </format>
        <abstract>This paper provides guidelines for allocating NSAPs in the Internet.[STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1629</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1238</doc-id>
        <title>CLNS MIB for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542)</title>
        <author>
            <name>G. Satz</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>65159</char-count>
            <page-count>32</page-count>
        </format>
        <keywords>
            <kw>CLNS-MIB</kw>
        </keywords>
        <abstract>This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This is an Experimental Protocol for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoletes>
            <doc-id>RFC1162</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1239</doc-id>
        <title>Reassignment of experimental MIBs to standard MIBs</title>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3656</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>STD-MIBs</kw>
        </keywords>
        <abstract>This memo specifically updates RFC 1229, RFC 1230, RFC 1231, RFC 1232 and RFC 1233 with new codes. [STANDARDS-TRACK] </abstract>
        <updates>
            <doc-id>RFC1229</doc-id>
            <doc-id>RFC1230</doc-id>
            <doc-id>RFC1231</doc-id>
            <doc-id>RFC1232</doc-id>
            <doc-id>RFC1233</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1240</doc-id>
        <title>OSI connectionless transport services on top of UDP: Version 1</title>
        <author>
            <name>C. Shue</name>
        </author>
        <author>
            <name>W. Haggerty</name>
        </author>
        <author>
            <name>K. Dobbins</name>
        </author>
        <date>
            <month>June</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18140</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>OSI-UDP</kw>
        </keywords>
        <abstract>This document describes a protocol for running OSI Connectionless service on UDP. [STANDARDS-TRACK] </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1241</doc-id>
        <title>Scheme for an internet encapsulation protocol: Version 1</title>
        <author>
            <name>R.A. Woodburn</name>
        </author>
        <author>
            <name>D.L. Mills</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42468</char-count>
            <page-count>17</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>128921</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>44593</char-count>
        </format>
        <keywords>
            <kw>IN-ENCAP</kw>
        </keywords>
        <abstract>This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1242</doc-id>
        <title>Benchmarking terminology for network interconnection devices</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22817</char-count>
            <page-count>12</page-count>
        </format>
        <abstract>This memo discusses and defines a number of terms that are used in describing performance benchmarking tests and the results of such tests. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1243</doc-id>
        <title>AppleTalk Management Information Base</title>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>61985</char-count>
            <page-count>29</page-count>
        </format>
        <abstract>This memo defines objects for managing AppleTalk objects for use with the SNMP protocol. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1742</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1244</doc-id>
        <title>Site Security Handbook</title>
        <author>
            <name>J.P. Holbrook</name>
        </author>
        <author>
            <name>J.K. Reynolds</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>259129</char-count>
            <page-count>101</page-count>
        </format>
        <abstract>This FYI RFC is a first attempt at providing Internet users guidance on how to deal with security issues in the Internet. This FYI RFC provides information for the Internet community. It does not specify an Internet standard. [FYI 8] </abstract>
        <obsoleted-by>
            <doc-id>RFC2196</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1245</doc-id>
        <title>OSPF Protocol Analysis</title>
        <author>
            <name>J. Moy</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26160</char-count>
            <page-count>12</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>33546</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>31723</char-count>
        </format>
        <keywords>
            <kw>OSPF</kw>
            <kw>SPF</kw>
            <kw>routing</kw>
            <kw>TOS</kw>
            <kw>LSA</kw>
            <kw>flooding</kw>
        </keywords>
        <abstract>This report attempts to summarize the key features of OSPF V2. It also attempts to analyze how the protocol will perform and scale in the Internet. This memo provides information for the Internet community. It does not specify any Internet standard. </abstract>
        <see-also>
            <doc-id>RFC1247</doc-id>
            <doc-id>RFC1246</doc-id>
        </see-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1246</doc-id>
        <title>Experience with the OSPF Protocol</title>
        <author>
            <name>J. Moy</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>70441</char-count>
            <page-count>31</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>141924</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>84633</char-count>
        </format>
        <keywords>
            <kw>OSPF</kw>
            <kw>SPF</kw>
            <kw>routing</kw>
            <kw>MIB</kw>
            <kw>experience</kw>
            <kw>testing</kw>
        </keywords>
        <abstract>This report documents experience with OSPF V2. This includes reports on interoperability testing, field experience, simulations and the current state of OSPF implementations. This memo provides information for the Internet community. It does not specify any Internet standard. </abstract>
        <see-also>
            <doc-id>RFC1247</doc-id>
            <doc-id>RFC1245</doc-id>
        </see-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1247</doc-id>
        <title>OSPF Version 2</title>
        <author>
            <name>J. Moy</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>433332</char-count>
            <page-count>189</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>989724</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>490300</char-count>
        </format>
        <keywords>
            <kw>equal-cost</kw>
            <kw>multipath</kw>
            <kw>link state</kw>
            <kw>LSA</kw>
        </keywords>
        <abstract>This memo documents version 2 of the OSPF protocol. OSPF is a link- state based routing protocol. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1131</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1583</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC1349</doc-id>
        </updated-by>
        <see-also>
            <doc-id>RFC1246</doc-id>
            <doc-id>RFC1245</doc-id>
        </see-also>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1248</doc-id>
        <title>OSPF Version 2 Management Information Base</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>R. Coltun</name>
        </author>
        <date>
            <month>July</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>74347</char-count>
            <page-count>42</page-count>
        </format>
        <keywords>
            <kw>OSPF</kw>
            <kw>SPF</kw>
            <kw>MIB</kw>
            <kw>routing</kw>
            <kw>network management</kw>
        </keywords>
        <abstract>This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1252</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC1349</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1249</doc-id>
        <title>DIXIE Protocol Specification</title>
        <author>
            <name>T. Howes</name>
        </author>
        <author>
            <name>M. Smith</name>
        </author>
        <author>
            <name>B. Beecher</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20028</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>DIXIE</kw>
            <kw>DIXIE</kw>
            <kw>protocol</kw>
            <kw>directory services</kw>
            <kw>X.500</kw>
            <kw>DAP</kw>
        </keywords>
        <abstract>This RFC defines a mechanism by which TCP/UDP based clients can access OSI Directory Service without the overhead of the ISO transport and presentation protocols required to implement full-blown DAP. This memo provides information for the Internet community. It does not specify any standard. </abstract>
        <see-also>
            <doc-id>RFC1202</doc-id>
        </see-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1250</doc-id>
        <title>IAB Official Protocol Standards</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>62555</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>standards</kw>
            <kw>protocol</kw>
            <kw>IAB</kw>
        </keywords>
        <abstract>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoletes>
            <doc-id>RFC1200</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2200</doc-id>
            <doc-id>RFC1280</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1251</doc-id>
        <title>Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>70383</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>IESG</kw>
            <kw>IRSG</kw>
            <kw>IAB</kw>
        </keywords>
        <abstract>This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 9] </abstract>
        <obsoleted-by>
            <doc-id>RFC1336</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1252</doc-id>
        <title>OSPF Version 2 Management Information Base</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>R. Coltun</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>74471</char-count>
            <page-count>42</page-count>
        </format>
        <keywords>
            <kw>OSPF</kw>
            <kw>SPF</kw>
            <kw>MIB</kw>
            <kw>routing</kw>
            <kw>network management</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS- TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1248</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1253</doc-id>
        </obsoleted-by>
        <see-also>
            <doc-id>RFC1247</doc-id>
            <doc-id>RFC1245</doc-id>
        </see-also>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1253</doc-id>
        <title>OSPF Version 2 Management Information Base</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>R. Coltun</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>74453</char-count>
            <page-count>42</page-count>
        </format>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS- TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1252</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1850</doc-id>
        </obsoleted-by>
        <see-also>
            <doc-id>RFC1247</doc-id>
            <doc-id>RFC1245</doc-id>
            <doc-id>RFC1246</doc-id>
        </see-also>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1254</doc-id>
        <title>Gateway Congestion Control Survey</title>
        <author>
            <name>A. Mankin</name>
        </author>
        <author>
            <name>K. Ramakrishnan</name>
        </author>
        <date>
            <month>August</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>67609</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>gateway</kw>
            <kw>congestion</kw>
            <kw>SQ</kw>
            <kw>source quench</kw>
            <kw>fiar queueing</kw>
            <kw>random drop</kw>
        </keywords>
        <abstract>The purpose of this paper is to present a review of the congestion control approaches, as a way of encouraging new discussion and experimentation. Included in the survey are Source Quench, Random Drop, Congestion Indication (DEC Bit), and Fair Queueing. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1255</doc-id>
        <title>A Naming Scheme for c=US</title>
        <author>
            <name>The North American Directory Forum</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51103</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>naming</kw>
            <kw>NADF</kw>
            <kw>X.500</kw>
            <kw>directory services</kw>
            <kw>c=us</kw>
        </keywords>
        <abstract>This memo documents the NADF's agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoletes>
            <doc-id>RFC1218</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1417</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1256</doc-id>
        <title>ICMP Router Discovery Messages</title>
        <author>
            <name>S. Deering</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43059</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>ICMP-ROUT</kw>
            <kw>ICMP</kw>
            <kw>router</kw>
            <kw>gateway</kw>
            <kw>discovery</kw>
            <kw>standard</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document specifies an extension of the Internet Control Message Protocol (ICMP) to enable hosts attached to multicast or broadcast networks to discover the IP addresses of their neighboring routers. [STANDARDS-TRACK] </abstract>
        <see-also>
            <doc-id>RFC0792</doc-id>
        </see-also>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1257</doc-id>
        <title>Isochronous applications do not require jitter-controlled networks</title>
        <author>
            <name>C. Partridge</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11075</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>This memo argues that jitter control is not required for networks to support isochronous applications. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1258</doc-id>
        <title>BSD Rlogin</title>
        <author>
            <name>B. Kantor</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10763</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>The rlogin facility provides a remote-echoed, locally flow-controlled virtual terminal with proper flushing of output.This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1259</doc-id>
        <title>Building the open road: The NREN as test-bed for the national public network</title>
        <author>
            <name>M. Kapor</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>61654</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>NREN</kw>
            <kw>test-bed</kw>
            <kw>network policy</kw>
        </keywords>
        <abstract>This memo discusses the background and importance of NREN. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC1260</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC1261</doc-id>
        <title>Transition of Nic Services</title>
        <author>
            <name>S. Williamson</name>
        </author>
        <author>
            <name>L. Nobile</name>
        </author>
        <date>
            <month>September</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4244</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>NIC</kw>
            <kw>transition</kw>
        </keywords>
        <abstract>This memo outlines the transition of NIC Services. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1262</doc-id>
        <title>Guidelines for Internet Measurement Activities</title>
        <author>
            <name>V.G. Cerf</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6381</char-count>
            <page-count>3</page-count>
        </format>
        <abstract>This RFC represents IAB guidance for researchers considering measurement experiments on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1263</doc-id>
        <title>TCP Extensions Considered Harmful</title>
        <author>
            <name>S. O'Malley</name>
        </author>
        <author>
            <name>L.L. Peterson</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54078</char-count>
            <page-count>19</page-count>
        </format>
        <abstract>This RFC comments on recent proposals to extend TCP. It argues that the backward compatible extensions proposed in RFC's 1072 and 1185 should not be pursued, and proposes an alternative way to evolve the Internet protocol suite. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1264</doc-id>
        <title>Internet Engineering Task Force Internet Routing Protocol Standardization Criteria</title>
        <author>
            <name>R.M. Hinden</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17016</char-count>
            <page-count>8</page-count>
        </format>
        <abstract>This informational RFC presents procedures for creating and documenting Internet standards on routing protocols. These procedures have been established by the Internet Activities Board (IAB) in consultation with the Internet Engineering Steering Group (IESG). This memo provides information for the Internet community. It does not specifiy an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1265</doc-id>
        <title>BGP Protocol Analysis</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20728</char-count>
            <page-count>8</page-count>
        </format>
        <abstract>This report summarizes the key feature of BGP, and analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1266</doc-id>
        <title>Experience with the BGP Protocol</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21938</char-count>
            <page-count>9</page-count>
        </format>
        <abstract>The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol (BGP). This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1267</doc-id>
        <title>Border Gateway Protocol 3 (BGP-3)</title>
        <author>
            <name>K. Lougheed</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>80724</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
            <kw>BGP3</kw>
        </keywords>
        <abstract>This memo, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1163</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1268</doc-id>
        <title>Application of the Border Gateway Protocol in the Internet</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>P. Gross</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31102</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>BGP3</kw>
        </keywords>
        <abstract>This document describes the usage of the BGP in the Internet. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1164</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1655</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1269</doc-id>
        <title>Definitions of Managed Objects for the Border Gateway Protocol: Version 3</title>
        <author>
            <name>S. Willis</name>
        </author>
        <author>
            <name>J.W. Burruss</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25717</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>BGP-MIB</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Border Gateway Protocol. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1270</doc-id>
        <title>SNMP Communications Services</title>
        <author>
            <name>F. Kastenholz</name>
        </author>
        <date>
            <month>October</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26167</char-count>
            <page-count>11</page-count>
        </format>
        <abstract>This document discusses various issues to be considered when determining the underlying communications services to be used by an SNMP implementation. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1271</doc-id>
        <title>Remote Network Monitoring Management Information Base</title>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>184111</char-count>
            <page-count>81</page-count>
        </format>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1757</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC1513</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1272</doc-id>
        <title>Internet Accounting: Background</title>
        <author>
            <name>C. Mills</name>
        </author>
        <author>
            <name>D. Hirsh</name>
        </author>
        <author>
            <name>G.R. Ruth</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46562</char-count>
            <page-count>19</page-count>
        </format>
        <abstract>This document provides background information for the "Internet Accounting Architecture". This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1273</doc-id>
        <title>Measurement Study of Changes in Service-Level Reachability in the Global TCP/IP Internet: Goals, Experimental Design, Implementation, and Policy Considerations</title>
        <author>
            <name>M.F. Schwartz</name>
        </author>
        <date>
            <month>November</month>
            <day>01</day>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19949</char-count>
            <page-count>8</page-count>
        </format>
        <abstract>This memo describes plans to carry out a longitudinal measurement study of changes in service-level reachability in the global TCP/IP Internet. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1274</doc-id>
        <title>The COSINE and Internet X.500 Schema</title>
        <author>
            <name>P. Barker</name>
        </author>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>November</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>92827</char-count>
            <page-count>60</page-count>
        </format>
        <keywords>
            <kw>Naming</kw>
        </keywords>
        <abstract>This document suggests an X.500 Directory Schema, or Naming Architecture, for use in the COSINE and Internet X.500 pilots. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1275</doc-id>
        <title>Replication Requirements to provide an Internet Directory using X.500</title>
        <author>
            <name>S.E. Hardcastle-Kille</name>
        </author>
        <date>
            <month>November</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4616</char-count>
            <page-count>3</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>83736</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>62498</char-count>
        </format>
        <abstract>This RFC considers certain deficiencies of the 1988 X.500 standard, which need to be addressed before an effective open Internet Directory can be established using these protocols and services [CCI88]. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1276</doc-id>
        <title>Replication and Distributed Operations extensions to provide an Internet Directory using X.500</title>
        <author>
            <name>S.E. Hardcastle-Kille</name>
        </author>
        <date>
            <month>November</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33731</char-count>
            <page-count>17</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>217170</char-count>
        </format>
        <keywords>
        </keywords>
        <abstract>Some requirements on extensions to X.500 are described in the RFC[HK91b], in order to build an Internet Directory using X.500(1988). This document specifies a set of solutions to the problems raised. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1277</doc-id>
        <title>Encoding Network Addresses to Support Operation over Non-OSI Lower Layers</title>
        <author>
            <name>S.E. Hardcastle-Kille</name>
        </author>
        <date>
            <month>November</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22254</char-count>
            <page-count>12</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>176169</char-count>
        </format>
        <keywords>
            <kw>address ISO OSI</kw>
        </keywords>
        <abstract>This document defines a new network address format, and rules for using some existing network address formats. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1278</doc-id>
        <title>A string encoding of Presentation Address</title>
        <author>
            <name>S.E. Hardcastle-Kille</name>
        </author>
        <date>
            <month>November</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10256</char-count>
            <page-count>7</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>128696</char-count>
        </format>
        <keywords>
            <kw>OSI</kw>
            <kw>ASN.1</kw>
        </keywords>
        <abstract>There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1279</doc-id>
        <title>X.500 and Domains</title>
        <author>
            <name>S.E. Hardcastle-Kille</name>
        </author>
        <date>
            <month>November</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26669</char-count>
            <page-count>15</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>170029</char-count>
        </format>
        <keywords>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>naming</kw>
        </keywords>
        <abstract>This RFC considers X.500 in relation to Internet and UK Domains. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1280</doc-id>
        <title>IAB Official Protocol Standards</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>March</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>70458</char-count>
            <page-count>32</page-count>
        </format>
        <abstract>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoletes>
            <doc-id>RFC1250</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1360</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1281</doc-id>
        <title>Guidelines for the Secure Operation of the Internet</title>
        <author>
            <name>R. Pethia</name>
        </author>
        <author>
            <name>S. Crocker</name>
        </author>
        <author>
            <name>B. Fraser</name>
        </author>
        <date>
            <month>November</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22618</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>privacy</kw>
            <kw>protection</kw>
            <kw>guideline</kw>
        </keywords>
        <abstract>The purpose of this document is to provide a set of guidelines to aid in the secure operation of the Internet. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1282</doc-id>
        <title>BSD Rlogin</title>
        <author>
            <name>B. Kantor</name>
        </author>
        <date>
            <month>December</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10704</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>BSD Login</kw>
            <kw>Unix</kw>
            <kw>remote-login</kw>
            <kw>remote-logon </kw>
        </keywords>
        <abstract>This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1283</doc-id>
        <title>SNMP over OSI</title>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>December</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16857</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>ISO</kw>
            <kw>Management</kw>
            <kw>MIB</kw>
        </keywords>
        <abstract>This memo describes mappings from the SNMP onto both the COTS and the CLTS. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet Standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1418</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1284</doc-id>
        <title>Definitions of Managed Objects for the Ethernet-like Interface Types</title>
        <author>
            <name>J. Cook</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43225</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
            <kw>MIB</kw>
            <kw>Management</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1398</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1285</doc-id>
        <title>FDDI Management Information Base</title>
        <author>
            <name>J. Case</name>
        </author>
        <date>
            <month>January</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>99747</char-count>
            <page-count>46</page-count>
        </format>
        <keywords>
            <kw>FDDI-MIB</kw>
            <kw>standard</kw>
            <kw>standards</kw>
            <kw>MIB</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing devices which implement the FDDI. [STANDARDS-TRACK] </abstract>
        <updated-by>
            <doc-id>RFC1512</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1286</doc-id>
        <title>Definitions of Managed Objects for Bridges</title>
        <author>
            <name>E. Decker</name>
        </author>
        <author>
            <name>P. Langille</name>
        </author>
        <author>
            <name>A. Rijsinghani</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>December</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>79104</char-count>
            <page-count>40</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
            <kw>MIB</kw>
            <kw>standard</kw>
            <kw>standards</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing bridges based on the IEEE 802.1d draft standard between Local Area Network (LAN) segments. This memo is an extension to the SNMP MIB. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1493</doc-id>
            <doc-id>RFC1525</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1287</doc-id>
        <title>Towards the Future Internet Architecture</title>
        <author>
            <name>D. Clark</name>
        </author>
        <author>
            <name>L. Chapin</name>
        </author>
        <author>
            <name>V. Cerf</name>
        </author>
        <author>
            <name>R. Braden</name>
        </author>
        <author>
            <name>R. Hobby</name>
        </author>
        <date>
            <month>December</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59812</char-count>
            <page-count>29</page-count>
        </format>
        <abstract>This informational RFC discusses important directions for possible future evolution of the Internet architecture, and suggests steps towards the desired goals. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1288</doc-id>
        <title>The Finger User Information Protocol</title>
        <author>
            <name>D. Zimmerman</name>
        </author>
        <date>
            <month>December</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25161</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>FINGER</kw>
        </keywords>
        <abstract>This memo describes the Finger user information protocol.This is a simple protocol which provides an interface to a remote user information program. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1196</doc-id>
            <doc-id>RFC1194</doc-id>
            <doc-id>RFC0742</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1289</doc-id>
        <title>DECnet Phase IV MIB Extensions</title>
        <author>
            <name>J. Saperia</name>
        </author>
        <date>
            <month>December</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>122272</char-count>
            <page-count>64</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>protocol</kw>
            <kw>standard</kw>
            <kw>standards</kw>
        </keywords>
        <abstract>This memo is an extension to the SNMP MIB. This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1559</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1290</doc-id>
        <title>There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places</title>
        <author>
            <name>J. Martin</name>
        </author>
        <date>
            <month>December</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46997</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>SIGUCCS</kw>
            <kw>User Services</kw>
            <kw>Help</kw>
            <kw>Internet</kw>
        </keywords>
        <abstract>This paper will present some of the "gold nuggets" of information and file repositories on the network that could be of use to end users. This RFC provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1402</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1291</doc-id>
        <title>Mid-Level Networks Potential Technical Services</title>
        <author>
            <name>V. Aggarwal</name>
        </author>
        <date>
            <month>December</month>
            <year>1991</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24314</char-count>
            <page-count>10</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>218918</char-count>
        </format>
        <keywords>
            <kw>statistics</kw>
            <kw>connectivity</kw>
            <kw>management</kw>
        </keywords>
        <abstract>This document proposes a set of technical services that each Internet mid-level network can offer within the mid-level network itself and and to its peer networks. This RFC provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1292</doc-id>
        <title>A Catalog of Available X.500 Implementations</title>
        <author>
            <name>R. Lang</name>
        </author>
        <author>
            <name>R. Wright</name>
        </author>
        <date>
            <month>January</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>129468</char-count>
            <page-count>103</page-count>
        </format>
        <abstract>The goal of this document is to provide information regarding the availability and capability of implementations of X.500. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1632</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1293</doc-id>
        <title>Inverse Address Resolution Protocol</title>
        <author>
            <name>T. Bradley</name>
        </author>
        <author>
            <name>C. Brown</name>
        </author>
        <date>
            <month>January</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11368</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>standard</kw>
            <kw>standards</kw>
            <kw>ARP</kw>
            <kw>DLCI</kw>
        </keywords>
        <abstract>This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2390</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1294</doc-id>
        <title>Multiprotocol Interconnect over Frame Relay</title>
        <author>
            <name>T. Bradley</name>
        </author>
        <author>
            <name>C. Brown</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <date>
            <month>January</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54992</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>standard</kw>
            <kw>standards</kw>
        </keywords>
        <abstract>This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1490</doc-id>
            <doc-id>RFC2427</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1295</doc-id>
        <title>User Bill of Rights for entries and listings in the Public Directory</title>
        <author>
            <name>The North American Directory Forum</name>
        </author>
        <date>
            <month>January</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3502</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>NADF-265</kw>
            <kw>NADF</kw>
            <kw>X.500</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) objects. This document is a companion document with Definitions of Managed Objects for the DS1/E1 and DS3/E3 Interface Types, RFC1406 and RFC1407. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC1417</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1296</doc-id>
        <title>Internet Growth (1981-1991)</title>
        <author>
            <name>M. Lottor</name>
        </author>
        <date>
            <month>January</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20103</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>statistics</kw>
            <kw>ZONE</kw>
        </keywords>
        <abstract>This document illustrates the growth of the Internet by examination of entries in the Domain Name System (DNS) and pre-DNS host tables. This memo provides information for the Internet community. It does not specify an Internet standard. This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service. [STANDARDS-TRACK] </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1297</doc-id>
        <title>NOC Internal Integrated Trouble Ticket System Functional Specification Wishlist ("NOC TT REQUIREMENTS")</title>
        <author>
            <name>D. Johnson</name>
        </author>
        <date>
            <month>January</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32964</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>problems</kw>
            <kw>tracking</kw>
            <kw>operations</kw>
            <kw>NOC</kw>
        </keywords>
        <abstract>This document explores competing uses, architectures, and desirable features of integrated internal trouble ticket systems for Network and other Operations Centers. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1298</doc-id>
        <title>SNMP over IPX</title>
        <author>
            <name>R. Wormley</name>
        </author>
        <author>
            <name>S. Bostock</name>
        </author>
        <date>
            <month>February</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7878</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>This memo defines a convention for encapsulating Simple Network Management Protocol (SNMP) packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1420</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1299</doc-id>
        <title>Summary of 1200-1299</title>
        <author>
            <name>M. Kennedy</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36594</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>Index</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1300</doc-id>
        <title>Remembrances of Things Past</title>
        <author>
            <name>S. Greenfield</name>
        </author>
        <date>
            <month>February</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4963</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>poem</kw>
        </keywords>
        <abstract>Poem. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1301</doc-id>
        <title>Multicast Transport Protocol</title>
        <author>
            <name>S. Armstrong</name>
        </author>
        <author>
            <name>A. Freier</name>
        </author>
        <author>
            <name>K. Marzullo</name>
        </author>
        <date>
            <month>February</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>91976</char-count>
            <page-count>38</page-count>
        </format>
        <keywords>
            <kw>MTP</kw>
            <kw>MTP</kw>
            <kw>reliable transport</kw>
            <kw>multicast</kw>
            <kw>broadcast</kw>
            <kw>collaboration</kw>
            <kw>networking</kw>
        </keywords>
        <abstract>This memo describes a protocol for reliable transport that utilizes the multicast capability of applicable lower layer networking architectures. The transport definition permits an arbitrary number of transport providers to perform realtime collaborations without requiring networking clients (aka, applications) to possess detailed knowledge of the population or geographical dispersion of the participating members. It is not network architectural specific, but does implicitly require some form of multicasting (or broadcasting) at the data link level, as well as some means of communicating that capability up through the layers to the transport. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1302</doc-id>
        <title>Building a Network Information Services Infrastructure</title>
        <author>
            <name>D. Sitzler</name>
        </author>
        <author>
            <name>P. Smith</name>
        </author>
        <author>
            <name>A. Marine</name>
        </author>
        <date>
            <month>February</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29135</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>NISI</kw>
            <kw>NIC</kw>
            <kw>User Services</kw>
        </keywords>
        <abstract>This FYI RFC document is intended for existing Internet Network Information Center (NIC) personnel, people interested in establishing a new NIC, Internet Network Operations Centers (NOCs), and funding agencies interested in contributing to user support facilities. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <is-also>
            <doc-id>FYI0012</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1303</doc-id>
        <title>A Convention for Describing SNMP-based Agents</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>February</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22915</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
            <kw>MIB</kw>
            <kw>Network Management</kw>
        </keywords>
        <abstract>This memo suggests a straight-forward approach towards describing SNMP- based agents. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <see-also>
            <doc-id>RFC1155</doc-id>
            <doc-id>RFC1212</doc-id>
            <doc-id>RFC1213</doc-id>
            <doc-id>RFC1157</doc-id>
        </see-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1304</doc-id>
        <title>Definitions of Managed Objects for the SIP Interface Type</title>
        <author>
            <name>T. Cox</name>
        </author>
        <author>
            <name>K. Tesink</name>
            <title>Editors</title>
        </author>
        <date>
            <month>February</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52491</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>Standard</kw>
            <kw>MIB</kw>
            <kw>Network Management</kw>
            <kw>SMDS</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing SIP (SMDS Interface Protocol) objects. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1694</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1305</doc-id>
        <title>Network Time Protocol (Version 3) Specification, Implementation</title>
        <author>
            <name>D. Mills</name>
        </author>
        <date>
            <month>March</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>307085</char-count>
            <page-count>109</page-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>442493</char-count>
        </format>
        <keywords>
            <kw>NTPV3</kw>
            <kw>NTP</kw>
        </keywords>
        <abstract>This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. [STANDARDS-TRACK] </abstract>
        <notes>There is a "compressed" "tar" file of three postscript files for this RFC.</notes>
        <obsoletes>
            <doc-id>RFC0958</doc-id>
            <doc-id>RFC1059</doc-id>
            <doc-id>RFC1119</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1306</doc-id>
        <title>Experiences Supporting By-Request Circuit-Switched T3 Networks</title>
        <author>
            <name>A. Nicholson</name>
        </author>
        <author>
            <name>J. Young</name>
        </author>
        <date>
            <month>March</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25788</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>WAN</kw>
            <kw>Wide Area Net</kw>
            <kw>FDDI</kw>
        </keywords>
        <abstract>This memo describes the experiences of a project team at Cray Research, Inc., in implementing support for circuit-switched T3 services. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers. This RFC provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1307</doc-id>
        <title>Dynamically Switched Link Control Protocol</title>
        <author>
            <name>J. Young</name>
        </author>
        <author>
            <name>A. Nicholson</name>
        </author>
        <date>
            <month>March</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24145</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>DSLCP</kw>
            <kw>Experimental Protocol</kw>
            <kw>T3</kw>
            <kw>FDDI</kw>
        </keywords>
        <abstract>This memo describes an experimental protocol developed by a project team at Cray Research, Inc., in implementing support for circuit-switched T3 services. The protocol is used for the control of network connections external to a host, but known to the host. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1308</doc-id>
        <title>Executive Introduction to Directory Services Using the X.500 Protocol</title>
        <author>
            <name>C. Weider</name>
        </author>
        <author>
            <name>J. Reynolds</name>
        </author>
        <date>
            <month>March</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9392</char-count>
            <page-count>4</page-count>
        </format>
        <abstract>This document is an Executive Introduction to Directory Services using the X.500 protocol. It briefly discusses the deficiencies in currently deployed Internet Directory Services, and then illustrates the solutions provided by X.500. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <is-also>
            <doc-id>FYI0013</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1309</doc-id>
        <title>Technical Overview of Directory Services Using the X.500 Protocol</title>
        <author>
            <name>C. Weider</name>
        </author>
        <author>
            <name>J. Reynolds</name>
        </author>
        <author>
            <name>S. Heker</name>
        </author>
        <date>
            <month>March</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35694</char-count>
            <page-count>16</page-count>
        </format>
        <abstract>This document is an overview of the X.500 standard for people not familiar with the technology. It compares and contrasts Directory Services based on X.500 with several of the other Directory services currently in use in the Internet. This paper also describes the status of the standard and provides references for further information on X.500 implementations and technical information. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <is-also>
            <doc-id>FYI0014</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1310</doc-id>
        <title>The Internet Standards Process</title>
        <author>
            <name>L. Chapin</name>
        </author>
        <date>
            <month>March</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54738</char-count>
            <page-count>23</page-count>
        </format>
        <abstract>This memo documents the process currently used for the standardization of Internet protocols and procedures. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1602</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1311</doc-id>
        <title>Introduction to the STD Notes</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>March</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11308</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>new</kw>
            <kw>IAB</kw>
        </keywords>
        <abstract>The STDs are a subseries of notes within the RFC series that are the Internet standards. The intent is to identify clearly for the Internet community those RFCs which document Internet standards. [STANDARDS- TRACK] </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1312</doc-id>
        <title>Message Send Protocol 2</title>
        <author>
            <name>R. Nelson</name>
        </author>
        <author>
            <name>G. Arnold</name>
        </author>
        <date>
            <month>April</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18037</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>MSP2</kw>
            <kw>MSP</kw>
            <kw>talk</kw>
        </keywords>
        <abstract>The Message Send Protocol is used to send a short message to a given user on a given terminal on a given host. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoletes>
            <doc-id>RFC1159</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1313</doc-id>
        <title>Today's Programming for KRFC AM 1313 Internet Talk Radio</title>
        <author>
            <name>C. Partridge</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5444</char-count>
            <page-count>3</page-count>
        </format>
        <abstract>Hi and welcome to KRFC Internet Talk Radio, your place on the AM dial for lively talk and just-breaking news on internetworking. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1314</doc-id>
        <title>A File Format for the Exchange of Images in the Internet</title>
        <author>
            <name>A. Katz</name>
        </author>
        <author>
            <name>D. Cohen</name>
        </author>
        <date>
            <month>April</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54072</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>NETFAX</kw>
            <kw>netfax</kw>
            <kw>TIFF</kw>
            <kw>facsimile</kw>
        </keywords>
        <abstract>This document defines a standard file format for the exchange of fax- like black and white images within the Internet. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1315</doc-id>
        <title>Management Information Base for Frame Relay DTEs</title>
        <author>
            <name>C. Brown</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>C. Carvalho</name>
        </author>
        <date>
            <month>April</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33825</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Frame Relay. [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2115</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1316</doc-id>
        <title>Definitions of Managed Objects for Character Stream Devices</title>
        <author>
            <name>B. Stewart</name>
        </author>
        <date>
            <month>April</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35143</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for the management of character stream devices. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1658</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1317</doc-id>
        <title>Definitions of Managed Objects for RS-232-like Hardware Devices</title>
        <author>
            <name>B. Stewart</name>
        </author>
        <date>
            <month>April</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30442</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>MIB	</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for the management of RS-232-like devices. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1659</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1318</doc-id>
        <title>Definitions of Managed Objects for Parallel-printer-like Hardware Devices</title>
        <author>
            <name>B. Stewart</name>
        </author>
        <date>
            <month>April</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19570</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for the management of parallel-printer- like devices. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1660</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1319</doc-id>
        <title>The MD2 Message-Digest Algorithm</title>
        <author>
            <name>B. Kaliski</name>
        </author>
        <date>
            <month>April</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25661</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>encryption</kw>
            <kw>signature</kw>
        </keywords>
        <abstract>This document describes the MD2 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1320</doc-id>
        <title>The MD4 Message-Digest Algorithm</title>
        <author>
            <name>R. Rivest</name>
        </author>
        <date>
            <month>April</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32407</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>MD4</kw>
            <kw>security</kw>
            <kw>encryption</kw>
            <kw>signature</kw>
        </keywords>
        <abstract>This document describes the MD4 message-digest algorithm [1]. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoletes>
            <doc-id>RFC1186</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1321</doc-id>
        <title>The MD5 Message-Digest Algorithm </title>
        <author>
            <name>R. Rivest</name>
        </author>
        <date>
            <month>April</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35222</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>signature</kw>
            <kw>eneryption</kw>
        </keywords>
        <abstract>This document describes the MD5 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1322</doc-id>
        <title>A Unified Approach to Inter-Domain Routing</title>
        <author>
            <name>D. Estrin</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>S. Hotz</name>
        </author>
        <date>
            <month>May</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>96934</char-count>
            <page-count>38</page-count>
        </format>
        <keywords>
            <kw>path</kw>
            <kw>vector</kw>
            <kw>routing</kw>
            <kw>source</kw>
            <kw>demand</kw>
            <kw>routing</kw>
        </keywords>
        <abstract>This memo is an informational RFC which outlines one potential approach for inter-domain routing in future global internets. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1323</doc-id>
        <title>TCP Extensions for High Performance</title>
        <author>
            <name>V. Jacobson</name>
        </author>
        <author>
            <name>R. Braden</name>
        </author>
        <author>
            <name>D. Borman</name>
        </author>
        <date>
            <month>May</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>84558</char-count>
            <page-count>37</page-count>
        </format>
        <keywords>
            <kw>TCP-EXT</kw>
            <kw>options</kw>
            <kw>PAWS</kw>
            <kw>window</kw>
            <kw>scale</kw>
            <kw>window</kw>
        </keywords>
        <abstract>This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1072</doc-id>
            <doc-id>RFC1185</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1324</doc-id>
        <title>A Discussion on Computer Network Conferencing</title>
        <author>
            <name>D. Reed</name>
        </author>
        <date>
            <month>May</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24988</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>talk</kw>
            <kw>real time</kw>
            <kw>chat</kw>
        </keywords>
        <abstract>This memo is intended to make more people aware of the present developments in the Computer Conferencing field as well as put forward ideas on what should be done to formalize this work so that there is a common standard for programmers and others who are involved in this field to work with. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1325</doc-id>
        <title>FYI on Questions and Answers Answers to Commonly asked "New Internet User" Questions</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <author>
            <name>A. Marine</name>
        </author>
        <date>
            <month>May</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>91884</char-count>
            <page-count>42</page-count>
        </format>
        <keywords>
            <kw>documentation</kw>
            <kw>help</kw>
            <kw>information</kw>
        </keywords>
        <abstract>This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoletes>
            <doc-id>RFC1206</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1594</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1326</doc-id>
        <title>Mutual Encapsulation Considered Dangerous</title>
        <author>
            <name>P. Tsuchiya</name>
        </author>
        <date>
            <month>May</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11277</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>protocol</kw>
            <kw>layering</kw>
            <kw>wrapping</kw>
        </keywords>
        <abstract>This memo describes a packet explosion problem that can occur with mutual encapsulation of protocols (A encapsulates B and B encapsulates A). This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1327</doc-id>
        <title>Mapping between X.400(1988) / ISO 10021 and RFC 822</title>
        <author>
            <name>S. Hardcastle-Kille</name>
        </author>
        <date>
            <month>May</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>228598</char-count>
            <page-count>113</page-count>
        </format>
        <keywords>
            <kw>Electronic-mail,Message handling systems</kw>
        </keywords>
        <abstract>This document specifies a mapping between two protocols. This specification should be used when this mapping is performed on the DARPA Internet or in the UK Academic Community. This specification may be modified in the light of implementation experience, but no substantial changes are expected. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC0987</doc-id>
            <doc-id>RFC1026</doc-id>
            <doc-id>RFC1138</doc-id>
            <doc-id>RFC1148</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2156</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0822</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC1495</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1328</doc-id>
        <title>X.400 1988 to 1984 downgrading</title>
        <author>
            <name>S. Hardcastle-Kille</name>
        </author>
        <date>
            <month>May</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10006</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>Electronic-mail</kw>
            <kw>message handling systems,mail</kw>
        </keywords>
        <abstract>This document considers issues of downgrading from X.400(1988) to X.400(1984) [MHS88a, MHS84]. Annexe B of X.419 specifies some downgrading rules [MHS88b], but these are not sufficient for provision of service in an environment containing both 1984 and 1988 components. This document defines a number of extensions to this annexe. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1329</doc-id>
        <title>Thoughts on Address Resolution for Dual MAC FDDI Networks</title>
        <author>
            <name>P. Kuehn</name>
        </author>
        <date>
            <month>May</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>58150</char-count>
            <page-count>28</page-count>
        </format>
        <abstract>In this document an idea is submitted how IP and ARP can be used on inhomogeneous FDDI networks (FDDI networks with single MAC and dual MAC stations) by introducing a new protocol layer in the protocol suite of the dual MAC stations. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1330</doc-id>
        <title>Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESNET Community</title>
        <author>
            <name>ESCC X.500/X.400 Task Force</name>
        </author>
        <author>
            <name>ESnet Site Coordinating Comittee (ESCC)</name>
        </author>
        <author>
            <name>Energy Sciences Network (ESnet)</name>
        </author>
        <date>
            <month>May</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>192925</char-count>
            <page-count>87</page-count>
        </format>
        <abstract>This RFC is a near verbatim copy of the whitepaper produced by the ESnet Site Coordinating Committee's X.500/X.400 Task Force. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1331</doc-id>
        <title>The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links</title>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>May</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>129892</char-count>
            <page-count>69</page-count>
        </format>
        <keywords>
            <kw>serial line</kw>
            <kw>IP over serial</kw>
            <kw>dial-up</kw>
        </keywords>
        <abstract>This document defines the PPP encapsulation scheme, together with the PPP Link Control Protocol (LCP), an extensible option negotiation protocol which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS- TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1171</doc-id>
            <doc-id>RFC1172</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1548</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1332</doc-id>
        <title>The PPP Internet Protocol Control Protocol (IPCP)</title>
        <author>
            <name>G. McGregor</name>
        </author>
        <date>
            <month>May</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17613</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>PPP-IPCP</kw>
            <kw>serial line</kw>
            <kw>IP over serial</kw>
            <kw>dial-up</kw>
        </keywords>
        <abstract>The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1172</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3241</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1333</doc-id>
        <title>PPP Link Quality Monitoring</title>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>May</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29965</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>serial line</kw>
            <kw>IP over serial</kw>
            <kw>dial-up</kw>
        </keywords>
        <abstract>The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of a Quality Protocol for continuous monitoring of the viability of the link. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1989</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1334</doc-id>
        <title>PPP Authentication Protocols</title>
        <author>
            <name>B. Lloyd</name>
        </author>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>October</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33248</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>point</kw>
            <kw>serial</kw>
            <kw>line</kw>
            <kw>dial-up</kw>
        </keywords>
        <abstract>This document defines two protocols for Authentication: the Password Authentication Protocol and the Challenge-Handshake Authentication Protocol. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1994</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1335</doc-id>
        <title>A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion</title>
        <author>
            <name>Z. Wang</name>
        </author>
        <author>
            <name>J. Crowcroft</name>
        </author>
        <date>
            <month>May</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15418</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>IP</kw>
        </keywords>
        <abstract>This RFC presents a solution to problem of address space exhaustion in the Internet. It proposes a two-tier address structure for the Internet. This is an "idea" paper and discussion is strongly encouraged. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1336</doc-id>
        <title>Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <date>
            <month>May</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>92119</char-count>
            <page-count>33</page-count>
        </format>
        <keywords>
            <kw>Almquist</kw>
            <kw>Braden</kw>
            <kw>Braun</kw>
            <kw>Callon</kw>
            <kw>Cerf</kw>
            <kw>Chiappa</kw>
            <kw>Chapin</kw>
            <kw>Clark</kw>
            <kw>Crocker</kw>
            <kw>Davin</kw>
            <kw>Estrin</kw>
            <kw>Hobby</kw>
            <kw>Huitema</kw>
            <kw>Huizer</kw>
            <kw>Kent</kw>
            <kw>Lauck</kw>
            <kw>Leiner</kw>
            <kw>Lynch</kw>
            <kw>Piscitello</kw>
            <kw>Postel</kw>
            <kw>Reynolds</kw>
            <kw>Schwartz</kw>
            <kw>Stockman</kw>
            <kw>Vaudreuil</kw>
        </keywords>
        <abstract>This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify any standard. </abstract>
        <obsoletes>
            <doc-id>RFC1251</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>FYI0009</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1337</doc-id>
        <title>TIME-WAIT Assassination Hazards in TCP</title>
        <author>
            <name>R. Braden</name>
        </author>
        <date>
            <month>May</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22887</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>TCP protocol</kw>
            <kw>protocol state</kw>
            <kw>graceful close</kw>
            <kw>reset</kw>
        </keywords>
        <abstract>This note describes some theoretically-possible failure modes for TCP connections and discusses possible remedies. In particular, one very simple fix is identified. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1338</doc-id>
        <title>Supernetting: an Address Assignment and Aggregation Strategy</title>
        <author>
            <name>V. Fuller</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>J. Yu</name>
        </author>
        <author>
            <name>K. Varadhan</name>
        </author>
        <date>
            <month>June</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47975</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>internet address</kw>
            <kw>routing</kw>
        </keywords>
        <abstract>This memo discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers run by transit routing domain providers. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1519</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1339</doc-id>
        <title>Remote Mail Checking Protocol</title>
        <author>
            <name>S. Dorner</name>
        </author>
        <author>
            <name>P. Resnick</name>
        </author>
        <date>
            <month>June</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13115</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>RMCP</kw>
            <kw>email</kw>
            <kw>remote mail</kw>
        </keywords>
        <abstract>This RFC defines a protocol to provide a mail checking service to be used between a client and server pair. Typically, a small program on a client workstation would use the protocol to query a server in order to find out whether new mail has arrived for a specified user. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1340</doc-id>
        <title>Assigned Numbers</title>
        <author>
            <name>J. Reynolds</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>July</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>232974</char-count>
            <page-count>139</page-count>
        </format>
        <abstract>This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community. </abstract>
        <obsoletes>
            <doc-id>RFC1060</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1700</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1341</doc-id>
        <title>MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies</title>
        <author>
            <name>N. Borenstein</name>
        </author>
        <author>
            <name>N. Freed</name>
        </author>
        <date>
            <month>June</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>211117</char-count>
            <page-count>80</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>347082</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>192244</char-count>
        </format>
        <keywords>
            <kw>EMail</kw>
            <kw>Multimedia</kw>
        </keywords>
        <abstract>This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1521</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1342</doc-id>
        <title>Representation of Non-ASCII Text in Internet Message Headers</title>
        <author>
            <name>K. Moore</name>
        </author>
        <date>
            <month>June</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15845</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>EMail</kw>
            <kw>Character Sets</kw>
        </keywords>
        <abstract>This memo describes an extension to the message format defined in [1] (known to the IETF Mail Extensions Working Group as "RFC 1341"), to allow the representation of character sets other than ASCII in RFC 822 message headers. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1522</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1343</doc-id>
        <title>A User Agent Configuration Mechanism for Multimedia Mail Format Information</title>
        <author>
            <name>N. Borenstein</name>
        </author>
        <date>
            <month>June</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29295</char-count>
            <page-count>10</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>59978</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>28495</char-count>
        </format>
        <keywords>
            <kw>EMail</kw>
            <kw>Multimedia</kw>
        </keywords>
        <abstract>This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1344</doc-id>
        <title>Implications of MIME for Internet Mail Gateways</title>
        <author>
            <name>N. Borenstein</name>
        </author>
        <date>
            <month>June</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25872</char-count>
            <page-count>9</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>51812</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>24430</char-count>
        </format>
        <keywords>
            <kw>EMail</kw>
            <kw>Forwarding</kw>
            <kw>Relaying</kw>
            <kw>Fragmentation</kw>
            <kw>Multimedia</kw>
        </keywords>
        <abstract>While MIME was carefully designed so that it does not require any changes to Internet electronic message transport facilities, there are several ways in which message transport systems may want to take advantage of MIME. These opportunities are the subject of this memo. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1345</doc-id>
        <title>Character Mnemonics and Character Sets</title>
        <author>
            <name>K. Simonsen</name>
        </author>
        <date>
            <month>June</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>249737</char-count>
            <page-count>103</page-count>
        </format>
        <abstract>This memo lists a selection of characters and their presence in some coded character sets. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1346</doc-id>
        <title>Resource Allocation, Control, and Accounting for the Use of Network Resources</title>
        <author>
            <name>P. Jones</name>
        </author>
        <date>
            <month>June</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13084</char-count>
            <page-count>6</page-count>
        </format>
        <abstract>The purpose of this RFC is to focus discussion on particular challenges in large service networks in general, and the International IP Internet in particular. No solution discussed in this document is intended as a standard. Rather, it is hoped that a general consensus will emerge as to the appropriate solutions, leading eventually to the adoption of standards. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1347</doc-id>
        <title>TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing</title>
        <author>
            <name>R. Callon</name>
        </author>
        <date>
            <month>June</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26563</char-count>
            <page-count>8</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>42398</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>22398</char-count>
        </format>
        <abstract>This paper describes a simple proposal which provides a long-term solution to Internet addressing, routing, and scaling. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1348</doc-id>
        <title>DNS NSAP RRs</title>
        <author>
            <name>B. Manning</name>
        </author>
        <date>
            <month>July</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6871</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>domain names</kw>
            <kw>CLNP</kw>
            <kw>resource records</kw>
        </keywords>
        <abstract>This RFC defines the format of two new Resource Records (RRs) for the Domain Name System (DNS), and reserves corresponding DNS type mnemonic and numerical codes. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC1637</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1349</doc-id>
        <title>Type of Service in the Internet Protocol Suite</title>
        <author>
            <name>P. Almquist</name>
        </author>
        <date>
            <month>July</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>68949</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>TOS</kw>
            <kw>TOS</kw>
            <kw>IP</kw>
        </keywords>
        <abstract>This memo changes and clarifies some aspects of the semantics of the Type of Service octet in the Internet Protocol (IP) header. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2474</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1248</doc-id>
            <doc-id>RFC1247</doc-id>
            <doc-id>RFC1195</doc-id>
            <doc-id>RFC1123</doc-id>
            <doc-id>RFC1122</doc-id>
            <doc-id>RFC1060</doc-id>
            <doc-id>RFC0791</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1350</doc-id>
        <title>The TFTP Protocol (Revision 2)</title>
        <author>
            <name>K. Sollins</name>
        </author>
        <date>
            <month>July</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24599</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>TFTP</kw>
            <kw>trivial</kw>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>booting</kw>
        </keywords>
        <abstract>TFTP is a very simple protocol used to transfer files. It is from this that its name comes, Trivial File Transfer Protocol or TFTP. Each nonterminal packet is acknowledged separately. This document describes the protocol and its types of packets. The document also explains the reasons behind some of the design decisions. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC0783</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC1782</doc-id>
            <doc-id>RFC1783</doc-id>
            <doc-id>RFC1784</doc-id>
            <doc-id>RFC1785</doc-id>
            <doc-id>RFC2347</doc-id>
            <doc-id>RFC2348</doc-id>
            <doc-id>RFC2349</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0033</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1351</doc-id>
        <title>SNMP Administrative Model</title>
        <author>
            <name>J. Davin</name>
        </author>
        <author>
            <name>J. Galvin</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>July</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>80721</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
            <kw>SNMP-ADMIN</kw>
            <kw>network</kw>
            <kw>management</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This memo presents an elaboration of the SNMP administrative model set forth in [1]. This model provides a unified conceptual basis for administering SNMP protocol entities to support: authenticaiton and integrity, privacy, access control, and cooperation of protocol entities. [STANDARDS-TRACK] </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1352</doc-id>
        <title>SNMP Security Protocols</title>
        <author>
            <name>J. Galvin</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>J. Davin</name>
        </author>
        <date>
            <month>July</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>95732</char-count>
            <page-count>41</page-count>
        </format>
        <keywords>
            <kw>SNMP-SEC</kw>
            <kw>network</kw>
            <kw>management</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>The Simple Network Management Protocol (SNMP) specification [1] allows for the protection of network management operations by a variety of security protocols. The SNMP administrative model described in [2] provides a framework for securing SNMP network management. In the context of that framework, this memo defines protocols to support the following three security services: data integrity, data origin authentication and data confidentiality. [STANDARDS-TRACK] </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1353</doc-id>
        <title>Definitions of Managed Objects for Administration of SNMP Parties</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>J. Davin</name>
        </author>
        <author>
            <name>J. Galvin</name>
        </author>
        <date>
            <month>July</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59556</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>SNMP-PARTY-MIB</kw>
            <kw>network</kw>
            <kw>management</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes a representation of the SNMP parties defined in [8] as objects defined according to the Internet Standard SMI [1]. [STANDARDS-TRACK] </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1354</doc-id>
        <title>IP Forwarding Table MIB</title>
        <author>
            <name>F. Baker</name>
        </author>
        <date>
            <month>July</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24905</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Route</kw>
            <kw>Table</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing routes in the IP Internet. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2096</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1355</doc-id>
        <title>Privacy and Accuracy Issues in Network Information Center Databases</title>
        <author>
            <name>J. Curran</name>
        </author>
        <author>
            <name>A. Marine</name>
        </author>
        <date>
            <month>August</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8858</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>NIC</kw>
            <kw>data</kw>
            <kw>privacy</kw>
            <kw>accuracy</kw>
        </keywords>
        <abstract>This document provides a set of guidelines for the administration and operation of public Network Information Center (NIC) databases. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <is-also>
            <doc-id>FYI0015</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1356</doc-id>
        <title>Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode</title>
        <author>
            <name>A. Malis</name>
        </author>
        <author>
            <name>D. Robinson</name>
        </author>
        <author>
            <name>R. Ullmann</name>
        </author>
        <date>
            <month>August</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32043</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>IP-X.25</kw>
            <kw>IP</kw>
            <kw>on</kw>
            <kw>X.25</kw>
        </keywords>
        <abstract>This document specifies the encapsulation of IP and other network layer protocols over X.25 networks, in accordance and alignment with ISO/IEC and CCITT standards. It is a replacement for RFC 877, "A Standard for the Transmission of IP Datagrams Over Public Data Networks" [1]. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC0877</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1357</doc-id>
        <title>A Format for E-mailing Bibliographic Records</title>
        <author>
            <name>D. Cohen</name>
        </author>
        <date>
            <month>July</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25021</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>library</kw>
            <kw>technical</kw>
            <kw>reports</kw>
            <kw>email</kw>
            <kw>services</kw>
        </keywords>
        <abstract>This memo defines a format for E-mailing bibliographic records of technical reports. It is intended to accelerate the dissemination of information about new Computer Science Technical Reports (CS-TR). This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1807</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1358</doc-id>
        <title>Charter of the Internet Architecture Board (IAB)</title>
        <author>
            <name>L. Chapin</name>
        </author>
        <date>
            <month>August</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11328</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>ISOC</kw>
            <kw>Internet</kw>
            <kw>Society</kw>
            <kw>IETF</kw>
            <kw>IRTF</kw>
        </keywords>
        <abstract>The Internet Architecture Board (IAB) shall be constituted and shall operate as a technical advisory group of the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1601</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1359</doc-id>
        <title>Connecting to the Internet - What Connecting Institutions Should Anticipate</title>
        <author>
            <name>ACM SIGUCCS</name>
        </author>
        <date>
            <month>August</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53449</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>access</kw>
        </keywords>
        <abstract>This FYI RFC outlines the major issues an institution should consider in the decision and implementation of a campus connection to the Internet. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <is-also>
            <doc-id>FYI0016</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1360</doc-id>
        <title>IAB Official Protocol Standards</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>September</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>71860</char-count>
            <page-count>33</page-count>
        </format>
        <keywords>
            <kw>proposed</kw>
            <kw>draft</kw>
            <kw>experimental</kw>
            <kw>informational</kw>
            <kw>historic</kw>
            <kw>full</kw>
        </keywords>
        <obsoletes>
            <doc-id>RFC1280</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1410</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1361</doc-id>
        <title>Simple Network Time Protocol (SNTP)</title>
        <author>
            <name>D. Mills</name>
        </author>
        <date>
            <month>August</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23812</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>Clocks</kw>
            <kw>Synchronization</kw>
            <kw>NTP</kw>
        </keywords>
        <abstract>This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. This memorandum does not obsolete or update any RFC. This memo provides information for the Internet community. It does not specify an Internet standard. Discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.9 contain the lists of protocols in each stage of standardization. Finally come pointers to references and contacts for further information. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1769</doc-id>
        </obsoleted-by>
        <see-also>
            <doc-id>RFC1305</doc-id>
        </see-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1362</doc-id>
        <title>Novell IPX over Various WAN Media (IPXWAN)</title>
        <author>
            <name>M. Allen</name>
        </author>
        <date>
            <month>September</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30219</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>IPX on X.25</kw>
            <kw>IPX on PPP</kw>
            <kw>IPX on Frame Relay</kw>
        </keywords>
        <abstract>This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1634</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1363</doc-id>
        <title>A Proposed Flow Specification</title>
        <author>
            <name>C. Partridge</name>
        </author>
        <date>
            <month>September</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59214</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>flow</kw>
            <kw>spec</kw>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>stream</kw>
            <kw>type of service</kw>
            <kw>quality of service</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1364</doc-id>
        <title>BGP OSPF Interaction</title>
        <author>
            <name>K. Varadhan</name>
        </author>
        <date>
            <month>September</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32121</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>autonomous</kw>
            <kw>system</kw>
            <kw>border</kw>
            <kw>router</kw>
            <kw>open</kw>
            <kw>shortest</kw>
            <kw>path</kw>
            <kw>first</kw>
            <kw>routing</kw>
            <kw>protocol</kw>
            <kw>domain</kw>
            <kw>route</kw>
            <kw>exchange</kw>
            <kw>exporting</kw>
            <kw>importing</kw>
        </keywords>
        <obsoleted-by>
            <doc-id>RFC1403</doc-id>
        </obsoleted-by>
        <see-also>
            <doc-id>RFC1247</doc-id>
            <doc-id>RFC1267</doc-id>
        </see-also>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1365</doc-id>
        <title>An IP Address Extension Proposal</title>
        <author>
            <name>K. Siyan</name>
        </author>
        <date>
            <month>September</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12790</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>class F addresses</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1366</doc-id>
        <title>Guidelines for Management of IP Address Space</title>
        <author>
            <name>E. Gerich</name>
        </author>
        <date>
            <month>October</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17793</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>routing</kw>
            <kw>tables</kw>
            <kw>allocation</kw>
            <kw>registry</kw>
            <kw>IR</kw>
            <kw>IANA</kw>
        </keywords>
        <abstract>This document has been reviewed by the Federal Engineering Task Force (FEPG) on behalf of the Federal Networking Council (FNC), the co-chairs of the International Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE). There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space. This memo provides information for the Internet community. It does not specify an Internet standard. This RFC suggests an extension to the IP protocol to solve the shortage of IP address problem, and requests discussion and suggestions for improvements. This memo provides information for the Internet community. It does not specify an Internet standard. This memo defines the various criteria to be used when designing Autonomous System Border Routers (ASBR) that will run BGP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK] 1363 Partridge Spt 92 A Proposed Flow Specification The flow specification defined in this memo is intended for information and possible experimentation (i.e., experimental use by consenting routers and applications only). This RFC is a product of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1466</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1367</doc-id>
        <title>Schedule for IP Address Space Management Guidelines</title>
        <author>
            <name>C. Topolcic</name>
        </author>
        <date>
            <month>October</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4780</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>routing</kw>
            <kw>tables</kw>
            <kw>allocation</kw>
            <kw>registry</kw>
            <kw>IR</kw>
            <kw>IANA</kw>
        </keywords>
        <abstract>This memo suggests a schedule for the implementation of the IP network number allocation plan described in RFC 1366. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1467</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1368</doc-id>
        <title>Definition of Managed Objects for IEEE 802.3 Repeater Devices</title>
        <author>
            <name>D. McMaster</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>October</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>83905</char-count>
            <page-count>40</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>hub</kw>
            <kw>management</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing IEEE 802.3 10 Mb/second baseband repeaters, sometimes referred to as "hubs". [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1516</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1369</doc-id>
        <title>Implementation Notes and Experience for the Internet Ethernet MIB</title>
        <author>
            <name>F. Kastenholz</name>
        </author>
        <date>
            <month>October</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13961</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>management</kw>
        </keywords>
        <abstract>This document reflects the currently known status of 11 different implementations of the MIB by 7 different vendors on 7 different Ethernet interface chips. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1370</doc-id>
        <title>Applicability Statement for OSPF</title>
        <author>
            <name>Internet Architecture Board</name>
        </author>
        <author>
            <name>L. Chapin</name>
        </author>
        <date>
            <month>October</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4303</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>routing</kw>
            <kw>open</kw>
            <kw>shortest</kw>
            <kw>path</kw>
            <kw>first</kw>
        </keywords>
        <abstract>This Applicability Statement places a requirement on vendors claiming conformance to this standard, in order to assure that users will have the option of deploying OSPF when they need a multivendor, interoperable IGP in their environment. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1371</doc-id>
        <title>Choosing a Common IGP for the IP Internet</title>
        <author>
            <name>P. Gross</name>
        </author>
        <date>
            <month>October</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18168</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>routing</kw>
            <kw>recommendation</kw>
            <kw>interior</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo presents motivation, rationale and other surrounding background information leading to the IESG's recommendation to the IAB for a single "common IGP" for the IP portions of the Internet. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1372</doc-id>
        <title>Telnet Remote Flow Control Option</title>
        <author>
            <name>C. Hedrick</name>
        </author>
        <author>
            <name>D. Borman</name>
        </author>
        <date>
            <month>October</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11098</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>TOPT-RFC</kw>
            <kw>terminal</kw>
            <kw>access</kw>
        </keywords>
        <abstract>This document specifies an extended version of the Telnet Remote Flow Control Option, RFC 1080, with the addition of the RESTART-ANY and RESTART-XON suboptions. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1080</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1373</doc-id>
        <title>Portable DUAs</title>
        <author>
            <name>T. Tignor</name>
        </author>
        <date>
            <month>October</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19931</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>directory</kw>
            <kw>user</kw>
            <kw>agents</kw>
            <kw>whois</kw>
            <kw>de</kw>
            <kw>dixie</kw>
            <kw>ud</kw>
            <kw>doog</kw>
            <kw>ISODE</kw>
            <kw>X.500</kw>
        </keywords>
        <abstract>This document comes in two parts. The first part is for regular people who wish to set up their own DUAs (Directory User Interfaces) to access the Directory. The second part is for ISODE-maintainers wishing to provide portable DUAs to users. This part gives instructions in a similar but longer, step-by-step format. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1374</doc-id>
        <title>IP and ARP on HIPPI</title>
        <author>
            <name>J. Renwick</name>
        </author>
        <author>
            <name>A. Nicholson</name>
        </author>
        <date>
            <month>October</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>100903</char-count>
            <page-count>43</page-count>
        </format>
        <abstract>The ANSI X3T9.3 committee has drafted a proposal for the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI. Another X3T9.3 draft describes the operation of HIPPI physical switches. X3T9.3 chose to leave HIPPI networking issues largely outside the scope of their standards; this document discusses methods of using of ANSI standard HIPPI hardware and protocols in the context of the Internet, including the use of HIPPI switches as LANs and interoperation with other networks. This memo is intended to become an Internet Standard. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2834</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1375</doc-id>
        <title>Suggestion for New Classes of IP Addresses</title>
        <author>
            <name>P. Robinson</name>
        </author>
        <date>
            <month>October</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16990</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>network</kw>
            <kw>numbers</kw>
        </keywords>
        <abstract>This RFC suggests a change in the method of specifying the IP address to add new classes of networks to be called F, G, H, and K, to reduce the amount of wasted address space, and to increase the available IP address number space, especially for smaller organizations or classes of connectors that do not need or do not want a full Class C IP address. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1376</doc-id>
        <title>The PPP DECnet Phase IV Control Protocol (DNCP)</title>
        <author>
            <name>S. Senum</name>
        </author>
        <date>
            <month>November</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12448</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>point</kw>
            <kw>DNA</kw>
            <kw>DDCMP</kw>
        </keywords>
        <abstract>This document defines the NCP for establishing and configuring Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP. This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc.). [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1762</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1377</doc-id>
        <title>The PPP OSI Network Layer Control Protocol (OSINLCP)</title>
        <author>
            <name>D. Katz</name>
        </author>
        <date>
            <month>November</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22109</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>PPP-OSINLCP</kw>
            <kw>point</kw>
            <kw>open</kw>
            <kw>systems</kw>
            <kw>interconnection</kw>
        </keywords>
        <abstract>This document defines the NCP for establishing and configuring OSI Network Layer Protocols. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1378</doc-id>
        <title>The PPP AppleTalk Control Protocol (ATCP)</title>
        <author>
            <name>B. Parker</name>
        </author>
        <date>
            <month>November</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28496</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>PPP-ATCP</kw>
            <kw>point</kw>
        </keywords>
        <abstract>This document defines the NCP for establishing and configuring the AppleTalk Protocol [3] over PPP. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1379</doc-id>
        <title>Extending TCP for Transactions -- Concepts</title>
        <author>
            <name>R. Braden</name>
        </author>
        <date>
            <month>November</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>91353</char-count>
            <page-count>38</page-count>
        </format>
        <keywords>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo discusses extension of TCP to provide transaction-oriented service, without altering its virtual-circuit operation. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <updated-by>
            <doc-id>RFC1644</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1380</doc-id>
        <title>IESG Deliberations on Routing and Addressing</title>
        <author>
            <name>P. Gross</name>
        </author>
        <author>
            <name>P. Almquist</name>
        </author>
        <date>
            <month>November</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49415</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>ROAD</kw>
        </keywords>
        <abstract>This memo summarizes issues surrounding the routing and addressing scaling problems in the IP architecture, and it provides a brief background of the ROAD group and related activities in the Internet Engineering Task Force (IETF). This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1381</doc-id>
        <title>SNMP MIB Extension for X.25 LAPB</title>
        <author>
            <name>D. Throop</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <date>
            <month>November</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>71253</char-count>
            <page-count>33</page-count>
        </format>
        <keywords>
            <kw>SNMP-LAPB</kw>
            <kw>management</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Link Layer of X.25, LAPB. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1382</doc-id>
        <title>SNMP MIB Extension for the X.25 Packet Layer</title>
        <author>
            <name>D. Throop</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>153877</char-count>
            <page-count>69</page-count>
        </format>
        <keywords>
            <kw>SNMP-X.25</kw>
            <kw>management</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1383</doc-id>
        <title>An Experiment in DNS Based IP Routing</title>
        <author>
            <name>C. Huitema</name>
        </author>
        <date>
            <month>December</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32680</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>DNS-IP</kw>
        </keywords>
        <abstract>Potential solutions to the routing explosion. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1384</doc-id>
        <title>Naming Guidelines for Directory Pilots</title>
        <author>
            <name>P. Barker</name>
        </author>
        <author>
            <name>S.E. Hardcastle-Kille</name>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25870</char-count>
            <page-count>12</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>175044</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>134487</char-count>
        </format>
        <keywords>
            <kw>X.500</kw>
            <kw>Multinational</kw>
        </keywords>
        <abstract>This document defines a number of naming guidelines. Alignment to these guidelines is recommended for directory pilots. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1617</doc-id>
            <doc-id>RTR0011</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1385</doc-id>
        <title>EIP: The Extended Internet Protocol</title>
        <author>
            <name>Z. Wang</name>
        </author>
        <date>
            <month>November</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39123</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>addressing</kw>
        </keywords>
        <abstract>EIP can substantially reduce the amount of modifications needed to the current Internet systems and greatly ease the difficulties of transition. This is an "idea" paper and discussion is strongly encouraged on Big-Internet@munnari.oz.au. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1386</doc-id>
        <title>The US Domain</title>
        <author>
            <name>A. Cooper</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>December</month>
            <year>1992</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>62310</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>DNS</kw>
            <kw>top-level</kw>
        </keywords>
        <abstract>This is a description of the US Top Level Domains on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1480</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1387</doc-id>
        <title>RIP Version 2 Protocol Analysis</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5598</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>RIP-2</kw>
        </keywords>
        <abstract>As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1721</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1388</doc-id>
        <title>RIP Version 2 Carrying Additional Information</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16227</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>RIP-2</kw>
        </keywords>
        <abstract>This document specifies an extension of the Routing Information Protocol (RIP), as defined in [1], to expand the amount of useful information carried in RIP packets and to add a measure of security. [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1723</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1058</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1389</doc-id>
        <title>RIP Version 2 MIB Extensions</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23569</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>RIP-2</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1724</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1390</doc-id>
        <title>Transmission of IP and ARP over FDDI Networks</title>
        <author>
            <name>D. Katz</name>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22077</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>IP-FDDI</kw>
            <kw>IEEE</kw>
            <kw>802</kw>
            <kw>MAC</kw>
        </keywords>
        <abstract>This memo defines a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK] </abstract>
        <is-also>
            <doc-id>STD0036</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1391</doc-id>
        <title>The Tao of the IETF: A Guide for New Attendees of the Internet Engineering Task Force</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41892</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>meetings</kw>
        </keywords>
        <abstract>The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1539</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1392</doc-id>
        <title>Internet Users' Glossary</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <author>
            <name>T. LaQuey Parker</name>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>104624</char-count>
            <page-count>53</page-count>
        </format>
        <abstract>There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1983</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1393</doc-id>
        <title>Traceroute Using an IP Option</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13140</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>TRACE-IP</kw>
            <kw>ICMP</kw>
            <kw>MTU</kw>
            <kw>Line</kw>
            <kw>Speed</kw>
        </keywords>
        <abstract>This document specifies a new IP option and ICMP message type which duplicates the functionality of the existing traceroute method while generating fewer packets and completing in a shorter time. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1394</doc-id>
        <title>Relationship of Telex Answerback Codes to Internet Domains</title>
        <author>
            <name>P. Robinson</name>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43776</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>DNS</kw>
            <kw>Country</kw>
        </keywords>
        <abstract>This RFC gives the list, as best known, of all common Internet domains and the conversion between specific country telex answerback codes and Internet country domain identifiers. It also lists the telex code and international dialing code, wherever it is available. It will also list major Internet "Public" E-Mail addresses. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1395</doc-id>
        <title>BOOTP Vendor Information Extensions</title>
        <author>
            <name>J. Reynolds</name>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16314</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>TAGS</kw>
        </keywords>
        <abstract>This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo will be updated as additional tags are defined. This edition introduces Tag 14 for Merit Dump File, Tag 15 for Domain Name, Tag 16 for Swap Server and Tag 17 for Root Path. This memo is a status report on the vendor information extensions used int the Bootstrap Protocol (BOOTP). </abstract>
        <obsoletes>
            <doc-id>RFC1084</doc-id>
            <doc-id>RFC1048</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1497</doc-id>
            <doc-id>RFC1533</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0951</doc-id>
        </updates>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1396</doc-id>
        <title>The Process for Organization of Internet Standards Working Group (POISED)</title>
        <author>
            <name>S. Crocker</name>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22096</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>IAB</kw>
            <kw>IESG</kw>
            <kw>ISOC</kw>
        </keywords>
        <abstract>This report provides a summary of the POISED Working Group (WG), starting from the events leading to the formation of the WG to the end of 1992. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1397</doc-id>
        <title>Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol</title>
        <author>
            <name>D. Haskin</name>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4124</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>BGP</kw>
        </keywords>
        <abstract>This document speficies the recommendation of the BGP Working Group on default route advertisement support in BGP2 [1] and BGP3 [2] versions of the Border Gateway Protocol. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1398</doc-id>
        <title>Definitions of Managed Objects for the Ethernet-Like Interface Types</title>
        <author>
            <name>F. Kastenholz</name>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36684</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>Management</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing ehternet-like objects. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1284</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1623</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1399</doc-id>
        <title>Summary of 1300-1399</title>
        <author>
            <name>J. Elliott</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43662</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>Index</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1400</doc-id>
        <title>Transition and Modernization of the Internet Registration Service</title>
        <author>
            <name>S. Williamson</name>
        </author>
        <date>
            <month>March</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13008</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>INTERNIC IR</kw>
        </keywords>
        <abstract>As a result of the NREN NIS award by National Science Foundation, non- DDN registration services will soon be transferred from the DDN NIC to the new Internet Registration Service, which is a part of an entity referred to as the InterNIC. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1401</doc-id>
        <title>Correspondence between the IAB and DISA on the use of DNS</title>
        <author>
            <name>Internet Architecture Board</name>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12528</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>Domain Name</kw>
            <kw>Milnet</kw>
        </keywords>
        <abstract>This memo reproduces three letters exchanged between the Internet Activities Board (IAB) and the Defense Information Systems Agency (DISA) regarding the importance of using the Domain Name System (DNS) throughout the Internet, and phasing out the use of older host name to address tables, such as "hosts.txt". This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1402</doc-id>
        <title>There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places</title>
        <author>
            <name>J. Martin</name>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>71176</char-count>
            <page-count>39</page-count>
        </format>
        <keywords>
            <kw>information</kw>
            <kw>introduction</kw>
            <kw>SIGUCCS</kw>
            <kw>User Services</kw>
            <kw>Help</kw>
        </keywords>
        <abstract>The ultimate goal is to make the route to these sources of information invisible to you. At present, this is not easy to do. I will explain some of the techniques that can be used to make these nuggets easier to pick up so that we all can be richer. This RFC provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoletes>
            <doc-id>RFC1290</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>FYI0010</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1403</doc-id>
        <title>BGP OSPF Interaction</title>
        <author>
            <name>K. Varadhan</name>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36173</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>BGP-OSPF</kw>
            <kw>border gateway protocol</kw>
            <kw>open shortest path first routing</kw>
        </keywords>
        <abstract>This memo defines the various criteria to be used when designing an Autonomous System Border Routers (ASBR) that will run BGP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1364</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1404</doc-id>
        <title>A Model for Common Operational Statistics</title>
        <author>
            <name>B. Stockman</name>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52814</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>Management</kw>
            <kw>Operations</kw>
        </keywords>
        <abstract>This memo describes a model for operational statistics in the Internet. It gives recommendations for metrics, measurements, polling periods, storage formats and presentation formats. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1857</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1405</doc-id>
        <title>Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)</title>
        <author>
            <name>C. Allocchio</name>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33885</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>SMTP</kw>
            <kw>EMail</kw>
            <kw>822</kw>
        </keywords>
        <abstract>This document describes a set of mappings which will enable inter working between systems operating the CCITT X.400 ( 1984 / 1988 ) Recommendations on Message Handling Systems, and systems running the Mail-11 (also known as DECnet mail) protocol. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC2162</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1406</doc-id>
        <title>Definitions of Managed Objects for the DS1 and E1 Interface Types</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>J. Watt</name>
            <title>Editors</title>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>97559</char-count>
            <page-count>50</page-count>
        </format>
        <keywords>
            <kw>DS1/E1-MIB</kw>
            <kw>T1</kw>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing DS1 Interfaces -- including both T1 and E1 (a.k.a., CEPT 2 Mbit/s) links. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1232</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2495</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1407</doc-id>
        <title>Definitions of Managed Objects for the DS3/E3 Interface Type</title>
        <author>
            <name>T. Cox</name>
        </author>
        <author>
            <name>K. Tesink</name>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>90682</char-count>
            <page-count>43</page-count>
        </format>
        <keywords>
            <kw>DS3/E3-MIB</kw>
            <kw>T3</kw>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract>This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing DS3 and E3 Interfaces. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1233</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2496</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1408</doc-id>
        <title>Telnet Environment Option</title>
        <author>
            <name>D. Borman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13936</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>TOPT-ENVIR</kw>
            <kw>Negotiation</kw>
        </keywords>
        <abstract>This document specifies a mechanism for passing environment information between a telnet client and server. [STANDARDS-TRACK] </abstract>
        <updated-by>
            <doc-id>RFC1571</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1409</doc-id>
        <title>Telnet Authentication Option</title>
        <author>
            <name>D. Borman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13119</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>security</kw>
        </keywords>
        <abstract>This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC1416</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1410</doc-id>
        <title>IAB Official Protocol Standards</title>
        <author>
            <name>J. Postel</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>76524</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
            <kw>proposed</kw>
            <kw>draft</kw>
            <kw>experimental</kw>
            <kw>informational</kw>
            <kw>historic</kw>
            <kw>full</kw>
        </keywords>
        <abstract>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). </abstract>
        <obsoletes>
            <doc-id>RFC1360</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1500</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1411</doc-id>
        <title>Telnet Authentication: Kerberos Version 4</title>
        <author>
            <name>D. Borman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7967</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>TEL-KER</kw>
            <kw>Security</kw>
            <kw>option</kw>
        </keywords>
        <abstract>This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1412</doc-id>
        <title>Telnet Authentication: SPX</title>
        <author>
            <name>K. Alagappan</name>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6952</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>TEL-SPX</kw>
            <kw>Security</kw>
            <kw>option</kw>
        </keywords>
        <abstract>This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1413</doc-id>
        <title>Identification Protocol</title>
        <author>
            <name>M. St. Johns</name>
        </author>
        <date>
            <month>February</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16291</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>IDENT</kw>
            <kw>Authentication</kw>
        </keywords>
        <abstract>The Identification Protocol was formerly called the Authentication Server Protocol. It has been renamed to better reflect its function. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC0931</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1414</doc-id>
        <title>Identification MIB</title>
        <author>
            <name>M. St. Johns</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>February</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14165</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>IDENT-MIB</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract>This memo defines a MIB for use with identifying the users associated with TCP connections. It provides functionality approximately equivalent to that provided by the protocol defined in RFC 1413 [1]. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1415</doc-id>
        <title>FTP-FTAM Gateway Specification</title>
        <author>
            <name>J. Mindel</name>
        </author>
        <author>
            <name>R. Slaski</name>
        </author>
        <date>
            <month>January</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>128261</char-count>
            <page-count>58</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
            <kw>FTAM</kw>
            <kw>transfer</kw>
            <kw>ISO</kw>
            <kw>OSI </kw>
        </keywords>
        <abstract>This memo describes a dual protocol stack application layer gateway that performs protocol translation, in an interactive environment, between the FTP and FTAM file transfer protocols. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1416</doc-id>
        <title>Telnet Authentication Option</title>
        <author>
            <name>D. Borman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13270</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>TOPT-AUTH</kw>
            <kw>Security</kw>
        </keywords>
        <abstract>This RFC 1416 replaces RFC 1409, which has an important typographical error in the example on page 6 (one occurance of "REPLY" should be "IS"). This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoletes>
            <doc-id>RFC1409</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2941</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1417</doc-id>
        <title>NADF Standing Documents: A Brief Overview</title>
        <author>
            <name>The North American Directory Forum</name>
        </author>
        <date>
            <month>February</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7270</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>X.500</kw>
            <kw>Directory</kw>
        </keywords>
        <abstract>The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoletes>
            <doc-id>RFC1295</doc-id>
            <doc-id>RFC1255</doc-id>
            <doc-id>RFC1218</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1758</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1418</doc-id>
        <title>SNMP over OSI</title>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>March</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7721</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>SNMP-OSI</kw>
            <kw>Management</kw>
        </keywords>
        <abstract>This memo addresses some concerns by defining a framework for running the SNMP in an environment which supports the OSI connectionless-mode transport service. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1161</doc-id>
            <doc-id>RFC1283</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1419</doc-id>
        <title>SNMP over AppleTalk</title>
        <author>
            <name>G. Minshall</name>
        </author>
        <author>
            <name>M. Ritter</name>
        </author>
        <date>
            <month>March</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16470</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>SNMP-AT</kw>
            <kw>Management</kw>
        </keywords>
        <abstract>This memo describes the method by which the Simple Network Management Protocol (SNMP) as specified in [1] can be used over AppleTalk protocols [2] instead of the Internet UDP/IP protocol stack. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1420</doc-id>
        <title>SNMP over IPX</title>
        <author>
            <name>S. Bostock</name>
        </author>
        <date>
            <month>March</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6762</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>SNMP-IPX</kw>
            <kw>Management</kw>
        </keywords>
        <abstract>This document defines a convention for encapsulating Simple Network Management Protocol (SNMP) [1] packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol [2]. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1298</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1421</doc-id>
        <title>Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures</title>
        <author>
            <name>J. Linn</name>
        </author>
        <date>
            <month>February</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>103894</char-count>
            <page-count>42</page-count>
        </format>
        <keywords>
            <kw>PEM-ENC</kw>
            <kw>PEM</kw>
        </keywords>
        <abstract>This document defines message encryption and authentication procedures, in order to provide privacy-enhanced mail (PEM) services for electronic mail transfer in the Internet. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1113</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1422</doc-id>
        <title>Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management</title>
        <author>
            <name>S. Kent</name>
        </author>
        <date>
            <month>February</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>86085</char-count>
            <page-count>32</page-count>
        </format>
        <keywords>
            <kw>PEM-CKM</kw>
            <kw>PEM</kw>
        </keywords>
        <abstract>This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1114</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1423</doc-id>
        <title>Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers</title>
        <author>
            <name>D. Balenson</name>
        </author>
        <date>
            <month>February</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33277</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>PEM-ALG</kw>
            <kw>PEM</kw>
        </keywords>
        <abstract>This document provides definitions, formats, references, and citations for cryptographic algorithms, usage modes, and associated identifiers and parameters used in support of Privacy Enhanced Mail (PEM) in the Internet community. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1115</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1424</doc-id>
        <title>Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services</title>
        <author>
            <name>B. Kaliski</name>
        </author>
        <date>
            <month>February</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17537</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>PEM-KEY</kw>
            <kw>PEM</kw>
        </keywords>
        <abstract>This document describes three types of service in support of Internet Privacy-Enhanced Mail (PEM) [1-3]: key certification, certificate- revocation list (CRL) storage, and CRL retrieval. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1425</doc-id>
        <title>SMTP Service Extensions</title>
        <author>
            <name>J. Klensin</name>
            <title>WG Chair</title>
        </author>
        <author>
            <name>N. Freed</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>E. Stefferud</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>February</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20932</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>Mail</kw>
        </keywords>
        <abstract>This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1651</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1426</doc-id>
        <title>SMTP Service Extension for 8bit-MIMEtransport</title>
        <author>
            <name>J. Klensin</name>
            <title>WG Chair</title>
        </author>
        <author>
            <name>N. Freed</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>E. Stefferud</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>February</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11661</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>Mail</kw>
        </keywords>
        <abstract>This memo defines an extension to the SMTP service whereby an SMTP content body containing octets outside of the US ASCII octet range (hex </abstract>
        <obsoleted-by>
            <doc-id>RFC1652</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1427</doc-id>
        <title>SMTP Service Extension for Message Size Declaration</title>
        <author>
            <name>J. Klensin</name>
            <title>WG Chair</title>
        </author>
        <author>
            <name>N. Freed</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Moore</name>
        </author>
        <date>
            <month>February</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17856</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>Mail</kw>
        </keywords>
        <abstract>This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1653</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1428</doc-id>
        <title>Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME</title>
        <author>
            <name>G. Vaudreuil</name>
        </author>
        <date>
            <month>February</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12064</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>Mail</kw>
        </keywords>
        <abstract>This document outlines the problems in this environment and an approach to minimizing the cost of transition from current usage of non-MIME 8bit messages to MIME. This RFC provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1429</doc-id>
        <title>Listserv Distribute Protocol</title>
        <author>
            <name>E. Thomas</name>
        </author>
        <date>
            <month>February</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17759</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>LISTSERV</kw>
            <kw>Mail</kw>
        </keywords>
        <abstract>This memo specifies a subset of the distribution protocol used by the BITNET LISTSERV to deliver mail messages to large amounts of recipients. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1430</doc-id>
        <title>A Strategic Plan for Deploying an Internet X.500 Directory Service</title>
        <author>
            <name>S. Hardcastle-Kille</name>
        </author>
        <author>
            <name>E. Huizer</name>
        </author>
        <author>
            <name>V. Cerf</name>
        </author>
        <author>
            <name>R. Hobby</name>
        </author>
        <author>
            <name>S. Kent</name>
        </author>
        <date>
            <month>February</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47587</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>X.500</kw>
        </keywords>
        <abstract>This document describes an overall strategy for deploying a Directory Service on the Internet, based on the OSI X.500 Directory Service. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1431</doc-id>
        <title>DUA Metrics (OSI-DS 33 (v2))</title>
        <author>
            <name>P. Barker</name>
        </author>
        <date>
            <month>February</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42240</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>Directory User Agent</kw>
            <kw>Measurement</kw>
            <kw>Statistics</kw>
            <kw>Survey</kw>
            <kw>X.500 </kw>
        </keywords>
        <abstract>This document defines a set of criteria by which a DUA implementation, or more precisely a Directory user interface, may be judged. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1432</doc-id>
        <title>Recent Internet Books</title>
        <author>
            <name>J. Quarterman</name>
        </author>
        <date>
            <month>March</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27089</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>bibiography</kw>
        </keywords>
        <abstract>Here is a list of books related to using the Internet. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1433</doc-id>
        <title>Directed ARP</title>
        <author>
            <name>J. Garrett</name>
        </author>
        <author>
            <name>J. Hagan</name>
        </author>
        <author>
            <name>J. Wong</name>
        </author>
        <date>
            <month>March</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41028</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>DIR-ARP</kw>
            <kw>public networks</kw>
            <kw>SMDS</kw>
        </keywords>
        <abstract>Directed ARP is a dynamic address resolution procedure that enables hosts and routers to resolve advertised potential next-hop IP addresses on foreign IP networks to their associated link level addresses. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1434</doc-id>
        <title>Data Link Switching: Switch-to-Switch Protocol</title>
        <author>
            <name>R. Dixon</name>
        </author>
        <author>
            <name>D. Kushi</name>
        </author>
        <date>
            <month>March</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>80182</char-count>
            <page-count>33</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>292006</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>181839</char-count>
        </format>
        <keywords>
            <kw>IBM</kw>
            <kw>SNA</kw>
            <kw>DLS</kw>
            <kw>SSP</kw>
            <kw>NetBIos</kw>
        </keywords>
        <abstract>This RFC describes IBM's support of Data Link Switching over TCP/IP. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1795</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1435</doc-id>
        <title>IESG Advice from Experience with Path MTU Discovery</title>
        <author>
            <name>S. Knowles</name>
        </author>
        <date>
            <month>March</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2708</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>Maximum</kw>
            <kw>Transmission</kw>
            <kw>Unit</kw>
        </keywords>
        <abstract>In the course of reviewing the MTU Discovery protocol for possible elevation to Draft Standard, a specific operational problem was uncovered. The problem results from the optional suppression of ICMP messages implemented in some routers. This memo outlines a modification to this practice to allow the correct functioning of MTU Discovery. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1436</doc-id>
        <title>The Internet Gopher Protocol (a distributed document search and retrieval protocol)</title>
        <author>
            <name>F. Anklesaria</name>
        </author>
        <author>
            <name>M. McCahill</name>
        </author>
        <author>
            <name>P. Lindner</name>
        </author>
        <author>
            <name>D. Johnson</name>
        </author>
        <author>
            <name>D. Torrey</name>
        </author>
        <author>
            <name>B. Albert</name>
        </author>
        <date>
            <month>March</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36493</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>GOPHER</kw>
            <kw>information</kw>
            <kw>locating</kw>
        </keywords>
        <abstract>This document describes the protocol, lists some of the implementations currently available, and has an overview of how to implement new client and server applications. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1437</doc-id>
        <title>The Extension of MIME Content-Types to a New Medium</title>
        <author>
            <name>N. Borenstein</name>
        </author>
        <author>
            <name>M. Linimon</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13356</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>life form</kw>
            <kw>Matter</kw>
            <kw>transport</kw>
            <kw>Sentient</kw>
        </keywords>
        <abstract>This document defines one particular type of MIME data, the matter- transport/sentient-life-form type. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1438</doc-id>
        <title>Internet Engineering Task Force Statements Of Boredom (SOBs)</title>
        <author>
            <name>A. Lyman Chapin</name>
        </author>
        <author>
            <name>C. Huitema</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3044</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>process</kw>
            <kw>policy</kw>
        </keywords>
        <abstract>This document creates a new subseries of RFCs, entitled, IETF Statements Of Boredom (SOBs). This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1439</doc-id>
        <title>The Uniqueness of Unique Identifiers</title>
        <author>
            <name>C. Finseth</name>
        </author>
        <date>
            <month>March</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20477</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>names</kw>
        </keywords>
        <abstract>This RFC provides information that may be useful when selecting a method to use for assigning unique identifiers to people. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1440</doc-id>
        <title>SIFT/UFT: Sender-Initiated/Unsolicited File Transfer</title>
        <author>
            <name>R. Troth</name>
        </author>
        <date>
            <month>July</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17366</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>SIFT</kw>
            <kw>UFT</kw>
            <kw>Send</kw>
            <kw>FTP</kw>
        </keywords>
        <abstract>This document describes a Sender-Initiated File Transfer (SIFT) protocol, also commonly called Unsolicited File Transfer (UFT) protocol. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1441</doc-id>
        <title>Introduction to version 2 of the Internet-standard Network Management Framework</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>April</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25386</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>SNMPv2</kw>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract>The purpose of this document is to provide an overview of version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2). [STANDARDS-TRACK] </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1442</doc-id>
        <title>Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>April</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>95779</char-count>
            <page-count>56</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
            <kw>SMI</kw>
        </keywords>
        <abstract>Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1]. It is the purpose of this document, the Structure of Management Information (SMI), to define that subset. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1902</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1443</doc-id>
        <title>Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>April</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>60947</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract>It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1903</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1444</doc-id>
        <title>Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2)</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>April</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>57744</char-count>
            <page-count>33</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract>It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1904</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1445</doc-id>
        <title>Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)</title>
        <author>
            <name>J. Galvin</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>April</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>99443</char-count>
            <page-count>48</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract>It is the purpose of this document, the Administrative Model for SNMPv2, to define how the administrative framework is applied to realize effective network management in a variety of configurations and environments. [STANDARDS-TRACK] </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1446</doc-id>
        <title>Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)</title>
        <author>
            <name>J. Galvin</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>April</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>108733</char-count>
            <page-count>52</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract>It is the purpose of this document, Security Protocols for SNMPv2, to define one such authentication and one such privacy protocol. [STANDARDS-TRACK] </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1447</doc-id>
        <title>Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>J. Galvin</name>
        </author>
        <date>
            <month>April</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>80762</char-count>
            <page-count>50</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract>The Administrative Model for SNMPv2 document [3] defines the properties associated with SNMPv2 parties, SNMPv2 contexts, and access control policies. It is the purpose of this document, the Party MIB for SNMPv2, to define managed objects which correspond to these properties. [STANDARDS-TRACK] </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1448</doc-id>
        <title>Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>April</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>74224</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract>It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1905</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1449</doc-id>
        <title>Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2)</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>April</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41161</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract>It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1906</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1450</doc-id>
        <title>Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>April</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42172</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract>It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1907</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1451</doc-id>
        <title>Manager-to-Manager Management Information Base</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>April</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>62935</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract>It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity acting in both a manager role and an agent role. [STANDARDS-TRACK] </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1452</doc-id>
        <title>Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>April</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32176</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
        </keywords>
        <abstract>The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2) [1], and the original Internet-standard Network Management Framework (SNMPv1). [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1908</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1453</doc-id>
        <title>A Comment on Packet Video Remote Conferencing and the Transport/Network Layers</title>
        <author>
            <name>W. Chimiak</name>
        </author>
        <date>
            <month>April</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23563</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>XTP</kw>
        </keywords>
        <abstract>This RFC is a vehicle to inform the Internet community about XTP as it benefits from past Internet activity and targets general-purpose applications and multimedia applications with the emerging ATM networks in mind. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1454</doc-id>
        <title>Comparison of Proposals for Next Version of IP</title>
        <author>
            <name>T. Dixon</name>
        </author>
        <date>
            <month>May</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35064</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>IPng</kw>
            <kw>PIP</kw>
            <kw>TUBA</kw>
            <kw>SIP </kw>
        </keywords>
        <abstract>This is a slightly edited reprint of RARE Technical Report (RTC(93)004). This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1455</doc-id>
        <title>Physical Link Security Type of Service</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>May</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12391</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>TOS-LS</kw>
            <kw>TOS</kw>
        </keywords>
        <abstract>This RFC documents an experimental protocol providing a Type of Service (TOS) to request maximum physical link security. This is an addition to the types of service enumerated in RFC 1349: Type of Service in the Internet Protocol Suite. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC2474</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1456</doc-id>
        <title>Conventions for Encoding the Vietnamese Language  VISCII: VIetnamese Standard Code for Information Interchange VIQR: VIetnamese Quoted-Readable Specification</title>
        <author>
            <name>Vietnamese Standardization Working Group</name>
        </author>
        <date>
            <month>May</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14775</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>Character</kw>
            <kw>Set</kw>
        </keywords>
        <abstract>This document provides information to the Internet community on the currently used conventions for encoding Vietnamese characters into 7-bit US ASCII and in an 8-bit form. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1457</doc-id>
        <title>Security Label Framework for the Internet</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>May</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35802</char-count>
            <page-count>14</page-count>
        </format>
        <abstract>This memo presents a security labeling framework for the Internet. The framework is intended to help protocol designers determine what, if any, security labeling should be supported by their protocols. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1458</doc-id>
        <title>Requirements for Multicast Protocols</title>
        <author>
            <name>R. Braudes</name>
        </author>
        <author>
            <name>S. Zabele</name>
        </author>
        <date>
            <month>May</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48106</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>Real-Time</kw>
        </keywords>
        <abstract>This memo discusses some of these unresolved issues, and provides a high-level design for a new multicast transport protocol, group address and membership authority, and modifications to existing routing protocols. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1459</doc-id>
        <title>Internet Relay Chat Protocol</title>
        <author>
            <name>J. Oikarinen</name>
        </author>
        <author>
            <name>D. Reed</name>
        </author>
        <date>
            <month>May</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>138964</char-count>
            <page-count>65</page-count>
        </format>
        <keywords>
            <kw>IRCP</kw>
            <kw>IRC</kw>
        </keywords>
        <abstract>The IRC protocol is a text-based protocol, with the simplest client being any socket program capable of connecting to the server. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <updated-by>
            <doc-id>RFC2810</doc-id>
            <doc-id>RFC2811</doc-id>
            <doc-id>RFC2812</doc-id>
            <doc-id>RFC2813</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1460</doc-id>
        <title>Post Office Protocol - Version 3</title>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>June</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38827</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>Email</kw>
        </keywords>
        <abstract>This memo is a revision to RFC 1225, a Draft Standard. [STANDARDS- TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1225</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1725</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1461</doc-id>
        <title>SNMP MIB extension for Multiprotocol Interconnect over X.25</title>
        <author>
            <name>D. Throop</name>
        </author>
        <date>
            <month>May</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47945</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>X25-MIB</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Multiprotocol Interconnect (including IP) traffic carried over X.25. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1462</doc-id>
        <title>FYI on "What is the Internet?"</title>
        <author>
            <name>E. Krol</name>
        </author>
        <author>
            <name>E. Hoffman</name>
        </author>
        <date>
            <month>May</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27811</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>Introduction</kw>
        </keywords>
        <abstract>This FYI RFC answers the question, "What is the Internet?" and is produced by the User Services Working Group of the Internet Engineering Task Force (IETF). This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <is-also>
            <doc-id>FYI0020</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1463</doc-id>
        <title>FYI on Introducing the Internet-- A Short Bibliography of Introductory Internetworking Readings</title>
        <author>
            <name>E. Hoffman</name>
        </author>
        <author>
            <name>L. Jackson</name>
        </author>
        <date>
            <month>May</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7116</char-count>
            <page-count>4</page-count>
        </format>
        <abstract>This bibliography offers a short list of recent information resources that will help the network novice become familiar with the Internet, including its associated networks, resources, protocols, and history. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <is-also>
            <doc-id>FYI0019</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1464</doc-id>
        <title>Using the Domain Name System To Store Arbitrary String Attributes</title>
        <author>
            <name>R. Rosenbaum</name>
        </author>
        <date>
            <month>May</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7953</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>DNS</kw>
            <kw>TXT</kw>
        </keywords>
        <abstract>This paper describes a simple means to associate arbitrary string information (ASCII text) with attributes that have not been defined by the DNS. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1465</doc-id>
        <title>Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing</title>
        <author>
            <name>D. Eppenberger</name>
        </author>
        <date>
            <month>May</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>66833</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>X400</kw>
        </keywords>
        <abstract>This document proposes short term solutions for maintaining and distributing routing information and shows how messages can travel over different networks by using multi stack MTAs as relays. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1466</doc-id>
        <title>Guidelines for Management of IP Address Space</title>
        <author>
            <name>E. Gerich</name>
        </author>
        <date>
            <month>May</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22262</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>CIDR</kw>
        </keywords>
        <abstract>This document proposes a plan which will forward the implementation of RFC 1174 and which defines the allocation and assignment of the network number space. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoletes>
            <doc-id>RFC1366</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2050</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1467</doc-id>
        <title>Status of CIDR Deployment in the Internet</title>
        <author>
            <name>C. Topolcic</name>
        </author>
        <date>
            <month>August</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20720</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>routing</kw>
            <kw>tables</kw>
            <kw>allocation</kw>
            <kw>registry</kw>
            <kw>IR</kw>
            <kw>IANA</kw>
            <kw>classless</kw>
        </keywords>
        <abstract>This document describes the current status of the development and deployment of CIDR technology into the Internet. This document replaces RFC 1367, which was a schedule for the deployment of IP address space management procedures to support route aggregation. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoletes>
            <doc-id>RFC1367</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1468</doc-id>
        <title>Japanese Character Encoding for Internet Messages</title>
        <author>
            <name>J. Murai</name>
        </author>
        <author>
            <name>M. Crispin</name>
        </author>
        <author>
            <name>E. van der Poel</name>
        </author>
        <date>
            <month>June</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10970</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>Set</kw>
        </keywords>
        <abstract>This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1469</doc-id>
        <title>IP Multicast over Token-Ring Local Area Networks</title>
        <author>
            <name>T. Pusateri</name>
        </author>
        <date>
            <month>June</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8189</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>IP-TR-MC</kw>
            <kw>802.2</kw>
            <kw>802.5</kw>
        </keywords>
        <abstract>This document specifies a method for the transmission of IP multicast datagrams over Token-Ring Local Area Networks. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1470</doc-id>
        <title>FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices</title>
        <author>
            <name>R. Enger</name>
        </author>
        <author>
            <name>J. Reynolds</name>
        </author>
        <date>
            <month>June</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>308528</char-count>
            <page-count>192</page-count>
        </format>
        <keywords>
            <kw>NOCTOOLS</kw>
        </keywords>
        <abstract>The goal of this FYI memo is to provide an update to FYI 2, RFC 1147 [1], which provided practical information to site administrators and network managers. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoletes>
            <doc-id>RFC1147</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>FYI0002</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1471</doc-id>
        <title>The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol</title>
        <author>
            <name>F. Kastenholz</name>
        </author>
        <date>
            <month>June</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53558</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>PPP/LCP MIB</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
            <kw>PPP</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Link Control Protocol and Link Quality Monitoring on subnetwork interfaces that use the family of Point-to-Point Protocols [8, 9, 10, 11, &amp; 12]. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1472</doc-id>
        <title>The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol</title>
        <author>
            <name>F. Kastenholz</name>
        </author>
        <date>
            <month>June</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27152</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>PPP/SEC MIB</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
            <kw>PPP</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Security Protocols on subnetwork interfaces using the family of Point-to-Point Protocols [8, 9, 10, 11, &amp; 12]. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1473</doc-id>
        <title>The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol</title>
        <author>
            <name>F. Kastenholz</name>
        </author>
        <date>
            <month>June</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20484</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>PPP/IP MIB</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
            <kw>PPP</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the IP Network Control Protocol on subnetwork interfaces using the family of Point-to-Point Protocols [8, 9, 10, 11, &amp; 12]. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1474</doc-id>
        <title>The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol</title>
        <author>
            <name>F. Kastenholz</name>
        </author>
        <date>
            <month>June</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31846</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>PPP/Bridge</kw>
            <kw>Management</kw>
            <kw>Framework</kw>
            <kw>PPP</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the bridge Network Control Protocol [10] on subnetwork interfaces using the family of Point-to-Point Protocols. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1475</doc-id>
        <title>TP/IX: The Next Internet</title>
        <author>
            <name>R. Ullmann</name>
        </author>
        <date>
            <month>June</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>77854</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
            <kw>TP-IX</kw>
            <kw>IPv7</kw>
            <kw>IPng</kw>
        </keywords>
        <abstract>This memo presents the specification for version 7 of the Internet Protocol, as well as version 7 of the TCP and the user datagram protocol. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1476</doc-id>
        <title>RAP: Internet Route Access Protocol</title>
        <author>
            <name>R. Ullmann</name>
        </author>
        <date>
            <month>June</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45560</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>RAP</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract>This RFC describes an open distance vector routing protocol for use at all levels of the internet, from isolated LANs to the major routers of an international commercial network provider. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1477</doc-id>
        <title>IDPR as a Proposed Standard</title>
        <author>
            <name>M. Steenstrup</name>
        </author>
        <date>
            <month>July</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32238</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>Routing</kw>
            <kw>Policy</kw>
        </keywords>
        <abstract>This document contains a discussion of inter-domain policy routing (IDPR), including an overview of functionality and a discussion of experiments. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1478</doc-id>
        <title>An Architecture for Inter-Domain Policy Routing</title>
        <author>
            <name>M. Steenstrup</name>
        </author>
        <date>
            <month>June</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>90673</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
            <kw>IDPR-ARCH</kw>
            <kw>IDPR</kw>
        </keywords>
        <abstract>We present an architecture for inter-domain policy routing (IDPR). [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1479</doc-id>
        <title>Inter-Domain Policy Routing Protocol Specification: Version 1</title>
        <author>
            <name>M. Steenstrup</name>
        </author>
        <date>
            <month>July</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>275823</char-count>
            <page-count>108</page-count>
        </format>
        <keywords>
            <kw>IDPR</kw>
            <kw>IDPR</kw>
        </keywords>
        <abstract>We present the set of protocols and procedures that constitute Inter- Domain Policy Routing (IDPR). [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1480</doc-id>
        <title>The US Domain</title>
        <author>
            <name>A. Cooper</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>June</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>100556</char-count>
            <page-count>47</page-count>
        </format>
        <keywords>
            <kw>DNS</kw>
            <kw>top-level</kw>
        </keywords>
        <abstract>This is a description of the US Top Level Domains on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoletes>
            <doc-id>RFC1386</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1481</doc-id>
        <title>IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling</title>
        <author>
            <name>C. Huitema</name>
        </author>
        <date>
            <month>July</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3502</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>CIDR</kw>
        </keywords>
        <abstract>CIDR is proposed as an immediate term strategy to extend the life of the current 32 bit IP address space. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1482</doc-id>
        <title>Aggregation Support in the NSFNET Policy-Based Routing Database</title>
        <author>
            <name>M. Knopper</name>
        </author>
        <author>
            <name>S. Richardson</name>
        </author>
        <date>
            <month>June</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25330</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>CIDR</kw>
        </keywords>
        <abstract>This document describes plans for support of route aggregation, as specified in the descriptions of Classless Inter-Domain Routing (CIDR) [1] and the BGP-4 protocol [2], by the NSFNET Backbone Network Service. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1483</doc-id>
        <title>Multiprotocol Encapsulation over ATM Adaptation Layer 5</title>
        <author>
            <name>Juha Heinanen</name>
        </author>
        <date>
            <month>July</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35192</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>ATM-ENCAP</kw>
            <kw>IP</kw>
            <kw>AAL5</kw>
            <kw>over</kw>
        </keywords>
        <abstract>This memo describes two encapsulations methods for carrying network interconnect traffic over ATM AAL5. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2684</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1484</doc-id>
        <title>Using the OSI Directory to achieve User Friendly Naming (OSI-DS 24 (v1.2))</title>
        <author>
            <name>S. Hardcastle-Kille</name>
        </author>
        <date>
            <month>July</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48974</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>X.500</kw>
            <kw>directory names</kw>
            <kw>representing names</kw>
        </keywords>
        <abstract>This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1781</doc-id>
            <doc-id>RFC3494</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1485</doc-id>
        <title>A String Representation of Distinguished Names (OSI-DS 23 (v5))</title>
        <author>
            <name>S. Hardcastle-Kille</name>
        </author>
        <date>
            <month>July</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11158</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>X.500</kw>
            <kw>directory names</kw>
            <kw>representing names</kw>
        </keywords>
        <abstract>When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name. [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1779</doc-id>
            <doc-id>RFC3494</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1486</doc-id>
        <title>An Experiment in Remote Printing</title>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>C. Malamud</name>
        </author>
        <date>
            <month>July</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26373</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>electronic mail</kw>
            <kw>facsimile</kw>
        </keywords>
        <abstract>This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1528</doc-id>
            <doc-id>RFC1529</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1487</doc-id>
        <title>X.500 Lightweight Directory Access Protocol</title>
        <author>
            <name>W. Yeong</name>
        </author>
        <author>
            <name>T. Howes</name>
        </author>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>July</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44947</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>X.500</kw>
            <kw>DAP</kw>
            <kw>interactive access</kw>
        </keywords>
        <abstract>The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1777</doc-id>
            <doc-id>RFC3494</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1488</doc-id>
        <title>The X.500 String Representation of Standard Attribute Syntaxes</title>
        <author>
            <name>T. Howes</name>
        </author>
        <author>
            <name>S. Kille</name>
        </author>
        <author>
            <name>W. Yeong</name>
        </author>
        <author>
            <name>C. Robbins</name>
        </author>
        <date>
            <month>July</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17182</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>X.500</kw>
            <kw>LDAP</kw>
            <kw>lightweight directory protocol</kw>
        </keywords>
        <abstract>This document defines the requirements that must be satisfied by encoding rules used to render Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes defined in [1,2] and [3]. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1778</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1489</doc-id>
        <title>Registration of a Cyrillic Character Set</title>
        <author>
            <name>A. Chernov</name>
        </author>
        <date>
            <month>July</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7798</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>Though the proposed character set "koi8-r" is not currently an international standard, there is very large user community (including Relcom Net) supporting it. Factually, "koi8-r" is de-facto standard for Unix and global network applications in the former Soviet Union. This is the reason the Society of Unix User Groups (SUUG) believes "koi8-r" should be registered. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1490</doc-id>
        <title>Multiprotocol Interconnect over Frame Relay</title>
        <author>
            <name>T. Bradley</name>
        </author>
        <author>
            <name>C. Brown</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <date>
            <month>July</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>75206</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
            <kw>standard</kw>
            <kw>standards</kw>
            <kw>IP</kw>
            <kw>over</kw>
        </keywords>
        <abstract>This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. Additionally, it describes a simple fragmentation procedure for carrying large frames over a frame relay network with a smaller MTU. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1294</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2427</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1491</doc-id>
        <title>A Survey of Advanced Usages of X.500</title>
        <author>
            <name>C. Weider</name>
        </author>
        <author>
            <name>R. Wright</name>
        </author>
        <date>
            <month>July</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34883</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>directory</kw>
        </keywords>
        <abstract>This document is the result of a survey asking people to detail their advanced usages of X.500. It is intended to show how various organizations are using X.500 in ways which extend the view of X.500 as a "White Pages" service. This RFC is a product of the Integrated Directory Services Working Group of the Application and User Services Areas of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <is-also>
            <doc-id>FYI0021</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1492</doc-id>
        <title>An Access Control Protocol, Sometimes Called TACACS</title>
        <author>
            <name>C. Finseth</name>
        </author>
        <date>
            <month>July</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41880</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>TACACS</kw>
            <kw>Terminal</kw>
            <kw>Server</kw>
            <kw>TAC</kw>
        </keywords>
        <abstract>This RFC documents the extended TACACS protocol use by the Cisco Systems terminal servers. This same protocol is used by the University of Minnesota's distributed authentication system. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1493</doc-id>
        <title>Definitions of Managed Objects for Bridges</title>
        <author>
            <name>E. Decker</name>
        </author>
        <author>
            <name>P. Langille</name>
        </author>
        <author>
            <name>A. Rijsinghani</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>July</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>74493</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>BRIDGE-MIB</kw>
            <kw>SNMP</kw>
            <kw>MIB</kw>
            <kw>standard</kw>
            <kw>standards</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing MAC bridges based on the IEEE 802.1D-1990 standard between Local Area Network (LAN) segments. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1286</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1494</doc-id>
        <title>Equivalences between 1988 X.400 and RFC-822 Message Bodies</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <author>
            <name>S. Thompson</name>
        </author>
        <date>
            <month>August</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37273</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>Equiv</kw>
            <kw>Mail</kw>
        </keywords>
        <abstract>This document describes the content of the "IANA MHS/MIME Equivalence table", and defines the initial configuration of this table. Mappings for new MIME content-types and/or X.400 body part types should be registered with the IANA to minimize redundancy and promote interoperability. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1495</doc-id>
        <title>Mapping between X.400 and RFC-822 Message Bodies</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <author>
            <name>S. Kille</name>
        </author>
        <author>
            <name>R. Miles</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>S. Thompson</name>
        </author>
        <date>
            <month>August</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20071</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>Mail</kw>
        </keywords>
        <abstract>Since the introduction of X.400(84), there has been work ongoing for defining mappings between MHS and RFC-822. The most recent work in this area is RFC-1327 [3], which focuses primarily on translation of envelope and headers. This document is complimentary to RFC-1327 as it focuses on translation of the message body. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2156</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1327</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1496</doc-id>
        <title>Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <author>
            <name>J. Romaguera</name>
        </author>
        <author>
            <name>K. Jordan</name>
        </author>
        <date>
            <month>August</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8411</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>HARPOON</kw>
            <kw>Mail</kw>
        </keywords>
        <abstract>This document describes how RFC-1328 must be modified in order to provide adequate support for the scenarios: It replaces chapter 6 of RFC-1328. The rest of RFC-1328 is NOT obsoleted. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1497</doc-id>
        <title>BOOTP Vendor Information Extensions</title>
        <author>
            <name>J. Reynolds</name>
        </author>
        <date>
            <month>August</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16805</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>TAGS</kw>
            <kw>Boot</kw>
        </keywords>
        <abstract>This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo is a status report on the vendor information extensions used in the Bootstrap Protocol (BOOTP). </abstract>
        <obsoletes>
            <doc-id>RFC1395</doc-id>
            <doc-id>RFC1084</doc-id>
            <doc-id>RFC1048</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1533</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0951</doc-id>
        </updates>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1498</doc-id>
        <title>On the Naming and Binding of Network Destinations</title>
        <author>
            <name>J. Saltzer</name>
        </author>
        <date>
            <month>August</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24698</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>NAMES</kw>
            <kw>Addresses</kw>
            <kw>Routes</kw>
            <kw>Objects</kw>
            <kw>Nodes</kw>
            <kw>Paths</kw>
        </keywords>
        <abstract>This brief paper offers a perspective on the subject of names of destinations in data communication networks. It suggests two ideas: First, it is helpful to distinguish among four different kinds of objects that may be named as the destination of a packet in a network. Second, the operating system concept of binding is a useful way to describe the relations among the four kinds of objects. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1499</doc-id>
        <title>Summary of 1400-1499</title>
        <author>
            <name>J. Elliott</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40923</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>Index</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1500</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>August</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>79557</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>IAB</kw>
        </keywords>
        <abstract>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1410</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1540</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1501</doc-id>
        <title>OS/2 User Group</title>
        <author>
            <name>E. Brunsen</name>
        </author>
        <date>
            <month>August</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3636</char-count>
            <page-count>2</page-count>
        </format>
        <abstract>Memo soliciting reactions to the proposal of a OS/2 User Group. This memo provides information for the Internet community. This memo does not specify an IAB standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1502</doc-id>
        <title>X.400 Use of Extended Character Sets</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>August</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27976</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>Mail</kw>
        </keywords>
        <abstract>This RFC defines a suggested method of using "GeneralText" in order to harmonize as much as possible the usage of this body part. [STANDARDS- TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1503</doc-id>
        <title>Algorithms for Automating Administration in SNMPv2 Managers</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>August</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33542</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract>When a user invokes an SNMPv2 management application, it may be desirable for the user to specify the minimum amount of information necessary to establish and maintain SNMPv2 communications. This memo suggests an approach to achieve this goal. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1504</doc-id>
        <title>Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing</title>
        <author>
            <name>A. Oppenheimer</name>
        </author>
        <date>
            <month>August</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>201553</char-count>
            <page-count>82</page-count>
        </format>
        <keywords>
            <kw>AVRP</kw>
        </keywords>
        <abstract>This document provides detailed information about the AppleTalk Update- based Routing Protocol (AURP) and wide area routing. AURP provides wide area routing enhancements to the AppleTalk routing protocols and is fully compatible with AppleTalk Phase 2. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1505</doc-id>
        <title>Encoding Header Field for Internet Messages</title>
        <author>
            <name>A. Costanzo</name>
        </author>
        <author>
            <name>D. Robinson</name>
        </author>
        <author>
            <name>R. Ullmann</name>
        </author>
        <date>
            <month>August</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63796</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>EHF-MAIL</kw>
            <kw>Mail</kw>
        </keywords>
        <abstract>This document expands upon the elective experimental Encoding header field which permits the mailing of multi-part, multi-structured messages. It replaces RFC 1154. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoletes>
            <doc-id>RFC1154</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1506</doc-id>
        <title>A Tutorial on Gatewaying between X.400 and Internet Mail</title>
        <author>
            <name>J. Houttuin</name>
        </author>
        <date>
            <month>August</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>85550</char-count>
            <page-count>39</page-count>
        </format>
        <keywords>
            <kw>822</kw>
            <kw>email</kw>
            <kw>RTR</kw>
        </keywords>
        <abstract>This tutorial was produced especially to help new gateway managers find their way into the complicated subject of mail gatewaying according to RFC 1327. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1507</doc-id>
        <title>DASS - Distributed Authentication Security Service</title>
        <author>
            <name>C. Kaufman</name>
        </author>
        <date>
            <month>September</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>287809</char-count>
            <page-count>119</page-count>
        </format>
        <keywords>
            <kw>DASS</kw>
            <kw>CAT</kw>
        </keywords>
        <abstract>The goal of DASS is to provide authentication services in a distributed environment which are both more secure and easier to use than existing mechanisms. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1508</doc-id>
        <title>Generic Security Service Application Program Interface</title>
        <author>
            <name>J. Linn</name>
        </author>
        <date>
            <month>September</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>111228</char-count>
            <page-count>49</page-count>
        </format>
        <keywords>
            <kw>CAT,GSS,API</kw>
        </keywords>
        <abstract>This Generic Security Service Application Program Interface (GSS-API) definition provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2078</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1509</doc-id>
        <title>Generic Security Service API : C-bindings</title>
        <author>
            <name>J. Wray</name>
        </author>
        <date>
            <month>September</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>99608</char-count>
            <page-count>48</page-count>
        </format>
        <keywords>
            <kw>GSSAPI</kw>
            <kw>CAT,GSS</kw>
        </keywords>
        <abstract>This document specifies C language bindings for the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in other documents. [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2744</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1510</doc-id>
        <title>The Kerberos Network Authentication Service (V5)</title>
        <author>
            <name>J. Kohl</name>
        </author>
        <author>
            <name>C. Neuman</name>
        </author>
        <date>
            <month>September</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>275395</char-count>
            <page-count>112</page-count>
        </format>
        <keywords>
            <kw>KERBEROS</kw>
            <kw>CAT,Security</kw>
        </keywords>
        <abstract>This document gives an overview and specification of Version 5 of the protocol for the Kerberos network authentication system. [STANDARDS- TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1511</doc-id>
        <title>Common Authentication Technology Overview</title>
        <author>
            <name>J. Linn</name>
        </author>
        <date>
            <month>September</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4185</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>CAT,Security</kw>
        </keywords>
        <abstract>This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1512</doc-id>
        <title>FDDI Management Information Base</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>A. Rijsinghani</name>
        </author>
        <date>
            <month>September</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>108589</char-count>
            <page-count>51</page-count>
        </format>
        <keywords>
            <kw>FDDI-MIB </kw>
            <kw>MIB</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing devices which implement the FDDI based on the ANSI FDDI SMT 7.3 draft standard, which has been forwarded for publication by the X3T9.5 committee. </abstract>
        <updates>
            <doc-id>RFC1285</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1513</doc-id>
        <title>Token Ring Extensions to the Remote Network Monitoring MIB</title>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>September</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>121974</char-count>
            <page-count>55</page-count>
        </format>
        <keywords>
            <kw>Monitoring</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract>This memo defines extensions to the Remote Network Monitoring MIB for managing 802.5 Token Ring networks. [STANDARDS-TRACK] </abstract>
        <updates>
            <doc-id>RFC1271</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1514</doc-id>
        <title>Host Resources MIB</title>
        <author>
            <name>P. Grillo</name>
        </author>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>September</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63775</char-count>
            <page-count>33</page-count>
        </format>
        <keywords>
            <kw>HOST-MIB</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract>This memo defines a MIB for use with managing host systems. [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2790</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1515</doc-id>
        <title>Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)</title>
        <author>
            <name>D. McMaster</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>S. Roberts</name>
        </author>
        <date>
            <month>September</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52828</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract>This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing IEEE 802.3 Medium Attachment Units (MAUs). [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3636</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1516</doc-id>
        <title>Definitions of Managed Objects for IEEE 802.3 Repeater Devices</title>
        <author>
            <name>D. McMaster</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>September</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>82918</char-count>
            <page-count>40</page-count>
        </format>
        <keywords>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 10 Mb/second baseband repeaters, sometimes referred to as "hubs." [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1368</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2108</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1517</doc-id>
        <title>Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)</title>
        <author>
            <name>Internet Engineering Steering Group</name>
        </author>
        <author>
            <name>R. Hinden</name>
        </author>
        <date>
            <month>September</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7357</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>CIDR</kw>
            <kw>Address</kw>
        </keywords>
        <abstract>Classless Inter-Domain Routing (CIDR) defines a mechanism to slow the growth of routing tables and reduce the need to allocate new IP network numbers. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1518</doc-id>
        <title>An Architecture for IP Address Allocation with CIDR</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <date>
            <month>September</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>72609</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>CIDR-ARCH</kw>
            <kw>Classless</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract>This paper provides an architecture and a plan for allocating IP addresses in the Internet. This architecture and the plan are intended to play an important role in steering the Internet towards the Address Assignment and Aggregating Strategy. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1519</doc-id>
        <title>Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy</title>
        <author>
            <name>V. Fuller</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>J. Yu</name>
        </author>
        <author>
            <name>K. Varadhan</name>
        </author>
        <date>
            <month>September</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59998</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>CIDR-STRA</kw>
        </keywords>
        <abstract>This memo discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1338</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1520</doc-id>
        <title>Exchanging Routing Information Across Provider Boundaries in the CIDR Environment</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>C. Topolcic</name>
        </author>
        <date>
            <month>September</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20389</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>Classless</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract>The purpose of this document is twofold. First, it describes various alternatives for exchanging inter-domain routing information across domain boundaries, where one of the peering domain is CIDR-capable and another is not. Second, it addresses the implications of running CIDR- capable inter-domain routing protocols (e.g., BGP-4, IDRP) on intra- domain routing. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1521</doc-id>
        <title>MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies</title>
        <author>
            <name>N. Borenstein</name>
        </author>
        <author>
            <name>N. Freed</name>
        </author>
        <date>
            <month>September</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>187424</char-count>
            <page-count>81</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>393670</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>205091</char-count>
        </format>
        <keywords>
            <kw>email</kw>
            <kw>multimedia</kw>
        </keywords>
        <abstract>This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. This is based on earlier work documented in RFC 934 and STD 11, RFC 1049, but extends and revises that work. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1341</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2045</doc-id>
            <doc-id>RFC2046</doc-id>
            <doc-id>RFC2047</doc-id>
            <doc-id>RFC2048</doc-id>
            <doc-id>RFC2049</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC1590</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1522</doc-id>
        <title>MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text</title>
        <author>
            <name>K. Moore</name>
        </author>
        <date>
            <month>September</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22502</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>email</kw>
            <kw>character</kw>
        </keywords>
        <abstract>This memo describes an extension to the message format defined in RFC 1521, to allow the representation of character sets other than ASCII in RFC 822 (STD 11) message headers. The extensions described were designed to be highly compatible with existing Internet mail handling software, and to be easily implemented in mail readers that support RFC 1521. </abstract>
        <obsoletes>
            <doc-id>RFC1342</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2045</doc-id>
            <doc-id>RFC2046</doc-id>
            <doc-id>RFC2047</doc-id>
            <doc-id>RFC2048</doc-id>
            <doc-id>RFC2049</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1523</doc-id>
        <title>The text/enriched MIME Content-type</title>
        <author>
            <name>N. Borenstein</name>
        </author>
        <date>
            <month>September</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32691</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>email</kw>
            <kw>mail</kw>
            <kw>richtext</kw>
        </keywords>
        <abstract>MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1563</doc-id>
            <doc-id>RFC1896</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1524</doc-id>
        <title>A User Agent Configuration Mechanism For Multimedia Mail Format Information</title>
        <author>
            <name>N. Borenstein</name>
        </author>
        <date>
            <month>September</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26464</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>MIME</kw>
            <kw>email</kw>
            <kw>mailcap</kw>
        </keywords>
        <abstract>This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1525</doc-id>
        <title>Definitions of Managed Objects for Source Routing Bridges</title>
        <author>
            <name>E. Decker</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>P. Langille</name>
        </author>
        <author>
            <name>A. Rijsinghani</name>
        </author>
        <date>
            <month>September</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38100</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>SRB-MIB</kw>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing source routing and source routing transparent bridges. These bridges are also required to implement relevant groups in the Bridge MIB. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1286</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1526</doc-id>
        <title>Assignment of System Identifiers for TUBA/CLNP Hosts</title>
        <author>
            <name>D. Piscitello</name>
        </author>
        <date>
            <month>September</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16848</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>NSAP</kw>
            <kw>Address</kw>
        </keywords>
        <abstract>This document describes conventions whereby the system identifier portion of an RFC 1237 style NSAP address may be guaranteed uniqueness within a routing domain for the purpose of autoconfiguration in TUBA/CLNP internets. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1527</doc-id>
        <title>What Should We Plan Given the Dilemma of the Network?</title>
        <author>
            <name>G. Cook</name>
        </author>
        <date>
            <month>September</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46935</char-count>
            <page-count>17</page-count>
        </format>
        <abstract>The Internet community needs to be asking what the most important policy issues facing the network are. And given agreement on any particular set of policy issues, the next thing we should be asking is, what would be some of the political choices that would follow for Congress to make? This memo is a shortened version of the suggested policy draft. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1528</doc-id>
        <title>Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures</title>
        <author>
            <name>C. Malamud</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>October</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18576</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>REM-PRINT</kw>
            <kw>FAX</kw>
            <kw>Facsimile</kw>
        </keywords>
        <abstract>This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoletes>
            <doc-id>RFC1486</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1529</doc-id>
        <title>Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Administrative Policies</title>
        <author>
            <name>C. Malamud</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>October</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11142</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>FAX</kw>
            <kw>Facsimile</kw>
        </keywords>
        <abstract>This document defines the administrative policies for the operation of remote printer facilities within the context of the tpc.int subdomain. The document describes different approaches to resource recovery for remote printer server sites and includes discussions of issues pertaining to auditing, security, and denial of access. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoletes>
            <doc-id>RFC1486</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1530</doc-id>
        <title>Principles of Operation for the TPC.INT Subdomain: General Principles and Policy</title>
        <author>
            <name>C. Malamud</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>October</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15031</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>FAX</kw>
            <kw>Facsimile</kw>
        </keywords>
        <abstract>This document defines the initial principles of operation for the tpc.int subdomain, a collection of service listings accessible over the Internet infrastructure through an administered namespace contained within the Domain Name System. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1531</doc-id>
        <title>Dynamic Host Configuration Protocol</title>
        <author>
            <name>R. Droms</name>
        </author>
        <date>
            <month>October</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>96192</char-count>
            <page-count>39</page-count>
        </format>
        <keywords>
            <kw>DHCP</kw>
        </keywords>
        <abstract>The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1541</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1532</doc-id>
        <title>Clarifications and Extensions for the Bootstrap Protocol</title>
        <author>
            <name>W. Wimer</name>
        </author>
        <date>
            <month>October</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51545</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>BOOTP</kw>
        </keywords>
        <abstract>Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1542</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC0951</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1533</doc-id>
        <title>DHCP Options and BOOTP Vendor Extensions</title>
        <author>
            <name>S. Alexander</name>
        </author>
        <author>
            <name>R. Droms</name>
        </author>
        <date>
            <month>October</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>50919</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>Dynamic</kw>
            <kw>Host</kw>
            <kw>Configuration</kw>
            <kw>Bootstrap</kw>
        </keywords>
        <abstract>This document specifies the current set of DHCP options. [STANDARDS- TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1497</doc-id>
            <doc-id>RFC1395</doc-id>
            <doc-id>RFC1084</doc-id>
            <doc-id>RFC1048</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2132</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1534</doc-id>
        <title>Interoperation Between DHCP and BOOTP</title>
        <author>
            <name>R. Droms</name>
        </author>
        <date>
            <month>October</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6966</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>DHCP-BOOTP</kw>
            <kw>Dynamic</kw>
            <kw>Host</kw>
            <kw>Configuration</kw>
            <kw>Bootstrap</kw>
        </keywords>
        <abstract>DHCP provides a superset of the functions provided by BOOTP. This document describes the interactions between DHCP and BOOTP network participants. [STANDARDS-TRACK] </abstract>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1535</doc-id>
        <title>A Security Problem and Proposed Correction With Widely Deployed DNS Software</title>
        <author>
            <name>E. Gavron</name>
        </author>
        <date>
            <month>October</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9722</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
        </keywords>
        <abstract>This document discusses a flaw in some of the currently distributed name resolver clients. The flaw exposes a security weakness related to the search heuristic invoked by these same resolvers when users provide a partial domain name, and which is easy to exploit. This document points out the flaw, a case in point, and a solution. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1536</doc-id>
        <title>Common DNS Implementation Errors and Suggested Fixes</title>
        <author>
            <name>A. Kumar</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>C. Neuman</name>
        </author>
        <author>
            <name>P. Danzig</name>
        </author>
        <author>
            <name>S. Miller</name>
        </author>
        <date>
            <month>October</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25476</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
        </keywords>
        <abstract>This memo describes common errors seen in DNS implementations and suggests some fixes. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1537</doc-id>
        <title>Common DNS Data File Configuration Errors</title>
        <author>
            <name>P. Beertema</name>
        </author>
        <date>
            <month>October</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19825</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
        </keywords>
        <abstract>This memo describes errors often found in DNS data files. It points out common mistakes system administrators tend to make and why they often go unnoticed for long periods of time. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <obsoleted-by>
            <doc-id>RFC1912</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1538</doc-id>
        <title>Advanced SNA/IP : A Simple SNA Transport Protocol</title>
        <author>
            <name>W. Behl</name>
        </author>
        <author>
            <name>B. Sterling</name>
        </author>
        <author>
            <name>W. Teskey</name>
        </author>
        <date>
            <month>October</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21217</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>ADSNA-IP</kw>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
        </keywords>
        <abstract>This RFC provides information for the Internet community about a method for establishing and maintaining SNA sessions over an IP internet. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1539</doc-id>
        <title>The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <date>
            <month>October</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48199</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>Introduction</kw>
        </keywords>
        <abstract>The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 17] </abstract>
        <obsoletes>
            <doc-id>RFC1391</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1718</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1540</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>October</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>75496</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>status</kw>
            <kw>procedure</kw>
            <kw>index</kw>
        </keywords>
        <abstract>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1500</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1600</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1541</doc-id>
        <title>Dynamic Host Configuration Protocol</title>
        <author>
            <name>R. Droms</name>
        </author>
        <date>
            <month>October</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>96950</char-count>
            <page-count>39</page-count>
        </format>
        <keywords>
            <kw>DHCP</kw>
        </keywords>
        <abstract>The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. DHCP is based on the Bootstrap Protocol (BOOTP) adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1531</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2131</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1542</doc-id>
        <title>Clarifications and Extensions for the Bootstrap Protocol</title>
        <author>
            <name>W. Wimer</name>
        </author>
        <date>
            <month>October</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52948</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>BOOTP</kw>
        </keywords>
        <abstract>Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1532</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC0951</doc-id>
        </updates>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1543</doc-id>
        <title>Instructions to RFC Authors</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>October</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31383</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>Request</kw>
            <kw>For</kw>
            <kw>Comment</kw>
        </keywords>
        <abstract>This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1111</doc-id>
            <doc-id>RFC0825</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2223</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1544</doc-id>
        <title>The Content-MD5 Header Field</title>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>November</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6478</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>MIME</kw>
            <kw>EMail</kw>
            <kw>Integrity</kw>
            <kw>MIC</kw>
            <kw>Digest</kw>
        </keywords>
        <abstract>This memo defines the use of an optional header field, Content-MD5, which may be used as a message integrity check (MIC), to verify that the decoded data are the same data that were initially sent. [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1864</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1545</doc-id>
        <title>FTP Operation Over Big Address Records (FOOBAR)</title>
        <author>
            <name>D. Piscitello</name>
        </author>
        <date>
            <month>November</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8985</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
            <kw>File Transfer</kw>
            <kw>PORT</kw>
            <kw>PASV</kw>
            <kw>LPRT</kw>
            <kw>LPSV</kw>
        </keywords>
        <abstract>This RFC specifies a method for assigning long addresses in the HOST- PORT specification for the data port to be used in establishing a data connection for File Transfer Protocol, FTP (STD 9, RFC 959). This is a general solution, applicable for all "next generation" IP alternatives, and can also be extended to allow FTP operation over transport interfaces other than TCP. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <notes>Related to RFC0959</notes>
        <obsoleted-by>
            <doc-id>RFC1639</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1546</doc-id>
        <title>Host Anycasting Service</title>
        <author>
            <name>C. Partridge</name>
        </author>
        <author>
            <name>T. Mendez</name>
        </author>
        <author>
            <name>W. Milliken</name>
        </author>
        <date>
            <month>November</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22263</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>Resource Location</kw>
            <kw>Multicasting</kw>
        </keywords>
        <abstract>This RFC describes an internet anycasting service for IP. The primary purpose of this memo is to establish the semantics of an anycasting service within an IP internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1547</doc-id>
        <title>Requirements for an Internet Standard Point-to-Point Protocol</title>
        <author>
            <name>D. Perkins</name>
        </author>
        <date>
            <month>December</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49810</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>PPP</kw>
            <kw>link</kw>
            <kw>serial</kw>
            <kw>line</kw>
        </keywords>
        <abstract>This document discusses the evaluation criteria for an Internet Standard Data Link Layer protocol to be used with point-to-point links. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1548</doc-id>
        <title>The Point-to-Point Protocol (PPP)</title>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>December</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>111638</char-count>
            <page-count>53</page-count>
        </format>
        <keywords>
            <kw>link</kw>
            <kw>serial</kw>
            <kw>line</kw>
        </keywords>
        <abstract>This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1331</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1661</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC1570</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1549</doc-id>
        <title>PPP in HDLC Framing</title>
        <author>
            <name>W. Simpson</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36352</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>point</kw>
            <kw>link</kw>
            <kw>serial</kw>
            <kw>line</kw>
        </keywords>
        <abstract>This document describes the use of HDLC for framing PPP encapsulated packets. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1662</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1550</doc-id>
        <title>IP: Next Generation (IPng) White Paper Solicitation</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <author>
            <name>A. Mankin</name>
        </author>
        <date>
            <month>December</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12472</char-count>
            <page-count>6</page-count>
        </format>
        <abstract>This memo solicits white papers on topics related to the IPng requirements and selection criteria. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1551</doc-id>
        <title>Novell IPX Over Various WAN Media (IPXWAN)</title>
        <author>
            <name>M. Allen</name>
        </author>
        <date>
            <month>December</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54210</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>Internetworking</kw>
            <kw>Packet</kw>
            <kw>Exchange</kw>
        </keywords>
        <abstract>This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC1634</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1552</doc-id>
        <title>The PPP Internetworking Packet Exchange Control Protocol (IPXCP)</title>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>December</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29173</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>IPXCP</kw>
            <kw>IPX</kw>
            <kw>point</kw>
            <kw>serial</kw>
            <kw>line</kw>
            <kw>link</kw>
        </keywords>
        <abstract>This document defines the Network Control Protocol for establishing and configuring the IPX protocol over PPP. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1553</doc-id>
        <title>Compressing IPX Headers Over WAN Media (CIPX)</title>
        <author>
            <name>S. Mathur</name>
        </author>
        <author>
            <name>M. Lewis</name>
        </author>
        <date>
            <month>December</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47450</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>CIPX</kw>
            <kw>Internetworking</kw>
            <kw>Packet</kw>
            <kw>Exchange</kw>
        </keywords>
        <abstract>This document describes a method for compressing the headers of IPX datagrams (CIPX). [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1554</doc-id>
        <title>ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP</title>
        <author>
            <name>M. Ohta</name>
        </author>
        <author>
            <name>K. Handa</name>
        </author>
        <date>
            <month>December</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11449</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>Character Set</kw>
            <kw>Japanese</kw>
        </keywords>
        <abstract>This memo describes a text encoding scheme: "ISO-2022-JP-2", which is used experimentally for electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks. The encoding is a multilingual extension of "ISO-2022-JP", the existing encoding for Japanese [2022JP]. The encoding is supported by an Emacs based multilingual text editor: MULE [MULE]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1555</doc-id>
        <title>Hebrew Character Encoding for Internet Messages</title>
        <author>
            <name>H. Nussbacher</name>
        </author>
        <author>
            <name>Y. Bourvine</name>
        </author>
        <date>
            <month>December</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9273</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>Character Set</kw>
        </keywords>
        <abstract>This document describes the encoding used in electronic mail [RFC822] for transferring Hebrew. The standard devised makes use of MIME [RFC1521] and ISO-8859-8. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1556</doc-id>
        <title>Handling of Bi-directional Texts in MIME</title>
        <author>
            <name>H. Nussbacher</name>
        </author>
        <date>
            <month>December</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5602</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>Character Set</kw>
        </keywords>
        <abstract>This document describes the format and syntax of the "direction" keyword to be used with bi-directional texts in MIME. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1557</doc-id>
        <title>Korean Character Encoding for Internet Messages</title>
        <author>
            <name>U. Choi</name>
        </author>
        <author>
            <name>K. Chon</name>
        </author>
        <author>
            <name>H. Park</name>
        </author>
        <date>
            <month>December</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8736</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>Character Set</kw>
        </keywords>
        <abstract>This document describes the encoding method being used to represent Korean characters in both header and body part of the Internet mail messages [RFC822]. This encoding method was specified in 1991, and has since then been used. It has now widely being used in Korean IP networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1558</doc-id>
        <title>A String Representation of LDAP Search Filters</title>
        <author>
            <name>T. Howes</name>
        </author>
        <date>
            <month>December</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5239</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>X.500</kw>
            <kw>Directory</kw>
        </keywords>
        <abstract>The Lightweight Directory Access Protocol (LDAP) defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC1960</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1559</doc-id>
        <title>DECnet Phase IV MIB Extensions</title>
        <author>
            <name>J. Saperia</name>
        </author>
        <date>
            <month>December</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>125427</char-count>
            <page-count>69</page-count>
        </format>
        <keywords>
            <kw>DECNET-MIB</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract>This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. It reflects changes which are the result of operational experience based on RFC 1289. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1289</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1560</doc-id>
        <title>The MultiProtocol Internet</title>
        <author>
            <name>B. Leiner</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>December</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16651</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>Architecture</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>There has recently been considerable discussion on two topics: MultiProtocol approaches in the Internet and the selection of a next generation Internet Protocol. This document suggests a strawman position for goals and approaches for the IETF/IESG/IAB in these areas. It takes the view that these two topics are related, and proposes directions for the IETF/IESG/IAB to pursue. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1561</doc-id>
        <title>Use of ISO CLNP in TUBA Environments</title>
        <author>
            <name>D. Piscitello</name>
        </author>
        <date>
            <month>December</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>55902</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>CLNP-TUBA</kw>
            <kw>OSI</kw>
            <kw>IP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This memo specifies a profile of the ISO/IEC 8473 Connectionless-mode Network Layer Protocol for use in conjunction with RFC 1347, TCP/UDP over Bigger Addresses. It describes the use of CLNP to provide the lower-level service expected by Transmission Control Protocol and User Datagram Protocol. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1562</doc-id>
        <title>Naming Guidelines for the AARNet X.500 Directory Service</title>
        <author>
            <name>G. Michaelson</name>
        </author>
        <author>
            <name>M. Prior</name>
        </author>
        <date>
            <month>December</month>
            <year>1993</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6884</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>Australia</kw>
        </keywords>
        <abstract>This document is an AARNet (Australian Academic and Research Network) Engineering Note (AEN-001). AARNet Engineering Notes are engineering documents of the AARNet Engineering Working Group, and record current or proposed operational practices related to the provision of Internetworking services within Australia, and AARNet in particular. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1563</doc-id>
        <title>The text/enriched MIME Content-type</title>
        <author>
            <name>N. Borenstein</name>
        </author>
        <date>
            <month>January</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32913</char-count>
            <page-count>16</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>73543</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>37459</char-count>
        </format>
        <keywords>
            <kw>email</kw>
            <kw>mail</kw>
            <kw>richtext</kw>
        </keywords>
        <abstract>MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1523</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1896</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1564</doc-id>
        <title>DSA Metrics (OSI-DS 34 (v3))</title>
        <author>
            <name>P. Barker</name>
        </author>
        <author>
            <name>R. Hedberg</name>
        </author>
        <date>
            <month>January</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46205</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>x.500</kw>
            <kw>Directory</kw>
            <kw>Service</kw>
            <kw>Agent</kw>
        </keywords>
        <abstract>This document defines a set of criteria by which a DSA implementation may be judged. Particular issues covered include conformance to standards; performance; demonstrated interoperability. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1565</doc-id>
        <title>Network Services Monitoring MIB</title>
        <author>
            <name>S. Kille</name>
        </author>
        <author>
            <name>N. Freed</name>
        </author>
        <date>
            <month>January</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29761</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>This document defines a MIB which contains the elements common to the monitoring of any network service application. This information includes a table of all monitorable network service applications, a count of the associations (connections) to each application, and basic information about the parameters and status of each application-related association. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2248</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1566</doc-id>
        <title>Mail Monitoring MIB</title>
        <author>
            <name>S. Kille</name>
        </author>
        <author>
            <name>N. Freed</name>
        </author>
        <date>
            <month>January</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33136</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this memo extends the basic Network Services Monitoring MIB to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2249</doc-id>
            <doc-id>RFC2789</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1567</doc-id>
        <title>X.500 Directory Monitoring MIB</title>
        <author>
            <name>G. Mansfield</name>
        </author>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>January</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33527</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>X500-MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>This document defines a portion of the Management Information Base (MIB). It defines the MIB for monitoring Directory System Agents (DSA), a component of the OSI Directory. This MIB will be used in conjunction with the APPLICATION-MIB for monitoring DSAs. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2605</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1568</doc-id>
        <title>Simple Network Paging Protocol - Version 1(b)</title>
        <author>
            <name>A. Gwinn</name>
        </author>
        <date>
            <month>January</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16558</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>Beeper</kw>
        </keywords>
        <abstract>This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC1645</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1569</doc-id>
        <title>Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures</title>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>January</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12597</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>Beeper</kw>
        </keywords>
        <abstract>This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC1703</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1570</doc-id>
        <title>PPP LCP Extensions</title>
        <author>
            <name>W. Simpson</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35719</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>PPP-LCP</kw>
            <kw>Point-to Point</kw>
            <kw>Link</kw>
            <kw>Control</kw>
            <kw>Protocol</kw>
            <kw>serial</kw>
            <kw>line</kw>
        </keywords>
        <abstract>The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. This document defines several additional LCP features which have been suggested over the past few years. [STANDARDS-TRACK] </abstract>
        <updates>
            <doc-id>RFC1548</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC2484</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1571</doc-id>
        <title>Telnet Environment Option Interoperability Issues</title>
        <author>
            <name>D. Borman</name>
        </author>
        <date>
            <month>January</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8117</char-count>
            <page-count>4</page-count>
        </format>
        <abstract>This document describes a method for allowing implementors to ensure that their implementation of the Environment option will be interoperable with as many other implementations as possible, by providing a set of heuristics that can be used to help identify which definitions for VAR and VALUE are being used by the other side of the connection. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <updates>
            <doc-id>RFC1408</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1572</doc-id>
        <title>Telnet Environment Option</title>
        <author>
            <name>S. Alexander</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14676</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>TOPT-ENVIR</kw>
        </keywords>
        <abstract>This document specifies a mechanism for passing environment information between a telnet client and server. Use of this mechanism enables a telnet user to propagate configuration information to a remote host when connecting. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1573</doc-id>
        <title>Evolution of the Interfaces Group of MIB-II</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>F. Kastenholz</name>
        </author>
        <date>
            <month>January</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>123057</char-count>
            <page-count>55</page-count>
        </format>
        <keywords>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. [STANARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1229</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2233</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1574</doc-id>
        <title>Essential Tools for the OSI Internet</title>
        <author>
            <name>S. Hares</name>
        </author>
        <author>
            <name>C. Wittbrodt</name>
        </author>
        <date>
            <month>February</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27735</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>Echo</kw>
            <kw>Traceroute</kw>
            <kw>Routing Table</kw>
            <kw>CLNP</kw>
        </keywords>
        <abstract>This document specifies the following three necessary tools to debug problems in the deployment and maintenance of networks using ISO 8473 (CLNP): ping or OSI Echo function, traceroute function which uses the OSI Echo function, and routing table dump function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1139</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1575</doc-id>
        <title>An Echo Function for CLNP (ISO 8473)</title>
        <author>
            <name>S. Hares</name>
        </author>
        <author>
            <name>C. Wittbrodt</name>
        </author>
        <date>
            <month>February</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22479</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>ISO-TS-ECHO</kw>
        </keywords>
        <abstract>This memo defines an echo function for the connection-less network layer protocol. The mechanism that is mandated here is in the final process of being standardized by ISO as "Amendment X: Addition of an Echo function to ISO 8473" an integral part of Version 2 of ISO 8473. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1139</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1576</doc-id>
        <title>TN3270 Current Practices</title>
        <author>
            <name>J. Penner</name>
        </author>
        <date>
            <month>January</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24477</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>Telnet Option Terminal Type EOR Binary</kw>
        </keywords>
        <abstract>This document describes the existing implementation of transferring 3270 display terminal data using currently available telnet capabilities. The name traditionally associated with this implementation is TN3270. This memo provides information for the Internet community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1577</doc-id>
        <title>Classical IP and ARP over ATM</title>
        <author>
            <name>M. Laubach</name>
        </author>
        <date>
            <month>January</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41239</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>Address</kw>
            <kw>Resolution</kw>
            <kw>Asynchronous</kw>
            <kw>Transmission</kw>
            <kw>Mode</kw>
        </keywords>
        <abstract>This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS). [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2225</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1578</doc-id>
        <title>FYI on Questions and Answers - Answers to Commonly Asked "Primary and Secondary School Internet User" Questions</title>
        <author>
            <name>J. Sellers</name>
        </author>
        <date>
            <month>February</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>113646</char-count>
            <page-count>53</page-count>
        </format>
        <keywords>
            <kw>K12</kw>
        </keywords>
        <abstract>The goal of this FYI RFC is to document the questions most commonly asked about the Internet by those in the primary and secondary school community, and to provide pointers to sources which answer those questions. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. [FYI 22] </abstract>
        <obsoleted-by>
            <doc-id>RFC1941</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1579</doc-id>
        <title>Firewall-Friendly FTP</title>
        <author>
            <name>S. Bellovin</name>
        </author>
        <date>
            <month>February</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8806</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>PORT</kw>
            <kw>PASV</kw>
            <kw>Security</kw>
        </keywords>
        <abstract>This memo describes a suggested change to the behavior of FTP client programs. This document provides information for the Internet community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1580</doc-id>
        <title>Guide to Network Resource Tools</title>
        <author>
            <name>EARN Staff</name>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>235112</char-count>
            <page-count>107</page-count>
        </format>
        <keywords>
            <kw>EARN</kw>
            <kw>BITNET</kw>
            <kw>Gopher</kw>
            <kw>World-Wide Web</kw>
            <kw>WWW</kw>
            <kw>WAIS</kw>
            <kw>Archie</kw>
            <kw>Whois</kw>
            <kw>X.500</kw>
            <kw>Netfind</kw>
            <kw>Trickle</kw>
            <kw>BIFTP</kw>
            <kw>Listserv</kw>
            <kw>Netnews</kw>
            <kw>Astra</kw>
            <kw>NetServ</kw>
            <kw>Mail Base</kw>
            <kw>Prospero</kw>
            <kw>IRC</kw>
            <kw>Relay</kw>
        </keywords>
        <abstract>The purpose of this guide is to supply the basic information that anyone on the network needs to try out and begin using tools. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. [FYI 23] </abstract>
        <is-also>
            <doc-id>FYI0023</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1581</doc-id>
        <title>Protocol Analysis for Extensions to RIP to Support Demand Circuits</title>
        <author>
            <name>G. Meyer</name>
        </author>
        <date>
            <month>February</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7536</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>routing</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>As required by Routing Protocol Criteria, this report documents the key features of Routing over Demand Circuits on Wide Area Networks - RIP and the current implementation experience. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1582</doc-id>
        <title>Extensions to RIP to Support Demand Circuits</title>
        <author>
            <name>G. Meyer</name>
        </author>
        <date>
            <month>February</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63271</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>RIP-DC</kw>
            <kw>routing</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This memo defines a generalized modification which can be applied to Bellman-Ford (or distance vector) algorithm information broadcasting protocols. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1583</doc-id>
        <title>OSPF Version 2</title>
        <author>
            <name>J. Moy</name>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>532636</char-count>
            <page-count>216</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>990794</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>465711</char-count>
        </format>
        <keywords>
            <kw>equal-cost</kw>
            <kw>multipath</kw>
            <kw>link state</kw>
            <kw>LSA</kw>
        </keywords>
        <abstract>This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1247</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2178</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1584</doc-id>
        <title>Multicast Extensions to OSPF</title>
        <author>
            <name>J. Moy</name>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>262463</char-count>
            <page-count>102</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>426358</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>243185</char-count>
        </format>
        <keywords>
            <kw>OSPF-Multi</kw>
            <kw>Open</kw>
            <kw>Shortest</kw>
            <kw>Path</kw>
            <kw>First</kw>
        </keywords>
        <abstract>This memo documents enhancements to the OSPF protocol enabling the routing of IP multicast datagrams. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1585</doc-id>
        <title>MOSPF: Analysis and Experience</title>
        <author>
            <name>J. Moy</name>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29754</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>Multicast</kw>
            <kw>Open</kw>
            <kw>Shortest</kw>
            <kw>Path</kw>
            <kw>First</kw>
            <kw>OSPF</kw>
        </keywords>
        <abstract>This memo documents how the MOSPF protocol satisfies the requirements imposed on Internet routing protocols by "Internet Engineering Task Force internet routing protocol standardization criteria" ([RFC 1264]). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1586</doc-id>
        <title>Guidelines for Running OSPF Over Frame Relay Networks</title>
        <author>
            <name>O. deSouza</name>
        </author>
        <author>
            <name>M. Rodrigues</name>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14968</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>FR</kw>
            <kw>Open</kw>
            <kw>Shortest</kw>
            <kw>Path</kw>
            <kw>First</kw>
        </keywords>
        <abstract>This memo specifies guidelines for implementors and users of the Open Shortest Path First (OSPF) routing protocol to bring about improvements in how the protocol runs over frame relay networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1587</doc-id>
        <title>The OSPF NSSA Option</title>
        <author>
            <name>R. Coltun</name>
        </author>
        <author>
            <name>V. Fuller</name>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37412</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>OSPF-NSSA</kw>
            <kw>Open</kw>
            <kw>Shortest</kw>
            <kw>Path</kw>
            <kw>First</kw>
            <kw>not so stubby</kw>
            <kw>area</kw>
            <kw>routing</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document describes a new optional type of OSPF area, somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3101</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1588</doc-id>
        <title>White Pages Meeting Report</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>C. Anderson</name>
        </author>
        <date>
            <month>February</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>77945</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
            <kw>X-500 directory</kw>
        </keywords>
        <abstract>This report describes the results of a meeting held at the November IETF (Internet Engineering Task Force) in Houston, TX, on November 2, 1993, to discuss the future of and approaches to a white pages directory services for the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1589</doc-id>
        <title>A Kernel Model for Precision Timekeeping</title>
        <author>
            <name>D. Mills</name>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>88129</char-count>
            <page-count>37</page-count>
        </format>
        <keywords>
            <kw>Time</kw>
            <kw>NTP</kw>
            <kw>Clock</kw>
        </keywords>
        <abstract>This memorandum describes an engineering model which implements a precision time-of-day function for a generic operating system. The model is based on the principles of disciplined oscillators and phase-lock loops (PLL) often found in the engineering literature. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1590</doc-id>
        <title>Media Type Registration Procedure</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13044</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>email</kw>
            <kw>multimedia</kw>
        </keywords>
        <abstract>Several questions have been raised about the requirements and administrative procedure for registering MIME content-type and subtypes, and the use of these Media Types for other applications. This document addresses these issues and specifies a procedure for the registration of new Media Types (content-type/subtypes). It also generalizes the scope of use of these Media Types to make it appropriate to use the same registrations and specifications with other applications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC2045</doc-id>
            <doc-id>RFC2046</doc-id>
            <doc-id>RFC2047</doc-id>
            <doc-id>RFC2048</doc-id>
            <doc-id>RFC2049</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1521</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1591</doc-id>
        <title>Domain Name System Structure and Delegation</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16481</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>DNS</kw>
            <kw>Policy</kw>
            <kw>Top-Level</kw>
            <kw>TLD</kw>
        </keywords>
        <abstract>This memo provides some information on the structure of the names in the Domain Name System (DNS), specifically the top-level domain names; and on the administration of domains. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1592</doc-id>
        <title>Simple Network Management Protocol Distributed Protocol Interface Version 2.0</title>
        <author>
            <name>B. Wijnen</name>
        </author>
        <author>
            <name>G. Carpenter</name>
        </author>
        <author>
            <name>K. Curran</name>
        </author>
        <author>
            <name>A. Sehgal</name>
        </author>
        <author>
            <name>G. Waters</name>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>135259</char-count>
            <page-count>54</page-count>
        </format>
        <keywords>
            <kw>SNMP-DPI</kw>
            <kw>SNMP</kw>
            <kw>DPT</kw>
            <kw>IBM</kw>
        </keywords>
        <abstract>This RFC describes version 2.0 of a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1228</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1593</doc-id>
        <title>SNA APPN Node MIB</title>
        <author>
            <name>W. McKenzie</name>
        </author>
        <author>
            <name>J. Cheng</name>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>207882</char-count>
            <page-count>120</page-count>
        </format>
        <keywords>
            <kw>IBM</kw>
            <kw>Management</kw>
        </keywords>
        <abstract>This RFC describes IBM's SNMP support for SNA Advanced Peer-to-Peer Networking (APPN) nodes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1594</doc-id>
        <title>FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions</title>
        <author>
            <name>A. Marine</name>
        </author>
        <author>
            <name>J. Reynolds</name>
        </author>
        <author>
            <name>G. Malkin</name>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>98753</char-count>
            <page-count>44</page-count>
        </format>
        <keywords>
            <kw>documentation</kw>
            <kw>help</kw>
            <kw>information</kw>
            <kw>FAQ</kw>
        </keywords>
        <abstract>This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. [FYI 4] </abstract>
        <obsoletes>
            <doc-id>RFC1325</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2664</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1595</doc-id>
        <title>Definitions of Managed Objects for the SONET/SDH Interface Type</title>
        <author>
            <name>T. Brown</name>
        </author>
        <author>
            <name>K. Tesink</name>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>121937</char-count>
            <page-count>59</page-count>
        </format>
        <keywords>
            <kw>SONET-MIB</kw>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <obsoleted-by>
            <doc-id>RFC2558</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1596</doc-id>
        <title>Definitions of Managed Objects for Frame Relay Service</title>
        <author>
            <name>T. Brown</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>88795</char-count>
            <page-count>46</page-count>
        </format>
        <keywords>
            <kw>FR</kw>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <obsoleted-by>
            <doc-id>RFC1604</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1597</doc-id>
        <title>Address Allocation for Private Internets</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>B. Moskowitz</name>
        </author>
        <author>
            <name>D. Karrenberg</name>
        </author>
        <author>
            <name>G. de Groot</name>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17430</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>IP</kw>
            <kw>Network</kw>
            <kw>Number</kw>
            <kw>Local</kw>
        </keywords>
        <abstract>This RFC describes methods to preserve IP address space by not allocating globally unique IP addresses to hosts private to an enterprise while still permitting full network layer connectivity between all hosts inside an enterprise as well as between all public hosts of different enterprises. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC1918</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1598</doc-id>
        <title>PPP in X.25</title>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13835</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>PPP-X25</kw>
            <kw>point</kw>
        </keywords>
        <abstract>The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of X.25 for framing PPP encapsulated packets. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1599</doc-id>
        <title>Summary of 1500-1599</title>
        <author>
            <name>M. Kennedy</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43761</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>Index</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1600</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>80958</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>status</kw>
            <kw>procedure</kw>
            <kw>index</kw>
        </keywords>
        <abstract>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1540</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1610</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1601</doc-id>
        <title>Charter of the Internet Architecture Board (IAB)</title>
        <author>
            <name>C. Huitema</name>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12424</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>ISOC</kw>
            <kw>Internet Society</kw>
            <kw>IETF</kw>
            <kw>IRTF</kw>
        </keywords>
        <abstract>This memo documents the composition, selection, roles, and organization of the Internet Architecture Board and its subsidiary organizations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1358</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2850</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1602</doc-id>
        <title>The Internet Standards Process -- Revision 2</title>
        <author>
            <name>Internet Architecture Board</name>
        </author>
        <author>
            <name>Internet Engineering Steering Group </name>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>88465</char-count>
            <page-count>37</page-count>
        </format>
        <abstract>This document is a revision of RFC 1310, which defined the official procedures for creating and documenting Internet Standards. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1310</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2026</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC1871</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1603</doc-id>
        <title>IETF Working Group Guidelines and Procedures</title>
        <author>
            <name>E. Huizer</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63900</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>WG</kw>
        </keywords>
        <abstract>This document describes the guidelines and procedures for formation and operation of IETF working groups. It describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC2418</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC1871</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1604</doc-id>
        <title>Definitions of Managed Objects for Frame Relay Service</title>
        <author>
            <name>T. Brown</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>88770</char-count>
            <page-count>46</page-count>
        </format>
        <keywords>
            <kw>FR-MIB</kw>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
            <kw>Network</kw>
        </keywords>
        <abstract>This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1596</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2954</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1605</doc-id>
        <title>SONET to Sonnet Translation</title>
        <author>
            <name>W. Shakespeare</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4451</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>Humor</kw>
        </keywords>
        <abstract>Because Synchronous Optical Network (SONET) transmits data in frames of bytes, it is fairly easy to envision ways to compress SONET frames to yield higher bandwidth over a given fiber optic link. This memo describes a particular method, SONET Over Novel English Translation (SONNET). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1606</doc-id>
        <title>A Historical Perspective On The Usage Of IP Version 9</title>
        <author>
            <name>J. Onions</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8398</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>Humor</kw>
        </keywords>
        <abstract>This paper reviews the usages of the old IP version protocol. It considers some of its successes and its failures. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1607</doc-id>
        <title>A VIEW FROM THE 21ST CENTURY</title>
        <author>
            <name>V. Cerf</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28165</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>V. Cerf</kw>
        </keywords>
        <abstract>This document is a composition of letters discussing a possible future. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1608</doc-id>
        <title>Representing IP Information in the X.500 Directory</title>
        <author>
            <name>T. Johannsen</name>
        </author>
        <author>
            <name>G. Mansfield</name>
        </author>
        <author>
            <name>M. Kosters</name>
        </author>
        <author>
            <name>S. Sataluri</name>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40269</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>X500-DIR</kw>
            <kw>Data</kw>
            <kw>Structure</kw>
            <kw>Schemo</kw>
        </keywords>
        <abstract>This document describes the objects necessary to include information about IP networks and IP numbers in the X.500 Directory. It extends the work "Charting networks in the X.500 Directory" [1] where a general framework is presented for representing networks in the Directory by applying it to IP networks. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1609</doc-id>
        <title>Charting Networks in the X.500 Directory</title>
        <author>
            <name>G. Mansfield</name>
        </author>
        <author>
            <name>T. Johannsen</name>
        </author>
        <author>
            <name>M. Knopper</name>
        </author>
        <date>
            <month>March</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30044</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>X500-CHART</kw>
            <kw>Data</kw>
            <kw>Structure</kw>
            <kw>Schemo</kw>
        </keywords>
        <abstract>This document presents a model in which a communication network with all its related details and descriptions can be represented in the X.500 Directory. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1610</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>81346</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>status</kw>
            <kw>procedure</kw>
            <kw>index</kw>
        </keywords>
        <abstract>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1600</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1720</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1611</doc-id>
        <title>DNS Server MIB Extensions</title>
        <author>
            <name>R. Austein</name>
        </author>
        <author>
            <name>J. Saperia</name>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>58700</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>DNS-S-MIB</kw>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of extensions which instrument DNS name server functions. This memo was produced by the DNS working group. [STANDARDS-TRACK] </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1612</doc-id>
        <title>DNS Resolver MIB Extensions</title>
        <author>
            <name>R. Austein</name>
        </author>
        <author>
            <name>J. Saperia</name>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>61382</char-count>
            <page-count>32</page-count>
        </format>
        <keywords>
            <kw>DNS-R-MIB</kw>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of extensions which instrument DNS resolver functions. This memo was produced by the DNS working group. [STANDARDS-TRACK] </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1613</doc-id>
        <title>cisco Systems X.25 over TCP (XOT)</title>
        <author>
            <name>J. Forster</name>
        </author>
        <author>
            <name>G. Satz</name>
        </author>
        <author>
            <name>G. Glick</name>
        </author>
        <author>
            <name>R. Day</name>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29267</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>Transmission</kw>
            <kw>Control</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This memo documents a method of sending X.25 packets over IP internets by encapsulating the X.25 Packet Level in TCP packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1614</doc-id>
        <title>Network Access to Multimedia Information</title>
        <author>
            <name>C. Adie</name>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>187253</char-count>
            <page-count>79</page-count>
        </format>
        <keywords>
            <kw>RARE</kw>
            <kw>Technical</kw>
            <kw>Report</kw>
        </keywords>
        <abstract>This report summarises the requirements of research and academic network users for network access to multimedia information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1615</doc-id>
        <title>Migrating from X.400(84) to X.400(88)</title>
        <author>
            <name>J. Houttuin</name>
        </author>
        <author>
            <name>J. Craigie</name>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39693</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>RARE</kw>
            <kw>Technical</kw>
            <kw>Report</kw>
            <kw>email</kw>
        </keywords>
        <abstract>This document compares X.400(88) to X.400(84) and describes what problems can be anticipated in the migration, especially considering the migration from the existing X.400(84) infrastructure created by the COSINE MHS project to an X.400(88) infrastructure. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1616</doc-id>
        <title>X.400(1988) for the Academic and Research Community in Europe</title>
        <author>
            <name>RARE WG-MSG Task Force 88</name>
        </author>
        <author>
            <name>E. Huizer</name>
        </author>
        <author>
            <name>J. Romaguera</name>
            <title>Editors</title>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>107432</char-count>
            <page-count>44</page-count>
        </format>
        <keywords>
            <kw>RARE</kw>
            <kw>Technical</kw>
            <kw>Report</kw>
            <kw>email</kw>
        </keywords>
        <abstract>The report documents the results of a task force on X.400(1988) deployment of the RARE Mails and Messaging Work Group during the period from November 1992 until October 1993. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1617</doc-id>
        <title>Naming and Structuring Guidelines for X.500 Directory Pilots</title>
        <author>
            <name>P. Barker</name>
        </author>
        <author>
            <name>S. Kille</name>
        </author>
        <author>
            <name>T. Lenggenhager</name>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>56739</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>RARE</kw>
            <kw>Technical</kw>
            <kw>Report</kw>
            <kw>White Pages </kw>
        </keywords>
        <abstract>This document defines a number of naming and structuring guidelines focused on White Pages usage. Alignment to these guidelines is recommended for directory pilots. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1384</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1618</doc-id>
        <title>PPP over ISDN</title>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14896</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>PPP-ISDN</kw>
            <kw>Point</kw>
            <kw>Integrated Services Digital Network</kw>
        </keywords>
        <abstract>This document describes the use of PPP over Integrated Services Digital Network (ISDN) switched circuits. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1619</doc-id>
        <title>PPP over SONET/SDH</title>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8893</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>PPP-SONET</kw>
            <kw>Point</kw>
            <kw>Synchronous Optical Network Digital Heirarchy</kw>
        </keywords>
        <abstract>This document describes the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Heirarchy (SDH) circuits. [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2615</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1620</doc-id>
        <title>Internet Architecture Extensions for Shared Media</title>
        <author>
            <name>B. Braden</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44999</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>Public</kw>
            <kw>data</kw>
            <kw>networks</kw>
            <kw>ARP</kw>
            <kw>address</kw>
            <kw>resolution</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo discusses alternative approaches to extending the Internet architecture to eliminate some or all unnecessary hops. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1621</doc-id>
        <title>Pip Near-term Architecture</title>
        <author>
            <name>P. Francis</name>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>128905</char-count>
            <page-count>51</page-count>
        </format>
        <keywords>
            <kw>Internet Protocol</kw>
            <kw>IPng</kw>
        </keywords>
        <abstract>The purpose of this RFC and the companion RFC "Pip Header Processing" are to record the ideas (good and bad) of Pip. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1622</doc-id>
        <title>Pip Header Processing</title>
        <author>
            <name>P. Francis</name>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34837</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>Internet Protocol</kw>
            <kw>IPng</kw>
        </keywords>
        <abstract>The purpose of this RFC and the companion RFC "Pip Near-term Architecture" are to record the ideas (good and bad) of Pip. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1623</doc-id>
        <title>Definitions of Managed Objects for the Ethernet-like Interface Types</title>
        <author>
            <name>F. Kastenholz</name>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38745</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1398</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1643</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1624</doc-id>
        <title>Computation of the Internet Checksum via Incremental Update</title>
        <author>
            <name>A. Rijsinghani</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9836</char-count>
            <page-count>6</page-count>
        </format>
        <abstract>This memo describes an updated technique for incremental computation of the standard Internet checksum. It updates the method described in RFC 1141. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <updates>
            <doc-id>RFC1141</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1625</doc-id>
        <title>WAIS over Z39.50-1988</title>
        <author>
            <name>M. St. Pierre</name>
        </author>
        <author>
            <name>J. Fullton</name>
        </author>
        <author>
            <name>K. Gamiel</name>
        </author>
        <author>
            <name>J. Goldman</name>
        </author>
        <author>
            <name>B. Kahle</name>
        </author>
        <author>
            <name>J. Kunze</name>
        </author>
        <author>
            <name>H. Morris</name>
        </author>
        <author>
            <name>F. Schiettecatte</name>
        </author>
        <date>
            <month>June</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14694</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>Wide</kw>
            <kw>Area</kw>
            <kw>Information</kw>
            <kw>Servers</kw>
            <kw>Library</kw>
        </keywords>
        <abstract>The purpose of this memo is to initiate a discussion for a migration path of the WAIS technology from Z39.50-1988 Information Retrieval Service Definitions and Protocol Specification for Library Applications [1] to Z39.50-1992 [2] and then to Z39.50-1994 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1626</doc-id>
        <title>Default IP MTU for use over ATM AAL5</title>
        <author>
            <name>R. Atkinson</name>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11841</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>Maximum</kw>
            <kw>Transmission</kw>
            <kw>Unit</kw>
            <kw>Asynchronous</kw>
            <kw>Transfer</kw>
            <kw>Mode</kw>
            <kw>Adaptation</kw>
            <kw>Layer</kw>
            <kw>Size</kw>
            <kw>Packet</kw>
        </keywords>
        <abstract>There are a number of good reasons to have a reasonably large default MTU value for IP over ATM AAL5. This paper presents the default IP MIU for use over ATM AAL5. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2225</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1627</doc-id>
        <title>Network 10 Considered Harmful (Some Practices Shouldn't be Codified)</title>
        <author>
            <name>E. Lear</name>
        </author>
        <author>
            <name>E. Fair</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <author>
            <name>T. Kessler</name>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18823</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>IP</kw>
            <kw>Network</kw>
            <kw>Number</kw>
            <kw>Local</kw>
        </keywords>
        <abstract>This document restates the arguments for maintaining a unique address space. Concerns for Internet architecture and operations, as well as IETF procedure, are explored. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC1918</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1628</doc-id>
        <title>UPS Management Information Base</title>
        <author>
            <name>J. Case</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>83439</char-count>
            <page-count>45</page-count>
        </format>
        <keywords>
            <kw>UPS-MIB</kw>
            <kw>Uninterruptible</kw>
            <kw>Power</kw>
            <kw>Supply</kw>
            <kw>MIB</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing uninterruptible power supply (UPS) systems. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1629</doc-id>
        <title>Guidelines for OSI NSAP Allocation in the Internet</title>
        <author>
            <name>R. Colella</name>
        </author>
        <author>
            <name>R. Callon</name>
        </author>
        <author>
            <name>E. Gardner</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>131640</char-count>
            <page-count>52</page-count>
        </format>
        <keywords>
            <kw>OSI-NSAP</kw>
            <kw>CLNP</kw>
            <kw>Address</kw>
        </keywords>
        <abstract>This paper provides guidelines for allocating NSAP addresses in the Internet. The guidelines provided in this paper have been the basis for initial deployment of CLNP in the Internet, and have proven very valuable both as an aid to scaling of CLNP routing, and for address administration. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1237</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1630</doc-id>
        <title>Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web</title>
        <author>
            <name>T. Berners-Lee</name>
        </author>
        <date>
            <month>June</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>57601</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>World</kw>
            <kw>Wide</kw>
            <kw>Web</kw>
            <kw>URI</kw>
        </keywords>
        <abstract>This document defines the syntax used by the World-Wide Web initiative to encode the names and addresses of objects on the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1631</doc-id>
        <title>The IP Network Address Translator (NAT)</title>
        <author>
            <name>K. Egevang</name>
        </author>
        <author>
            <name>P. Francis</name>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22714</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>Internet Protocol</kw>
        </keywords>
        <abstract>This memo proposes another short-term solution, address reuse, that complements CIDR or even makes it unnecessary. The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC3022</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1632</doc-id>
        <title>A Revised Catalog of Available X.500 Implementations</title>
        <author>
            <name>A. Getchell</name>
        </author>
        <author>
            <name>S. Sataluri</name>
            <title>Editors</title>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>124111</char-count>
            <page-count>94</page-count>
        </format>
        <keywords>
            <kw>Directory</kw>
            <kw>White</kw>
            <kw>Pages</kw>
        </keywords>
        <abstract>This document is the result of a survey that gathered new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings. This document is a revision of RFC 1292. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1292</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2116</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1633</doc-id>
        <title>Integrated Services in the Internet Architecture: an Overview</title>
        <author>
            <name>R. Braden</name>
        </author>
        <author>
            <name>D. Clark</name>
        </author>
        <author>
            <name>S. Shenker</name>
        </author>
        <date>
            <month>June</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>89691</char-count>
            <page-count>33</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>207016</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>201858</char-count>
        </format>
        <keywords>
            <kw>real time</kw>
            <kw>Multi-media</kw>
            <kw>reservations</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This memo discusses a proposed extension to the Internet architecture and protocols to provide integrated services, i.e., to support real-time as well as the current non-real-time service of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1634</doc-id>
        <title>Novell IPX Over Various WAN Media (IPXWAN)</title>
        <author>
            <name>M. Allen</name>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>55347</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>wide</kw>
            <kw>area</kw>
            <kw>network</kw>
        </keywords>
        <abstract>This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1551</doc-id>
            <doc-id>RFC1362</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1635</doc-id>
        <title>How to Use Anonymous FTP</title>
        <author>
            <name>P. Deutsch</name>
        </author>
        <author>
            <name>A. Emtage</name>
        </author>
        <author>
            <name>A. Marine</name>
        </author>
        <date>
            <month>May</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27258</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>File</kw>
            <kw>Transfer</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document provides information for the novice Internet user about using the File Transfer Protocol (FTP). It explains what FTP is, what anonymous FTP is, and what an anonymous FTP archive site is. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <is-also>
            <doc-id>FYI0024</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1636</doc-id>
        <title>Report of IAB Workshop on Security in the Internet Architecture - February 8-10, 1994</title>
        <author>
            <name>R. Braden</name>
        </author>
        <author>
            <name>D. Clark</name>
        </author>
        <author>
            <name>S. Crocker</name>
        </author>
        <author>
            <name>C. Huitema</name>
        </author>
        <date>
            <month>June</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>130761</char-count>
            <page-count>52</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Architecture</kw>
            <kw>Board</kw>
        </keywords>
        <abstract>This document is a report on an Internet architecture workshop, initiated by the IAB and held at USC Information Sciences Institute on February 8-10, 1994. This workshop generally focused on security issues in the Internet architecture. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1637</doc-id>
        <title>DNS NSAP Resource Records</title>
        <author>
            <name>B. Manning</name>
        </author>
        <author>
            <name>R. Colella</name>
        </author>
        <date>
            <month>June</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21768</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
            <kw>ISO</kw>
            <kw>OSI</kw>
            <kw>Address</kw>
        </keywords>
        <abstract>This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoletes>
            <doc-id>RFC1348</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1706</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1638</doc-id>
        <title>PPP Bridging Control Protocol (BCP)</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>R. Bowen</name>
        </author>
        <date>
            <month>June</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>58477</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>PPP-BCP</kw>
            <kw>Point to Point</kw>
        </keywords>
        <abstract>This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1220</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2878</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1639</doc-id>
        <title>FTP Operation Over Big Address Records (FOOBAR)</title>
        <author>
            <name>D. Piscitello</name>
        </author>
        <date>
            <month>June</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10055</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>FOOBAR</kw>
            <kw>File</kw>
            <kw>Transfer</kw>
            <kw>Port</kw>
        </keywords>
        <abstract>This RFC specifies a method for assigning addresses other than 32-bit IPv4 addresses to data ports through the specification of a "long Port (LPRT)" command and "Long Passive (LPSV)" reply, each having as its argument a &lt;long-host-port&gt;, which allows for additional address families, variable length network addresses and variable length port numbers. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoletes>
            <doc-id>RFC1545</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1640</doc-id>
        <title>The Process for Organization of Internet Standards Working Group (POISED)</title>
        <author>
            <name>S. Crocker</name>
        </author>
        <date>
            <month>June</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21780</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>IETF</kw>
            <kw>IESG</kw>
            <kw>IAB</kw>
            <kw>ISOC</kw>
        </keywords>
        <abstract>This report, originally prepared in January 1993 provides a summary of the POISED WG, starting from the events leading to the formation of the WG to the end of 1992. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1641</doc-id>
        <title>Using Unicode with MIME</title>
        <author>
            <name>D. Goldsmith</name>
        </author>
        <author>
            <name>M. Davis</name>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11258</char-count>
            <page-count>6</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>20451</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>11658</char-count>
        </format>
        <keywords>
            <kw>MIME-UNI</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extension</kw>
            <kw>Character</kw>
            <kw>Set</kw>
        </keywords>
        <abstract>This document specifies the usage of Unicode within MIME. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1642</doc-id>
        <title>UTF-7 - A Mail-Safe Transformation Format of Unicode</title>
        <author>
            <name>D. Goldsmith</name>
        </author>
        <author>
            <name>M. Davis</name>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27770</char-count>
            <page-count>14</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>50907</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>29573</char-count>
        </format>
        <keywords>
            <kw>character</kw>
            <kw>Set</kw>
        </keywords>
        <abstract>This document describes a new transformation format of Unicode that contains only 7-bit ASCII characters and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC2152</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1643</doc-id>
        <title>Definitions of Managed Objects for the Ethernet-like Interface Types</title>
        <author>
            <name>F. Kastenholz</name>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39008</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>ETHER-MIB</kw>
            <kw>MIB</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
            <kw>Ethernet</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1623</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3638</doc-id>
        </obsoleted-by>
        <is-also>
            <doc-id>STD0050</doc-id>
        </is-also>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1644</doc-id>
        <title>T/TCP -- TCP Extensions for Transactions Functional Specification</title>
        <author>
            <name>R. Braden</name>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>87362</char-count>
            <page-count>38</page-count>
        </format>
        <keywords>
            <kw>T/TCP</kw>
            <kw>Transmission</kw>
            <kw>Control</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This memo specifies T/TCP, an experimental TCP extension for efficient transaction-oriented (request/response) service. This memo describes an Experimental Protocol for the Internet community. </abstract>
        <updates>
            <doc-id>RFC1379</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1645</doc-id>
        <title>Simple Network Paging Protocol - Version 2</title>
        <author>
            <name>A. Gwinn</name>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31243</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>Beeper</kw>
            <kw>SNPP</kw>
            <kw>Mail</kw>
        </keywords>
        <abstract>This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1568</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1861</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1646</doc-id>
        <title>TN3270 Extensions for LUname and Printer Selection</title>
        <author>
            <name>C. Graves</name>
        </author>
        <author>
            <name>T. Butts</name>
        </author>
        <author>
            <name>M. Angel</name>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27564</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>Telnet</kw>
            <kw>Option</kw>
        </keywords>
        <abstract>This document describes protocol extensions to TN3270. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1647</doc-id>
        <title>TN3270 Enhancements</title>
        <author>
            <name>B. Kelly</name>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>84420</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>Telnet</kw>
            <kw>Option</kw>
        </keywords>
        <abstract>This document describes a protocol that more fully supports 3270 devices than do the existing tn3270 practices. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2355</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1648</doc-id>
        <title>Postmaster Convention for X.400 Operations</title>
        <author>
            <name>A. Cargille</name>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8761</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>Mail</kw>
        </keywords>
        <abstract>This paper extends this concept to X.400 mail domains which have registered RFC 1327 mapping rules, and which therefore appear to have normal RFC822-style addresses. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1649</doc-id>
        <title>Operational Requirements for X.400 Management Domains in the GO-MHS Community</title>
        <author>
            <name>R. Hagens</name>
        </author>
        <author>
            <name>A. Hansen</name>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28138</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>Mail</kw>
            <kw>Global</kw>
            <kw>Open</kw>
            <kw>Message</kw>
            <kw>Handling</kw>
            <kw>System</kw>
        </keywords>
        <abstract>The goal of this document is to unite regionally operated X.400 services on the various continents into one GO-MHS Community (as seen from an end-user's point of view). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1650</doc-id>
        <title>Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2</title>
        <author>
            <name>F. Kastenholz</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40484</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>802.3</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2358</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1651</doc-id>
        <title>SMTP Service Extensions</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>E. Stefferud</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22153</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>Mail</kw>
            <kw>Simple</kw>
            <kw>Transfer</kw>
        </keywords>
        <abstract>This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1425</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1869</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1652</doc-id>
        <title>SMTP Service Extension for 8bit-MIMEtransport</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>E. Stefferud</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11842</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>SMTP</kw>
            <kw>Mail</kw>
            <kw>Simple</kw>
            <kw>Transfer</kw>
        </keywords>
        <abstract>This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US- ASCII octet range (hex 00-7F) may be relayed using SMTP. [STANDARDS- TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1426</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1653</doc-id>
        <title>SMTP Service Extension for Message Size Declaration</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>K. Moore</name>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17883</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>Mail</kw>
            <kw>Simple</kw>
            <kw>Transfer</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1427</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1870</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1654</doc-id>
        <title>A Border Gateway Protocol 4 (BGP-4)</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>T. Li</name>
            <title>Editors</title>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>130118</char-count>
            <page-count>56</page-count>
        </format>
        <keywords>
            <kw>routing</kw>
        </keywords>
        <abstract>This document defines an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1771</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1655</doc-id>
        <title>Application of the Border Gateway Protocol in the Internet</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>P. Gross</name>
            <title>Editors</title>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43664</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>BGP-4</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract>This document, together with its companion document, "A Border Gateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1268</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1772</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1656</doc-id>
        <title>BGP-4 Protocol Document Roadmap and Implementation Experience</title>
        <author>
            <name>P. Traina</name>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7705</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>Border</kw>
            <kw>Gateway</kw>
            <kw>Protocol</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract>Border Gateway Protocol v4 (BGP-4) [1] is an inter-Autonomous System routing protocol. It is built on experience gained with BGP as defined in RFC-1267 [2] and BGP usage in the connected Internet as described in RFC-1268 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC1773</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1657</doc-id>
        <title>Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2</title>
        <author>
            <name>S. Willis</name>
        </author>
        <author>
            <name>J. Burruss</name>
        </author>
        <author>
            <name>J. Chu</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45505</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>BGP-4-MIB</kw>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower [1, 2]. [STANDARDS-TRACK] </abstract>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1658</doc-id>
        <title>Definitions of Managed Objects for Character Stream Devices using SMIv2</title>
        <author>
            <name>B. Stewart</name>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32579</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of character stream devices. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1316</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1659</doc-id>
        <title>Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2</title>
        <author>
            <name>B. Stewart</name>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36479</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of RS-232-like devices. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1317</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1660</doc-id>
        <title>Definitions of Managed Objects for Parallel-printer-like Hardware Devices using SMIv2</title>
        <author>
            <name>B. Stewart</name>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16784</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of Parallel-printer- like devices. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1318</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1661</doc-id>
        <title>The Point-to-Point Protocol (PPP)</title>
        <author>
            <name>W. Simpson</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>103026</char-count>
            <page-count>53</page-count>
        </format>
        <keywords>
            <kw>PPP</kw>
            <kw>Specification</kw>
            <kw>Standard</kw>
            <kw>link</kw>
            <kw>serial</kw>
            <kw>line</kw>
        </keywords>
        <abstract>This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1548</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC2153</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0051</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1662</doc-id>
        <title>PPP in HDLC-like Framing</title>
        <author>
            <name>W. Simpson</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48058</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>PPP-HDLC</kw>
            <kw>Point</kw>
            <kw>Protocol</kw>
            <kw>Specification</kw>
            <kw>Standard</kw>
            <kw>link</kw>
            <kw>serial</kw>
            <kw>line</kw>
        </keywords>
        <abstract>This document describes the use of HDLC-like framing for PPP encapsulated packets. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1549</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0051</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1663</doc-id>
        <title>PPP Reliable Transmission</title>
        <author>
            <name>D. Rand</name>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17281</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>PPP-TRANS</kw>
            <kw>Point</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document defines a method for negotiating and using Numbered-Mode, as defined by ISO 7776 [2], to provide a reliable serial link. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1664</doc-id>
        <title>Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables</title>
        <author>
            <name>C. Allocchio</name>
        </author>
        <author>
            <name>A. Bonito</name>
        </author>
        <author>
            <name>B. Cole</name>
        </author>
        <author>
            <name>S. Giordano</name>
        </author>
        <author>
            <name>R. Hagens</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>50783</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
            <kw>X.400</kw>
            <kw>Email</kw>
        </keywords>
        <abstract>This memo defines how to store in the Internet Domain Name System the mapping information needed by e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC2163</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1665</doc-id>
        <title>Definitions of Managed Objects for SNA NAUs using SMIv2</title>
        <author>
            <name>Z. Kielczewski</name>
        </author>
        <author>
            <name>D. Kostick</name>
        </author>
        <author>
            <name>K. Shih</name>
            <title>Editors</title>
        </author>
        <date>
            <month>July</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>133381</char-count>
            <page-count>67</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>System</kw>
            <kw>Network</kw>
            <kw>Architecture</kw>
            <kw>Addressable</kw>
            <kw>Units</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1666</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1666</doc-id>
        <title>Definitions of Managed Objects for SNA NAUs using SMIv2</title>
        <author>
            <name>Z. Kielczewski</name>
        </author>
        <author>
            <name>D. Kostick</name>
        </author>
        <author>
            <name>K. Shih</name>
            <title>Editors</title>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>134385</char-count>
            <page-count>68</page-count>
        </format>
        <keywords>
            <kw>SNANAU-MIB</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
            <kw>MIB</kw>
            <kw>Protocol</kw>
            <kw>Units</kw>
            <kw>Architecture</kw>
            <kw>Addressable</kw>
            <kw>Information</kw>
            <kw>System</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1665</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1667</doc-id>
        <title>Modeling and Simulation Requirements for IPng</title>
        <author>
            <name>S. Symington</name>
        </author>
        <author>
            <name>D. Wood</name>
        </author>
        <author>
            <name>M. Pullen</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17291</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract>This white paper summarizes the Distributed Interactive Simulation environment that is under development, with regard to its real-time nature, scope and magnitude of networking requirements. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1668</doc-id>
        <title>Unified Routing Requirements for IPng</title>
        <author>
            <name>D. Estrin</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5106</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract>The document provides requirements on the IPng from the perspective of the Unified Routing Architecture, as described in RFC 1322. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1669</doc-id>
        <title>Market Viability as a IPng Criteria</title>
        <author>
            <name>J. Curran</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8099</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract>"Viability in the Marketplace" is an important requirement for any IPng candidate and this paper is an attempt to summarize some important factors in determing market viability of IPng proposals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1670</doc-id>
        <title>Input to IPng Engineering Considerations</title>
        <author>
            <name>D. Heagerty</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5350</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract>This white paper expresses some personal opinions on IPng engineering considerations, based on experience with DECnet Phase V transition. It suggests breaking down the IPng decisions and transition tasks into smaller parts so they can be tackled early by the relevant experts. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1671</doc-id>
        <title>IPng White Paper on Transition and Other Considerations</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17631</char-count>
            <page-count>8</page-count>
        </format>
        <abstract>This white paper outlines some general requirements for IPng in selected areas. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1672</doc-id>
        <title>Accounting Requirements for IPng</title>
        <author>
            <name>N. Brownlee</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6185</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract>This white paper discusses accounting requirements for IPng. It recommends that all IPng packets carry accounting tags, which would vary in size. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1673</doc-id>
        <title>Electric Power Research Institute Comments on IPng</title>
        <author>
            <name>R. Skelton</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7476</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract>This document was submitted to the IETF IPng area in response to RFC 1550. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1674</doc-id>
        <title>A Cellular Industry View of IPng</title>
        <author>
            <name>M. Taylor</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6157</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract>This is a draft of the requirements for IPng as envisioned by representatives of the Cellular Digital Packet Data (CDPD) consortium of service providers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1675</doc-id>
        <title>Security Concerns for IPng</title>
        <author>
            <name>S. Bellovin</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8290</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract>A number of the candidates for IPng have some features that are somewhat worrisome from a security perspective. While it is not necessary that IPng be an improvement over IPv4, it is mandatory that it not make things worse. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1676</doc-id>
        <title>INFN Requirements for an IPng</title>
        <author>
            <name>A. Ghiselli</name>
        </author>
        <author>
            <name>D. Salomoni</name>
        </author>
        <author>
            <name>C. Vistoli</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8493</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract>With this paper we would like to emphasize the key points that we would to consider if charged with IPng plan. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1677</doc-id>
        <title>Tactical Radio Frequency Communication Requirements for IPng</title>
        <author>
            <name>B. Adamson</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24065</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract>This paper describes requirements for Internet Protocol next generation (IPng) candidates with respect to their application to military tactical radio frequency (RF) communication networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1678</doc-id>
        <title>IPng Requirements of Large Corporate Networks</title>
        <author>
            <name>E. Britton</name>
        </author>
        <author>
            <name>J. Tavs</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18650</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract>This draft summarizes some of the requirements of large corporate networks for the next generation of the Internet protcol suite. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1679</doc-id>
        <title>HPN Working Group Input to the IPng Requirements Solicitation</title>
        <author>
            <name>D. Green</name>
        </author>
        <author>
            <name>P. Irey</name>
        </author>
        <author>
            <name>D. Marlow</name>
        </author>
        <author>
            <name>K. O'Donoghue</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22974</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract>The purpose of this document is to provide what the HPN working group perceives as requirements for an IPng protocol set. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1680</doc-id>
        <title>IPng Support for ATM Services</title>
        <author>
            <name>C. Brazdziunas</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17846</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract>This white paper describes engineering considerations for IPng as solicited by RFC 1550 [1]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1681</doc-id>
        <title>On Many Addresses per Host</title>
        <author>
            <name>S. Bellovin</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11964</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract>This document was submitted to the IETF IPng area in response to RFC 1550.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1682</doc-id>
        <title>IPng BSD Host Implementation Analysis</title>
        <author>
            <name>J. Bound</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22295</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
            <kw>Unix</kw>
        </keywords>
        <abstract>This IPng white paper, IPng BSD Host Implementation Analysis, was submitted to the IPng Directorate to provide a BSD host point of reference to assist with the engineering considerations during the IETF process to select an IPng proposal. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1683</doc-id>
        <title>Multiprotocol Interoperability In IPng</title>
        <author>
            <name>R. Clark</name>
        </author>
        <author>
            <name>M. Ammar</name>
        </author>
        <author>
            <name>K. Calvert</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28201</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract>In this document, we identify several features that affect a protocol's ability to operate in a multiprotocol environment and propose the incorporation of these features into IPng. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1684</doc-id>
        <title>Introduction to White Pages Services based on X.500</title>
        <author>
            <name>P. Jurg</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22985</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>Directory</kw>
        </keywords>
        <abstract>The document provides an introduction to the international ITU-T (formerly CCITT) X.500 and ISO 9594 standard, which is particularly suited for providing an integrated local and global electronic White Pages Service. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1685</doc-id>
        <title>Writing X.400 O/R Names</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21242</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>EMail</kw>
            <kw>Mail</kw>
        </keywords>
        <abstract>There is a need for human beings who use X.400 systems to be able to write down O/R names in a uniform way. This memo is a discussion of this topic. This memo provides information for the Internet Community. It does not specify an Internet Standard of any kind. </abstract>
        <see-also>
            <doc-id>RTR0012</doc-id>
        </see-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1686</doc-id>
        <title>IPng Requirements: A Cable Television Industry Viewpoint</title>
        <author>
            <name>M. Vecchi</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39052</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract>This paper provides comments on topics related to the IPng requirements and selection criteria from a cable television industry viewpoint. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1687</doc-id>
        <title>A Large Corporate User's View of IPng</title>
        <author>
            <name>E. Fleischman</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34120</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract>The goal of this paper is to examine the implications of IPng from the point of view of Fortune 100 corporations which have heavily invested in TCP/IP technology in order to achieve their (non-computer related) business goals.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1688</doc-id>
        <title>IPng Mobility Considerations</title>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19151</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract>This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1689</doc-id>
        <title>A Status Report on Networked Information Retrieval: Tools and Groups</title>
        <author>
            <name>J. Foster</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>375469</char-count>
            <page-count>226</page-count>
        </format>
        <keywords>
            <kw>NIR</kw>
        </keywords>
        <abstract>The purpose of this report is to increase the awareness of Networked Information Retrieval by bringing together in one place information about the various networked information retrieval tools, their developers, interested organisations, and other activities that relate to the production, dissemination, and support of NIR tools. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <notes>See also RTR0013</notes>
        <is-also>
            <doc-id>FYI0025</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1690</doc-id>
        <title>Introducing the Internet Engineering and Planning Group (IEPG)</title>
        <author>
            <name>G. Huston</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3013</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>charter</kw>
        </keywords>
        <abstract>This memo introduces the IEPG to the Internet Community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1691</doc-id>
        <title>The Document Architecture for the Cornell Digital Library</title>
        <author>
            <name>W. Turner</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20438</char-count>
            <page-count>10</page-count>
        </format>
        <abstract>This memo defines an architecture for the storage and retrieval of the digital representations for books, journals, photographic images, etc., which are collected in a large organized digital library. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1692</doc-id>
        <title>Transport Multiplexing Protocol (TMux)</title>
        <author>
            <name>P. Cameron</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <author>
            <name>D. Cohen</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26163</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>TMUX</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>IP</kw>
        </keywords>
        <abstract>This RFC documents the extended TACACS protocol use by the Cisco Systems terminal servers. This same protocol is used by the University of Minnesota's distributed authentication system. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1693</doc-id>
        <title>An Extension to TCP : Partial Order Service</title>
        <author>
            <name>T.  Connolly</name>
        </author>
        <author>
            <name>P. Amer</name>
        </author>
        <author>
            <name>P. Conrad</name>
        </author>
        <date>
            <month>November</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>90100</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>TCP-POS</kw>
            <kw>Transmission</kw>
            <kw>Control</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This RFC introduces a new transport mechanism for TCP based upon partial ordering. The aim is to present the concepts of partial ordering and promote discussions on its usefulness in network communications. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1694</doc-id>
        <title>Definitions of Managed Objects for SMDS Interfaces using SMIv2</title>
        <author>
            <name>T. Brown</name>
        </author>
        <author>
            <name>K. Tesink</name>
            <title>Editors</title>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>70856</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
            <kw>SIP-MIB</kw>
            <kw>Standard,MIB,Network,Management,Switched,Multimegabit,Data,Service,Informatiom,Base,SMDS</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing objects for SMDS access interfaces. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1304</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1695</doc-id>
        <title>Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2</title>
        <author>
            <name>M. Ahmed</name>
        </author>
        <author>
            <name>K. Tesink</name>
            <title>Editors</title>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>175461</char-count>
            <page-count>73</page-count>
        </format>
        <keywords>
            <kw>ATM-MIB</kw>
            <kw>MIB</kw>
            <kw>Management,Information,Base,Asychronous,Transmission,Mode</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2515</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1696</doc-id>
        <title>Modem Management Information Base (MIB) using SMIv2</title>
        <author>
            <name>J. Barnes</name>
        </author>
        <author>
            <name>L. Brown</name>
        </author>
        <author>
            <name>R. Royston</name>
        </author>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54054</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>MODEM-MIB</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing dial-up modems and similar dial-up devices. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1697</doc-id>
        <title>Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2</title>
        <author>
            <name>D. Brower</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Purvy</name>
        </author>
        <author>
            <name>A. Daniel</name>
        </author>
        <author>
            <name>M. Sinykin</name>
        </author>
        <author>
            <name>J. Smith</name>
        </author>
        <date>
            <month>August</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>76202</char-count>
            <page-count>38</page-count>
        </format>
        <keywords>
            <kw>RDBMS-MIB</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing relational database (RDBMS) implementations. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1698</doc-id>
        <title>Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications</title>
        <author>
            <name>P. Furniss</name>
        </author>
        <date>
            <month>October</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>67433</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>Protocol</kw>
            <kw>Headers</kw>
        </keywords>
        <abstract>This document states particular octet sequences that comprise the OSI upper-layer protocols (Session, Presentation and ACSE) when used to support applications with "basic communications requirements". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1699</doc-id>
        <title>Summary of 1600-1699</title>
        <author>
            <name>J. Elliott</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40674</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>Index</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1700</doc-id>
        <title>Assigned Numbers</title>
        <author>
            <name>J. Reynolds</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>October</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>458860</char-count>
            <page-count>230</page-count>
        </format>
        <keywords>
            <kw>status</kw>
            <kw>procedure</kw>
            <kw>index</kw>
            <kw>parameters</kw>
            <kw>registered</kw>
            <kw>allocated</kw>
        </keywords>
        <abstract>This RFC is a snapshot of the ongoing process of the assignment of protocol parameters for the Internet protocol suite. To make the current information readily available the assignments are kept up-to- date in a set of online text files. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community. </abstract>
        <obsoletes>
            <doc-id>RFC1340</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3232</doc-id>
        </obsoleted-by>
        <is-also>
            <doc-id>STD0002</doc-id>
        </is-also>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1701</doc-id>
        <title>Generic Routing Encapsulation (GRE)</title>
        <author>
            <name>S. Hanks</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>P. Traina</name>
        </author>
        <date>
            <month>October</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15460</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>GRE</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>IP</kw>
        </keywords>
        <abstract>This document specifies a protocol for performing encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1702</doc-id>
        <title>Generic Routing Encapsulation over IPv4 networks</title>
        <author>
            <name>S. Hanks</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>P. Traina</name>
        </author>
        <date>
            <month>October</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7288</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>GRE-IPv4</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>IP</kw>
        </keywords>
        <abstract>This memo addresses the case of using IP as the delivery protocol or the payload protocol and the special case of IP as both the delivery and payload. This memo also describes using IP addresses and autonomous system numbers as part of a GRE source route. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1703</doc-id>
        <title>Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures</title>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>October</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17985</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>RADIO-PAGE</kw>
            <kw>Beepers</kw>
        </keywords>
        <abstract>This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1569</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1704</doc-id>
        <title>On Internet Authentication</title>
        <author>
            <name>N. Haller</name>
        </author>
        <author>
            <name>R. Atkinson</name>
        </author>
        <date>
            <month>October</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42269</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>Security</kw>
            <kw>Energyption</kw>
            <kw>Policy</kw>
            <kw>Guidelines</kw>
        </keywords>
        <abstract>This document describes a spectrum of authentication technologies and provides suggestions to protocol developers on what kinds of authentication might be suitable for some kinds of protocols and applications used in the Internet. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1705</doc-id>
        <title>Six Virtual Inches to the Left: The Problem with IPng</title>
        <author>
            <name>R. Carlson</name>
        </author>
        <author>
            <name>D. Ficarella</name>
        </author>
        <date>
            <month>October</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>65222</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>IPng</kw>
            <kw>White paper</kw>
        </keywords>
        <abstract>This document was submitted to the IETF IPng area in response to RFC 1550. This RFC suggests that a new version of TCP (TCPng), and UDP, be developed and deployed. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1706</doc-id>
        <title>DNS NSAP Resource Records</title>
        <author>
            <name>B. Manning</name>
        </author>
        <author>
            <name>R. Colella</name>
        </author>
        <date>
            <month>October</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19721</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>DNS-NSAP</kw>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
            <kw>ISO</kw>
            <kw>OSI</kw>
            <kw>Address</kw>
            <kw>RR</kw>
            <kw>Record</kw>
            <kw>Resource</kw>
        </keywords>
        <abstract>This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. The RR may be used with any NSAP address format. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1637</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1707</doc-id>
        <title>CATNIP: Common Architecture for the Internet</title>
        <author>
            <name>M. McGovern</name>
        </author>
        <author>
            <name>R. Ullmann</name>
        </author>
        <date>
            <month>October</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37568</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>IPng</kw>
            <kw>White</kw>
            <kw>Paper</kw>
            <kw>IPv7</kw>
        </keywords>
        <abstract>This document was submitted to the IETF IPng area in response to RFC 1550. This paper describes a common architecture for the network layer protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1708</doc-id>
        <title>NTP PICS PROFORMA - For the Network Time Protocol Version 3</title>
        <author>
            <name>D. Gowin</name>
        </author>
        <date>
            <month>October</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26523</char-count>
            <page-count>13</page-count>
        </format>
        <abstract>This RFC describes a PICS Proforma translated into an Internet acceptable form. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1709</doc-id>
        <title>K-12 Internetworking Guidelines</title>
        <author>
            <name>J. Gargano</name>
        </author>
        <author>
            <name>D. Wasley</name>
        </author>
        <date>
            <month>November</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>66659</char-count>
            <page-count>26</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>662030</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>134065</char-count>
        </format>
        <keywords>
            <kw>school</kw>
            <kw>network</kw>
            <kw>education</kw>
            <kw>connection</kw>
        </keywords>
        <abstract>The K-12 community traditionally has not had this level of staffing available for telecommunications planning. This document is intended to bridge that gap and provides a recommended technical direction, an introduction to the role the Internet now plays in K-12 education and technical guidelines for building a campus data communications infrastructure that provides internetworking services and connections to the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <is-also>
            <doc-id>FYI0026</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1710</doc-id>
        <title>Simple Internet Protocol Plus White Paper</title>
        <author>
            <name>R. Hinden</name>
        </author>
        <date>
            <month>October</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>56910</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>SIPP</kw>
            <kw>IPng</kw>
        </keywords>
        <abstract>This document was submitted to the IETF IPng area in response to RFC 1550. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1711</doc-id>
        <title>Classifications in E-mail Routing</title>
        <author>
            <name>J. Houttuin</name>
        </author>
        <date>
            <month>October</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47584</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>Email</kw>
            <kw>Electronic</kw>
            <kw>Mail</kw>
        </keywords>
        <abstract>This paper presents a classification for e-mail routing issues. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1712</doc-id>
        <title>DNS Encoding of Geographical Location</title>
        <author>
            <name>C. Farrell</name>
        </author>
        <author>
            <name>M. Schulze</name>
        </author>
        <author>
            <name>S. Pleitner</name>
        </author>
        <author>
            <name>D. Baldoni</name>
        </author>
        <date>
            <month>November</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13237</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>DNS-ENCODE</kw>
            <kw>Domain</kw>
            <kw>Names</kw>
            <kw>System</kw>
            <kw>GPOS</kw>
        </keywords>
        <abstract>This document defines the format of a new Resource Record (RR) for the Domain Naming System (DNS), and reserves a corresponding DNS type mnemonic and numerical code. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1713</doc-id>
        <title>Tools for DNS debugging</title>
        <author>
            <name>A. Romao</name>
        </author>
        <date>
            <month>November</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33500</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>Domain</kw>
            <kw>Names</kw>
            <kw>System</kw>
            <kw>Host</kw>
            <kw>DNSWalk</kw>
            <kw>DOC</kw>
            <kw>DDT</kw>
            <kw>Checker</kw>
        </keywords>
        <abstract>Although widely used (and most of the times unnoticed), DNS (Domain Name System) is too much overlooked, in the sense that people, especially administrators, tend to ignore possible anomalies as long as applications that need name-to-address mapping continue to work. This document presents some tools available for domain administrators to detect and correct those anomalies. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <is-also>
            <doc-id>FYI0027</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1714</doc-id>
        <title>Referral Whois Protocol (RWhois)</title>
        <author>
            <name>S. Williamson</name>
        </author>
        <author>
            <name>M. Kosters</name>
        </author>
        <date>
            <month>November</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>85395</char-count>
            <page-count>46</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>204207</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>85556</char-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Pages</kw>
            <kw>Directory</kw>
        </keywords>
        <abstract>This memo describes version 1.0 of the client/server interaction of RWhois. RWhois provides a distributed system for the display of hierarchical information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC2167</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1715</doc-id>
        <title>The H Ratio for Address Assignment Efficiency</title>
        <author>
            <name>C. Huitema</name>
        </author>
        <date>
            <month>November</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7392</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>IPng</kw>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract>This document was submitted to the IETF IPng area in response to RFC 1550. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <updated-by>
            <doc-id>RFC3194</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1716</doc-id>
        <title>Towards Requirements for IP Routers</title>
        <author>
            <name>P. Almquist</name>
        </author>
        <author>
            <name>F. Kastenholz</name>
        </author>
        <date>
            <month>November</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>432330</char-count>
            <page-count>192</page-count>
        </format>
        <keywords>
            <kw>Gateway</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>The goal of this work is to replace RFC-1009, Requirements for Internet Gateways ([INTRO:1]) with a new document. It defines and discusses requirements for devices which perform the network layer forwarding function of the Internet protocol suite. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC1812</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1717</doc-id>
        <title>The PPP Multilink Protocol (MP)</title>
        <author>
            <name>K. Sklower</name>
        </author>
        <author>
            <name>B. Lloyd</name>
        </author>
        <author>
            <name>G. McGregor</name>
        </author>
        <author>
            <name>D. Carr</name>
        </author>
        <date>
            <month>November</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46264</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>Point</kw>
        </keywords>
        <abstract>This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC1990</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1718</doc-id>
        <title>The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force</title>
        <author>
            <name>IETF Secretariat</name>
        </author>
        <author>
            <name>G. Malkin</name>
        </author>
        <date>
            <month>November</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>50458</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Engineering</kw>
            <kw>Task</kw>
            <kw>Force</kw>
            <kw>Meeting</kw>
        </keywords>
        <abstract>The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 17] </abstract>
        <obsoletes>
            <doc-id>RFC1539</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3160</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1719</doc-id>
        <title>A Direction for IPng</title>
        <author>
            <name>P. Gross</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11118</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>IPng</kw>
            <kw>White</kw>
            <kw>Paper</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1720</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>89063</char-count>
            <page-count>41</page-count>
        </format>
        <keywords>
            <kw>status</kw>
            <kw>procedure</kw>
            <kw>index</kw>
        </keywords>
        <abstract>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1610</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1780</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1721</doc-id>
        <title>RIP Version 2 Protocol Analysis</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <date>
            <month>November</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6680</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>RIP-2</kw>
        </keywords>
        <abstract>As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience. This report is a prerequisite to advancing RIP-2 on the standards track. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1387</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1722</doc-id>
        <title>RIP Version 2 Protocol Applicability Statement</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <date>
            <month>November</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10236</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>RIP2-APP</kw>
            <kw>RIP-2</kw>
        </keywords>
        <abstract>As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIP-2 protocol within the Internet. This report is a prerequisite to advancing RIP-2 on the standards track. [STANDARDS-TRACK] </abstract>
        <is-also>
            <doc-id>STD0057</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1723</doc-id>
        <title>RIP Version 2 - Carrying Additional Information</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <date>
            <month>November</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18597</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>RIP-2</kw>
        </keywords>
        <abstract>This document specifies an extension of the Routing Information Protocol (RIP), o expand the amount of useful information carried in RIP messages and to add a measure of security. This memo obsoletes RFC 1388, which specifies an update to the "Routing Information Protocol" STD 34, RFC 1058. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1388</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2453</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1058</doc-id>
        </updates>
        <is-also>
            <doc-id>STD0056</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1724</doc-id>
        <title>RIP Version 2 MIB Extension</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <date>
            <month>November</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29645</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>RIP2-MIB</kw>
            <kw>RIP-2</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing RIP Version 2. [STANDARDS- TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1389</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1725</doc-id>
        <title>Post Office Protocol - Version 3</title>
        <author>
            <name>J. Myers</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>November</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35058</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>POP</kw>
            <kw>Email</kw>
            <kw>Electronic</kw>
            <kw>Mail</kw>
        </keywords>
        <abstract>This memo is a revision to RFC 1460, a Draft Standard. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1460</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1939</doc-id>
        </obsoleted-by>
        <is-also>
            <doc-id>STD0053</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1726</doc-id>
        <title>Technical Criteria for Choosing IP The Next Generation (IPng)</title>
        <author>
            <name>C. Partridge</name>
        </author>
        <author>
            <name>F. Kastenholz</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>74109</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>IPng</kw>
            <kw>White</kw>
            <kw>Paper</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1727</doc-id>
        <title>A Vision of an Integrated Internet Information Service</title>
        <author>
            <name>C. Weider</name>
        </author>
        <author>
            <name>P. Deutsch</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28468</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>Universal</kw>
            <kw>Resource</kw>
            <kw>Names</kw>
        </keywords>
        <abstract>This paper lays out a vision of how Internet information services might be integrated over the next few years, and discusses in some detail what steps will be needed to achieve this integration. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1728</doc-id>
        <title>Resource Transponders</title>
        <author>
            <name>C. Weider</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12092</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>Universal</kw>
            <kw>Resource</kw>
            <kw>Names</kw>
            <kw>Location</kw>
            <kw>System</kw>
        </keywords>
        <abstract>This paper describes an automatic mechanism, the resource transponder, for maintaining resource location information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1729</doc-id>
        <title>Using the Z39.50 Information Retrieval Protocol</title>
        <author>
            <name>C. Lynch</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20927</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>Basic</kw>
            <kw>Endcoding</kw>
            <kw>Rules</kw>
            <kw>ASN1</kw>
        </keywords>
        <abstract>This memo describes an approach to the implementation of the ANSI/NISO Z39.50-1992 Standard for Information Retrieval in the TCP/IP environment which is currently in wide use by the Z39.50 implementor community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1730</doc-id>
        <title>Internet Message Access Protocol - Version 4</title>
        <author>
            <name>M. Crispin</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>156660</char-count>
            <page-count>77</page-count>
        </format>
        <keywords>
            <kw>IMAP</kw>
            <kw>IMAP4</kw>
            <kw>EMail</kw>
        </keywords>
        <abstract>The Internet Message Access Protocol, Version 4 (IMAP4) allows a client to access and manipulate electronic mail messages on a server. IMAP4 permits manipulation of remote message folders, called "mailboxes", in a way that is functionally equivalent to local mailboxes. IMAP4 also provides the capability for an offline client to resynchronize with the server. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2060</doc-id>
            <doc-id>RFC2061</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1731</doc-id>
        <title>IMAP4 Authentication Mechanisms</title>
        <author>
            <name>J. Myers</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11433</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>IMAP4-AUTH</kw>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
            <kw>Email</kw>
        </keywords>
        <abstract>The Internet Message Access Protocol, Version 4 [IMAP4] contains the AUTHENTICATE command, for identifying and authenticating a user to an IMAP4 server and for optionally negotiating a protection mechanism for subsequent protocol interactions. This document describes several authentication mechanisms for use by the IMAP4 AUTHENTICATE command. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1732</doc-id>
        <title>IMAP4 Compatibility with IMAP2 and IMAP2bis</title>
        <author>
            <name>M. Crispin</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9276</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
            <kw>Email</kw>
        </keywords>
        <abstract>This is a summary of hints and recommendations to enable an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1733</doc-id>
        <title>Distributed Electronic Mail Models in IMAP4</title>
        <author>
            <name>M. Crispin</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6205</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
            <kw>Email</kw>
        </keywords>
        <abstract>There are three fundamental models of client/server email: offline, online, and disconnected use. IMAP4 can be used in any one of these three models. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1734</doc-id>
        <title>POP3 AUTHentication command</title>
        <author>
            <name>J. Myers</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8499</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>POP3-AUTH</kw>
            <kw>Post</kw>
            <kw>Office</kw>
            <kw>Protocol</kw>
            <kw>Email</kw>
        </keywords>
        <abstract>This document describes the optional AUTH command, for indicating an authentication mechanism to the server, performing an authentication protocol exchange, and optionally negotiating a protection mechanism for subsequent protocol interactions. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1735</doc-id>
        <title>NBMA Address Resolution Protocol (NARP)</title>
        <author>
            <name>J. Heinanen</name>
        </author>
        <author>
            <name>R. Govindan</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24485</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>NARP</kw>
            <kw>Non-Broadcast</kw>
            <kw>Multi</kw>
            <kw>Access</kw>
            <kw>Address</kw>
            <kw>Resolution</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document describes the NBMA Address Resolution Protocol (NARP). NARP can be used by a source terminal (host or router) connected to a Non-Broadcast, Multi-Access link layer (NBMA) network to find out the NBMA addresses of the a destination terminal provided that the destination terminal is connected to the same NBMA network. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1736</doc-id>
        <title>Functional Recommendations for Internet Resource Locators</title>
        <author>
            <name>J. Kunze</name>
        </author>
        <date>
            <month>February</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22415</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>Uniform</kw>
            <kw>Resource</kw>
            <kw>URL</kw>
        </keywords>
        <abstract>This document specifies a minimum set of requirements for Internet resource locators, which convey location and access information for resources. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1737</doc-id>
        <title>Functional Requirements for Uniform Resource Names</title>
        <author>
            <name>K. Sollins</name>
        </author>
        <author>
            <name>L. Masinter</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16337</char-count>
            <page-count>7</page-count>
        </format>
        <abstract>This document specifies a minimum set of requirements for a kind of Internet resource identifier known as Uniform Resource Names (URNs). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1738</doc-id>
        <title>Uniform Resource Locators (URL)</title>
        <author>
            <name>T. Berners-Lee</name>
        </author>
        <author>
            <name>L. Masinter</name>
        </author>
        <author>
            <name>M. McCahill</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51348</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>URL</kw>
        </keywords>
        <abstract>This document specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and access of resources via the Internet. [STANDARDS-TRACK] </abstract>
        <updated-by>
            <doc-id>RFC1808</doc-id>
            <doc-id>RFC2368</doc-id>
            <doc-id>RFC2396</doc-id>
            <doc-id>RFC3986</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1739</doc-id>
        <title>A Primer On Internet and TCP/IP Tools</title>
        <author>
            <name>G. Kessler</name>
        </author>
        <author>
            <name>S. Shepard</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>102676</char-count>
            <page-count>46</page-count>
        </format>
        <keywords>
            <kw>NSlookup</kw>
            <kw>PING</kw>
            <kw>FINGER</kw>
            <kw>TRACEROUTE</kw>
            <kw>FTP</kw>
            <kw>TELNET</kw>
            <kw>WHOIS</kw>
            <kw>NICNAME</kw>
            <kw>KNOWBOT</kw>
            <kw>NETFIND</kw>
            <kw>ARCHIE</kw>
            <kw>Gopher</kw>
            <kw>Email</kw>
            <kw>Mailing</kw>
            <kw>Lists</kw>
            <kw>USENET</kw>
        </keywords>
        <abstract>This memo is an introductory guide to some of the TCP/IP and Internet tools and utilities that allow users to access the wide variety of information on the network, from determining if a particular host is up to viewing a multimedia thesis on foreign policy. It also describes discussion lists accessible from the Internet, ways to obtain Internet documents, and resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC2151</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1740</doc-id>
        <title>MIME Encapsulation of Macintosh Files - MacMIME</title>
        <author>
            <name>P. Faltstrom</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <author>
            <name>E. Fair</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31297</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>MacMIME</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract>This memo describes the format to use when sending Apple Macintosh files via MIME [BORE93]. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1741</doc-id>
        <title>MIME Content Type for BinHex Encoded Files</title>
        <author>
            <name>P. Faltstrom</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <author>
            <name>E. Fair</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10155</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>BINHEX</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract>This memo describes the format to use when sending BinHex4.0 files via MIME [BORE93]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1742</doc-id>
        <title>AppleTalk Management Information Base II</title>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <author>
            <name>K. Frisa</name>
        </author>
        <date>
            <month>January</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>168306</char-count>
            <page-count>84</page-count>
        </format>
        <keywords>
            <kw>AT-MIB</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing AppleTalk networks. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1243</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1743</doc-id>
        <title>IEEE 802.5 MIB using SMIv2</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>E. Decker</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43224</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>SNMP,</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1231</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1748</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1744</doc-id>
        <title>Observations on the Management of the Internet Address Space</title>
        <author>
            <name>G. Huston</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32411</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>IP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This memo examines some of the issues associated with the current management practices of the Internet IPv4 address space, and examines the potential outcomes of these practices as the unallocated address pool shrinks in size. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1745</doc-id>
        <title>BGP4/IDRP for IP---OSPF Interaction</title>
        <author>
            <name>K. Varadhan</name>
        </author>
        <author>
            <name>S. Hares</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43675</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>BGP4/IDRP</kw>
            <kw>Internet</kw>
            <kw>Inter-Domain</kw>
            <kw>Routing</kw>
            <kw>Protocol</kw>
            <kw>Border</kw>
            <kw>Gateway</kw>
            <kw>Open</kw>
            <kw>Shortest</kw>
            <kw>Path</kw>
            <kw>First</kw>
        </keywords>
        <abstract>This memo defines the various criteria to be used when designing an Autonomous System Border Router (ASBR) that will run either BGP4 or IDRP for IP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK] </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1746</doc-id>
        <title>Ways to Define User Expectations</title>
        <author>
            <name>B. Manning</name>
        </author>
        <author>
            <name>D. Perkins</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46164</char-count>
            <page-count>18</page-count>
        </format>
        <abstract>This paper covers basic fundamentals that must be understood when one defines, interprets, or implements methods to control user expectations on or over the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1747</doc-id>
        <title>Definitions of Managed Objects for SNA Data Link Control (SDLC) using SMIv2</title>
        <author>
            <name>J. Hilgeman</name>
            <title>Chair</title>
        </author>
        <author>
            <name>S. Nix</name>
        </author>
        <author>
            <name>A. Bartky</name>
        </author>
        <author>
            <name>W. Clark</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>147388</char-count>
            <page-count>67</page-count>
        </format>
        <keywords>
            <kw>SDLCSMIv2</kw>
        </keywords>
        <abstract>This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for managing the configuration, monitoring and control of data link controls in an SNA environment. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1748</doc-id>
        <title>IEEE 802.5 MIB using SMIv2 </title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>E. Decker</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43224</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>802.5-MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1743</doc-id>
            <doc-id>RFC1231</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC1749</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1749</doc-id>
        <title>IEEE 802.5 Station Source Routing MIB using SMIv2</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>E. Decker</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17563</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>802.5-SSR</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used by IEEE 802.5 end-stations for managing source routes on a Token Ring network where IEEE source- routing is in use. [STANDARDS-TRACK] </abstract>
        <updates>
            <doc-id>RFC1748</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1750</doc-id>
        <title>Randomness Recommendations for Security</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>S. Crocker</name>
        </author>
        <author>
            <name>J. Schiller</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>73842</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>Random</kw>
            <kw>Numbers</kw>
            <kw>Seed</kw>
        </keywords>
        <abstract>Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This paper points out many pitfalls in using traditional pseudo-random number generation techniques for choosing such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1751</doc-id>
        <title>A Convention for Human-Readable 128-bit Keys</title>
        <author>
            <name>D. McDonald</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31428</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>Security</kw>
            <kw>Password</kw>
        </keywords>
        <abstract>This memo proposes a convention for use with Internet applications &amp; protocols using 128-bit cryptographic keys. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1752</doc-id>
        <title>The Recommendation for the IP Next Generation Protocol</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <author>
            <name>A. Mankin</name>
        </author>
        <date>
            <month>January</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>127784</char-count>
            <page-count>52</page-count>
        </format>
        <keywords>
            <kw>IPNG</kw>
            <kw>IPng</kw>
            <kw>Internet</kw>
        </keywords>
        <abstract>This document presents the recommendation of the IPng Area Directors on what should be used to replace the current version of the Internet Protocol. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1753</doc-id>
        <title>IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture</title>
        <author>
            <name>N. Chiappa</name>
        </author>
        <date>
            <month>December</month>
            <year>1994</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46586</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>IPng</kw>
            <kw>White</kw>
            <kw>Paper</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document presents the requirements that the Nimrod routing and addressing architecture has upon the internetwork layer protocol. To be most useful to Nimrod, any protocol selected as the IPng should satisfy these requirements. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1754</doc-id>
        <title>IP over ATM Working Group's Recommendations for the ATM Forum's Multiprotocol BOF Version 1</title>
        <author>
            <name>M. Laubach</name>
        </author>
        <date>
            <month>January</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13483</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Asynchromous</kw>
            <kw>Transfer</kw>
            <kw>Mode</kw>
        </keywords>
        <abstract>This document represents an initial list of requirements submitted to the ATM Forum's Multiprotocol BOF for the operation of IP over ATM networks as determined by the IETF IP over ATM Working Group and other working groups. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1755</doc-id>
        <title>ATM Signaling Support for IP over ATM</title>
        <author>
            <name>M. Perez</name>
        </author>
        <author>
            <name>F. Liaw</name>
        </author>
        <author>
            <name>A. Mankin</name>
        </author>
        <author>
            <name>E. Hoffman</name>
        </author>
        <author>
            <name>D. Grossman</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <date>
            <month>February</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>55209</char-count>
            <page-count>32</page-count>
        </format>
        <keywords>
            <kw>ATM</kw>
            <kw>Asynchronous</kw>
            <kw>Transfer</kw>
            <kw>Mode</kw>
        </keywords>
        <abstract>This memo describes the ATM call control signaling exchanges needed to support Classical IP over ATM implementations as described in RFC 1577. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1756</doc-id>
        <title>Remote Write Protocol - Version 1.0</title>
        <author>
            <name>T. Rinne</name>
        </author>
        <date>
            <month>January</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22078</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>RWP</kw>
            <kw>Application</kw>
        </keywords>
        <abstract>This document describes a simple Remote Write Protocol (RWP). This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1757</doc-id>
        <title>Remote Network Monitoring Management Information Base</title>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>February</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>208117</char-count>
            <page-count>91</page-count>
        </format>
        <keywords>
            <kw>RMON-MIB</kw>
            <kw>MIB</kw>
            <kw>RMON</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1271</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2819</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1758</doc-id>
        <title>NADF Standing Documents: A Brief Overview</title>
        <author>
            <name>The North American Directory Forum</name>
        </author>
        <date>
            <month>February</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7294</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>X.500</kw>
            <kw>North</kw>
            <kw>American</kw>
            <kw>Directory</kw>
            <kw>Forum</kw>
            <kw>Public</kw>
            <kw>CCITT</kw>
            <kw>Providers</kw>
        </keywords>
        <abstract>The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1417</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1759</doc-id>
        <title>Printer MIB</title>
        <author>
            <name>R. Smith</name>
        </author>
        <author>
            <name>F. Wright</name>
        </author>
        <author>
            <name>T. Hastings</name>
        </author>
        <author>
            <name>S. Zilles</name>
        </author>
        <author>
            <name>J. Gyllenskog</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>239228</char-count>
            <page-count>113</page-count>
        </format>
        <keywords>
            <kw>Print-MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>A printer is the physical device that takes media from an input source, produces marks on that media according to some page description or page control language and puts the result in some output destination, possibly with finishing applied. The information needed in the management of the physical printer and the management of a printing job overlap highly and many of the tasks in each management area require the same or similar information. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3805</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1760</doc-id>
        <title>The S/KEY One-Time Password System</title>
        <author>
            <name>N. Haller</name>
        </author>
        <date>
            <month>February</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31124</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>Security</kw>
        </keywords>
        <abstract>This document describes the S/KEY* One-Time Password system as released for public use by Bellcore. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1761</doc-id>
        <title>Snoop Version 2 Packet Capture File Format</title>
        <author>
            <name>B. Callaghan</name>
        </author>
        <author>
            <name>R. Gilligan</name>
        </author>
        <date>
            <month>February</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10761</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>SNOOP</kw>
            <kw>Measurement</kw>
            <kw>debugging</kw>
            <kw>collecting</kw>
            <kw>data</kw>
        </keywords>
        <abstract>This paper describes the file format used by "snoop", a packet monitoring and capture program developed by Sun. This paper is provided so that people can write compatible programs to generate and interpret snoop packet capture files. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1762</doc-id>
        <title>The PPP DECnet Phase IV Control Protocol (DNCP)</title>
        <author>
            <name>S. Senum</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12709</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>PPP-DNCP</kw>
            <kw>Point</kw>
            <kw>Digital</kw>
            <kw>Equipment</kw>
            <kw>Corporation</kw>
        </keywords>
        <abstract>This document defines the NCP for establishing and configuring Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP. This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc). [STANDARDS- TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1376</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1763</doc-id>
        <title>The PPP Banyan Vines Control Protocol (BVCP)</title>
        <author>
            <name>S. Senum</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17817</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>BVCP</kw>
            <kw>Point</kw>
        </keywords>
        <abstract>This document defines the Network Control Protocol for establishing and configuring the Banyan VINES protocol over PPP. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1764</doc-id>
        <title>The PPP XNS IDP Control Protocol (XNSCP)</title>
        <author>
            <name>S. Senum</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9525</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>XNSCP</kw>
            <kw>Point</kw>
            <kw>Xerox</kw>
            <kw>Network</kw>
            <kw>Internetwork</kw>
            <kw>Datagram</kw>
            <kw>Service</kw>
        </keywords>
        <abstract>This document defines the Network Control Protocol for establishing and configuring the Xerox Network Systems (XNS) Internet Datagram Protocol (IDP) over PPP. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1765</doc-id>
        <title>OSPF Database Overflow</title>
        <author>
            <name>J. Moy</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21613</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>OSPF-OVFL</kw>
        </keywords>
        <abstract>This memo details a way of gracefully handling unanticipated database overflows. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1766</doc-id>
        <title>Tags for the Identification of Languages</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16966</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>Lang-Tag</kw>
        </keywords>
        <abstract>This document describes a language tag for use in cases where it is desired to indicate the language used in an information object. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3066</doc-id>
            <doc-id>RFC3282</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1767</doc-id>
        <title>MIME Encapsulation of EDI Objects</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15293</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>MIME-EDI</kw>
            <kw>Electronic</kw>
            <kw>Data</kw>
            <kw>Interchange</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
            <kw>delivery</kw>
            <kw>mechanism</kw>
            <kw>encapsulation</kw>
        </keywords>
        <abstract>Since there are many different EDI specifications, the current document defines three distinct categories as three different MIME content-types. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1768</doc-id>
        <title>Host Group Extensions for CLNP Multicasting</title>
        <author>
            <name>D. Marlow</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>111499</char-count>
            <page-count>45</page-count>
        </format>
        <keywords>
            <kw>CLNP-MULT</kw>
            <kw>ISO</kw>
            <kw>OSI</kw>
        </keywords>
        <abstract>This memo provides a specification for multicast extensions to the CLNP protocol similar to those provided to IP by RFC1112. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1769</doc-id>
        <title>Simple Network Time Protocol (SNTP)</title>
        <author>
            <name>D. Mills</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34454</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>Clocks</kw>
            <kw>Synchronization</kw>
            <kw>NTP</kw>
        </keywords>
        <abstract>This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1361</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2030</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1770</doc-id>
        <title>IPv4 Option for Sender Directed Multi-Destination Delivery</title>
        <author>
            <name>C. Graff</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11606</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>SDMD</kw>
        </keywords>
        <abstract>This memo defines an IPv4 option to provide a sender directed multi- destination delivery mechanism called Selective Directed Broadcast Mode (SDBM). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1771</doc-id>
        <title>A Border Gateway Protocol 4 (BGP-4)</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>131903</char-count>
            <page-count>57</page-count>
        </format>
        <keywords>
            <kw>BGP-4</kw>
            <kw>routing</kw>
        </keywords>
        <abstract>This document, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1654</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1772</doc-id>
        <title>Application of the Border Gateway Protocol in the Internet</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>P. Gross</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43916</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>BGP-4-APP</kw>
            <kw>BGP-4</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract>This document, together with its companion document, "A Border Gateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet. This document describes the usage of the BGP in the Internet. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1655</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1773</doc-id>
        <title>Experience with the BGP-4 protocol</title>
        <author>
            <name>P. Traina</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19936</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>BGP-4</kw>
            <kw>Border</kw>
            <kw>Gateway</kw>
            <kw>Protocol</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract>The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report documents experience with BGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1656</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1774</doc-id>
        <title>BGP-4 Protocol Analysis</title>
        <author>
            <name>P. Traina</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23823</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>Border</kw>
            <kw>Gateway</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract>The purpose of this report is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by the Border Gateway Protocol version 4 (BGP-4). This report summarizes the key features of BGP, and analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1775</doc-id>
        <title>To Be "On" the Internet</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8454</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>access</kw>
            <kw>full</kw>
            <kw>Client</kw>
            <kw>Mediated</kw>
            <kw>Messaging</kw>
        </keywords>
        <abstract>The Internet permits different levels of access for consumers and providers of service. The nature of those differences is quite important in the capabilities They afford. Hence, it is appropriate to provide terminology that distinguishes among the range, so that the Internet community can gain some clarity when distinguishing whether a user (or an organization) is "on" the Internet. This document suggests four terms, for distinguishing the major classes of access. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1776</doc-id>
        <title>The Address is the Message</title>
        <author>
            <name>S. Crocker</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2051</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>IPng</kw>
        </keywords>
        <abstract>Declaring that the address is the message, the IPng WG has selected a packet format which includes 1696 bytes of address space. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1777</doc-id>
        <title>Lightweight Directory Access Protocol</title>
        <author>
            <name>W. Yeong</name>
        </author>
        <author>
            <name>T. Howes</name>
        </author>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45459</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>X.500</kw>
            <kw>DAP</kw>
            <kw>interactive</kw>
            <kw>access</kw>
        </keywords>
        <abstract>The protocol described in this document is designed to provide access to the X.500 Directory while not incurring the resource requirements of the Directory Access Protocol (DAP).This protocol is specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the X.500 Directory, and is intended to be a complement to the DAP itself. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1487</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3494</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1778</doc-id>
        <title>The String Representation of Standard Attribute Syntaxes</title>
        <author>
            <name>T. Howes</name>
        </author>
        <author>
            <name>S. Kille</name>
        </author>
        <author>
            <name>W. Yeong</name>
        </author>
        <author>
            <name>C. Robbins</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19053</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>X.500</kw>
            <kw>LDAP</kw>
            <kw>lightweight directory protocol</kw>
        </keywords>
        <abstract>The Lightweight Directory Access Protocol (LDAP) requires that the contents of AttributeValue fields in protocol elements be octet strings. This document defines the requirements that must be satisfied by encoding rules used to render X.500 Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1488</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3494</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC2559</doc-id>
        </updated-by>
        <current-status>HISTORIC</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1779</doc-id>
        <title>A String Representation of Distinguished Names</title>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12429</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>STR-REP</kw>
            <kw>X.500</kw>
            <kw>directory names</kw>
            <kw>representing names</kw>
        </keywords>
        <abstract>The OSI Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1. When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name. This specification defines a string format for representing names, which is designed to give a clean representation of commonly used names, whilst being able to represent any distinguished name. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1485</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2253</doc-id>
            <doc-id>RFC3494</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1780</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Postel</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>86594</char-count>
            <page-count>39</page-count>
        </format>
        <keywords>
            <kw>status</kw>
            <kw>procedure</kw>
            <kw>index</kw>
        </keywords>
        <abstract>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1720</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1800</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1781</doc-id>
        <title>Using the OSI Directory to Achieve User Friendly Naming</title>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47129</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>OSI-Dir</kw>
            <kw>X.500</kw>
            <kw>directory names</kw>
            <kw>representing names</kw>
        </keywords>
        <abstract>This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1484</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3494</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1782</doc-id>
        <title>TFTP Option Extension</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <author>
            <name>A. Harkin</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11508</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>trivial</kw>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>booting</kw>
        </keywords>
        <abstract>The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer. </abstract>
        <obsoleted-by>
            <doc-id>RFC2347</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1350</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1783</doc-id>
        <title>TFTP Blocksize Option</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <author>
            <name>A. Harkin</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7814</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>trivial</kw>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>booting</kw>
        </keywords>
        <abstract>This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2348</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1350</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1784</doc-id>
        <title>TFTP Timeout Interval and Transfer Size Options</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <author>
            <name>A. Harkin</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6106</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>trivial</kw>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>booting</kw>
        </keywords>
        <abstract>This document describes two TFTP options. The first allows the client and server to negotiate the Timeout Interval. The second allows the side receiving the file to determine the ultimate size of the transfer before it begins. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2349</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1350</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1785</doc-id>
        <title>TFTP Option Negotiation Analysis</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <author>
            <name>A. Harkin</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3354</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>trivial</kw>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>booting</kw>
        </keywords>
        <abstract>This document was written to allay concerns that the presence of options in a TFTP Request packet might cause pathological behavior on servers which do not support TFTP option negotiation. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <updates>
            <doc-id>RFC1350</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1786</doc-id>
        <title>Representation of IP Routing Policies in a Routing Registry (ripe-81++)</title>
        <author>
            <name>T. Bates</name>
        </author>
        <author>
            <name>E. Gerich</name>
        </author>
        <author>
            <name>L. Joncheray</name>
        </author>
        <author>
            <name>J-M. Jouanigot</name>
        </author>
        <author>
            <name>D. Karrenberg</name>
        </author>
        <author>
            <name>M. Terpstra</name>
        </author>
        <author>
            <name>J. Yu</name>
        </author>
        <date>
            <month>March</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>133643</char-count>
            <page-count>83</page-count>
        </format>
        <abstract>This document is an update to the original `ripe-81' proposal for representing and storing routing polices within the RIPE database. It incorporates several extensions proposed by Merit Inc. and gives details of a generalized IP routing policy representation to be used by all Internet routing registries. It acts as both tutorial and provides details of database objects and attributes that use and make up a routing registry. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1787</doc-id>
        <title>Routing in a Multi-provider Internet</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>April</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20754</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>Architechure Board</kw>
            <kw>IAB</kw>
        </keywords>
        <abstract>This document presents some of the issues related to network layer routing in a multi-provider Internet, and specifically to the unicast routing. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1788</doc-id>
        <title>ICMP Domain Name Messages</title>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>April</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11722</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>ICMP-DM</kw>
            <kw>Internet</kw>
            <kw>Control</kw>
            <kw>Message</kw>
            <kw>Protocol</kw>
            <kw>DNS</kw>
            <kw>Service</kw>
        </keywords>
        <abstract>This document specifies ICMP messages for learning the Fully Qualified Domain Name associated with an IP address. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1789</doc-id>
        <title>INETPhone: Telephone Services and Servers on Internet</title>
        <author>
            <name>C. Yang</name>
        </author>
        <date>
            <month>April</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14186</char-count>
            <page-count>6</page-count>
        </format>
        <abstract>This RFC presents a true telephone service, called INETPhone, which supports voice communication through the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1790</doc-id>
        <title>An Agreement between the Internet Society and Sun Microsystems, Inc. in the Matter of ONC RPC and XDR Protocols</title>
        <author>
            <name>V. Cerf</name>
        </author>
        <date>
            <month>April</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8226</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>ISOC</kw>
        </keywords>
        <abstract>This RFC is an official public record of an agreement between SUN Microsystems and the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1791</doc-id>
        <title>TCP And UDP Over IPX Networks With Fixed Path MTU</title>
        <author>
            <name>T. Sung</name>
        </author>
        <date>
            <month>April</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22347</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>Transmission</kw>
            <kw>Control</kw>
            <kw>Protocol</kw>
            <kw>User</kw>
            <kw>Datagram</kw>
            <kw>Maxium</kw>
            <kw>Unit</kw>
        </keywords>
        <abstract>TCP/IPX allows TCP/IP applications to run over IPX networks by letting TCP and UDP run over IPX. And this memo specifies the packet format and operational procedures for running TCP and UDP over IPX. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1792</doc-id>
        <title>TCP/IPX Connection Mib Specification</title>
        <author>
            <name>T. Sung</name>
        </author>
        <date>
            <month>April</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16389</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>TCP/IPXMIB</kw>
            <kw>Transmission</kw>
            <kw>Control</kw>
            <kw>Protocol</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>New MIB objects, tcpIpxConnTable, udpIpxTable, tcpUnspecConnTable and udpUnspecTable are presented in this paper, to be used in place of tcpConnTable and udpListenerTable when TCP and UDP are running over IPX. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1793</doc-id>
        <title>Extending OSPF to Support Demand Circuits</title>
        <author>
            <name>J. Moy</name>
        </author>
        <date>
            <month>April</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>78728</char-count>
            <page-count>32</page-count>
        </format>
        <keywords>
            <kw>OSPF-DC</kw>
            <kw>Open</kw>
            <kw>Shortest</kw>
            <kw>Path</kw>
            <kw>First</kw>
        </keywords>
        <abstract>This memo defines enhancements to the OSPF protocol that allow efficient operation over "demand circuits". [STANDARDS-TRACK] </abstract>
        <updated-by>
            <doc-id>RFC3883</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1794</doc-id>
        <title>DNS Support for Load Balancing</title>
        <author>
            <name>T. Brisco</name>
        </author>
        <date>
            <month>April</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15494</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
        </keywords>
        <abstract>This RFC is meant to first chronicle a foray into the IETF DNS Working Group, discuss other possible alternatives to provide/simulate load balancing support for DNS, and to provide an ultimate, flexible solution for providing DNS support for balancing loads of many types. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1795</doc-id>
        <title>Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1</title>
        <author>
            <name>L. Wells</name>
            <title>Chair</title>
        </author>
        <author>
            <name>A. Bartky</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>214848</char-count>
            <page-count>91</page-count>
        </format>
        <keywords>
            <kw>IBM</kw>
            <kw>SNA</kw>
            <kw>DLS</kw>
            <kw>SSP</kw>
            <kw>NetBIos</kw>
            <kw>APPN</kw>
        </keywords>
        <abstract>This RFC describes use of Data Link Switching over TCP/IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1434</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1796</doc-id>
        <title>Not All RFCs are Standards</title>
        <author>
            <name>C. Huitema</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>S. Crocker</name>
        </author>
        <date>
            <month>April</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7049</char-count>
            <page-count>4</page-count>
        </format>
        <abstract>This document discusses the relationship of the Request for Comments (RFCs) notes to Internet Standards. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1797</doc-id>
        <title>Class A Subnet Experiment</title>
        <author>
            <name>Internet Assigned Numbers Authority (IANA)</name>
        </author>
        <date>
            <month>April</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6779</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>Network</kw>
            <kw>Address</kw>
            <kw>39</kw>
            <kw>Number</kw>
        </keywords>
        <abstract>There appears to be some interest in experimenting with subnetting the class A addresses. It is suggested that conducting an experiment now to identify and fix any software that does not properly handle subnetted class A addresses would be useful and important. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1798</doc-id>
        <title>Connection-less Lightweight X.500 Directory Access Protocol</title>
        <author>
            <name>A. Young</name>
        </author>
        <date>
            <month>June</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18548</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>CLDAP</kw>
            <kw>CLDAP</kw>
            <kw>Presentation</kw>
            <kw>Address</kw>
            <kw>Application</kw>
            <kw>Entity</kw>
            <kw>Title</kw>
        </keywords>
        <abstract>The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3352</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1799</doc-id>
        <title>Request for Comments Summary RFC Numbers 1700-1799</title>
        <author>
            <name>M. Kennedy</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42038</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>Index</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1800</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Postel</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>83649</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>status</kw>
            <kw>procedure</kw>
            <kw>index</kw>
        </keywords>
        <abstract>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1780</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1880</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1801</doc-id>
        <title>MHS use of the X.500 Directory to support MHS Routing</title>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>June</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>156462</char-count>
            <page-count>73</page-count>
        </format>
        <keywords>
            <kw>Routing</kw>
            <kw>Mail</kw>
            <kw>EMail</kw>
            <kw>Message</kw>
            <kw>Handling</kw>
            <kw>System</kw>
            <kw>X.400</kw>
        </keywords>
        <abstract>The key problem in routing is to map from an O/R Address onto an MTA (next hop). This shall be an MTA which in some sense is "nearer" to the destination UA. This is done repeatedly until the message can be directly delivered to the recipient UA. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1802</doc-id>
        <title>Introducing Project Long Bud: Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <author>
            <name>K. Jordan</name>
        </author>
        <author>
            <name>S. Langlois</name>
        </author>
        <author>
            <name>J. Romaguera</name>
        </author>
        <date>
            <month>June</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24637</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>Mail</kw>
            <kw>EMail</kw>
            <kw>Message</kw>
            <kw>Handling</kw>
            <kw>System</kw>
            <kw>MHS</kw>
        </keywords>
        <abstract>This memo describes a proposed Internet Pilot Project that seeks to prove the MHS-DS approach on a larger scale. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1803</doc-id>
        <title>Recommendations for an X.500 Production Directory Service</title>
        <author>
            <name>R. Wright</name>
        </author>
        <author>
            <name>A. Getchell</name>
        </author>
        <author>
            <name>T. Howes</name>
        </author>
        <author>
            <name>S. Sataluri</name>
        </author>
        <author>
            <name>P. Yee</name>
        </author>
        <author>
            <name>W. Yeong</name>
        </author>
        <date>
            <month>June</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14721</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Pages</kw>
            <kw>DSA</kw>
            <kw>Directory</kw>
            <kw>User</kw>
            <kw>Agent</kw>
        </keywords>
        <abstract>This document contains a set of basic recommendations for a country- level X.500 DSA. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1804</doc-id>
        <title>Schema Publishing in X.500 Directory</title>
        <author>
            <name>G. Mansfield</name>
        </author>
        <author>
            <name>P. Rajeev</name>
        </author>
        <author>
            <name>S. Raghavan</name>
        </author>
        <author>
            <name>T. Howes</name>
        </author>
        <date>
            <month>June</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18268</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>In this document we propose a solution using the existing mechanisms of the directory [1] itself. We present a naming scheme for naming schema objects and a meta-schema for storing schema objects in the directory. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1805</doc-id>
        <title>Location-Independent Data/Software Integrity Protocol </title>
        <author>
            <name>A. Rubin</name>
        </author>
        <date>
            <month>June</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13352</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>Betsi</kw>
            <kw>Security</kw>
            <kw>Cryptography</kw>
        </keywords>
        <abstract>This memo describes a protocol for adding integrity assurance to files that are distributed across the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1806</doc-id>
        <title>Communicating Presentation Information in Internet Messages: The Content-Disposition Header</title>
        <author>
            <name>R. Troost</name>
        </author>
        <author>
            <name>S. Dorner</name>
        </author>
        <date>
            <month>June</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15548</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>MIME</kw>
            <kw>EMail</kw>
            <kw>Mail</kw>
        </keywords>
        <abstract>This memo provides a mechanism whereby messages conforming to the [RFC 1521] ("MIME") specification can convey presentational information. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <updated-by>
            <doc-id>RFC2183</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1807</doc-id>
        <title>A Format for Bibliographic Records</title>
        <author>
            <name>R. Lasher</name>
        </author>
        <author>
            <name>D. Cohen</name>
        </author>
        <date>
            <month>June</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29417</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>library</kw>
            <kw>technical reports</kw>
            <kw>email services</kw>
        </keywords>
        <abstract>This RFC defines a format for bibliographic records describing technical reports. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1357</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1808</doc-id>
        <title>Relative Uniform Resource Locators</title>
        <author>
            <name>R. Fielding</name>
        </author>
        <date>
            <month>June</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34950</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>URL</kw>
            <kw>URL</kw>
            <kw>syntax</kw>
            <kw>semantics</kw>
        </keywords>
        <abstract>In situations where the base URL is well-defined and known to the parser (human or machine), it is useful to be able to embed URL references which inherit that context rather than re-specifying it in every instance. This document defines the syntax and semantics for such Relative Uniform Resource Locators. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3986</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1738</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC2368</doc-id>
            <doc-id>RFC2396</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1809</doc-id>
        <title>Using the Flow Label Field in IPv6</title>
        <author>
            <name>C. Partridge</name>
        </author>
        <date>
            <month>June</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13591</char-count>
            <page-count>6</page-count>
        </format>
        <abstract>The purpose of this memo is to distill various opinions and suggestions of the End-to-End Research Group regarding the handling of Flow Labels into a set of suggestions for IPv6. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1810</doc-id>
        <title>Report on MD5 Performance</title>
        <author>
            <name>J. Touch</name>
        </author>
        <date>
            <month>June</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16607</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>IPv6</kw>
            <kw>Message</kw>
            <kw>Digest</kw>
            <kw>Algorithm</kw>
            <kw>Authentication</kw>
        </keywords>
        <abstract>This RFC addresses how fast MD5 can be implemented in software and hardware, and whether it supports currently available IP bandwidth. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1811</doc-id>
        <title>U.S. Government Internet Domain Names</title>
        <author>
            <name>Federal Networking Council</name>
        </author>
        <date>
            <month>June</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6641</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>GOV</kw>
            <kw>FNC</kw>
            <kw>IANA</kw>
        </keywords>
        <abstract>This document describes the registration policies for the top-level domain ".GOV". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC1816</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1812</doc-id>
        <title>Requirements for IP Version 4 Routers</title>
        <author>
            <name>F. Baker</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>415740</char-count>
            <page-count>175</page-count>
        </format>
        <keywords>
            <kw>routing</kw>
            <kw>IPv4</kw>
        </keywords>
        <abstract>This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1716</doc-id>
            <doc-id>RFC1009</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC2644</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1813</doc-id>
        <title>NFS Version 3 Protocol Specification</title>
        <author>
            <name>B. Callaghan</name>
        </author>
        <author>
            <name>B. Pawlowski</name>
        </author>
        <author>
            <name>P. Staubach</name>
        </author>
        <date>
            <month>June</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>229793</char-count>
            <page-count>126</page-count>
        </format>
        <keywords>
            <kw>NFSV3</kw>
        </keywords>
        <abstract>This paper describes the NFS version 3 protocol. This paper is provided so that people can write compatible implementations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <notes>10/29/03 - back in June 2002, Matthew Wilcox sent an email stating that RFC 3010 is listed as erronously obsoleting RFCs 1813 and 1094.  This was confirmed by Scott Bradner in October 2003.  I have removed the Obsoleted by tag for for this entry.</notes>
        <see-also>
            <doc-id>RFC1094</doc-id>
        </see-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1814</doc-id>
        <title>Unique Addresses are Good</title>
        <author>
            <name>E. Gerich</name>
        </author>
        <date>
            <month>June</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5936</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Registries</kw>
            <kw>Protocol</kw>
            <kw>Private</kw>
            <kw>Network</kw>
            <kw>Numbers</kw>
        </keywords>
        <abstract>The IAB suggests that while RFC 1597 establishes reserved IP address space for the use of private networks which are isolated and will remain isolated from the Internet, any enterprise which anticipates external connectivity to the Internet should apply for a globally unique address from an Internet registry or service provider. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1815</doc-id>
        <title>Character Sets ISO-10646 and ISO-10646-J-1</title>
        <author>
            <name>M. Ohta</name>
        </author>
        <date>
            <month>July</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11823</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>Japanese</kw>
            <kw>Latin</kw>
        </keywords>
        <abstract>For the practical use of ISO 10646, a lot of external profiling such as restriction of characters, restriction of combination of characters and addition of language information is necessary. This memo provides information on such profiling, along with charset names to each profiled instance. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1816</doc-id>
        <title>U.S. Government Internet Domain Names</title>
        <author>
            <name>Federal Networking Council</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17979</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>GOV</kw>
            <kw>FNC</kw>
            <kw>IANA</kw>
        </keywords>
        <abstract>This memo provides an update and clarification to RFC 1811. This document describes the registration policies for the top-level domain ".GOV". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1811</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2146</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1817</doc-id>
        <title>CIDR and Classful Routing</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3416</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>Classless</kw>
            <kw>Inter</kw>
            <kw>Domain</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract>This document represents the IAB's (Internet Architecture Board) evaluation of the current and near term implications of CIDR on organizations that use Classful routing technology. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1818</doc-id>
        <title>Best Current Practices</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4114</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>BCP</kw>
        </keywords>
        <abstract>This document describes a new series of documents which describe best current practices for the Internet community. Documents in this series carry the endorsement of the Internet Engineering Steering Group (IESG). </abstract>
        <is-also>
            <doc-id>BCP0001</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1819</doc-id>
        <title>Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+</title>
        <author>
            <name>L. Delgrossi</name>
        </author>
        <author>
            <name>L. Berger</name>
            <title>Editors</title>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>266875</char-count>
            <page-count>109</page-count>
        </format>
        <keywords>
            <kw>ST2</kw>
        </keywords>
        <abstract>This memo contains a revised specification of the Internet STream Protocol Version 2 (ST2). This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoletes>
            <doc-id>RFC1190</doc-id>
            <doc-id>IEN119</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1820</doc-id>
        <title>Multimedia E-mail (MIME) User Agent Checklist</title>
        <author>
            <name>E. Huizer</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14672</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
            <kw>Media</kw>
            <kw>Types</kw>
        </keywords>
        <abstract>This document presents a checklist to facilitate evaluation of MIME capable User Agents. Access to a MIME test-responder, that generates test-messages is described. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC1844</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1821</doc-id>
        <title>Integration of Real-time Services in an IP-ATM Network Architecture</title>
        <author>
            <name>M. Borden</name>
        </author>
        <author>
            <name>E. Crawley</name>
        </author>
        <author>
            <name>B. Davie</name>
        </author>
        <author>
            <name>S. Batsell</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>64466</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>Asynchronous</kw>
            <kw>Transfer</kw>
            <kw>Mode</kw>
        </keywords>
        <abstract>The purpose of this paper is to provide a clear statement of what issues need to be addressed in interfacing the IP integrated services environment with an ATM service environment so as to create a seamless interface between the two in support of end users desiring real-time networking services. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1822</doc-id>
        <title>A Grant of Rights to Use a Specific IBM patent with Photuris</title>
        <author>
            <name>J. Lowe</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2664</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Key</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>IKMP</kw>
            <kw>IETF</kw>
        </keywords>
        <abstract>This Request for Comments records a grant by IBM Corporation to permit the conditional free use of one of its patents. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1823</doc-id>
        <title>The LDAP Application Program Interface</title>
        <author>
            <name>T. Howes</name>
        </author>
        <author>
            <name>M. Smith</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41081</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>API</kw>
            <kw>X.500</kw>
        </keywords>
        <abstract>This document defines a C language application program interface to the lightweight directory access protocol (LDAP). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1824</doc-id>
        <title>The Exponential Security System TESS: An Identity-Based Cryptographic Protocol for Authenticated Key-Exchange (E.I.S.S.-Report 1995/4)</title>
        <author>
            <name>H. Danisch</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45540</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>TESS</kw>
            <kw>public</kw>
            <kw>keys</kw>
        </keywords>
        <abstract>This informational RFC describes the basic mechanisms and functions of an identity based system for the secure authenticated exchange of cryptographic keys, the generation of signatures, and the authentic distribution of public keys. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1825</doc-id>
        <title>Security Architecture for the Internet Protocol</title>
        <author>
            <name>R. Atkinson</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>56772</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
            <kw>IP-layer</kw>
            <kw>ipsec</kw>
        </keywords>
        <abstract>This memo describes the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2401</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1826</doc-id>
        <title>IP Authentication Header</title>
        <author>
            <name>R. Atkinson</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27583</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>ipsec</kw>
            <kw>IPV6-AH</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>AH</kw>
            <kw>security</kw>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
        </keywords>
        <abstract>This document describes a mechanism for providing cryptographic authentication for IPv4 and IPv6 datagrams. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2402</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1827</doc-id>
        <title>IP Encapsulating Security Payload (ESP)</title>
        <author>
            <name>R. Atkinson</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30278</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>ESP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
            <kw>ipsec</kw>
        </keywords>
        <abstract>This document describes the IP Encapsulating Security Payload (ESP). ESP is a mechanism for providing integrity and confidentiality to IP datagrams. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2406</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1828</doc-id>
        <title>IP Authentication using Keyed MD5</title>
        <author>
            <name>P. Metzger</name>
        </author>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9800</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>ipsec</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>Authentication</kw>
            <kw>Header</kw>
            <kw>AH</kw>
            <kw>Message</kw>
            <kw>Digest</kw>
            <kw>5</kw>
            <kw>Security</kw>
        </keywords>
        <abstract>This document describes the use of keyed MD5 with the IP Authentication Header. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1829</doc-id>
        <title>The ESP DES-CBC Transform</title>
        <author>
            <name>P. Karn</name>
        </author>
        <author>
            <name>P. Metzger</name>
        </author>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19291</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>Encapsulating</kw>
            <kw>Security</kw>
            <kw>Payload</kw>
            <kw>US</kw>
            <kw>Data</kw>
            <kw>Encryption</kw>
            <kw>Standard</kw>
            <kw>Cipher</kw>
            <kw>Block</kw>
            <kw>Chaining</kw>
            <kw>IP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>Security</kw>
            <kw>ipsec</kw>
        </keywords>
        <abstract>This document describes the DES-CBC security transform for the IP Encapsulating Security Payload (ESP). [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1830</doc-id>
        <title>SMTP Service Extensions for Transmission of Large and Binary MIME Messages</title>
        <author>
            <name>G. Vaudreuil</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16555</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>Simple</kw>
            <kw>Mail</kw>
            <kw>Transfer</kw>
            <kw>Multipurpose</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract>This memo defines two extensions to the SMTP service. The first service enables a SMTP client and server to negotiate the use of an alternate DATA command "BDAT" for efficiently sending large MIME messages. The second extension takes advantage of the BDAT command to permit the negotiated sending of unencoded binary data. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC3030</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1831</doc-id>
        <title>RPC: Remote Procedure Call Protocol Specification Version 2</title>
        <author>
            <name>R. Srinivasan</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37798</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>RPC</kw>
            <kw>ONC</kw>
            <kw>Open</kw>
            <kw>Network</kw>
            <kw>Computing</kw>
        </keywords>
        <abstract>This document describes the ONC Remote Procedure Call (ONC RPC Version 2) protocol as it is currently deployed and accepted. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1832</doc-id>
        <title>XDR: External Data Representation Standard</title>
        <author>
            <name>R. Srinivasan</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47418</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>XDR</kw>
            <kw>RPC</kw>
            <kw>ONC</kw>
            <kw>Open</kw>
            <kw>Network</kw>
            <kw>Computing </kw>
        </keywords>
        <abstract>This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. [STANDARDS-TRACK] </abstract>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1833</doc-id>
        <title>Binding Protocols for ONC RPC Version 2</title>
        <author>
            <name>R. Srinivasan</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24449</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>ONC</kw>
            <kw>Open</kw>
            <kw>Network</kw>
            <kw>Computing</kw>
        </keywords>
        <abstract>This document describes the binding protocols used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocols. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1834</doc-id>
        <title>Whois and Network Information Lookup Service, Whois++</title>
        <author>
            <name>J. Gargano</name>
        </author>
        <author>
            <name>K. Weiss</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14429</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>nicname</kw>
            <kw>TCP</kw>
            <kw>Transmission</kw>
            <kw>Control</kw>
            <kw>Protocol</kw>
            <kw>directory</kw>
            <kw>service</kw>
            <kw>server</kw>
            <kw>retrieval</kw>
        </keywords>
        <abstract>This memo describes new features for WHOIS. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1835</doc-id>
        <title>Architecture of the WHOIS++ service</title>
        <author>
            <name>P. Deutsch</name>
        </author>
        <author>
            <name>R. Schoultz</name>
        </author>
        <author>
            <name>P. Faltstrom</name>
        </author>
        <author>
            <name>C. Weider</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>80581</char-count>
            <page-count>41</page-count>
        </format>
        <keywords>
            <kw>WHOIS++</kw>
            <kw>nicname</kw>
            <kw>TCP</kw>
            <kw>Transmission</kw>
            <kw>Control</kw>
            <kw>Protocol</kw>
            <kw>directory</kw>
            <kw>service</kw>
            <kw>server</kw>
            <kw>retrieval</kw>
        </keywords>
        <abstract>This document describes WHOIS++, an extension to the trivial WHOIS service described in RFC 954 to permit WHOIS-like servers to make available more structured information to the Internet. [STANDARDS- TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1836</doc-id>
        <title>Representing the O/R Address hierarchy in the X.500 Directory Information Tree</title>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20175</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>message</kw>
            <kw>handling</kw>
        </keywords>
        <abstract>This document defines a representation of the O/R Address hierarchy in the Directory Information Tree [6, 1]. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC2294</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1837</doc-id>
        <title>Representing Tables and Subtrees in the X.500 Directory</title>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10924</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>message</kw>
            <kw>handling</kw>
        </keywords>
        <abstract>This document defines techniques for representing two types of information mapping in the OSI Directory. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC2293</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1838</doc-id>
        <title>Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses </title>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12216</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>message</kw>
            <kw>handling</kw>
        </keywords>
        <abstract>This document defines how to use directory to support the mapping between X.400 O/R Addresses and mailboxes defined in RFC 1327 [2]. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC2164</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC1839</doc-id>
    </rfc-not-issued-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC1840</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC1841</doc-id>
        <title>PPP Network Control Protocol for LAN Extension</title>
        <author>
            <name>J. Chapman</name>
        </author>
        <author>
            <name>D. Coli</name>
        </author>
        <author>
            <name>A. Harvey</name>
        </author>
        <author>
            <name>B. Jensen</name>
        </author>
        <author>
            <name>K. Rowett</name>
        </author>
        <date>
            <month>September</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>146206</char-count>
            <page-count>66</page-count>
        </format>
        <keywords>
            <kw>point-to-point</kw>
            <kw>local</kw>
            <kw>area</kw>
            <kw>interface</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1842</doc-id>
        <title>ASCII Printable Characters-Based Chinese Character Encoding for Internet Messages</title>
        <author>
            <name>Y. Wei</name>
        </author>
        <author>
            <name>Y. Zhang</name>
        </author>
        <author>
            <name>J. Li</name>
        </author>
        <author>
            <name>J. Ding</name>
        </author>
        <author>
            <name>Y. Jiang</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24143</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>electronic</kw>
            <kw>mail</kw>
            <kw>HZ-GB-2312</kw>
        </keywords>
        <abstract>This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages over the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Telecommunications infrastructure is improving to offer higher bandwidth connections at lower cost. Access to the network is changing from modems to more intelligent devices. This informational RFC discusses a PPP Network Control Protocol for one such intelligent device. The protocol is the LAN extension interface protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1843</doc-id>
        <title>HZ - A Data Format for Exchanging Files of Arbitrarily Mixed Chinese and ASCII characters</title>
        <author>
            <name>F. Lee</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8787</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>GB2312-80</kw>
            <kw>electronic</kw>
            <kw>mail</kw>
        </keywords>
        <abstract>The content of this memo is identical to an article of the same title written by the author on September 4, 1989. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1844</doc-id>
        <title>Multimedia E-mail (MIME) User Agent Checklist</title>
        <author>
            <name>E. Huizer</name>
        </author>
        <date>
            <month>August</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15072</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
            <kw>Media</kw>
            <kw>Types</kw>
        </keywords>
        <abstract>This document presents a checklist to facilitate evaluation of MIME capable User Agents. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1820</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1845</doc-id>
        <title>SMTP Service Extension for Checkpoint/Restart</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>A. Cargille</name>
        </author>
        <date>
            <month>September</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15399</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>simple</kw>
            <kw>mail</kw>
            <kw>transfer</kw>
            <kw>transaction</kw>
        </keywords>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1846</doc-id>
        <title>SMTP 521 Reply Code</title>
        <author>
            <name>A. Durand</name>
        </author>
        <author>
            <name>F. Dupont</name>
        </author>
        <date>
            <month>September</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6558</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>simple</kw>
            <kw>mail</kw>
            <kw>transfer</kw>
        </keywords>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1847</doc-id>
        <title>Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted</title>
        <author>
            <name>J. Galvin</name>
        </author>
        <author>
            <name>S. Murphy</name>
        </author>
        <author>
            <name>S. Crocker</name>
        </author>
        <author>
            <name>N. Freed</name>
        </author>
        <date>
            <month>October</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23679</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>MIME-Encyp</kw>
            <kw>mail</kw>
            <kw>multipurpose</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document defines a framework within which security services may be applied to MIME body parts. [STANDARDS-TRACK] This memo defines a new Simple Mail Transfer Protocol (SMTP) [1] reply code, 521, which one may use to indicate that an Internet host does not accept incoming mail. This memo defines an Experimental Protocol for the Internet community. This memo defines an extension to the SMTP service whereby an interrupted SMTP transaction can be restarted at a later time without having to repeat all of the commands and message content sent prior to the interruption. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1848</doc-id>
        <title>MIME Object Security Services</title>
        <author>
            <name>S. Crocker</name>
        </author>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>J. Galvin</name>
        </author>
        <author>
            <name>S. Murphy</name>
        </author>
        <date>
            <month>October</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>95010</char-count>
            <page-count>48</page-count>
        </format>
        <keywords>
            <kw>MIME-Sec</kw>
            <kw>mail</kw>
            <kw>multipurpose</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document defines MIME Object Security Services (MOSS), a protocol that uses the multipart/signed and multipart/encrypted framework [7] to apply digital signature and encryption services to MIME objects. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC1849</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC1850</doc-id>
        <title>OSPF Version 2 Management Information Base</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>R. Coltun</name>
        </author>
        <date>
            <month>November</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>140255</char-count>
            <page-count>80</page-count>
        </format>
        <keywords>
            <kw>OSPF-MIB</kw>
            <kw>Open</kw>
            <kw>Shortest</kw>
            <kw>Path</kw>
            <kw>First</kw>
            <kw>SPF</kw>
            <kw>MIB</kw>
            <kw>routing</kw>
            <kw>network management</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Open Shortest Path First Routing Protocol. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1253</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1851</doc-id>
        <title>The ESP Triple DES Transform</title>
        <author>
            <name>P. Karn</name>
        </author>
        <author>
            <name>P. Metzger</name>
        </author>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>September</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20000</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>ESP3DES</kw>
            <kw>encryption encapsulating security payload cipher block chaining</kw>
        </keywords>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1852</doc-id>
        <title>IP Authentication using Keyed SHA</title>
        <author>
            <name>P. Metzger</name>
        </author>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>September</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9367</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>encryption secure hash algorithm</kw>
        </keywords>
        <obsoleted-by>
            <doc-id>RFC2841</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1853</doc-id>
        <title>IP in IP Tunneling</title>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>October</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14803</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>internet protocol payload encapsulation</kw>
        </keywords>
        <abstract>This document discusses implementation techniques for using IP Protocol/Payload number 4 Encapsulation for tunneling with IP Security and other protocols. This memo provides information for the Internet community. It does not specify an Internet standard. This document describes the use of keyed SHA with the IP Authentication Header. This document defines an Experimental Protocol for the Internet community. This document describes the Triple DES-CBC security transform for the IP Encapsulating Security Payload (ESP). This document defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1854</doc-id>
        <title>SMTP Service Extension for Command Pipelining</title>
        <author>
            <name>N. Freed</name>
        </author>
        <date>
            <month>October</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14097</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>simple mail transfer protocol</kw>
        </keywords>
        <abstract>This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2197</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1855</doc-id>
        <title>Netiquette Guidelines</title>
        <author>
            <name>S. Hambridge</name>
        </author>
        <date>
            <month>October</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46185</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>Network</kw>
            <kw>Etiquette</kw>
        </keywords>
        <abstract>This document provides a minimum set of guidelines for Network Etiquette (Netiquette) which organizations may take and adapt for their own use. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <is-also>
            <doc-id>FYI0028</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1856</doc-id>
        <title>The Opstat Client-Server Model for Statistics Retrieval</title>
        <author>
            <name>H. Clark</name>
        </author>
        <date>
            <month>September</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29954</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>tools</kw>
            <kw>performance</kw>
            <kw>utilization</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1857</doc-id>
        <title>A Model for Common Operational Statistics</title>
        <author>
            <name>M. Lambert</name>
        </author>
        <date>
            <month>October</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>55314</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>metrics</kw>
            <kw>measurements</kw>
            <kw>polling periods</kw>
        </keywords>
        <abstract>This memo describes a model for operational statistics in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document defines a model and protocol for a set of tools which could be used by NSPs and Network Operation Centers (NOCs) to share data among themselves and with customers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1404</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1858</doc-id>
        <title>Security Considerations for IP Fragment Filtering</title>
        <author>
            <name>G. Ziemba</name>
        </author>
        <author>
            <name>D. Reed</name>
        </author>
        <author>
            <name>P. Traina</name>
        </author>
        <date>
            <month>October</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20468</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>tcp</kw>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
            <kw>routers</kw>
            <kw>hosts</kw>
        </keywords>
        <abstract>IP fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts. This document describes two methods of attack as well as remedies to prevent them. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <updated-by>
            <doc-id>RFC3128</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1859</doc-id>
        <title>ISO Transport Class 2 Non-use of Explicit Flow Control over TCP RFC1006 extension</title>
        <author>
            <name>Y. Pouffary</name>
        </author>
        <date>
            <month>October</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14572</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>International</kw>
            <kw>Standard</kw>
            <kw>Organizatio</kw>
        </keywords>
        <abstract>This document is an extension to STD35, RFC1006, a standard for the Internet community. The document does not duplicate the protocol definitions contained in RFC1006 and in International Standard ISO 8073. It supplements that information with the description of how to implement ISO Transport Class 2 Non-use of Explicit Flow Control on top of TCP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1860</doc-id>
        <title>Variable Length Subnet Table For IPv4</title>
        <author>
            <name>T. Pummill</name>
        </author>
        <author>
            <name>B. Manning</name>
        </author>
        <date>
            <month>October</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5694</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>values</kw>
            <kw>IPv4</kw>
            <kw>subnets</kw>
        </keywords>
        <abstract>This document itemizes the potential values for IPv4 subnets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC1878</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1861</doc-id>
        <title>Simple Network Paging Protocol - Version 3 -Two-Way Enhanced</title>
        <author>
            <name>A. Gwinn</name>
        </author>
        <date>
            <month>October</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49181</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>SNPP</kw>
            <kw>SNPP</kw>
            <kw>wireless</kw>
            <kw>paging</kw>
        </keywords>
        <abstract>This RFC suggests a simple way for delivering wireless messages, both one and two-way, to appropriate receiving devices. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1645</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1862</doc-id>
        <title>Report of the IAB Workshop on Internet Information Infrastructure, October 12-14, 1994</title>
        <author>
            <name>M. McCahill</name>
        </author>
        <author>
            <name>J. Romkey</name>
        </author>
        <author>
            <name>M. Schwartz</name>
        </author>
        <author>
            <name>K. Sollins</name>
        </author>
        <author>
            <name>T. Verschuren</name>
        </author>
        <author>
            <name>C. Weider</name>
        </author>
        <date>
            <month>November</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>62483</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Architecture</kw>
            <kw>Board</kw>
        </keywords>
        <abstract>This document is a report on an Internet architecture workshop, initiated by the IAB and held at MCI on October 12-14, 1994. This workshop generally focused on aspects of the information infrastructure on the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1863</doc-id>
        <title>A BGP/IDRP Route Server alternative to a full mesh routing</title>
        <author>
            <name>D. Haskin</name>
        </author>
        <date>
            <month>October</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37426</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>BGP-IDRP</kw>
            <kw>border</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
            <kw>inter-domain</kw>
            <kw>routing</kw>
        </keywords>
        <abstract>This document describes the use and detailed design of Route Servers for dissemination of routing information among BGP/IDRP speaking routers. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1864</doc-id>
        <title>The Content-MD5 Header Field</title>
        <author>
            <name>J. Myers</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>October</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7216</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>CON-MD5</kw>
            <kw>MIME</kw>
            <kw>EMail</kw>
            <kw>Integrity</kw>
            <kw>MIC</kw>
            <kw>Digest</kw>
        </keywords>
        <abstract>This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1544</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1865</doc-id>
        <title>EDI Meets the Internet Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet</title>
        <author>
            <name>W. Houser</name>
        </author>
        <author>
            <name>J. Griffin</name>
        </author>
        <author>
            <name>C. Hage</name>
        </author>
        <date>
            <month>January</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>98361</char-count>
            <page-count>41</page-count>
        </format>
        <keywords>
            <kw>FAQ</kw>
        </keywords>
        <abstract>This memo is targeted towards the EDI community that is unfamiliar with the Internet, including EDI software developers, users, and service providers. The memo introduces the Internet and assumes a basic knowledge of EDI. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1866</doc-id>
        <title>Hypertext Markup Language - 2.0</title>
        <author>
            <name>T. Berners-Lee</name>
        </author>
        <author>
            <name>D. Connolly</name>
        </author>
        <date>
            <month>November</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>146904</char-count>
            <page-count>77</page-count>
        </format>
        <keywords>
            <kw>HTML</kw>
            <kw>HTML</kw>
            <kw>SGML</kw>
            <kw>Standard</kw>
            <kw>Generalized</kw>
            <kw>Language</kw>
            <kw>WWW</kw>
            <kw>World</kw>
            <kw>Wide</kw>
            <kw>Web</kw>
        </keywords>
        <abstract>This document defines a HTML 2.0 (to distinguish it from the previous informal specifications). [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2854</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1867</doc-id>
        <title>Form-based File Upload in HTML</title>
        <author>
            <name>E. Nebel</name>
        </author>
        <author>
            <name>L. Masinter</name>
        </author>
        <date>
            <month>November</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26183</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>Hypertext</kw>
            <kw>Markup</kw>
            <kw>Language</kw>
            <kw>MIME</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract>Since file-upload is a feature that will benefit many applications, this proposes an extension to HTML to allow information providers to express file upload requests uniformly, and a MIME compatible representation for file upload responses. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC2854</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1868</doc-id>
        <title>ARP Extension - UNARP</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <date>
            <month>November</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7681</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>UNARP</kw>
            <kw>Address</kw>
            <kw>Resolution</kw>
            <kw>Protocol</kw>
            <kw>delete</kw>
            <kw>entry</kw>
        </keywords>
        <abstract>This document specifies a trivial modification to the ARP mechanism, not the packet format, which allows a node to announce that it is leaving the network and that all other nodes should modify their ARP tables accordingly. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1869</doc-id>
        <title>SMTP Service Extensions</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>E. Stefferud</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>November</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23299</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>ESMTP</kw>
            <kw>Simple</kw>
            <kw>Mail</kw>
            <kw>Transfer</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1651</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2821</doc-id>
        </obsoleted-by>
        <is-also>
            <doc-id>STD0010</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1870</doc-id>
        <title>SMTP Service Extension for Message Size Declaration</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>K. Moore</name>
        </author>
        <date>
            <month>November</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18226</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>SMTP-SIZE</kw>
            <kw>Simple Mail Transfer Protocol</kw>
        </keywords>
        <abstract>This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1653</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0010</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1871</doc-id>
        <title>Addendum to RFC 1602 -- Variance Procedure</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7747</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>BCP</kw>
            <kw>WG</kw>
            <kw>escape</kw>
            <kw>clause</kw>
            <kw>procedures</kw>
        </keywords>
        <abstract>This document describes a modification to the IETF procedures to allow an escape from a situation where the existing procedures are not working or do not seem to apply. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <updates>
            <doc-id>RFC1602</doc-id>
            <doc-id>RFC1603</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0002</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1872</doc-id>
        <title>The MIME Multipart/Related Content-type</title>
        <author>
            <name>E. Levinson</name>
        </author>
        <date>
            <month>December</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15565</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract>The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. This document defines the Multipart/Related content-type and provides examples of its use. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC2112</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1873</doc-id>
        <title>Message/External-Body Content-ID Access Type</title>
        <author>
            <name>E. Levinson</name>
        </author>
        <date>
            <month>December</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5878</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>CONT-MT</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract>The existing MIME Content-Type Message/External-Body access-types allow a MIME entity (body-part) to refer to an object that is not in the message by specifying how to access that object. The Content-ID access method described in this document provides the capability to refer to an object within the message. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1874</doc-id>
        <title>SGML Media Types</title>
        <author>
            <name>E. Levinson</name>
        </author>
        <date>
            <month>December</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12515</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>SGML-MT</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract>This document proposes new media sub-types of Text/SGML and Application/SGML. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1875</doc-id>
        <title>UNINETT PCA Policy Statements</title>
        <author>
            <name>N. Berge</name>
        </author>
        <date>
            <month>December</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19089</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>Policy</kw>
            <kw>Certification</kw>
            <kw>Authority</kw>
            <kw>Encryption</kw>
        </keywords>
        <abstract>This document provides information about policy statements submitted by the UNINETT Policy Certification Authority (UNINETT PCA). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1876</doc-id>
        <title>A Means for Expressing Location Information in the Domain Name System</title>
        <author>
            <name>C. Davis</name>
        </author>
        <author>
            <name>P. Vixie</name>
        </author>
        <author>
            <name>T. Goodwin</name>
        </author>
        <author>
            <name>I. Dickinson</name>
        </author>
        <date>
            <month>January</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29631</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>DNS-LOC</kw>
            <kw>DNS</kw>
            <kw>Resource</kw>
            <kw>Record</kw>
            <kw>(RR)</kw>
            <kw>LOC</kw>
        </keywords>
        <abstract>This memo defines a new DNS RR type for experimental purposes. This RFC describes a mechanism to allow the DNS to carry location information about hosts, networks, and subnets. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1877</doc-id>
        <title>PPP Internet Protocol Control Protocol Extensions for Name Server Addresses</title>
        <author>
            <name>S. Cobb</name>
        </author>
        <date>
            <month>December</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10591</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>Network</kw>
            <kw>Control</kw>
            <kw>Domain</kw>
            <kw>System</kw>
            <kw>NetBIOS</kw>
        </keywords>
        <abstract>This document extends the NCP for establishing and configuring the Internet Protocol over PPP [2], defining the negotiation of primary and secondary Domain Name System (DNS) [3] and NetBIOS Name Server (NBNS) [4] addresses. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1878</doc-id>
        <title>Variable Length Subnet Table For IPv4</title>
        <author>
            <name>T. Pummill</name>
        </author>
        <author>
            <name>B. Manning</name>
        </author>
        <date>
            <month>December</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19414</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>values</kw>
            <kw>IPv4</kw>
            <kw>subnets</kw>
        </keywords>
        <abstract>This memo clarifies issues surrounding subnetting IP networks by providing a standard subnet table. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1860</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1879</doc-id>
        <title>Class A Subnet Experiment Results and Recommendations</title>
        <author>
            <name>B. Manning</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10589</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Registry</kw>
            <kw>Operations</kw>
        </keywords>
        <abstract>This memo documents some experiences with the RFC 1797 [1] subnet A experiment (performed by the Net39 Test Group (see credits)) and provides a number of recommendations on future direction for both the Internet Registries and the Operations community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1880</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Postel</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>89153</char-count>
            <page-count>38</page-count>
        </format>
        <keywords>
            <kw>status</kw>
            <kw>procedure</kw>
            <kw>index</kw>
        </keywords>
        <abstract>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1800</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC1920</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1881</doc-id>
        <title>IPv6 Address Allocation Management</title>
        <author>
            <name>IAB</name>
        </author>
        <author>
            <name>IESG</name>
        </author>
        <date>
            <month>December</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3215</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>IANA</kw>
            <kw>Internet</kw>
            <kw>Assigned</kw>
            <kw>Numbers</kw>
            <kw>Authority</kw>
        </keywords>
        <abstract>The IPv6 address space will be managed by the IANA for the good of the Internet community, with advice from the IAB and the IESG, by delegation to the regional registries. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1882</doc-id>
        <title>The 12-Days of Technology Before Christmas</title>
        <author>
            <name>B. Hancock</name>
        </author>
        <date>
            <month>December</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9130</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1883</doc-id>
        <title>Internet Protocol, Version 6 (IPv6) Specification</title>
        <author>
            <name>S. Deering</name>
        </author>
        <author>
            <name>R. Hinden</name>
        </author>
        <date>
            <month>December</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>82089</char-count>
            <page-count>37</page-count>
        </format>
        <keywords>
            <kw>IP</kw>
            <kw>Next</kw>
            <kw>Generation</kw>
            <kw>IPng</kw>
        </keywords>
        <abstract>This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2460</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1884</doc-id>
        <title>IP Version 6 Addressing Architecture</title>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>S. Deering</name>
            <title>Editors</title>
        </author>
        <date>
            <month>December</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37860</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>IPV6-Addr</kw>
            <kw>IP</kw>
            <kw>Next</kw>
            <kw>Generation</kw>
            <kw>IPng</kw>
        </keywords>
        <abstract>This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2373</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1885</doc-id>
        <title>Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)</title>
        <author>
            <name>A. Conta</name>
        </author>
        <author>
            <name>S. Deering</name>
        </author>
        <date>
            <month>December</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32214</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>IP</kw>
            <kw>Next</kw>
            <kw>Generation</kw>
            <kw>IPng</kw>
            <kw>Internet</kw>
            <kw>Group</kw>
            <kw>Management</kw>
            <kw>IGMP</kw>
        </keywords>
        <abstract>This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2463</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1886</doc-id>
        <title>DNS Extensions to support IP version 6</title>
        <author>
            <name>S. Thomson</name>
        </author>
        <author>
            <name>C. Huitema</name>
        </author>
        <date>
            <month>December</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6424</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>DNS-IPV6</kw>
            <kw>IP</kw>
            <kw>Next</kw>
            <kw>Generation</kw>
            <kw>IPng</kw>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
        </keywords>
        <abstract>This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3596</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC2874</doc-id>
            <doc-id>RFC3152</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1887</doc-id>
        <title>An Architecture for IPv6 Unicast Address Allocation</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>T. Li</name>
            <title>Editors</title>
        </author>
        <date>
            <month>December</month>
            <year>1995</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>66066</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>IP</kw>
            <kw>Next</kw>
            <kw>Generation</kw>
            <kw>IPng,</kw>
        </keywords>
        <abstract>This document provides an architecture for allocating IPv6 [1] unicast addresses in the Internet. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1888</doc-id>
        <title>OSI NSAPs and IPv6</title>
        <author>
            <name>J. Bound</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>D. Harrington</name>
        </author>
        <author>
            <name>J. Houldsworth</name>
        </author>
        <author>
            <name>A. Lloyd</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36469</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>Open</kw>
            <kw>Systems</kw>
            <kw>Interconnection</kw>
        </keywords>
        <abstract>This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IPv6, should redesign a native IPv6 addressing plan to meet their needs. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <notes>made historic by rfc4048.</notes>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1889</doc-id>
        <title>RTP: A Transport Protocol for Real-Time Applications</title>
        <author>
            <name>Audio-Video Transport Working Group</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>S. Casner</name>
        </author>
        <author>
            <name>R. Frederick</name>
        </author>
        <author>
            <name>V. Jacobson</name>
        </author>
        <date>
            <month>January</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>188544</char-count>
            <page-count>75</page-count>
        </format>
        <keywords>
            <kw>RTP</kw>
            <kw>end-to-end</kw>
            <kw>network</kw>
            <kw>audio</kw>
            <kw>video</kw>
            <kw>RTCP</kw>
        </keywords>
        <abstract>This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3550</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1890</doc-id>
        <title>RTP Profile for Audio and Video Conferences with Minimal Control</title>
        <author>
            <name>Audio-Video Transport Working Group</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>January</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37509</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>RTP-AV</kw>
            <kw>end-to-end</kw>
            <kw>network</kw>
            <kw>conference</kw>
        </keywords>
        <abstract>This memo describes a profile for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3551</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1891</doc-id>
        <title>SMTP Service Extension for Delivery Status Notifications</title>
        <author>
            <name>K. Moore</name>
        </author>
        <date>
            <month>January</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>65192</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>SMTP-DSN</kw>
            <kw>simple</kw>
            <kw>mail</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo defines an extension to the SMTP service, which allows an SMTP client to specify (a) that delivery status notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3461</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1892</doc-id>
        <title>The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages</title>
        <author>
            <name>G. Vaudreuil</name>
        </author>
        <date>
            <month>January</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7800</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>MIME-RPT</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract>The Multipart/Report MIME content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3462</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1893</doc-id>
        <title>Enhanced Mail System Status Codes</title>
        <author>
            <name>G. Vaudreuil</name>
        </author>
        <date>
            <month>January</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28218</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>EMS-CODE</kw>
            <kw>simple</kw>
            <kw>mail</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>SMTP</kw>
        </keywords>
        <abstract>There currently is not a standard mechanism for the reporting of mail system errors except for the limited set offered by SMTP and the system specific text descriptions sent in mail messages. There is a pressing need for a rich machine readable status code for use in delivery status notifications [DSN]. This document proposes a new set of status codes for this purpose. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3463</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1894</doc-id>
        <title>An Extensible Message Format for Delivery Status Notifications</title>
        <author>
            <name>K. Moore</name>
        </author>
        <author>
            <name>G. Vaudreuil</name>
        </author>
        <date>
            <month>January</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>77462</char-count>
            <page-count>39</page-count>
        </format>
        <keywords>
            <kw>DSN</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
            <kw>Content</kw>
            <kw>Type</kw>
        </keywords>
        <abstract>This memo defines a MIME content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3464</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC2852</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1895</doc-id>
        <title>The Application/CALS-1840 Content-type</title>
        <author>
            <name>E. Levinson</name>
        </author>
        <date>
            <month>February</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10576</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>MIL-STD-1840</kw>
            <kw>MIME</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract>This memorandum provides guidelines for using the United States Department of Defense Military Standard MIL-STD-1840, "Automated Interchange of Technical Information," with the Internet electronic mail standards, RFC 822 and RFC 1521. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1896</doc-id>
        <title>The text/enriched MIME Content-type</title>
        <author>
            <name>P. Resnick</name>
        </author>
        <author>
            <name>A. Walker</name>
        </author>
        <date>
            <month>February</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45926</char-count>
            <page-count>21</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>81217</char-count>
        </format>
        <keywords>
            <kw>MIME</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract>This document defines one particular type of MIME data, the text/enriched MIME type. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1523</doc-id>
            <doc-id>RFC1563</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1897</doc-id>
        <title>IPv6 Testing Address Allocation</title>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>January</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6643</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>prototype</kw>
            <kw>software</kw>
        </keywords>
        <abstract>This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This document specifies an Experimental protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC2471</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1898</doc-id>
        <title>CyberCash Credit Card Protocol Version 0.8</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>B. Boesch</name>
        </author>
        <author>
            <name>S. Crocker</name>
        </author>
        <author>
            <name>M. Yesil</name>
        </author>
        <date>
            <month>February</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>113633</char-count>
            <page-count>52</page-count>
        </format>
        <keywords>
            <kw>general</kw>
            <kw>payments</kw>
            <kw>system</kw>
        </keywords>
        <abstract>This document covers only the current CyberCash system which is one of the few operational systems in the rapidly evolving area of Internet payments. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1899</doc-id>
        <title>Request for Comments Summary RFC Numbers 1800-1899</title>
        <author>
            <name>J. Elliott</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37984</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>Index</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1900</doc-id>
        <title>Renumbering Needs Work</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>February</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9528</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>IP</kw>
            <kw>network</kw>
            <kw>number</kw>
            <kw>addressing</kw>
        </keywords>
        <abstract>Hosts in an IP network are identified by IP addresses, and the IP address prefixes of subnets are advertised by routing protocols. A change in such IP addressing information associated with a host or subnet is known as "renumbering". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1901</doc-id>
        <title>Introduction to Community-based SNMPv2</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>January</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15903</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>SNMPV2CB</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version</kw>
            <kw>2</kw>
        </keywords>
        <abstract>The purpose of this document is to define the Community-based Administrative Framework for the SNMP version 2 framework (SNMPv2). This document specifies an Experimental protocol for the Internet community. </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1902</doc-id>
        <title>Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>January</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>77453</char-count>
            <page-count>40</page-count>
        </format>
        <keywords>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version</kw>
            <kw>2</kw>
        </keywords>
        <abstract>It is the purpose of this document, the Structure of Management Information (SMI), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1442</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2578</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1903</doc-id>
        <title>Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>January</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52652</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version</kw>
            <kw>2</kw>
        </keywords>
        <abstract>It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1443</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2579</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1904</doc-id>
        <title>Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>January</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47083</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version</kw>
            <kw>2</kw>
        </keywords>
        <abstract>It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1444</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2580</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1905</doc-id>
        <title>Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>January</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>55526</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>OPS-MIB</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version</kw>
            <kw>2</kw>
        </keywords>
        <abstract>It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1448</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3416</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1906</doc-id>
        <title>Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2) </title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>January</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27465</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>TRANS-MIB</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version</kw>
            <kw>2</kw>
        </keywords>
        <abstract>It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1449</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3417</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1907</doc-id>
        <title>Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>January</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34881</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>SNMPv2-MIB</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version</kw>
            <kw>2</kw>
        </keywords>
        <abstract>It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1450</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3418</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1908</doc-id>
        <title>Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework </title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>January</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21463</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>COEX-MIB</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version</kw>
            <kw>2</kw>
        </keywords>
        <abstract>The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework [1-6], termed the SNMP version 2 framework (SNMPv2), and the original Internet- standard Network Management Framework (SNMPv1&gt;. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1452</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2576</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1909</doc-id>
        <title>An Administrative Infrastructure for SNMPv2</title>
        <author>
            <name>K. McCloghrie</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45773</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>SNMPV2AI</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version</kw>
            <kw>2</kw>
        </keywords>
        <abstract>It is the purpose of this document, An Administrative Infrastructure for SNMPv2, to define an administrative framework which realizes effective management in a variety of configurations and environments. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1910</doc-id>
        <title>User-based Security Model for SNMPv2</title>
        <author>
            <name>G. Waters</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>98252</char-count>
            <page-count>44</page-count>
        </format>
        <keywords>
            <kw>SNMPV2SM</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version</kw>
            <kw>2</kw>
        </keywords>
        <abstract>In this administrative framework, a security model defines the mechanisms used to achieve an administratively-defined level of security for protocol interactions. Although many such security models might be defined, it is the purpose of this document, User-based Security Model for SNMPv2, to define the first, and, as of this writing, only, security model for this administrative framework. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1911</doc-id>
        <title>Voice Profile for Internet Mail</title>
        <author>
            <name>G. Vaudreuil</name>
        </author>
        <date>
            <month>February</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>50242</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>MIME</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
            <kw>ESMTP</kw>
            <kw>SMTP</kw>
            <kw>Service</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract>The following document is a profile of the Internet standard MIME and ESMTP protocols for use as a digital voice networking protocol. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC2421</doc-id>
            <doc-id>RFC2422</doc-id>
            <doc-id>RFC2423</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1912</doc-id>
        <title>Common DNS Operational and Configuration Errors</title>
        <author>
            <name>D. Barr</name>
        </author>
        <date>
            <month>February</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38252</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
        </keywords>
        <abstract>This memo describes errors often found in both the operation of Domain Name System (DNS) servers, and in the data that these DNS servers contain. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1537</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1913</doc-id>
        <title>Architecture of the Whois++ Index Service</title>
        <author>
            <name>C. Weider</name>
        </author>
        <author>
            <name>J. Fullton</name>
        </author>
        <author>
            <name>S. Spero</name>
        </author>
        <date>
            <month>February</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33743</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>WHOIS++A</kw>
            <kw>Bunyip Information Systems</kw>
            <kw>Inc.</kw>
            <kw>MCNC Center for Communications</kw>
        </keywords>
        <abstract>The authors describe an architecture for indexing in distributed databases, and apply this to the WHOIS++ protocol. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1914</doc-id>
        <title>How to Interact with a Whois++ Mesh</title>
        <author>
            <name>P. Faltstrom</name>
        </author>
        <author>
            <name>R. Schoultz</name>
        </author>
        <author>
            <name>C. Weider</name>
        </author>
        <date>
            <month>February</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17842</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>WHOIS++M</kw>
            <kw>distributed</kw>
            <kw>databases</kw>
            <kw>directory</kw>
            <kw>service</kw>
        </keywords>
        <abstract>In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is done by the client, since each server 'refers' the client to the next appropriate server(s). [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1915</doc-id>
        <title>Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol</title>
        <author>
            <name>F. Kastenholz</name>
        </author>
        <date>
            <month>February</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14347</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>Point</kw>
            <kw>to</kw>
            <kw>Point</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>The PPP Working group has developed two protocols, one to control compression on PPP links; the Compression Control Protocol (CCP), documented in draft-ietf-pppext-compression-04.txt. The second is the Encryption Control Protocol (ECP), used to control encryption on serial links, documented in draft-ietf-pppext-encryption-03.txt. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <notes>Document had been mis-titled Connection Control Protocol.</notes>
        <is-also>
            <doc-id>BCP0003</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1916</doc-id>
        <title>Enterprise Renumbering: Experience and Information Solicitation</title>
        <author>
            <name>H. Berkowitz</name>
        </author>
        <author>
            <name>P. Ferguson</name>
        </author>
        <author>
            <name>W. Leland</name>
        </author>
        <author>
            <name>P. Nesser</name>
        </author>
        <date>
            <month>February</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16117</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>tools</kw>
            <kw>applications</kw>
        </keywords>
        <abstract>Because of the urgent need for, and substantial difficulty in, renumbering IP networks, the PIER working group is compiling a series of documents to assist sites in their renumbering efforts. The intent of these documents is to provide both educational and practical information to the Internet community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1917</doc-id>
        <title>An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA</title>
        <author>
            <name>P. Nesser II</name>
        </author>
        <date>
            <month>February</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23623</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>address</kw>
            <kw>space</kw>
            <kw>Internet</kw>
            <kw>Assigned</kw>
            <kw>Numbers</kw>
            <kw>Authority</kw>
            <kw>IANA</kw>
        </keywords>
        <abstract>This document is an appeal to the Internet community to return unused address space, i.e. any block of consecutive IP prefixes, to the Internet Assigned Numbers Authority (IANA) or any of the delegated registries, for reapportionment. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <is-also>
            <doc-id>BCP0004</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1918</doc-id>
        <title>Address Allocation for Private Internets</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>B. Moskowitz</name>
        </author>
        <author>
            <name>D. Karrenberg</name>
        </author>
        <author>
            <name>G. J. de Groot</name>
        </author>
        <author>
            <name>E. Lear</name>
        </author>
        <date>
            <month>February</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22270</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>TCP/IP</kw>
            <kw>network</kw>
            <kw>host</kw>
        </keywords>
        <abstract>This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <obsoletes>
            <doc-id>RFC1627</doc-id>
            <doc-id>RFC1597</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0005</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1919</doc-id>
        <title>Classical versus Transparent IP Proxies</title>
        <author>
            <name>M. Chatel</name>
        </author>
        <date>
            <month>March</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>87374</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
            <kw>firewalls</kw>
            <kw>security</kw>
        </keywords>
        <abstract>This document explains "classical" and "transparent" proxy techniques and attempts to provide rules to help determine when each proxy system may be used without causing problems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1920</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>March</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>91936</char-count>
            <page-count>40</page-count>
        </format>
        <keywords>
            <kw>status</kw>
            <kw>procedure</kw>
            <kw>index</kw>
        </keywords>
        <abstract>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1880</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2000</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1921</doc-id>
        <title>TNVIP Protocol</title>
        <author>
            <name>J. Dujonc</name>
        </author>
        <date>
            <month>March</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>57475</char-count>
            <page-count>30</page-count>
        </format>
        <abstract>The goal of this document specifies a Telnet profile to support VIP terminal emulation allowing the access to the BULL hosts applications through a TCP/IP network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1922</doc-id>
        <title>Chinese Character Encoding for Internet Messages</title>
        <author>
            <name>HF. Zhu</name>
        </author>
        <author>
            <name>DY. Hu</name>
        </author>
        <author>
            <name>ZG. Wang</name>
        </author>
        <author>
            <name>TC. Kao</name>
        </author>
        <author>
            <name>WCH. Chang</name>
        </author>
        <author>
            <name>M. Crispin</name>
        </author>
        <date>
            <month>March</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>50995</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>transport</kw>
            <kw>electronic</kw>
            <kw>mail</kw>
            <kw>telnet</kw>
            <kw>WWW</kw>
        </keywords>
        <abstract>This memo describes methods of transporting Chinese characters in Internet services which transport text, such as electronic mail [RFC-822], network news [RFC-1036], telnet [RFC-854] and the World Wide Web [RFC-1866]. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1923</doc-id>
        <title>RIPv1 Applicability Statement for Historic Status</title>
        <author>
            <name>J. Halpern</name>
        </author>
        <author>
            <name>S. Bradner</name>
        </author>
        <date>
            <month>March</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5560</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>Routing</kw>
            <kw>Information</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>RIP Version 1 [RFC-1058] has been declared an historic document. This Applicability statement provides the supporting motivation for that declaration. The primary reason, as described below, is the Classful nature of RIPv1. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1924</doc-id>
        <title>A Compact Representation of IPv6 Addresses</title>
        <author>
            <name>R. Elz</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10409</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>encoding</kw>
        </keywords>
        <abstract>This document specifies a more compact representation of IPv6 addresses, which permits encoding in a mere 20 bytes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1925</doc-id>
        <title>The Twelve Networking Truths</title>
        <author>
            <name>R. Callon</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4294</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>fundamentals</kw>
        </keywords>
        <abstract>This memo documents the fundamental truths of networking for the Internet community. This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1926</doc-id>
        <title>An Experimental Encapsulation of IP Datagrams on Top of ATM</title>
        <author>
            <name>J. Eriksson</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2969</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>Acoustical</kw>
            <kw>Transmission</kw>
            <kw>Media (ATM)</kw>
        </keywords>
        <abstract>This RFC describes a method of encapsulating IP datagrams on top of Acoustical Transmission Media (ATM). This is a non-recommended standard. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1927</doc-id>
        <title>Suggested Additional MIME Types for Associating Documents</title>
        <author>
            <name>C. Rogers</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5254</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>media-type</kw>
        </keywords>
        <abstract>Seven new types of MIME types are suggested in this document. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1928</doc-id>
        <title>SOCKS Protocol Version 5</title>
        <author>
            <name>M. Leech</name>
        </author>
        <author>
            <name>M. Ganis</name>
        </author>
        <author>
            <name>Y. Lee</name>
        </author>
        <author>
            <name>R. Kuris</name>
        </author>
        <author>
            <name>D. Koblas</name>
        </author>
        <author>
            <name>L. Jones</name>
        </author>
        <date>
            <month>March</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19741</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>SOCKSV5</kw>
            <kw>firewalls</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1929</doc-id>
        <title>Username/Password Authentication for SOCKS V5</title>
        <author>
            <name>M. Leech</name>
        </author>
        <date>
            <month>March</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3568</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>AUTH-SOCKS</kw>
            <kw>firewalls</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial socks connection setup. This document describes one of those protocols, as it fits into the SOCKS Version 5 authentication "subnegotiation". [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1930</doc-id>
        <title>Guidelines for creation, selection, and registration of an Autonomous System (AS)</title>
        <author>
            <name>J. Hawkinson</name>
        </author>
        <author>
            <name>T. Bates</name>
        </author>
        <date>
            <month>March</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22073</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>routing</kw>
            <kw>policy</kw>
            <kw>Exterior</kw>
            <kw>Gateway</kw>
            <kw>Protocol</kw>
            <kw>Border</kw>
            <kw>Inter-Domain</kw>
            <kw>Domain</kw>
            <kw>Identifier</kw>
            <kw>EGP</kw>
            <kw>BGP</kw>
            <kw>IDRP</kw>
        </keywords>
        <abstract>This memo discusses when it is appropriate to register and utilize an Autonomous System (AS), and lists criteria for such. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <is-also>
            <doc-id>BCP0006</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1931</doc-id>
        <title>Dynamic RARP Extensions for Automatic Network Address Acquisition</title>
        <author>
            <name>D. Brownell</name>
        </author>
        <date>
            <month>April</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27544</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>Reverse</kw>
            <kw>Address</kw>
            <kw>Resolution</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This memo describes extensions to the Reverse Address Resolution Protocol (RARP [2]) and called Dynamic RARP (DRARP, pronounced D-RARP). This memo provides information for the Internet community. This memo does not define an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1932</doc-id>
        <title>IP over ATM: A Framework Document</title>
        <author>
            <name>R. Cole</name>
        </author>
        <author>
            <name>D. Shur</name>
        </author>
        <author>
            <name>C. Villamizar</name>
        </author>
        <date>
            <month>April</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>68031</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>end-to-end</kw>
            <kw>connectivity</kw>
        </keywords>
        <abstract>It is hoped that this document, in classifying ATM approaches and issues will help to focus the IP over ATM working group's direction.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1933</doc-id>
        <title>Transition Mechanisms for IPv6 Hosts and Routers</title>
        <author>
            <name>R. Gilligan</name>
        </author>
        <author>
            <name>E. Nordmark</name>
        </author>
        <date>
            <month>April</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47005</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>TRANS-IPV6</kw>
            <kw>IPv4</kw>
        </keywords>
        <abstract>This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2893</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1934</doc-id>
        <title>Ascend's Multilink Protocol Plus (MP+)</title>
        <author>
            <name>K. Smith</name>
        </author>
        <date>
            <month>April</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>87072</char-count>
            <page-count>47</page-count>
        </format>
        <keywords>
            <kw>PPP</kw>
        </keywords>
        <abstract>This document proposes an extension to the PPP Multilink Protocol (MP) [1]. Multilink Protocol Plus (MP+) is a new control protocol for managing multiple data links that are bundled by MP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1935</doc-id>
        <title>What is the Internet, Anyway?</title>
        <author>
            <name>J. Quarterman</name>
        </author>
        <author>
            <name>S. Carl-Mitchell</name>
        </author>
        <date>
            <month>April</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30369</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>information</kw>
            <kw>tutorial</kw>
        </keywords>
        <abstract>This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1936</doc-id>
        <title>Implementing the Internet Checksum in Hardware</title>
        <author>
            <name>J. Touch</name>
        </author>
        <author>
            <name>B. Parham</name>
        </author>
        <date>
            <month>April</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36618</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>PLD</kw>
            <kw>code</kw>
            <kw>UDP</kw>
            <kw>TCP</kw>
        </keywords>
        <abstract>This memo presents a techniques for efficiently implementing the Internet Checksum in hardware. It includes PLD code for programming a single, low cost part to perform checksumming at 1.26 Gbps. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1937</doc-id>
        <title>"Local/Remote" Forwarding Decision in Switched Data Link Subnetworks</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>D. Kandlur</name>
        </author>
        <date>
            <month>May</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18302</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>IP</kw>
            <kw>subnet</kw>
        </keywords>
        <abstract>This document describes extensions to the IP architecture that relaxes these constraints, thus enabling the full utilization of the services provided by SVC-based Data Link subnetworks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1938</doc-id>
        <title>A One-Time Password System</title>
        <author>
            <name>N. Haller</name>
        </author>
        <author>
            <name>C. Metz</name>
        </author>
        <date>
            <month>May</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44844</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>OTP</kw>
            <kw>authentication</kw>
            <kw>S/KEY</kw>
        </keywords>
        <abstract>This document describes a one-time password authentication system (OTP). [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2289</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1939</doc-id>
        <title>Post Office Protocol - Version 3</title>
        <author>
            <name>J. Myers</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>May</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47018</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>POP3</kw>
            <kw>POP3</kw>
        </keywords>
        <abstract>The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1725</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC1957</doc-id>
            <doc-id>RFC2449</doc-id>
        </updated-by>
        <is-also>
            <doc-id>STD0053</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1940</doc-id>
        <title>Source Demand Routing: Packet Format and Forwarding Specification (Version 1)</title>
        <author>
            <name>D. Estrin</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>K. Varadhan</name>
        </author>
        <author>
            <name>D. Zappala</name>
        </author>
        <date>
            <month>May</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>60858</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>SDRP</kw>
        </keywords>
        <abstract>The purpose of SDRP is to support source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter-domain and intra-domain routes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1941</doc-id>
        <title>Frequently Asked Questions for Schools</title>
        <author>
            <name>J. Sellers</name>
        </author>
        <author>
            <name>J. Robichaux</name>
        </author>
        <date>
            <month>May</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>150980</char-count>
            <page-count>70</page-count>
        </format>
        <keywords>
            <kw>FAQ</kw>
            <kw>Internet</kw>
            <kw>Education</kw>
        </keywords>
        <abstract>The goal of this FYI document, produced by the Internet School Networking (ISN) group in the User Services Area of the Internet Engineering Task Force (IETF), is to act as an introduction to the Internet for faculty, administration, and other school personnel in primary and secondary schools. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1578</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>FYI0022</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1942</doc-id>
        <title>HTML Tables</title>
        <author>
            <name>D. Raggett</name>
        </author>
        <date>
            <month>May</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>68705</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>HTML-TBL</kw>
            <kw>HyperText</kw>
            <kw>Markup</kw>
            <kw>Language</kw>
            <kw>SGML</kw>
        </keywords>
        <abstract>This specification extends HTML to support a wide variety of tables. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC2854</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1943</doc-id>
        <title>Building an X.500 Directory Service in the US</title>
        <author>
            <name>B. Jennings</name>
        </author>
        <date>
            <month>May</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51266</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>White</kw>
            <kw>Pages</kw>
        </keywords>
        <abstract>This document provides definition and recommends considerations that must be undertaken to operate a X.500 Directory Service in the United States. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1944</doc-id>
        <title>Benchmarking Methodology for Network Interconnect Devices</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <author>
            <name>J. McQuaid</name>
        </author>
        <date>
            <month>May</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>66061</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>testing</kw>
            <kw>performance</kw>
        </keywords>
        <abstract>This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC2544</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1945</doc-id>
        <title>Hypertext Transfer Protocol -- HTTP/1.0</title>
        <author>
            <name>T. Berners-Lee</name>
        </author>
        <author>
            <name>R. Fielding</name>
        </author>
        <author>
            <name>H. Frystyk</name>
        </author>
        <date>
            <month>May</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>137582</char-count>
            <page-count>60</page-count>
        </format>
        <keywords>
            <kw>HTTP-1.0</kw>
            <kw>HTTP</kw>
            <kw>World-Wide</kw>
            <kw>Web</kw>
            <kw>application</kw>
        </keywords>
        <abstract>The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1946</doc-id>
        <title>Native ATM Support for ST2+</title>
        <author>
            <name>S. Jackowski</name>
        </author>
        <date>
            <month>May</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>50430</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>integrated</kw>
            <kw>services</kw>
            <kw>ATM</kw>
            <kw>Quality</kw>
            <kw>of</kw>
            <kw>Service</kw>
            <kw>QoS</kw>
        </keywords>
        <abstract>This memo describes a working implementation which enables applications to directly invoke ATM services in the following environments: ATM to internet, internet to ATM, and internet to internet across ATM. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1947</doc-id>
        <title>Greek Character Encoding for Electronic Mail Messages</title>
        <author>
            <name>D. Spinellis</name>
        </author>
        <date>
            <month>May</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14428</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>character</kw>
            <kw>set</kw>
            <kw>ISO</kw>
            <kw>MIME</kw>
        </keywords>
        <abstract>This document describes a standard encoding for electronic mail [RFC822] containing Greek text and provides implementation guide-lines. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1948</doc-id>
        <title>Defending Against Sequence Number Attacks</title>
        <author>
            <name>S. Bellovin</name>
        </author>
        <date>
            <month>May</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13074</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>crypgraphic</kw>
            <kw>authentication</kw>
            <kw>spoofing</kw>
        </keywords>
        <abstract>IP spoofing attacks based on sequence number spoofing have become a serious threat on the Internet (CERT Advisory CA-95:01). While ubiquitous crypgraphic authentication is the right answer, we propose a simple modification to TCP implementations that should be a very substantial block to the current wave of attacks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1949</doc-id>
        <title>Scalable Multicast Key Distribution</title>
        <author>
            <name>A. Ballardie</name>
        </author>
        <date>
            <month>May</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41853</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>SMKD</kw>
            <kw>MBONE</kw>
            <kw>security</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This memo provides a scalable solution to the multicast key distribution problem. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1950</doc-id>
        <title>ZLIB Compressed Data Format Specification version 3.3</title>
        <author>
            <name>P. Deutsch</name>
        </author>
        <author>
            <name>J-L. Gailly</name>
        </author>
        <date>
            <month>May</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20502</char-count>
            <page-count>11</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>37768</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>36393</char-count>
        </format>
        <keywords>
            <kw>ZLIB</kw>
            <kw>compressed</kw>
            <kw>data</kw>
            <kw>format</kw>
            <kw>checksum</kw>
        </keywords>
        <abstract>This specification defines a lossless compressed data format. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1951</doc-id>
        <title>DEFLATE Compressed Data Format Specification version 1.3</title>
        <author>
            <name>P. Deutsch</name>
        </author>
        <date>
            <month>May</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36944</char-count>
            <page-count>17</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>57408</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>56620</char-count>
        </format>
        <keywords>
            <kw>DEFLATE</kw>
            <kw>compressed</kw>
            <kw>data</kw>
            <kw>format</kw>
            <kw>coding</kw>
        </keywords>
        <abstract>This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1952</doc-id>
        <title>GZIP file format specification version 4.3</title>
        <author>
            <name>P. Deutsch</name>
        </author>
        <date>
            <month>May</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25036</char-count>
            <page-count>12</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>43337</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>43211</char-count>
        </format>
        <keywords>
            <kw>GZIP</kw>
            <kw>compressed</kw>
            <kw>data</kw>
            <kw>format</kw>
            <kw>redundancy</kw>
            <kw>check</kw>
        </keywords>
        <abstract>This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1953</doc-id>
        <title>Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0</title>
        <author>
            <name>P. Newman</name>
        </author>
        <author>
            <name>W. Edwards</name>
        </author>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>E. Hoffman</name>
        </author>
        <author>
            <name>F. Ching Liaw</name>
        </author>
        <author>
            <name>T. Lyon</name>
        </author>
        <author>
            <name>G. Minshall</name>
        </author>
        <date>
            <month>May</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43749</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>IFMP</kw>
            <kw>IP</kw>
            <kw>flow</kw>
            <kw>routing</kw>
            <kw>information</kw>
        </keywords>
        <abstract>The Ipsilon Flow Management Protocol (IFMP), is a protocol for allowing a node to instruct an adjacent node to attach a layer 2 label to a specified IP flow. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1954</doc-id>
        <title>Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0</title>
        <author>
            <name>P. Newman</name>
        </author>
        <author>
            <name>W. Edwards</name>
        </author>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>E. Hoffman</name>
        </author>
        <author>
            <name>F. Ching Liaw</name>
        </author>
        <author>
            <name>T. Lyon</name>
        </author>
        <author>
            <name>G. Minshall</name>
        </author>
        <date>
            <month>May</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16075</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>datagrams</kw>
            <kw>IFMP</kw>
        </keywords>
        <abstract>This document specifies the manner for transmitting IPv4 datagrams over an ATM data link, both in a default manner and in the presence of flow labelling via Ipsilon Flow Management Protocol [IFMP]. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1955</doc-id>
        <title>New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG</title>
        <author>
            <name>R. Hinden</name>
        </author>
        <date>
            <month>June</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10115</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>IPNG</kw>
            <kw>addressing</kw>
            <kw>routing</kw>
        </keywords>
        <abstract>This paper proposes a new scheme which I believe is a good medium term solution to the routing and address problems of the internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1956</doc-id>
        <title>Registration in the MIL Domain</title>
        <author>
            <name>D. Engebretson</name>
        </author>
        <author>
            <name>R. Plzak</name>
        </author>
        <date>
            <month>June</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2923</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>DoD</kw>
            <kw>Department</kw>
            <kw>of</kw>
            <kw>Defense</kw>
        </keywords>
        <abstract>This RFC describes the policy for the registration of second level domains under the ".MIL" domain. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1957</doc-id>
        <title>Some Observations on Implementations of the Post Office Protocol (POP3)</title>
        <author>
            <name>R. Nelson</name>
        </author>
        <date>
            <month>June</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>2325</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>client</kw>
            <kw>server</kw>
        </keywords>
        <abstract>This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <updates>
            <doc-id>RFC1939</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1958</doc-id>
        <title>Architectural Principles of the Internet</title>
        <author>
            <name>B. Carpenter</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17345</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>IAB</kw>
        </keywords>
        <abstract>The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan. While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture. This is intended for general guidance and general interest, and is in no way intended to be a formal or invariant reference model. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <updated-by>
            <doc-id>RFC3439</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1959</doc-id>
        <title>An LDAP URL Format</title>
        <author>
            <name>T. Howes</name>
        </author>
        <author>
            <name>M. Smith</name>
        </author>
        <date>
            <month>June</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7243</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>LDAP-URL</kw>
            <kw>Lightweight</kw>
            <kw>Directory</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
            <kw>Uniform</kw>
            <kw>Resource</kw>
            <kw>Locator</kw>
        </keywords>
        <abstract>This document describes a format for an LDAP Uniform Resource Locator which will allow Internet clients to have direct access to the LDAP protocol. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2255</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1960</doc-id>
        <title>A String Representation of LDAP Search Filters</title>
        <author>
            <name>T. Howes</name>
        </author>
        <date>
            <month>June</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5288</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>LDAP-STR</kw>
            <kw>Lightweight</kw>
            <kw>Directory</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1558</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2254</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1961</doc-id>
        <title>GSS-API Authentication Method for SOCKS Version 5</title>
        <author>
            <name>P. McMahon</name>
        </author>
        <date>
            <month>June</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16036</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>GSSAPI-SOC</kw>
            <kw>Generic</kw>
            <kw>Security</kw>
            <kw>Service</kw>
            <kw>Application</kw>
            <kw>Program</kw>
            <kw>Interface</kw>
        </keywords>
        <abstract>This document provides the specification for the SOCKS V5 GSS-API authentication protocol, and defines a GSS-API-based encapsulation for provision of integrity, authentication and optional confidentiality. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1962</doc-id>
        <title>The PPP Compression Control Protocol (CCP)</title>
        <author>
            <name>D. Rand</name>
        </author>
        <date>
            <month>June</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18005</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>PPP-CCP</kw>
            <kw>point-to-point</kw>
            <kw>protocol</kw>
            <kw>data</kw>
            <kw>links</kw>
        </keywords>
        <abstract>This document defines a method for negotiating data compression over PPP links. [STANDARDS-TRACK] </abstract>
        <updated-by>
            <doc-id>RFC2153</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1963</doc-id>
        <title>PPP Serial Data Transport Protocol (SDTP)</title>
        <author>
            <name>K. Schneider</name>
        </author>
        <author>
            <name>S. Venters</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38185</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document describes a new Network level protocol (from the PPP point of view), PPP Serial Data Transport Protocol, that provides encapsulation and an associated control protocol for transporting serial data streams over a PPP link. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1964</doc-id>
        <title>The Kerberos Version 5 GSS-API Mechanism</title>
        <author>
            <name>J. Linn</name>
        </author>
        <date>
            <month>June</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47413</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>GSSAPI-KER</kw>
            <kw>Generic</kw>
            <kw>Security</kw>
            <kw>Service</kw>
            <kw>Application</kw>
            <kw>Program</kw>
            <kw>Interface</kw>
        </keywords>
        <abstract>This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using Kerberos Version 5 technology (as specified in RFC 1510). [STANDARDS- TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1965</doc-id>
        <title>Autonomous System Confederations for BGP</title>
        <author>
            <name>P. Traina</name>
        </author>
        <date>
            <month>June</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13575</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>BGP-ASC</kw>
            <kw>Border</kw>
            <kw>Gateway</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document describes an extension to BGP which may be used to create a confederation of autonomous systems which is represented as one single autonomous system to BGP peers external to the confederation. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC3065</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1966</doc-id>
        <title>BGP Route Reflection An alternative to full mesh IBGP</title>
        <author>
            <name>T. Bates</name>
        </author>
        <author>
            <name>R. Chandra</name>
        </author>
        <date>
            <month>June</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14320</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>BGP-RR</kw>
            <kw>Border</kw>
            <kw>Gateway</kw>
            <kw>Protocol</kw>
            <kw>autonomous</kw>
            <kw>system</kw>
        </keywords>
        <abstract>This document describes the use and design of a method known as "Route Reflection" to alleviate the the need for "full mesh" IBGP. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <updated-by>
            <doc-id>RFC2796</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1967</doc-id>
        <title>PPP LZS-DCP Compression Protocol (LZS-DCP)</title>
        <author>
            <name>K. Schneider</name>
        </author>
        <author>
            <name>R. Friend</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40039</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>Compression</kw>
            <kw>Control</kw>
            <kw>CCP</kw>
        </keywords>
        <abstract>This document describes the use of the Stac LZS data compression algorithm for compressing PPP encapsulated packets, using a DCP header [6]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1968</doc-id>
        <title>The PPP Encryption Control Protocol (ECP)</title>
        <author>
            <name>G. Meyer</name>
        </author>
        <date>
            <month>June</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20781</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>PPP-ECP</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>data</kw>
        </keywords>
        <abstract>This document defines a method for negotiating data encryption over PPP links. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1969</doc-id>
        <title>The PPP DES Encryption Protocol (DESE)</title>
        <author>
            <name>K. Sklower</name>
        </author>
        <author>
            <name>G. Meyer</name>
        </author>
        <date>
            <month>June</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20383</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>encapsulated</kw>
            <kw>packets</kw>
        </keywords>
        <abstract>This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC2419</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1970</doc-id>
        <title>Neighbor Discovery for IP Version 6 (IPv6)</title>
        <author>
            <name>T. Narten</name>
        </author>
        <author>
            <name>E. Nordmark</name>
        </author>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>197632</char-count>
            <page-count>82</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document specifies the Neighbor Discovery protocol for IP Version 6. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2461</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1971</doc-id>
        <title>IPv6 Stateless Address Autoconfiguration</title>
        <author>
            <name>S. Thomson</name>
        </author>
        <author>
            <name>T. Narten</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>56890</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>link-local</kw>
            <kw>address</kw>
            <kw>Duplicate</kw>
            <kw>Address</kw>
            <kw>Detection</kw>
            <kw>procedure</kw>
        </keywords>
        <abstract>This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2462</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1972</doc-id>
        <title>A Method for the Transmission of IPv6 Packets over Ethernet Networks</title>
        <author>
            <name>M. Crawford</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6353</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>IPV6-ETHER</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>frame</kw>
            <kw>format</kw>
            <kw>transmission</kw>
        </keywords>
        <abstract>This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on Ethernet networks. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2464</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1973</doc-id>
        <title>PPP in Frame Relay</title>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>June</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14780</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>PPP-FRAME</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>encapsulated</kw>
            <kw>packets</kw>
        </keywords>
        <abstract>This document describes the use of Frame Relay for framing PPP encapsulated packets. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1974</doc-id>
        <title>PPP Stac LZS Compression Protocol</title>
        <author>
            <name>R. Friend</name>
        </author>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45267</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>PPP-STAC</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>Compression</kw>
            <kw>Control</kw>
            <kw>CCP</kw>
        </keywords>
        <abstract>This document describes the use of the Stac LZS data compression algorithm, with single or multiple compression histories, for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1975</doc-id>
        <title>PPP Magnalink Variable Resource Compression</title>
        <author>
            <name>D. Schremp</name>
        </author>
        <author>
            <name>J. Black</name>
        </author>
        <author>
            <name>J. Weiss</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8655</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>PPP-MAG</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>MVRCA</kw>
        </keywords>
        <abstract>The Magnalink Variable Resource Compression Algorithm (MVRCA) allows a wide range of interoperable compression implementations whose performance characteristics are a function of available CPU and memory resources. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1976</doc-id>
        <title>PPP for Data Compression in Data Circuit-Terminating Equipment (DCE)</title>
        <author>
            <name>K. Schneider</name>
        </author>
        <author>
            <name>S. Venters</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19781</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>PPP-DCE</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>LCP</kw>
            <kw>extension</kw>
        </keywords>
        <abstract>This document defines a specific set of parameters for these protocols and an LCP extension to define a standard way of using PPP for data compression of serial data in Data Circuit-Terminating Equipment (DCE). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1977</doc-id>
        <title>PPP BSD Compression Protocol</title>
        <author>
            <name>V. Schryver</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>50747</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>PPP-BSD</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>Unix</kw>
            <kw>Compress</kw>
        </keywords>
        <abstract>This document describes the use of the Unix Compress compression protocol for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1978</doc-id>
        <title>PPP Predictor Compression Protocol</title>
        <author>
            <name>D. Rand</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17424</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>PPP-PRED</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document describes the use of the Predictor data compression algorithm for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1979</doc-id>
        <title>PPP Deflate Protocol</title>
        <author>
            <name>J. Woods</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18803</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>PPP-DEFL</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>Compression</kw>
            <kw>Control</kw>
        </keywords>
        <abstract>This document describes the use of the PPP Deflate compression protocol for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1980</doc-id>
        <title>A Proposed Extension to HTML : Client-Side Image Maps</title>
        <author>
            <name>J. Seidman</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13448</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>HyperText</kw>
            <kw>Markup</kw>
            <kw>Language</kw>
            <kw>Uniform</kw>
            <kw>Identifier</kw>
            <kw>URI</kw>
        </keywords>
        <abstract>This document specifies an extension to the HTML language, referred to as "Client-Side Image Maps," which resolves some limitations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC2854</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1981</doc-id>
        <title>Path MTU Discovery for IP version 6</title>
        <author>
            <name>J. McCann</name>
        </author>
        <author>
            <name>S. Deering</name>
        </author>
        <author>
            <name>J. Mogul</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34088</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>MTU-IPV6</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. [STANDARDS-TRACK] </abstract>
        <notes>updated to draft standard 8/20/98</notes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1982</doc-id>
        <title>Serial Number Arithmetic</title>
        <author>
            <name>R. Elz</name>
        </author>
        <author>
            <name>R. Bush</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14440</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>SNA</kw>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>DNS</kw>
        </keywords>
        <abstract>The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in an IETF document, though which has been widely understood. This memo supplies the missing definition. It is intended to update RFC1034 and RFC1035. [STANDARDS- TRACK] </abstract>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1983</doc-id>
        <title>Internet Users' Glossary</title>
        <author>
            <name>G. Malkin</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>123008</char-count>
            <page-count>62</page-count>
        </format>
        <keywords>
            <kw>basic</kw>
            <kw>terms</kw>
            <kw>acronyms</kw>
        </keywords>
        <abstract>There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1392</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>FYI0018</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1984</doc-id>
        <title>IAB and IESG Statement on Cryptographic Technology and the Internet</title>
        <author>
            <name>IAB</name>
        </author>
        <author>
            <name>IESG</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10738</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>privacy</kw>
        </keywords>
        <abstract>The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1985</doc-id>
        <title>SMTP Service Extension for Remote Message Queue Starting</title>
        <author>
            <name>J. De Winter</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14815</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>SMTP-ETRN</kw>
            <kw>Simple</kw>
            <kw>ETRN</kw>
            <kw>Mail</kw>
            <kw>Transfer</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to start the processing of its queues for messages to go to a given host. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1986</doc-id>
        <title>Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP)</title>
        <author>
            <name>W. Polites</name>
        </author>
        <author>
            <name>W. Wollman</name>
        </author>
        <author>
            <name>D. Woo</name>
        </author>
        <author>
            <name>R. Langan</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49772</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>ETFTP</kw>
            <kw>TFTP</kw>
            <kw>NETBLT</kw>
        </keywords>
        <abstract>This document is a description of the Enhanced Trivial File Transfer Protocol (ETFTP). This protocol is an experimental implementation of the NETwork BLock Transfer Protocol (NETBLT), RFC 998 [1], as a file transfer application program. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1987</doc-id>
        <title>Ipsilon's General Switch Management Protocol Specification Version 1.1</title>
        <author>
            <name>P. Newman</name>
        </author>
        <author>
            <name>W. Edwards</name>
        </author>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>E. Hoffman</name>
        </author>
        <author>
            <name>F. Ching Liaw</name>
        </author>
        <author>
            <name>T. Lyon</name>
        </author>
        <author>
            <name>G. Minshall</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>105821</char-count>
            <page-count>44</page-count>
        </format>
        <keywords>
            <kw>GSMP</kw>
            <kw>ATM</kw>
            <kw>switch</kw>
        </keywords>
        <abstract>The General Switch Management Protocol (GSMP), is a general purpose protocol to control an ATM switch. GSMP allows a controller to establish and release connections across the switch; add and delete leaves on a point-to-multipoint connection; manage switch ports; request configuration information; and request statistics. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <updated-by>
            <doc-id>RFC2297</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1988</doc-id>
        <title>Conditional Grant of Rights to Specific Hewlett-Packard Patents In Conjunction With the Internet Engineering Task Force's Internet-Standard Network Management Framework</title>
        <author>
            <name>G. McAnally</name>
        </author>
        <author>
            <name>D. Gilbert</name>
        </author>
        <author>
            <name>J. Flick</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3821</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>HP</kw>
        </keywords>
        <abstract>This grant is made to help facilitate inclusion of certain patented search address technology covering network device mapping in IETF standards-track Management Information Base (MIB) modules. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1989</doc-id>
        <title>PPP Link Quality Monitoring</title>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29289</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>PPP-LINK</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document defines a protocol for generating Link-Quality-Reports. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1333</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1990</doc-id>
        <title>The PPP Multilink Protocol (MP)</title>
        <author>
            <name>K. Sklower</name>
        </author>
        <author>
            <name>B. Lloyd</name>
        </author>
        <author>
            <name>G. McGregor</name>
        </author>
        <author>
            <name>D. Carr</name>
        </author>
        <author>
            <name>T. Coradetti</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53271</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>PPP-MP</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>datagrams</kw>
        </keywords>
        <abstract>This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. [STANDARDS- TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1717</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1991</doc-id>
        <title>PGP Message Exchange Formats</title>
        <author>
            <name>D. Atkins</name>
        </author>
        <author>
            <name>W. Stallings</name>
        </author>
        <author>
            <name>P. Zimmermann</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46255</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>PGP-MEF</kw>
            <kw>Pretty</kw>
            <kw>Good</kw>
            <kw>Privacy</kw>
            <kw>encryption</kw>
            <kw>electronic</kw>
            <kw>mail</kw>
        </keywords>
        <abstract>This document describes the format of "PGP files", i.e., messages that have been encrypted and/or signed with PGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1992</doc-id>
        <title>The Nimrod Routing Architecture</title>
        <author>
            <name>I. Castineyra</name>
        </author>
        <author>
            <name>N. Chiappa</name>
        </author>
        <author>
            <name>M. Steenstrup</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59848</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>scalable</kw>
            <kw>internetwork</kw>
        </keywords>
        <abstract>Nimrod is a scalable routing architecture designed to accommodate a continually expanding and diversifying internetwork. First suggested by Noel Chiappa, the Nimrod architecture has undergone revision and refinement through the efforts of the Nimrod working group of the IETF. In this document, we present a detailed description of this architecture. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1993</doc-id>
        <title>PPP Gandalf FZA Compression Protocol</title>
        <author>
            <name>A. Barbir</name>
        </author>
        <author>
            <name>D. Carr</name>
        </author>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9811</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document describes the use of the Gandalf FZA data compression algorithm [3] for compressing PPP encapsulated packets. This memo provides information for the Internet community. It does not specify an Internet standard. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1994</doc-id>
        <title>PPP Challenge Handshake Authentication Protocol (CHAP)</title>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24094</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>PPP-CHAP</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>cryptology</kw>
        </keywords>
        <abstract>This document defines a method for Authentication using PPP, which uses a random Challenge, with a cryptographically hashed Response which depends upon the Challenge and a secret key. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1334</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC2484</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1995</doc-id>
        <title>Incremental Zone Transfer in DNS</title>
        <author>
            <name>M. Ohta</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16810</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>DNS-IZT</kw>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
            <kw>IXFR</kw>
        </keywords>
        <abstract>This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism. [STANDARDS-TRACK] </abstract>
        <updates>
            <doc-id>RFC1035</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1996</doc-id>
        <title>A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)</title>
        <author>
            <name>P. Vixie</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15247</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>DNS-NOTIFY</kw>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
        </keywords>
        <abstract>This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data. [STANDARDS-TRACK] </abstract>
        <updates>
            <doc-id>RFC1035</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1997</doc-id>
        <title>BGP Communities Attribute</title>
        <author>
            <name>R. Chandra</name>
        </author>
        <author>
            <name>P. Traina</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8275</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>BGP-COMM</kw>
            <kw>Border</kw>
            <kw>Gateway</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1998</doc-id>
        <title>An Application of the BGP Community Attribute in Multi-home Routing</title>
        <author>
            <name>E. Chen</name>
        </author>
        <author>
            <name>T. Bates</name>
        </author>
        <date>
            <month>August</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16953</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>Border</kw>
            <kw>Gateway</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document presents an application of the BGP community attribute [2] in simplifying the implementation and configuration of routing policies in the multi-provider Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC1999</doc-id>
        <title>Request for Comments Summary RFC Numbers 1900-1999</title>
        <author>
            <name>J. Elliott</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39819</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>Index</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2000</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Postel</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>121356</char-count>
            <page-count>56</page-count>
        </format>
        <keywords>
            <kw>status</kw>
            <kw>procedure</kw>
            <kw>index</kw>
        </keywords>
        <abstract>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard. </abstract>
        <obsoletes>
            <doc-id>RFC1920</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2200</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2001</doc-id>
        <title>TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms</title>
        <author>
            <name>W. Stevens</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12981</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>TCPSLOWSRT</kw>
            <kw>Transmission</kw>
            <kw>Control</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>Modern implementations of TCP contain four intertwined algorithms that have never been fully documented as Internet standards: slow start, congestion avoidance, fast retransmit, and fast recovery. [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2581</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2002</doc-id>
        <title>IP Mobility Support</title>
        <author>
            <name>C. Perkins</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>193103</char-count>
            <page-count>79</page-count>
        </format>
        <keywords>
            <kw>MOBILEIPSUPIP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3220</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC2290</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2003</doc-id>
        <title>IP Encapsulation within IP</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30291</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>IPENCAPIP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. [STANDARDS- TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2004</doc-id>
        <title>Minimal Encapsulation within IP</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12202</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>MINI-IP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram, with less overhead than "conventional" IP encapsulation that adds a second IP header to each encapsulated datagram. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2005</doc-id>
        <title>Applicability Statement for IP Mobility Support</title>
        <author>
            <name>J. Solomon</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10509</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>As required by [RFC 1264], this report discusses the applicability of Mobile IP to provide host mobility in the Internet. In particular, this document describes the key features of Mobile IP and shows how the requirements for advancement to Proposed Standard RFC have been satisfied. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2006</doc-id>
        <title>The Definitions of Managed Objects for IP Mobility Support using SMIv2</title>
        <author>
            <name>D. Cong</name>
        </author>
        <author>
            <name>M. Hamlen</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>95030</char-count>
            <page-count>52</page-count>
        </format>
        <keywords>
            <kw>MOBILEIPMIB</kw>
            <kw>Mobile</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>MIB</kw>
            <kw>Managed</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2007</doc-id>
        <title>Catalogue of Network Training Materials</title>
        <author>
            <name>J. Foster</name>
        </author>
        <author>
            <name>M. Isaacs</name>
        </author>
        <author>
            <name>M. Prior</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>78941</char-count>
            <page-count>55</page-count>
        </format>
        <keywords>
            <kw>TRAINMAT</kw>
            <kw>IETF</kw>
            <kw>TERENA</kw>
        </keywords>
        <abstract>The purpose of this document is to provide a catalogue of quality Network Training Materials for use by Internet trainers in training their users. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <is-also>
            <doc-id>FYI0029</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2008</doc-id>
        <title>Implications of Various Address Allocation Policies for Internet Routing</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34717</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>IP</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract>The purpose of this document is to articulate certain relevant fundamental technical issues that must be considered in formulating unicast address allocation and management policies for the Public Internet, and to provide recommendations with respect to these policies. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <is-also>
            <doc-id>BCP0007</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2009</doc-id>
        <title>GPS-Based Addressing and Routing</title>
        <author>
            <name>T. Imielinski</name>
        </author>
        <author>
            <name>J. Navas</name>
        </author>
        <date>
            <month>November</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>66229</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>GPS-AR</kw>
            <kw>domain</kw>
            <kw>names</kw>
            <kw>geographic</kw>
        </keywords>
        <abstract>This document describes a possible experiment with geographic addresses. It uses several specific IP addresses and domain names in the discussion as concrete examples to aid in understanding the concepts. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2010</doc-id>
        <title>Operational Criteria for Root Name Servers</title>
        <author>
            <name>B. Manning</name>
        </author>
        <author>
            <name>P. Vixie</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14870</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>host</kw>
            <kw>hardware</kw>
        </keywords>
        <abstract>This document specifies the operational requirements of root name servers, including host hardware capacities, name server software revisions, network connectivity, and physical environment. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC2870</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2011</doc-id>
        <title>SNMPv2 Management Information Base for the Internet Protocol using SMIv2</title>
        <author>
            <name>K. McCloghrie</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31168</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>MIB-IP</kw>
            <kw>IP</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>MIB</kw>
        </keywords>
        <abstract>This document is the MIB module which defines managed objects for managing implementations of the Internet Protocol (IP) and its associated Internet Control Message Protocol (ICMP). [STANDARDS-TRACK] </abstract>
        <updates>
            <doc-id>RFC1213</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2012</doc-id>
        <title>SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2</title>
        <author>
            <name>K. McCloghrie</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16792</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>MIB-TCP</kw>
            <kw>TCP</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>MIB</kw>
        </keywords>
        <abstract>This document is the MIB module which defines managed objects for managing implementations of the Transmission Control Protocol (TCP). [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC4022</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1213</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2013</doc-id>
        <title>SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2</title>
        <author>
            <name>K. McCloghrie</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9333</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>MIB-UDP</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>MIB</kw>
            <kw>UDP</kw>
        </keywords>
        <abstract>This document is the MIB module which defines managed objects for managing implementations of the User Datagram Protocol (UDP). [STANDARDS-TRACK] </abstract>
        <updates>
            <doc-id>RFC1213</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2014</doc-id>
        <title>IRTF Research Group Guidelines and Procedures</title>
        <author>
            <name>A. Weinrib</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27507</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Research</kw>
            <kw>Task</kw>
            <kw>Force</kw>
        </keywords>
        <abstract>This document describes the guidelines and procedures for formation and operation of IRTF Research Groups. It describes the relationship between IRTF participants, Research Groups, the Internet Research Steering Group (IRSG) and the Internet Architecture Board (IAB). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <is-also>
            <doc-id>BCP0008</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2015</doc-id>
        <title>MIME Security with Pretty Good Privacy (PGP)</title>
        <author>
            <name>M. Elkins</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14223</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>MIME-PGP</kw>
            <kw>Authentication</kw>
            <kw>Encryption</kw>
        </keywords>
        <abstract>This document describes how Pretty Good Privacy (PGP) can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC1847. [STANDARDS-TRACK] </abstract>
        <updated-by>
            <doc-id>RFC3156</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2016</doc-id>
        <title>Uniform Resource Agents (URAs)</title>
        <author>
            <name>L. Daigle</name>
        </author>
        <author>
            <name>P. Deutsch</name>
        </author>
        <author>
            <name>B. Heelan</name>
        </author>
        <author>
            <name>C. Alpaugh</name>
        </author>
        <author>
            <name>M. Maclachlan</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38355</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>URAS</kw>
        </keywords>
        <abstract>This paper presents an experimental architecture for an agent system that provides sophisticated Internet information access and management. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2017</doc-id>
        <title>Definition of the URL MIME External-Body Access-Type</title>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name> K. Moore</name>
        </author>
        <author>
            <name>A. Cargille</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9000</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>URL-ACC</kw>
            <kw>Uniform</kw>
            <kw>Resource</kw>
            <kw>Locators</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract>This memo defines a new access-type for message/external-body MIME parts for Uniform Resource Locators (URLs). [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2018</doc-id>
        <title>TCP Selective Acknowledgement Options</title>
        <author>
            <name>M. Mathis</name>
        </author>
        <author>
            <name>J. Mahdavi</name>
        </author>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>A. Romanow</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25671</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>TCP-ACK</kw>
            <kw>Transmission</kw>
            <kw>Control</kw>
            <kw>Protocol</kw>
            <kw>SACK</kw>
        </keywords>
        <abstract>This memo proposes an implementation of SACK and discusses its performance and related issues. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1072</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2019</doc-id>
        <title>Transmission of IPv6 Packets Over FDDI</title>
        <author>
            <name>M. Crawford</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12344</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>IPV6-FDDI</kw>
            <kw>frame</kw>
            <kw>format</kw>
            <kw>Fiber</kw>
            <kw>Distributed</kw>
            <kw>Data</kw>
            <kw>Interface</kw>
        </keywords>
        <abstract>This memo specifies the MTU and frame format for transmission of IPv6 [IPV6] packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2467</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2020</doc-id>
        <title>IEEE 802.12 Interface MIB</title>
        <author>
            <name>J. Flick</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>72135</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>802.12-MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing network interfaces based on IEEE 802.12. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2021</doc-id>
        <title>Remote Network Monitoring Management Information Base Version 2 using SMIv2</title>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>262223</char-count>
            <page-count>130</page-count>
        </format>
        <keywords>
            <kw>RMON-MIB</kw>
            <kw>RMON</kw>
            <kw>MIB</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2022</doc-id>
        <title>Support for Multicast over UNI 3.0/3.1 based ATM Networks</title>
        <author>
            <name>G. Armitage</name>
        </author>
        <date>
            <month>November</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>189219</char-count>
            <page-count>82</page-count>
        </format>
        <keywords>
            <kw>MULTI-UNI</kw>
            <kw>Asynchronous</kw>
            <kw>Transfer</kw>
            <kw>Mode</kw>
        </keywords>
        <abstract>This memo describes a mechanism to support the multicast needs of Layer 3 protocols in general, and describes its application to IP multicasting in particular. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2023</doc-id>
        <title>IP Version 6 over PPP</title>
        <author>
            <name>D. Haskin</name>
        </author>
        <author>
            <name>E. Allen</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20275</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>IPV6-PPP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>Point</kw>
            <kw>IPv6</kw>
        </keywords>
        <abstract>This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2472</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2024</doc-id>
        <title>Definitions of Managed Objects for Data Link Switching using SMIv2</title>
        <author>
            <name>D. Chen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Gayek</name>
        </author>
        <author>
            <name>S. Nix</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>173952</char-count>
            <page-count>90</page-count>
        </format>
        <keywords>
            <kw>DLSW-MIB</kw>
            <kw>MIB</kw>
            <kw>DLSW</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling Data Link Switches (DLSw). [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2025</doc-id>
        <title>The Simple Public-Key GSS-API Mechanism (SPKM)</title>
        <author>
            <name>C. Adams</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>101692</char-count>
            <page-count>45</page-count>
        </format>
        <keywords>
            <kw>SPKM</kw>
        </keywords>
        <abstract>This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using the Simple Public-Key Mechanism. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2026</doc-id>
        <title>The Internet Standards Process -- Revision 3</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>86731</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>Protocols</kw>
            <kw>copyrights</kw>
            <kw>intellectual</kw>
            <kw>property</kw>
        </keywords>
        <abstract>This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <obsoletes>
            <doc-id>RFC1602</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3667</doc-id>
            <doc-id>RFC3668</doc-id>
            <doc-id>RFC3932</doc-id>
            <doc-id>RFC3979</doc-id>
            <doc-id>RFC3978</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0009</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2027</doc-id>
        <title>IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees</title>
        <author>
            <name>J. Galvin</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24207</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Architecture</kw>
            <kw>Board</kw>
            <kw>Engineering</kw>
            <kw>Steering</kw>
            <kw>Group</kw>
        </keywords>
        <abstract>The process by which the members of the IAB and IESG are selected, confirmed, and recalled has been exercised four times since its formal creation. The evolution of the process has relied principally on oral tradition as a means by which the lessons learned could be passed on to successive committees. This document is a self-consistent, organized compilation of the process as it is known today. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <obsoleted-by>
            <doc-id>RFC2282</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2028</doc-id>
        <title>The Organizations Involved in the IETF Standards Process</title>
        <author>
            <name>R. Hovey</name>
        </author>
        <author>
            <name>S. Bradner</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13865</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Engineering</kw>
            <kw>Task</kw>
            <kw>Force</kw>
        </keywords>
        <abstract>This document describes the individuals and organizations involved in the IETF. This includes descriptions of the IESG, the IETF Working Groups and the relationship between the IETF and the Internet Society. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <updated-by>
            <doc-id>RFC3668</doc-id>
            <doc-id>RFC3979</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0011</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2029</doc-id>
        <title>RTP Payload Format of Sun's CellB Video Encoding</title>
        <author>
            <name>M. Speer</name>
        </author>
        <author>
            <name>D. Hoffman</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11216</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>RTP-CELLB</kw>
            <kw>Real</kw>
            <kw>Time</kw>
            <kw>Transport</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This memo describes a packetization scheme for the CellB video encoding. The scheme proposed allows applications to transport CellB video flows over protocols used by RTP. This document is meant for implementors of video applications that want to use RTP and CellB. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2030</doc-id>
        <title>Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI</title>
        <author>
            <name>D. Mills</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48620</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>NTP</kw>
            <kw>SNTP</kw>
            <kw>time</kw>
            <kw>computer</kw>
            <kw>clock</kw>
            <kw>synchronization</kw>
        </keywords>
        <abstract>This memorandum describes the Simple Network Time Protocol (SNTP) Version 4, which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1769</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2031</doc-id>
        <title>IETF-ISOC relationship</title>
        <author>
            <name>E. Huizer</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8816</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Society</kw>
            <kw>Engineering</kw>
            <kw>Task</kw>
            <kw>Force</kw>
        </keywords>
        <abstract>This memo summarises the issues on IETF - ISOC relationships as the have been discussed by the Poised Working Group. The purpose of the document is to gauge consensus on these issues. And to allow further discussions where necessary. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2032</doc-id>
        <title>RTP Payload Format for H.261 Video Streams</title>
        <author>
            <name>T. Turletti</name>
        </author>
        <author>
            <name>C. Huitema</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27488</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>RTP-H.261</kw>
            <kw>Real</kw>
            <kw>Time</kw>
            <kw>Transport</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2033</doc-id>
        <title>Local Mail Transfer Protocol</title>
        <author>
            <name>J. Myers</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14711</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>LMTP</kw>
            <kw>SMTP</kw>
            <kw>Simple</kw>
            <kw>Mail</kw>
            <kw>Transfer</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a mechanism for transferring mail reliably and efficiently. The design of the SMTP protocol effectively requires the server to manage a mail delivery queue. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2034</doc-id>
        <title>SMTP Service Extension for Returning Enhanced Error Codes</title>
        <author>
            <name>N. Freed</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10460</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>SMTP-ENH</kw>
            <kw>Simple</kw>
            <kw>Mail</kw>
            <kw>Transfer</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This memo defines an extension to the SMTP service [RFC-821, RFC-1869] whereby an SMTP server augments its responses with the enhanced mail system status codes defined in RFC 1893. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2035</doc-id>
        <title>RTP Payload Format for JPEG-compressed Video</title>
        <author>
            <name>L. Berc</name>
        </author>
        <author>
            <name>W. Fenner</name>
        </author>
        <author>
            <name>R. Frederick</name>
        </author>
        <author>
            <name>S. McCanne</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30079</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>RTP-JPEG</kw>
            <kw>Real</kw>
            <kw>Time</kw>
            <kw>Transport</kw>
            <kw>Protocol</kw>
            <kw>Joint</kw>
            <kw>Photographic</kw>
            <kw>Experts</kw>
            <kw>Group</kw>
        </keywords>
        <abstract>This memo describes the RTP payload format for JPEG video streams. The packet format is optimized for real-time video streams where codec parameters change rarely from frame to frame. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2435</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2036</doc-id>
        <title>Observations on the use of Components of the Class A Address Space within the Internet</title>
        <author>
            <name>G. Huston</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20743</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Assigned</kw>
            <kw>Numbers</kw>
            <kw>Authority</kw>
            <kw>IANA</kw>
        </keywords>
        <abstract>This document is a commentary on the recommendation that IANA commence allocation of the presently unallocated components of the Class A address space to registries, for deployment within the Internet as class-less address blocks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2037</doc-id>
        <title>Entity MIB using SMIv2</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>A. Bierman</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>74362</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
            <kw>ENTITY-MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2737</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2038</doc-id>
        <title>RTP Payload Format for MPEG1/MPEG2 Video</title>
        <author>
            <name>D. Hoffman</name>
        </author>
        <author>
            <name>G. Fernando</name>
        </author>
        <author>
            <name>V. Goyal</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23266</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>Real</kw>
            <kw>Time</kw>
            <kw>Transport</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This memo describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2250</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2039</doc-id>
        <title>Applicability of Standards Track MIBs to Management of World Wide Web Servers</title>
        <author>
            <name>C. Kalbfleisch</name>
        </author>
        <date>
            <month>November</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31966</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>HTTP</kw>
        </keywords>
        <abstract>This document was produced at the request of the Network Management Area Director following the HTTP-MIB BOF at the 35th IETF meeting to report on the applicability of the existing standards track MIBs to management of WWW servers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2040</doc-id>
        <title>The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms</title>
        <author>
            <name>R. Baldwin</name>
        </author>
        <author>
            <name>R. Rivest</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54598</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>RC5</kw>
            <kw>Cipher</kw>
            <kw>Block</kw>
            <kw>Chaining</kw>
            <kw>CBC</kw>
        </keywords>
        <abstract>This document defines four ciphers with enough detail to ensure interoperability between different implementations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2041</doc-id>
        <title>Mobile Network Tracing</title>
        <author>
            <name>B. Noble</name>
        </author>
        <author>
            <name>G. Nguyen</name>
        </author>
        <author>
            <name>M. Satyanarayanan</name>
        </author>
        <author>
            <name>R. Katz</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>64688</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>IP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This RFC argues that mobile network tracing provides both tools to improve our understanding of wireless channels, as well as to build realistic, repeatable testbeds for mobile software and systems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2042</doc-id>
        <title>Registering New BGP Attribute Types</title>
        <author>
            <name>B. Manning</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4001</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>Border</kw>
            <kw>Gateway</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document describes the process for creating new BGP attribute type codes. Basic attribute type codes are described in RFC 1771, pages 12 through 15. These, and new attribute type codes that are used in the Internet are registered with the IANA. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2043</doc-id>
        <title>The PPP SNA Control Protocol (SNACP)</title>
        <author>
            <name>A. Fuqua</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13719</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>PPP-SNACP</kw>
            <kw>Point-to-point</kw>
            <kw>protocol</kw>
            <kw>systems</kw>
            <kw>network</kw>
            <kw>architecture</kw>
        </keywords>
        <abstract>This document defines the Network Control Protocols for establishing and configuring Systems Network Architecture (SNA) over PPP and SNA over LLC 802.2 over PPP. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2044</doc-id>
        <title>UTF-8, a transformation format of Unicode and ISO 10646</title>
        <author>
            <name>F. Yergeau</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11932</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>UCS</kw>
            <kw>Transformation</kw>
            <kw>Format</kw>
        </keywords>
        <abstract>The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993 jointly define a 16 bit character set which encompasses most of the world's writing systems. UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC2279</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2045</doc-id>
        <title>Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>N. Borenstein</name>
        </author>
        <date>
            <month>November</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>72932</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>MIME</kw>
            <kw>media</kw>
            <kw>types</kw>
            <kw>headers</kw>
        </keywords>
        <abstract>This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1521</doc-id>
            <doc-id>RFC1522</doc-id>
            <doc-id>RFC1590</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC2184</doc-id>
            <doc-id>RFC2231</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2046</doc-id>
        <title>Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>N. Borenstein</name>
        </author>
        <date>
            <month>November</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>105854</char-count>
            <page-count>44</page-count>
        </format>
        <keywords>
            <kw>MIME-MEDIA</kw>
            <kw>headers</kw>
            <kw>structure</kw>
        </keywords>
        <abstract>This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS- TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1521</doc-id>
            <doc-id>RFC1522</doc-id>
            <doc-id>RFC1590</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC2646</doc-id>
            <doc-id>RFC3798</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2047</doc-id>
        <title>MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text </title>
        <author>
            <name>K. Moore</name>
        </author>
        <date>
            <month>November</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33262</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>MIME-MSG</kw>
            <kw>media</kw>
            <kw>type </kw>
        </keywords>
        <abstract>This particular document is the third document in the series. It describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1521</doc-id>
            <doc-id>RFC1522</doc-id>
            <doc-id>RFC1590</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC2184</doc-id>
            <doc-id>RFC2231</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2048</doc-id>
        <title>Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures</title>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45033</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>media</kw>
            <kw>types</kw>
            <kw>external</kw>
            <kw>body</kw>
            <kw>access</kw>
            <kw>content-transfer-encodings</kw>
        </keywords>
        <abstract>This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages. This fourth document, RFC 2048, specifies various IANA registration procedures for some MIME facilities. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <obsoletes>
            <doc-id>RFC1521</doc-id>
            <doc-id>RFC1522</doc-id>
            <doc-id>RFC1590</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3023</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0013</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2049</doc-id>
        <title>Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples</title>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>N. Borenstein</name>
        </author>
        <date>
            <month>November</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51207</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>MIME-CONF</kw>
            <kw>media</kw>
            <kw>type</kw>
            <kw>message</kw>
            <kw>formats</kw>
        </keywords>
        <abstract>This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages. This fifth and final document describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1521</doc-id>
            <doc-id>RFC1522</doc-id>
            <doc-id>RFC1590</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2050</doc-id>
        <title>Internet Registry IP Allocation Guidelines</title>
        <author>
            <name>K. Hubbard</name>
        </author>
        <author>
            <name>M. Kosters</name>
        </author>
        <author>
            <name>D. Conrad</name>
        </author>
        <author>
            <name>D. Karrenberg</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>November</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28975</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Addresses</kw>
            <kw>Network</kw>
            <kw>Numbers</kw>
        </keywords>
        <abstract>This document describes the registry system for the distribution of globally unique Internet address space and registry operations. Particularly this document describes the rules and guidelines governing the distribution of this address space. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <obsoletes>
            <doc-id>RFC1466</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0012</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2051</doc-id>
        <title>Definitions of Managed Objects for APPC using SMIv2</title>
        <author>
            <name>M. Allen</name>
        </author>
        <author>
            <name>B. Clouston</name>
        </author>
        <author>
            <name>Z. Kielczewski</name>
        </author>
        <author>
            <name>W. Kwan</name>
        </author>
        <author>
            <name>B. Moore</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>239359</char-count>
            <page-count>124</page-count>
        </format>
        <keywords>
            <kw>SNANAU-APP</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and controlling of network devices with APPC (Advanced Program-to-Program Communications) capabilities. This memo identifies managed objects for the SNA LU6.2 protocols. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2052</doc-id>
        <title>A DNS RR for specifying the location of services (DNS SRV)</title>
        <author>
            <name>A. Gulbrandsen</name>
        </author>
        <author>
            <name>P. Vixie</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19257</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>DNS-SRV</kw>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
        </keywords>
        <abstract>This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain (like a more general form of MX). This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC2782</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2053</doc-id>
        <title>The AM (Armenia) Domain</title>
        <author>
            <name>E. Der-Danieliantz</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4128</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>Top</kw>
            <kw>Level</kw>
            <kw>Domain</kw>
            <kw>Country</kw>
            <kw>Code</kw>
        </keywords>
        <abstract>The AM Domain is an official Internet top-level domain of Armenia. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2054</doc-id>
        <title>WebNFS Client Specification</title>
        <author>
            <name>B. Callaghan</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36354</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>Network</kw>
            <kw>Fil</kw>
            <kw>System</kw>
        </keywords>
        <abstract>This document describes a lightweight binding mechanism that allows NFS clients to obtain service from WebNFS-enabled servers with a minimum of protocol overhead. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2055</doc-id>
        <title>WebNFS Server Specification</title>
        <author>
            <name>B. Callaghan</name>
        </author>
        <date>
            <month>October</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20498</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>Network</kw>
            <kw>Fil</kw>
            <kw>System</kw>
        </keywords>
        <abstract>This document describes the specifications for a server of WebNFS clients. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2056</doc-id>
        <title>Uniform Resource Locators for Z39.50</title>
        <author>
            <name>R. Denenberg</name>
        </author>
        <author>
            <name>J. Kunze</name>
        </author>
        <author>
            <name>D. Lynch</name>
        </author>
        <date>
            <month>November</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14204</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>URLZ39.50</kw>
            <kw>URL</kw>
            <kw>information</kw>
            <kw>retrieval</kw>
        </keywords>
        <abstract>Z39.50 is an information retrieval protocol that does not fit neatly into a retrieval model designed primarily around the stateless fetch of data. Instead, it models a general user inquiry as a session-oriented, multi-step task, any step of which may be suspended temporarily while the server requests additional parameters from the client before continuing. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2057</doc-id>
        <title>Source Directed Access Control on the Internet</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <date>
            <month>November</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>56664</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>content</kw>
            <kw>regulation</kw>
            <kw>deposition</kw>
        </keywords>
        <abstract>This memo was developed from a deposition that I submitted as part of a challenge to the Communications Decency Act of 1996, part of the Telecommunications Reform Act of 1996. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2058</doc-id>
        <title>Remote Authentication Dial In User Service (RADIUS)</title>
        <author>
            <name>C. Rigney</name>
        </author>
        <author>
            <name>A. Rubens</name>
        </author>
        <author>
            <name>W. Simpson</name>
        </author>
        <author>
            <name>S. Willens</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>118880</char-count>
            <page-count>64</page-count>
        </format>
        <keywords>
            <kw>encryption</kw>
            <kw>NAS</kw>
            <kw>Network</kw>
            <kw>Access</kw>
            <kw>Server</kw>
        </keywords>
        <abstract>This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2138</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2059</doc-id>
        <title>RADIUS Accounting</title>
        <author>
            <name>C. Rigney</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44237</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>remote</kw>
            <kw>authentication</kw>
            <kw>dial</kw>
            <kw>in</kw>
            <kw>user</kw>
            <kw>service</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract>This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC2139</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2060</doc-id>
        <title>Internet Message Access Protocol - Version 4rev1</title>
        <author>
            <name>M. Crispin</name>
        </author>
        <date>
            <month>December</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>166513</char-count>
            <page-count>82</page-count>
        </format>
        <keywords>
            <kw>IMAPV4</kw>
            <kw>IMAP</kw>
            <kw>electronic</kw>
            <kw>mail</kw>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1730</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3501</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2061</doc-id>
        <title> IMAP4 Compatibility with IMAP2bis</title>
        <author>
            <name>M. Crispin</name>
        </author>
        <date>
            <month>December</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5867</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>IMAP</kw>
            <kw>electronic</kw>
            <kw>mail</kw>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document is intended to be read along with RFC 1176 and the most recent IMAP4 specification (RFC 2060) to assist implementors in creating an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1730</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2062</doc-id>
        <title>Internet Message Access Protocol - Obsolete Syntax</title>
        <author>
            <name>M. Crispin</name>
        </author>
        <date>
            <month>December</month>
            <year>1996</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14222</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>IMAP</kw>
            <kw>electronic</kw>
            <kw>mail</kw>
        </keywords>
        <abstract>This document describes obsolete syntax which may be encountered by IMAP4 implementations which deal with older versions of the Internet Mail Access Protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2063</doc-id>
        <title>Traffic Flow Measurement:  Architecture</title>
        <author>
            <name>N. Brownlee</name>
        </author>
        <author>
            <name>C. Mills</name>
        </author>
        <author>
            <name>G. Ruth</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>89092</char-count>
            <page-count>37</page-count>
        </format>
        <keywords>
            <kw>TFM-ARCH</kw>
            <kw>network</kw>
            <kw>data</kw>
        </keywords>
        <abstract>This document describes an architecture for the measurement and reporting of network traffic flows, discusses how this relates to an overall network traffic flow architecture, and describes how it can be used within the Internet. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC2722</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2064</doc-id>
        <title>Traffic Flow Measurement:  Meter MIB</title>
        <author>
            <name>N. Brownlee</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>67520</char-count>
            <page-count>38</page-count>
        </format>
        <keywords>
            <kw>METER-MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>Network</kw>
            <kw>Data</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for obtaining traffic flow information from network traffic meters. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC2720</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2065</doc-id>
        <title>Domain Name System Security Extensions</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>C. Kaufman</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>97718</char-count>
            <page-count>41</page-count>
        </format>
        <keywords>
            <kw>DNS-SEC</kw>
            <kw>DNS</kw>
            <kw>authentication</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract>The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2535</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2066</doc-id>
        <title>TELNET CHARSET Option</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26088</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>TOPT-CHARSET</kw>
            <kw>character</kw>
            <kw>set</kw>
            <kw>application</kw>
        </keywords>
        <abstract>This document specifies a mechanism for passing character set and translation information between a TELNET client and server. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2067</doc-id>
        <title>IP over HIPPI</title>
        <author>
            <name>J. Renwick</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>66702</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>IP-HIPPI</kw>
            <kw>ANSI</kw>
            <kw>High-Performance</kw>
            <kw>Parallel</kw>
            <kw>Interface</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>ANSI Standard X3.218-1993 (HIPPI-LE[3]) defines the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI. This memo is a revision of RFC 1374, "IP and ARP on HIPPI", and is intended to replace it in the Standards Track. [STANDARDS-TRACK] </abstract>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2068</doc-id>
        <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
        <author>
            <name>R. Fielding</name>
        </author>
        <author>
            <name>J. Gettys</name>
        </author>
        <author>
            <name>J. Mogul</name>
        </author>
        <author>
            <name>H. Frystyk</name>
        </author>
        <author>
            <name>T. Berners-Lee</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>378114</char-count>
            <page-count>162</page-count>
        </format>
        <keywords>
            <kw>HTTP-1.1</kw>
            <kw>World</kw>
            <kw>Wide</kw>
            <kw>Web</kw>
            <kw>WWW</kw>
            <kw>hypermedia</kw>
        </keywords>
        <abstract>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2616</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2069</doc-id>
        <title>An Extension to HTTP : Digest Access Authentication</title>
        <author>
            <name>J. Franks</name>
        </author>
        <author>
            <name>P. Hallam-Baker</name>
        </author>
        <author>
            <name>J. Hostetler</name>
        </author>
        <author>
            <name>P. Leach</name>
        </author>
        <author>
            <name>A. Luotonen</name>
        </author>
        <author>
            <name>E. Sink</name>
        </author>
        <author>
            <name>L. Stewart</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41733</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>DAA</kw>
            <kw>Hypertext</kw>
            <kw>Transfer</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>The protocol referred to as "HTTP/1.0" includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication, as the user name and password are passed over the network as clear text. A specification for a different authentication scheme is needed to address this severe limitation. This document provides specification for such a scheme, referred to as "Digest Access Authentication". [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2617</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2070</doc-id>
        <title>Internationalization of the Hypertext Markup Language</title>
        <author>
            <name>F. Yergeau</name>
        </author>
        <author>
            <name>G. Nicol</name>
        </author>
        <author>
            <name>G. Adams</name>
        </author>
        <author>
            <name>M. Duerst</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>91887</char-count>
            <page-count>43</page-count>
        </format>
        <keywords>
            <kw>HTML-INT</kw>
            <kw>HTML</kw>
            <kw>WWW</kw>
            <kw>World</kw>
            <kw>Wide</kw>
            <kw>Web</kw>
        </keywords>
        <abstract>This document is meant to address the issue of the internationalization (i18n, i followed by 18 letters followed by n) of HTML by extending the specification of HTML and giving additional recommendations for proper internationalization support. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2854</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2071</doc-id>
        <title>Network Renumbering Overview: Why would I want it and what is it anyway?</title>
        <author>
            <name>P. Ferguson</name>
        </author>
        <author>
            <name>H. Berkowitz</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33218</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Enterprise</kw>
            <kw>Connecting</kw>
            <kw>Routers</kw>
        </keywords>
        <abstract>This document attempts to clearly define the concept of network renumbering and discuss some of the more pertinent reasons why an organization would have a need to do so. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2072</doc-id>
        <title>Router Renumbering Guide</title>
        <author>
            <name>H. Berkowitz</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>110591</char-count>
            <page-count>48</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Enterprise</kw>
            <kw>Connecting</kw>
            <kw>Routers</kw>
        </keywords>
        <abstract>Routers interact with numerous network infrastructure servers, including DNS and SNMP. These interactions, not just the pure addressing and routing structure, must be considered as part of router renumbering. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2073</doc-id>
        <title>An IPv6 Provider-Based Unicast Address Format</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>P. Lothberg</name>
        </author>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>S. Deering</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15549</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>IPV6-UNI</kw>
        </keywords>
        <abstract>This document defines an IPv6 provider-based unicast address format for use in the Internet. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2374</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2074</doc-id>
        <title>Remote Network Monitoring MIB Protocol Identifiers</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <author>
            <name>R. Iddon</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>81262</char-count>
            <page-count>43</page-count>
        </format>
        <keywords>
            <kw>RMON-MIB</kw>
            <kw>RMON</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the algorithms required to identify different protocol encapsulations managed with the Remote Network Monitoring MIB Version 2 [RMON2]. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2895</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2075</doc-id>
        <title>IP Echo Host Service</title>
        <author>
            <name>C. Partridge</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12536</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>IP-Echo</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>datagram</kw>
        </keywords>
        <abstract>This memo describes how to implement an IP echo host. IP echo hosts send back IP datagrams after exchanging the source and destination IP addresses. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2076</doc-id>
        <title>Common Internet Message Headers</title>
        <author>
            <name>J. Palme</name>
        </author>
        <date>
            <month>February</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47639</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>email</kw>
        </keywords>
        <abstract>This memo contains a table of commonly occurring headers in headings of e-mail messages. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2077</doc-id>
        <title>The Model Primary Content Type for Multipurpose Internet Mail Extensions</title>
        <author>
            <name>S. Nelson</name>
        </author>
        <author>
            <name>C. Parks</name>
        </author>
        <author>
            <name>Mitra</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30158</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>MIME-MODEL</kw>
            <kw>MIME</kw>
            <kw>Media</kw>
            <kw>Type</kw>
            <kw>Content</kw>
            <kw>Type</kw>
        </keywords>
        <abstract>The purpose of this memo is to propose an update to Internet RFC 2045 to include a new primary content-type to be known as "model". [STANDARDS- TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2078</doc-id>
        <title>Generic Security Service Application Program Interface, Version 2</title>
        <author>
            <name>J. Linn</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>185990</char-count>
            <page-count>85</page-count>
        </format>
        <keywords>
            <kw>GSSAP</kw>
            <kw>Authentication</kw>
            <kw>Cryptology</kw>
            <kw>Data</kw>
            <kw>integrity</kw>
        </keywords>
        <abstract>The Generic Security Service Application Program Interface (GSS-API), as defined in RFC-1508, provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1508</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2743</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2079</doc-id>
        <title>Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)</title>
        <author>
            <name>M. Smith</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8757</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>URI-ATT</kw>
            <kw>URL</kw>
            <kw>Universal</kw>
            <kw>Resource</kw>
            <kw>Locators</kw>
            <kw>Directory</kw>
        </keywords>
        <abstract>This document builds on the experimentation to date and defines a new attribute type and an auxiliary object class to allow URIs, including URLs, to be stored in directory entries in a standard way. [STANDARDS- TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2080</doc-id>
        <title>RIPng for IPv6</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <author>
            <name>R. Minnear</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47534</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>RIPNG-IPV6</kw>
            <kw>Routing</kw>
            <kw>Information</kw>
            <kw>Protocol</kw>
            <kw>Internet</kw>
        </keywords>
        <abstract>This document specifies a routing protocol for an IPv6 internet. It is based on protocols and algorithms currently in wide use in the IPv4 Internet [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2081</doc-id>
        <title>RIPng Protocol Applicability Statement</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6821</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>Routing</kw>
            <kw>Information</kw>
            <kw>Protocol</kw>
            <kw>Internet</kw>
        </keywords>
        <abstract>As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIPng protocol within the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2082</doc-id>
        <title>RIP-2 MD5 Authentication</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>R. Atkinson</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25436</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>RIP2-MD5</kw>
            <kw>Routing</kw>
            <kw>Information</kw>
            <kw>Protocol</kw>
            <kw>Encryption</kw>
        </keywords>
        <abstract>Growth in the Internet has made us aware of the need for improved authentication of routing information. RIP-2 provides for unauthenticated service (as in classical RIP), or password authentication. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2083</doc-id>
        <title>PNG (Portable Network Graphics) Specification Version 1.0</title>
        <author>
            <name>T. Boutell</name>
        </author>
        <date>
            <month>March</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>242528</char-count>
            <page-count>102</page-count>
        </format>
        <keywords>
            <kw>PNG</kw>
            <kw>file</kw>
            <kw>format</kw>
            <kw>bitmap</kw>
        </keywords>
        <abstract>This document describes PNG (Portable Network Graphics), an extensible file format for the lossless, portable, well-compressed storage of raster images. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2084</doc-id>
        <title>Considerations for Web Transaction Security</title>
        <author>
            <name>G. Bossert</name>
        </author>
        <author>
            <name>S. Cooper</name>
        </author>
        <author>
            <name>W. Drummond</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9022</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>authentication</kw>
            <kw>encryption</kw>
            <kw>World</kw>
            <kw>Wide</kw>
            <kw>Web</kw>
            <kw>WWW</kw>
        </keywords>
        <abstract>This document specifies the requirements for the provision of security services to the HyperText Transport Protocol. These services include confidentiality, integrity, user authentication, and authentication of servers/services, including proxied or gatewayed services. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2085</doc-id>
        <title>HMAC-MD5 IP Authentication with Replay Prevention</title>
        <author>
            <name>M. Oehler</name>
        </author>
        <author>
            <name>R. Glenn</name>
        </author>
        <date>
            <month>February</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13399</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>HMAC-MD5</kw>
            <kw>ipsec</kw>
            <kw>Message</kw>
            <kw>Digest</kw>
            <kw>Security</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>Encryption</kw>
        </keywords>
        <abstract>This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2086</doc-id>
        <title>IMAP4 ACL extension</title>
        <author>
            <name>J. Myers</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13925</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>IMAP4-ACL</kw>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
            <kw>Control</kw>
            <kw>List</kw>
        </keywords>
        <abstract>The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2087</doc-id>
        <title>IMAP4 QUOTA extension</title>
        <author>
            <name>J. Myers</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8542</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>IMAP4-QUO</kw>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>The QUOTA extension of the Internet Message Access Protocol [IMAP4] permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2088</doc-id>
        <title>IMAP4 non-synchronizing literals</title>
        <author>
            <name>J. Myers</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4052</char-count>
            <page-count>2</page-count>
        </format>
        <keywords>
            <kw>IMAP4-LIT</kw>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>The Internet Message Access Protocol [IMAP4] contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP4 requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal which does not require this network round trip. [STANDARDS- TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2089</doc-id>
        <title>V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent</title>
        <author>
            <name>B. Wijnen</name>
        </author>
        <author>
            <name>D. Levi</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23814</char-count>
            <page-count>12</page-count>
        </format>
        <abstract>The goal of this memo is to document a common way of mapping an SNMPv2 response into an SNMPv1 response within a bi-lingual SNMP agent (one that supports both SNMPv1 and SNMPv2). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC2576</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2090</doc-id>
        <title>TFTP Multicast Option</title>
        <author>
            <name>A. Emberson</name>
        </author>
        <date>
            <month>February</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11857</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>TFTP-MULTI</kw>
            <kw>Trivial</kw>
            <kw>File</kw>
            <kw>Transfer</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document describes a new TFTP option. This new option will allow the multiple clients to receive the same file concurrently through the use of Multicast packets. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2091</doc-id>
        <title>Triggered Extensions to RIP to Support Demand Circuits</title>
        <author>
            <name>G. Meyer</name>
        </author>
        <author>
            <name>S. Sherry</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44835</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>RIP-TRIG</kw>
        </keywords>
        <abstract>This document defines a modification which can be applied to Bellman- Ford (distance vector) algorithm information broadcasting protocols. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2092</doc-id>
        <title>Protocol Analysis for Triggered RIP</title>
        <author>
            <name>S. Sherry</name>
        </author>
        <author>
            <name>G. Meyer</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10865</char-count>
            <page-count>6</page-count>
        </format>
        <abstract>As required by Routing Protocol Criteria [1], this report documents the key features of Triggered Extensions to RIP to Support Demand Circuits [2] and the current implementation experience. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2093</doc-id>
        <title>Group Key Management Protocol (GKMP) Specification</title>
        <author>
            <name>H. Harney</name>
        </author>
        <author>
            <name>C. Muckenhirn</name>
        </author>
        <date>
            <month>July</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48678</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>GKMP-SPEC</kw>
        </keywords>
        <abstract>This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2094</doc-id>
        <title>Group Key Management Protocol (GKMP) Architecture</title>
        <author>
            <name>H. Harney</name>
        </author>
        <author>
            <name>C. Muckenhirn</name>
        </author>
        <date>
            <month>July</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53097</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>GKMP-ARCH</kw>
        </keywords>
        <abstract>This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2095</doc-id>
        <title>IMAP/POP AUTHorize Extension for Simple Challenge/Response</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>R. Catoe</name>
        </author>
        <author>
            <name>P. Krumviede</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10446</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>Post</kw>
            <kw>Office</kw>
            <kw>Protocol</kw>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
        </keywords>
        <abstract>This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2195</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2096</doc-id>
        <title>IP Forwarding Table MIB</title>
        <author>
            <name>F. Baker</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35930</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>TABLE-MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This memo defines an update to RFC 1354. The significant difference between this MIB and RFC 1354 is the recognition (explicitly discussed but by consensus left to future work) that CIDR routes may have the same network number but different network masks. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1354</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2097</doc-id>
        <title>The PPP NetBIOS Frames Control Protocol (NBFCP)</title>
        <author>
            <name>G. Pall</name>
        </author>
        <date>
            <month>January</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27104</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>PPP-NBFCP</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document defines the Network Control Protocol for establishing and configuring the NBF protocol over PPP. The NBFCP protocol is only applicable for an end system to connect to a peer system or the LAN that peer system is connected to. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2098</doc-id>
        <title>Toshiba's Router Architecture Extensions for ATM : Overview</title>
        <author>
            <name>Y. Katsube</name>
        </author>
        <author>
            <name>K. Nagami</name>
        </author>
        <author>
            <name>H. Esaki</name>
        </author>
        <date>
            <month>February</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43622</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>Asynchronis</kw>
            <kw>Transfer</kw>
            <kw>Mode</kw>
            <kw>datagram</kw>
            <kw>IP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This memo describes a new internetworking architecture which makes better use of the property of ATM. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2099</doc-id>
        <title>Request for Comments Summary RFC Numbers 2000-2099</title>
        <author>
            <name>J. Elliott</name>
        </author>
        <date>
            <month>March</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40763</char-count>
            <page-count>21</page-count>
        </format>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2100</doc-id>
        <title>The Naming of Hosts</title>
        <author>
            <name>J. Ashworth</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4077</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>April</kw>
            <kw>Fool's</kw>
        </keywords>
        <abstract>This RFC is a commentary on the difficulty of deciding upon an acceptably distinctive hostname for one's computer, a problem which grows in direct proportion to the logarithmically increasing size of the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2101</doc-id>
        <title>IPv4 Address Behaviour Today</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>J. Crowcroft</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>February</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31407</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>Internet</kw>
            <kw>Architecture</kw>
            <kw>Board</kw>
        </keywords>
        <abstract>The main purpose of this note is to clarify the current interpretation of the 32-bit IP version 4 address space, whose significance has changed substantially since it was originally defined. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2102</doc-id>
        <title>Multicast Support for Nimrod :  Requirements and Solution Approaches</title>
        <author>
            <name>R. Ramanathan</name>
        </author>
        <date>
            <month>February</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>50963</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>scalable</kw>
            <kw>routing</kw>
            <kw>architecture</kw>
        </keywords>
        <abstract>Nimrod does not specify a particular solution for multicasting. Rather, Nimrod may use any of a number of emerging multicast techniques. We identify the requirements that Nimrod has of a solution for multicast support. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2103</doc-id>
        <title>Mobility Support for Nimrod :  Challenges and Solution Approaches</title>
        <author>
            <name>R. Ramanathan</name>
        </author>
        <date>
            <month>February</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41352</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>IP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>routing</kw>
            <kw>addressing</kw>
        </keywords>
        <abstract>We discuss the issue of mobility in Nimrod. While a mobility solution is not part of the Nimrod architecture, Nimrod does require that the solution have certain characteristics. We identify the requirements that Nimrod has of any solution for mobility support. We also classify and compare existing approaches for supporting mobility within an internetwork and discuss their advantages and disadvantages. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2104</doc-id>
        <title>HMAC: Keyed-Hashing for Message Authentication</title>
        <author>
            <name>H. Krawczyk</name>
        </author>
        <author>
            <name>M. Bellare</name>
        </author>
        <author>
            <name>R. Canetti</name>
        </author>
        <date>
            <month>February</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22297</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>ipsec</kw>
            <kw>Message</kw>
            <kw>Digest</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>Security</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract>This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2105</doc-id>
        <title>Cisco Systems' Tag Switching Architecture Overview</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>B. Davie</name>
        </author>
        <author>
            <name>D. Katz</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <date>
            <month>February</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33013</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>network</kw>
            <kw>layer</kw>
            <kw>packet</kw>
            <kw>ATM</kw>
            <kw>switches</kw>
        </keywords>
        <abstract>This document provides an overview of a novel approach to network layer packet forwarding, called tag switching. The two main components of the tag switching architecture - forwarding and control - are described. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2106</doc-id>
        <title>Data Link Switching Remote Access Protocol</title>
        <author>
            <name>S. Chiang</name>
        </author>
        <author>
            <name>J. Lee</name>
        </author>
        <author>
            <name>H. Yasuda</name>
        </author>
        <date>
            <month>February</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40819</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>DLSRAP</kw>
            <kw>NetBios</kw>
            <kw>DLSW</kw>
        </keywords>
        <abstract>This memo describes the Data Link Switching Remote Access Protocol that is used between workstations and routers to transport SNA/ NetBIOS traffic over TCP sessions. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC2114</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2107</doc-id>
        <title>Ascend Tunnel Management Protocol - ATMP</title>
        <author>
            <name>K. Hamzeh</name>
        </author>
        <date>
            <month>February</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44300</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>RADIUS</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This document specifies a generic tunnel management protocol that allows remote dial-in users to access their home network as if they were directly attached to the home network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2108</doc-id>
        <title>Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2</title>
        <author>
            <name>K. de Graaf</name>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <author>
            <name>D. McMaster</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>February</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>166336</char-count>
            <page-count>82</page-count>
        </format>
        <keywords>
            <kw>802.3-MIB</kw>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 10 and 100 Mb/second baseband repeaters based on IEEE Std 802.3 Section 30, "10 &amp; </abstract>
        <obsoletes>
            <doc-id>RFC1516</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2109</doc-id>
        <title>HTTP State Management Mechanism</title>
        <author>
            <name>D. Kristol</name>
        </author>
        <author>
            <name>L. Montulli</name>
        </author>
        <date>
            <month>February</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43469</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>HTTP-STATE</kw>
            <kw>Hypertext</kw>
            <kw>Transfer</kw>
            <kw>Protocol</kw>
            <kw>cookie</kw>
        </keywords>
        <abstract>This document specifies a way to create a stateful session with HTTP requests and responses. It describes two new headers, Cookie and Set- Cookie, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal, but it can interoperate with HTTP/1.0 user agents that use Netscape's method. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2965</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2110</doc-id>
        <title>MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)</title>
        <author>
            <name>J. Palme</name>
        </author>
        <author>
            <name>A. Hopmann</name>
        </author>
        <date>
            <month>March</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41961</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>MHTML</kw>
            <kw>Hyper</kw>
            <kw>Text</kw>
            <kw>Markup</kw>
            <kw>Language</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract>This document describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display these objects, such as HTML objects, that can contain links represented by URIs. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2557</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2111</doc-id>
        <title>Content-ID and Message-ID Uniform Resource Locators</title>
        <author>
            <name>E. Levinson</name>
        </author>
        <date>
            <month>March</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9099</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>Hyper</kw>
            <kw>Text</kw>
            <kw>Markup</kw>
            <kw>Language</kw>
            <kw>URL</kw>
            <kw>MIME</kw>
        </keywords>
        <abstract>The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2392</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2112</doc-id>
        <title>The MIME Multipart/Related Content-type</title>
        <author>
            <name>E. Levinson</name>
        </author>
        <date>
            <month>March</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17052</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>Hyper</kw>
            <kw>Text</kw>
            <kw>Markup</kw>
            <kw>Language</kw>
            <kw>Multipurpose</kw>
            <kw>Internet,Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract>The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. This document defines the Multipart/Related content-type and provides examples of its use. [STANDARDS-TRACK] </abstract>
        <notes>RFC1872</notes>
        <obsoletes>
            <doc-id>RFC1872</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2387</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2113</doc-id>
        <title>IP Router Alert Option</title>
        <author>
            <name>D. Katz</name>
        </author>
        <date>
            <month>February</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7924</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>ROUT-ALERT</kw>
        </keywords>
        <abstract>This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2114</doc-id>
        <title>Data Link Switching Client Access Protocol</title>
        <author>
            <name>S. Chiang</name>
        </author>
        <author>
            <name>J. Lee</name>
        </author>
        <author>
            <name>H. Yasuda</name>
        </author>
        <date>
            <month>February</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>50872</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>DLSCAP </kw>
        </keywords>
        <abstract>This memo describes the Data Link Switching Client Access Protocol that is used between workstations and routers to transport SNA/ NetBIOS traffic over TCP sessions. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC2106</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2115</doc-id>
        <title>Management Information Base for Frame Relay DTEs Using SMIv2</title>
        <author>
            <name>C. Brown</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59950</char-count>
            <page-count>32</page-count>
        </format>
        <keywords>
            <kw>FRAME-MIB</kw>
            <kw>MIB</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP- based internets. In particular, it defines objects for managing Frame Relay interfaces on DTEs. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1315</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2116</doc-id>
        <title>X.500 Implementations Catalog-96</title>
        <author>
            <name>C. Apple</name>
        </author>
        <author>
            <name>K. Rossen</name>
        </author>
        <date>
            <month>April</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>243994</char-count>
            <page-count>164</page-count>
        </format>
        <keywords>
            <kw>Directory</kw>
            <kw>Services</kw>
            <kw>DSA</kw>
            <kw>DUA</kw>
            <kw>Agent</kw>
            <kw>Interfaces</kw>
        </keywords>
        <abstract>This document is a revision to [RFC 1632]: A Revised Catalog of Available X.500 Implementations and is based on the results of data collection via a WWW home page that enabled implementors to submit new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings. [RFC 1632] is a revision of [RFC 1292]. This document contains detailed description of 31 X.500 implementations - DSAs, DUAs, and DUA interfaces. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1632</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>FYI0011</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2117</doc-id>
        <title>Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification</title>
        <author>
            <name>D. Estrin</name>
        </author>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>A. Helmy</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>S. Deering</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>V. Jacobson</name>
        </author>
        <author>
            <name>C. Liu</name>
        </author>
        <author>
            <name>P. Sharma</name>
        </author>
        <author>
            <name>L. Wei</name>
        </author>
        <date>
            <month>June</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>151886</char-count>
            <page-count>66</page-count>
        </format>
        <abstract>This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC2362</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2118</doc-id>
        <title>Microsoft Point-To-Point Compression (MPPC) Protocol</title>
        <author>
            <name>G. Pall</name>
        </author>
        <date>
            <month>March</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17443</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
            <kw>PPP</kw>
        </keywords>
        <abstract>This document describes the use of the Microsoft Point to Point Compression protocol (also referred to as MPPC in this document) for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2119</doc-id>
        <title>Key words for use in RFCs to Indicate Requirement Levels</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <date>
            <month>March</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4723</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>Standards</kw>
            <kw>Track</kw>
            <kw>Documents</kw>
        </keywords>
        <abstract>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <is-also>
            <doc-id>BCP0014</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2120</doc-id>
        <title>Managing the X.500 Root Naming Context</title>
        <author>
            <name>D. Chadwick</name>
        </author>
        <date>
            <month>March</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30773</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>X.500-NAME</kw>
            <kw>ISO</kw>
            <kw>International</kw>
            <kw>Standards</kw>
            <kw>Organization</kw>
        </keywords>
        <abstract>This document describes the use of 1993 ISO X.500 Standard protocols for managing the root context. Whilst the ASN.1 is compatible with that of the X.500 Standard, the actual settings of the parameters are supplementary to that of the X.500 Standard. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2121</doc-id>
        <title>Issues affecting MARS Cluster Size</title>
        <author>
            <name>G. Armitage</name>
        </author>
        <date>
            <month>March</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26781</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>ATM</kw>
            <kw>Asynchronous</kw>
            <kw>Transfer</kw>
            <kw>Mode</kw>
            <kw>Multicast</kw>
            <kw>IP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document provides a qualitative look at the issues constraining a MARS Cluster's size, including the impact of VC limits in switches and NICs, geographical distribution of cluster members, and the use of VC Mesh or MCS modes to support multicast groups. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2122</doc-id>
        <title>VEMMI URL Specification</title>
        <author>
            <name>D. Mavrakis</name>
        </author>
        <author>
            <name>H. Layec</name>
        </author>
        <author>
            <name>K. Kartmann</name>
        </author>
        <date>
            <month>March</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25043</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>VEMMI-URL</kw>
            <kw>Uniform</kw>
            <kw>Resource</kw>
            <kw>Locator</kw>
            <kw>Enhanced</kw>
            <kw>Man-Machine</kw>
            <kw>Interface Videotex</kw>
        </keywords>
        <abstract>A new URL scheme, "vemmi" is defined. VEMMI is a new international standard for on-line multimedia services, that is both an ITU-T (International Telecommunications Union, ex. CCITT) International Standard (T.107) and an European Standard (ETSI European Telecommunications Standard Institute) standard (ETS 300 382, obsoleted by ETS 300 709). [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2123</doc-id>
        <title>Traffic Flow Measurement: Experiences with NeTraMet</title>
        <author>
            <name>N. Brownlee</name>
        </author>
        <date>
            <month>March</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>81874</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>Meter</kw>
            <kw>Reader</kw>
            <kw>Network</kw>
        </keywords>
        <abstract>This memo records experiences in implementing and using the Traffic Flow Measurement Architecture and Meter MIB. It discusses the implementation of NeTraMet (a traffic meter) and NeMaC (a combined manager and meter reader), considers the writing of meter rule sets and gives some guidance on setting up a traffic flow measurement system using NeTraMet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2124</doc-id>
        <title>Cabletron's Light-weight Flow Admission Protocol Specification Version 1.0</title>
        <author>
            <name>P. Amsden</name>
        </author>
        <author>
            <name>J. Amweg</name>
        </author>
        <author>
            <name>P. Calato</name>
        </author>
        <author>
            <name>S. Bensley</name>
        </author>
        <author>
            <name>G. Lyons</name>
        </author>
        <date>
            <month>March</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47912</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>LFAP</kw>
        </keywords>
        <abstract>This document specifies the protocol between the switch Connection Control Entity (CCE) and the external FAS. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2125</doc-id>
        <title>The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP)</title>
        <author>
            <name>C. Richards</name>
        </author>
        <author>
            <name>K. Smith</name>
        </author>
        <date>
            <month>March</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49213</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>BAP-BACP</kw>
            <kw>Point-to-Point</kw>
            <kw>datagram</kw>
            <kw>multilink</kw>
        </keywords>
        <abstract>This document proposes a method to manage the dynamic bandwidth allocation of implementations supporting the PPP multilink protocol. This is done by defining the Bandwidth Allocation Protocol (BAP), as well as its associated control protocol, the Bandwidth Allocation Control Protocol (BACP). [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2126</doc-id>
        <title>ISO Transport Service on top of TCP (ITOT)</title>
        <author>
            <name>Y. Pouffary</name>
        </author>
        <author>
            <name>A. Young</name>
        </author>
        <date>
            <month>March</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51032</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>ITOT</kw>
            <kw>International</kw>
            <kw>Standards</kw>
            <kw>Organization</kw>
            <kw>Transmission</kw>
            <kw>Control</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document is a revision to STD35, RFC1006. This document describes the mechanism to allow ISO Transport Services to run over TCP over IPv4 or IPv6. It also defines a number of new features, which are not provided in RFC1006. [STANDARDS-TRACK] </abstract>
        <updates>
            <doc-id>RFC1006</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2127</doc-id>
        <title>ISDN Management Information Base using SMIv2</title>
        <author>
            <name>G. Roeck</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>95994</char-count>
            <page-count>49</page-count>
        </format>
        <keywords>
            <kw>ISDN-MIB</kw>
            <kw>MIB</kw>
            <kw>ISDN</kw>
            <kw>Integrated</kw>
            <kw>Services</kw>
            <kw>Digital</kw>
            <kw>Network</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a minimal set of managed objects for SNMP-based management of ISDN terminal interfaces. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2128</doc-id>
        <title>Dial Control Management Information Base using SMIv2</title>
        <author>
            <name>G. Roeck</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>66153</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>DC-MIB</kw>
            <kw>MIB</kw>
            <kw>ISDN</kw>
            <kw>Integrated</kw>
            <kw>Services</kw>
            <kw>Digital</kw>
            <kw>Network</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing demand access circuits, including ISDN. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2129</doc-id>
        <title>Toshiba's Flow Attribute Notification Protocol (FANP) Specification</title>
        <author>
            <name>K. Nagami</name>
        </author>
        <author>
            <name>Y. Katsube</name>
        </author>
        <author>
            <name>Y. Shobatake</name>
        </author>
        <author>
            <name>A. Mogi</name>
        </author>
        <author>
            <name>S. Matsuzawa</name>
        </author>
        <author>
            <name>T. Jinmei</name>
        </author>
        <author>
            <name>H. Esaki</name>
        </author>
        <date>
            <month>April</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41137</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>packet</kw>
            <kw>flow</kw>
            <kw>datalink</kw>
            <kw>mapping</kw>
        </keywords>
        <abstract>This memo discusses Flow Attribute Notification Protocol (FANP), which is a protocol between neighbor nodes for the management of cut-through packet forwarding functionalities. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2130</doc-id>
        <title>The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996</title>
        <author>
            <name>C. Weider</name>
        </author>
        <author>
            <name>C. Preston</name>
        </author>
        <author>
            <name>K. Simonsen</name>
        </author>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <author>
            <name>R. Atkinson</name>
        </author>
        <author>
            <name>M. Crispin</name>
        </author>
        <author>
            <name>P. Svanberg</name>
        </author>
        <date>
            <month>April</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63443</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Architecture</kw>
            <kw>Board</kw>
            <kw>interoperability</kw>
        </keywords>
        <abstract>This report details the conclusions of an IAB-sponsored invitational workshop held 29 February - 1 March, 1996, to discuss the use of character sets on the Internet. It motivates the need to have character set handling in Internet protocols which transmit text, provides a conceptual framework for specifying character sets, recommends the use of MIME tagging for transmitted text, recommends a default character set *without* stating that there is no need for other character sets, and makes a series of recommendations to the IAB, IANA, and the IESG for furthering the integration of the character set framework into text transmission protocols. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2131</doc-id>
        <title>Dynamic Host Configuration Protocol</title>
        <author>
            <name>R. Droms</name>
        </author>
        <date>
            <month>March</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>113738</char-count>
            <page-count>45</page-count>
        </format>
        <keywords>
            <kw>DHCP</kw>
        </keywords>
        <abstract>The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1541</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3396</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2132</doc-id>
        <title>DHCP Options and BOOTP Vendor Extensions</title>
        <author>
            <name>S. Alexander</name>
        </author>
        <author>
            <name>R. Droms</name>
        </author>
        <date>
            <month>March</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63670</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>DHCP-BOOTP</kw>
            <kw>Dynamic</kw>
            <kw>Host</kw>
            <kw>Configuration</kw>
            <kw>Protocol</kw>
            <kw>Bootstrap</kw>
        </keywords>
        <abstract>This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1533</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3442</doc-id>
            <doc-id>RFC3942</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2133</doc-id>
        <title>Basic Socket Interface Extensions for IPv6</title>
        <author>
            <name>R. Gilligan</name>
        </author>
        <author>
            <name>S. Thomson</name>
        </author>
        <author>
            <name>J. Bound</name>
        </author>
        <author>
            <name>W. Stevens</name>
        </author>
        <date>
            <month>April</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>69737</char-count>
            <page-count>32</page-count>
        </format>
        <keywords>
            <kw>application</kw>
            <kw>program</kw>
            <kw>interface</kw>
            <kw>API</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>addresses</kw>
        </keywords>
        <abstract>This memo defines a set of extensions to the socket interface to support the larger address size and new features of IPv6. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC2553</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2134</doc-id>
        <title>Articles of Incorporation of Internet Society</title>
        <author>
            <name>ISOC Board of Trustees</name>
        </author>
        <date>
            <month>April</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9131</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>ISOC</kw>
        </keywords>
        <abstract>These are the articles of incorporation of the Internet Society. They are published for the information of the IETF community at the request of the poisson working group. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2135</doc-id>
        <title>Internet Society By-Laws</title>
        <author>
            <name>ISOC Board of Trustees</name>
        </author>
        <date>
            <month>April</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20467</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>ISOC</kw>
        </keywords>
        <abstract>These are the by-laws of the Internet Society, as amended, as of June 1996. They are published for the information of the IETF community at the request of the poisson working group. Please refer to the ISOC web page (www.isoc.org) for the current version of the by-laws. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2136</doc-id>
        <title>Dynamic Updates in the Domain Name System (DNS UPDATE)</title>
        <author>
            <name>P. Vixie</name>
            <title>Editor</title>
        </author>
        <author>
            <name> S. Thomson</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>J. Bound</name>
        </author>
        <date>
            <month>April</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>56354</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>DNS-UPDATE</kw>
            <kw>database</kw>
            <kw>opcode</kw>
            <kw>zone</kw>
        </keywords>
        <abstract>Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR. [STANDARDS-TRACK] </abstract>
        <updates>
            <doc-id>RFC1035</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC3007</doc-id>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4035</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2137</doc-id>
        <title>Secure Domain Name System Dynamic Update</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>April</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24824</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>SDNSDU</kw>
            <kw>DNS</kw>
            <kw>digital</kw>
            <kw>signatures</kw>
            <kw>cryptographic</kw>
        </keywords>
        <abstract>This memo describes how to use DNSSEC digital signatures covering requests and data to secure updates and restrict updates to those authorized to perform them as indicated by the updater's possession of cryptographic keys. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3007</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1035</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2138</doc-id>
        <title>Remote Authentication Dial In User Service (RADIUS)</title>
        <author>
            <name>C. Rigney</name>
        </author>
        <author>
            <name>A. Rubens</name>
        </author>
        <author>
            <name>W. Simpson</name>
        </author>
        <author>
            <name>S. Willens</name>
        </author>
        <date>
            <month>April</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>120407</char-count>
            <page-count>65</page-count>
        </format>
        <keywords>
            <kw>RADIUS</kw>
            <kw>encryption</kw>
            <kw>NAS</kw>
            <kw>Network</kw>
            <kw>Access</kw>
            <kw>Server</kw>
        </keywords>
        <abstract>This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2058</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2865</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2139</doc-id>
        <title>RADIUS Accounting</title>
        <author>
            <name>C. Rigney</name>
        </author>
        <date>
            <month>April</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44919</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>RADIUS-ACC</kw>
            <kw>remote</kw>
            <kw>authentication</kw>
            <kw>dial</kw>
            <kw>in</kw>
            <kw>user</kw>
            <kw>service</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract>This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC2059</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2866</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2140</doc-id>
        <title>TCP Control Block Interdependence</title>
        <author>
            <name>J. Touch</name>
        </author>
        <date>
            <month>April</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26032</char-count>
            <page-count>11</page-count>
        </format>
        <abstract>This memo makes the case for interdependent TCP control blocks, where part of the TCP state is shared among similar concurrent connections, or across similar connection instances. TCP state includes a combination of parameters, such as connection state, current round-trip time estimates, congestion control information, and process information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2141</doc-id>
        <title>URN Syntax</title>
        <author>
            <name>R. Moats</name>
        </author>
        <date>
            <month>May</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14077</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>URN-SYNTAX</kw>
            <kw>Uniform</kw>
            <kw>Resource</kw>
            <kw>Names</kw>
        </keywords>
        <abstract>Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document sets forward the canonical syntax for URNs. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2142</doc-id>
        <title>Mailbox Names for Common Services, Roles and Functions</title>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>May</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12195</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>MAIL-SERV</kw>
            <kw>email</kw>
            <kw>internet</kw>
            <kw>addresses</kw>
        </keywords>
        <abstract>This specification enumerates and describes Internet mail addresses (mailbox name @ host reference) to be used when contacting personnel at an organization. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2143</doc-id>
        <title>Encapsulating IP with the Small Computer System Interface</title>
        <author>
            <name>B. Elliston</name>
        </author>
        <date>
            <month>May</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10749</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>IP-SCSI</kw>
            <kw>SCSI</kw>
        </keywords>
        <abstract>This document outlines a protocol for connecting hosts running the TCP/IP protocol suite over a Small Computer System Interface (SCSI) bus. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2144</doc-id>
        <title>The CAST-128 Encryption Algorithm</title>
        <author>
            <name>C. Adams</name>
        </author>
        <date>
            <month>May</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37532</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>CAST-128 </kw>
        </keywords>
        <abstract>There is a need in the Internet community for an unencumbered encryption algorithm with a range of key sizes that can provide security for a variety of cryptographic applications and protocols. This document describes an existing algorithm that can be used to satisfy this requirement. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2145</doc-id>
        <title>Use and Interpretation of HTTP Version Numbers</title>
        <author>
            <name>J. C. Mogul</name>
        </author>
        <author>
            <name>R. Fielding</name>
        </author>
        <author>
            <name>J. Gettys</name>
        </author>
        <author>
            <name>H. Frystyk</name>
        </author>
        <date>
            <month>May</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13659</char-count>
            <page-count>7</page-count>
        </format>
        <abstract>HTTP request and response messages include an HTTP protocol version number. Some confusion exists concerning the proper use and interpretation of HTTP version numbers, and concerning interoperability of HTTP implementations of different protocol versions. This document is an attempt to clarify the situation. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2146</doc-id>
        <title>U.S. Government Internet Domain Names</title>
        <author>
            <name>Federal Networking Council</name>
        </author>
        <date>
            <month>May</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26564</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>Gov</kw>
            <kw>FED.US</kw>
        </keywords>
        <abstract>This memo provides an update and clarification to RFC 1816. This document describes the registration policies for the top-level domain ".GOV". The purpose of the domain is to provide naming conventions that identify US Federal government agencies in order to facilitate access to their electronic resources. This memo provides guidance for registrations by Federal Agencies that avoids name duplication and facilitates responsiveness to the public. It restricts registrations to coincide with the approved structure of the US government and the advice of its Chief Information Officers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1816</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2147</doc-id>
        <title>TCP and UDP over IPv6 Jumbograms</title>
        <author>
            <name>D. Borman</name>
        </author>
        <date>
            <month>May</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>1883</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>IPv6-Jumbo</kw>
            <kw>User</kw>
            <kw>Datagram</kw>
            <kw>Protocol</kw>
            <kw>Terminal</kw>
            <kw>Control</kw>
            <kw>Internet</kw>
        </keywords>
        <abstract>IPv6 supports datagrams larger than 65535 bytes long, often referred to as jumbograms, through use of the Jumbo Payload hop-by-hop option. The UDP protocol has a 16-bit length field that keeps it from being able to make use of jumbograms, and though TCP does not have a length field, both the MSS option and the Urgent field are constrained by 16-bits. This document describes some simple changes that can be made to allow TCP and UDP to make use of IPv6 jumbograms. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2675</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2148</doc-id>
        <title>Deployment of the Internet White Pages Service</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <author>
            <name>P. Jurg</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31539</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>X. 500</kw>
            <kw>data structure</kw>
            <kw>naming scheme</kw>
            <kw>IWPS</kw>
        </keywords>
        <abstract>This document describes the way in which the Internet White Pages Service is best exploited using today's experience, today's protocols, today's products and today's procedures. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <is-also>
            <doc-id>BCP0015</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2149</doc-id>
        <title>Multicast Server Architectures for MARS-based ATM multicasting</title>
        <author>
            <name>R. Talpade</name>
        </author>
        <author>
            <name>M. Ammar</name>
        </author>
        <date>
            <month>May</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42007</char-count>
            <page-count>18</page-count>
        </format>
        <abstract>This memo provides details on the design and implementation of an MCS, building on the core mechanisms defined in RFC 2022. It also provides a mechanism for using multiple MCSs per group for providing fault tolerance. This approach can be used with RFC 2022 based MARS server and clients, without needing any change in their functionality. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2150</doc-id>
        <title>Humanities and Arts: Sharing Center Stage on the Internet</title>
        <author>
            <name>J. Max</name>
        </author>
        <author>
            <name>W. Stickle</name>
        </author>
        <date>
            <month>October</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>154037</char-count>
            <page-count>62</page-count>
        </format>
        <keywords>
            <kw>informational</kw>
            <kw>infrastructure</kw>
            <kw>guide</kw>
            <kw>introduction</kw>
        </keywords>
        <abstract>The purpose of this document is to provide members of the Arts and Humanities communities with an introduction to the Internet as a valuable tool, resource, and medium for the creation, presentation, and preservation of Arts and Humanities-based content. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <is-also>
            <doc-id>FYI0031</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2151</doc-id>
        <title>A Primer On Internet and TCP/IP Tools and Utilities</title>
        <author>
            <name>G. Kessler</name>
        </author>
        <author>
            <name>S. Shepard</name>
        </author>
        <date>
            <month>June</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>114130</char-count>
            <page-count>52</page-count>
        </format>
        <keywords>
            <kw>resource</kw>
            <kw>guide</kw>
            <kw>user</kw>
        </keywords>
        <abstract>This memo is an introductory guide to many of the most commonly- available TCP/IP and Internet tools and utilities. It also describes discussion lists accessible from the Internet, ways to obtain Internet and TCP/IP documents, and some resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1739</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>FYI0030</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2152</doc-id>
        <title>UTF-7 A Mail-Safe Transformation Format of Unicode</title>
        <author>
            <name>D. Goldsmith</name>
        </author>
        <author>
            <name>M. Davis</name>
        </author>
        <date>
            <month>May</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28065</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>UTF-7</kw>
        </keywords>
        <abstract>This document describes a transformation format of Unicode that contains only 7-bit ASCII octets and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. It also specifies how this transformation format is used in the context of MIME and RFC 1641, "Using Unicode with MIME". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1642</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2153</doc-id>
        <title>PPP Vendor Extensions</title>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>May</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10780</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>PPP-EXT</kw>
            <kw>Point-to-Point</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection; and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <updates>
            <doc-id>RFC1661</doc-id>
            <doc-id>RFC1962</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2154</doc-id>
        <title>OSPF with Digital Signatures</title>
        <author>
            <name>S. Murphy</name>
        </author>
        <author>
            <name>M. Badger</name>
        </author>
        <author>
            <name>B. Wellington</name>
        </author>
        <date>
            <month>June</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>72701</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>OSPF-DIG</kw>
        </keywords>
        <abstract>This memo describes the extensions to OSPF required to add digital signature authentication to Link State data, and to provide a certification mechanism for router data. Added LSA processing and key management is detailed. A method for migration from, or co-existence with, standard OSPF V2 is described. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2155</doc-id>
        <title>Definitions of Managed Objects for APPN using SMIv2</title>
        <author>
            <name>B. Clouston</name>
        </author>
        <author>
            <name>B. Moore</name>
        </author>
        <date>
            <month>June</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>213809</char-count>
            <page-count>124</page-count>
        </format>
        <keywords>
            <kw>APPN-MIB</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol. [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2455</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2156</doc-id>
        <title>MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME</title>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>280385</char-count>
            <page-count>144</page-count>
        </format>
        <keywords>
            <kw>MIXER</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>message</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document relates primarily to the ITU-T 1988 and 1992 X.400 Series Recommendations / ISO IEC 10021 International Standard. This ISO/ITU-T standard is referred to in this document as "X.400", which is a convenient shorthand. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC0987</doc-id>
            <doc-id>RFC1026</doc-id>
            <doc-id>RFC1138</doc-id>
            <doc-id>RFC1148</doc-id>
            <doc-id>RFC1327</doc-id>
            <doc-id>RFC1495</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC0822</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2157</doc-id>
        <title>Mapping between X.400 and RFC-822/MIME Message Bodies</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>92554</char-count>
            <page-count>49</page-count>
        </format>
        <keywords>
            <kw>mixer</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document defines how to map body parts of X.400 messages into MIME entities and vice versa, including the handling of multipart messages and forwarded messages. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2158</doc-id>
        <title>X.400 Image Body Parts</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5547</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>mixer</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document contains the body parts defined in RFC 1495 for carrying image formats that were originally defined in MIME through an X.400 system. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2159</doc-id>
        <title>A MIME Body Part for FAX</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11471</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>mixer</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document contains the definitions, originally contained in RFC 1494, on how to carry CCITT G3Fax in MIME, and how to translate it to its X.400 representation. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2160</doc-id>
        <title>Carrying PostScript in X.400 and MIME</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7059</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>mixer</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document describes methods for carrying PostScript information in the two standard mail systems MIME and X.400, and the conversion between them. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2161</doc-id>
        <title>A MIME Body Part for ODA</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8009</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>MIME-ODA</kw>
            <kw>mixer</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document contains the definitions, originally contained in RFC 1495 and RFC 1341, on how to carry ODA in MIME, and how to translate it to its X.400 representation. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2162</doc-id>
        <title>MaXIM-11 - Mapping between X.400 / Internet mail and  Mail-11 mail</title>
        <author>
            <name>C. Allocchio</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>58553</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>MAP-MAIL</kw>
            <kw>mixer</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>mime</kw>
        </keywords>
        <abstract>The standard referred shortly into this document as "X.400" relates to the ISO/IEC 10021 - CCITT 1984, 1988 and 1992 X.400 Series Recommendations covering the Message Oriented Text Interchange Service (MOTIS). This document covers the Inter Personal Messaging System (IPMS) only. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoletes>
            <doc-id>RFC1405</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2163</doc-id>
        <title>Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM)</title>
        <author>
            <name>C. Allocchio</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>58789</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>DNS-MCGAM</kw>
            <kw>mime</kw>
            <kw>internet</kw>
            <kw>enhanced</kw>
            <kw>Relay</kw>
            <kw>Multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>x.400</kw>
            <kw>mixer</kw>
        </keywords>
        <abstract>This memo is the complete technical specification to store in the Internet Domain Name System (DNS) the mapping information (MCGAM) needed by MIXER conformant e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1664</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3597</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2164</doc-id>
        <title>Use of an X.500/LDAP directory to support MIXER address mapping</title>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16701</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>mime</kw>
            <kw>internet</kw>
            <kw>x,.400</kw>
            <kw>enhanced</kw>
            <kw>relay</kw>
        </keywords>
        <abstract>This specification defines how to represent and maintain these mappings (MIXER Conformant Global Address Mappings of MCGAMs) in an X.500 or LDAP directory. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1838</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2165</doc-id>
        <title>Service Location Protocol</title>
        <author>
            <name>J. Veizades</name>
        </author>
        <author>
            <name>E. Guttman</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>S. Kaplan</name>
        </author>
        <date>
            <month>June</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>169889</char-count>
            <page-count>72</page-count>
        </format>
        <keywords>
            <kw>SLP</kw>
        </keywords>
        <abstract>The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet no longer need so much static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. [STANDARDS-TRACK] </abstract>
        <updated-by>
            <doc-id>RFC2608</doc-id>
            <doc-id>RFC2609</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2166</doc-id>
        <title>APPN Implementer's Workshop Closed Pages Document DLSw v2.0 Enhancements</title>
        <author>
            <name>D. Bryant</name>
        </author>
        <author>
            <name>P. Brittain</name>
        </author>
        <date>
            <month>June</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>75527</char-count>
            <page-count>34</page-count>
        </format>
        <abstract>This document specifies a set of extensions to RFC 1795 designed to improve the scalability of DLSw clarifications to RFC 1795 in the light of the implementation experience to-date. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2167</doc-id>
        <title>Referral Whois (RWhois) Protocol V1.5</title>
        <author>
            <name>S. Williamson</name>
        </author>
        <author>
            <name>M. Kosters</name>
        </author>
        <author>
            <name>D. Blacka</name>
        </author>
        <author>
            <name>J. Singh</name>
        </author>
        <author>
            <name>K. Zeilstra</name>
        </author>
        <date>
            <month>June</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>136355</char-count>
            <page-count>69</page-count>
        </format>
        <keywords>
            <kw>RWHOIS</kw>
        </keywords>
        <abstract>This memo describes Version 1.5 of the client/server interaction of RWhois. RWhois provides a distributed system for the discovery, retrieval, and maintenance of directory information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1714</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2168</doc-id>
        <title>Resolution of Uniform Resource Identifiers using the Domain Name System</title>
        <author>
            <name>R. Daniel</name>
        </author>
        <author>
            <name>M. Mealling</name>
        </author>
        <date>
            <month>June</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46528</char-count>
            <page-count>20</page-count>
        </format>
        <abstract>The requirements document for URN resolution systems defines the concept of a "resolver discovery service". This document describes the first, experimental, RDS. It is implemented by a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC3401</doc-id>
            <doc-id>RFC3402</doc-id>
            <doc-id>RFC3403</doc-id>
            <doc-id>RFC3404</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC2915</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2169</doc-id>
        <title>A Trivial Convention for using HTTP in URN Resolution</title>
        <author>
            <name>R. Daniel</name>
        </author>
        <date>
            <month>June</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17763</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document specifies the "THTTP" resolution protocol - a trivial convention for encoding resolution service requests and responses as HTTP 1.0 or 1.1 requests and responses. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2170</doc-id>
        <title>Application REQuested IP over ATM (AREQUIPA)</title>
        <author>
            <name>W. Almesberger</name>
        </author>
        <author>
            <name>J. Le Boudec</name>
        </author>
        <author>
            <name>P. Oechslin</name>
        </author>
        <date>
            <month>July</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22874</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document specifies a method for allowing ATM-attached hosts that have direct ATM connectivity to set up end-to-end IP over ATM connections within the reachable ATM cloud, on request from applications, and for the exclusive use by the requesting applications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2171</doc-id>
        <title>MAPOS - Multiple Access Protocol over SONET/SDH Version 1</title>
        <author>
            <name>K. Murakami</name>
        </author>
        <author>
            <name>M. Maruyama</name>
        </author>
        <date>
            <month>June</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17480</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>MAPOS-SONET</kw>
        </keywords>
        <abstract>This memo documents a multiple access protocol for transmission of network-protocol datagrams, encapsulated in High-Level Data Link Control (HDLC) frames, over SONET/SDH. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2172</doc-id>
        <title>MAPOS Version 1 Assigned Numbers</title>
        <author>
            <name>M. Maruyama</name>
        </author>
        <author>
            <name>K. Murakami</name>
        </author>
        <date>
            <month>June</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>4857</char-count>
            <page-count>3</page-count>
        </format>
        <abstract>This memo documents the parameters used in the Multiple Access Protocol over SONET/SDH Version 1. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2173</doc-id>
        <title>A MAPOS version 1 Extension - Node Switch Protocol</title>
        <author>
            <name>K. Murakami</name>
        </author>
        <author>
            <name>M. Maruyama</name>
        </author>
        <date>
            <month>June</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12251</char-count>
            <page-count>6</page-count>
        </format>
        <abstract>This document describes a MAPOS extension, Node Switch Protocol, for automatic node address assignment. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2174</doc-id>
        <title>A MAPOS version 1 Extension - Switch-Switch Protocol</title>
        <author>
            <name>K. Murakami</name>
        </author>
        <author>
            <name>M. Maruyama</name>
        </author>
        <date>
            <month>June</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47967</char-count>
            <page-count>22</page-count>
        </format>
        <abstract>This memo documents a MAPOS (Multiple Access Protocol over SONET/SDH) version 1 extension, Switch Switch Protocol which provides dynamic routing for unicast, broadcast, and multicast. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2175</doc-id>
        <title>MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing</title>
        <author>
            <name>K. Murakami</name>
        </author>
        <author>
            <name>M. Maruyama</name>
        </author>
        <date>
            <month>June</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11677</char-count>
            <page-count>6</page-count>
        </format>
        <abstract>This memo documents MAPOS 16, a multiple access protocol for transmission of network-protocol datagrams, encapsulated in HDLC frames with 16 bit addressing, over SONET/SDH. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2176</doc-id>
        <title>IPv4 over MAPOS Version 1</title>
        <author>
            <name>K. Murakami</name>
        </author>
        <author>
            <name>M. Maruyama</name>
        </author>
        <date>
            <month>June</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12305</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>IPV4-MAPOS</kw>
        </keywords>
        <abstract>This memo documents a mechanism for supporting Version 4 of the Internet Protocol (IPv4) on Version 1 of the Multiple Access Protocol over SONET/SDH. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2177</doc-id>
        <title>IMAP4 IDLE command</title>
        <author>
            <name>B. Leiba</name>
        </author>
        <date>
            <month>June</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6770</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>IMAP4-IDLE</kw>
        </keywords>
        <abstract>This document specifies the syntax of an IDLE command, which will allow a client to tell the server that it's ready to accept such real-time updates. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2178</doc-id>
        <title>OSPF Version 2</title>
        <author>
            <name>J. Moy</name>
        </author>
        <date>
            <month>July</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>495866</char-count>
            <page-count>211</page-count>
        </format>
        <keywords>
            <kw>Open</kw>
            <kw>Shortest</kw>
            <kw>Path</kw>
            <kw>First</kw>
            <kw>routing</kw>
            <kw>Autonomous</kw>
            <kw>system</kw>
            <kw>AS</kw>
        </keywords>
        <abstract>This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1583</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2328</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2179</doc-id>
        <title>Network Security For Trade Shows</title>
        <author>
            <name>A. Gwinn</name>
        </author>
        <date>
            <month>July</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20690</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>network</kw>
            <kw>system</kw>
            <kw>attacks</kw>
        </keywords>
        <abstract>This document is designed to assist vendors and other participants in trade shows, such as Networld+Interop, in designing effective protection against network and system attacks by unauthorized individuals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2180</doc-id>
        <title>IMAP4 Multi-Accessed Mailbox Practice</title>
        <author>
            <name>M. Gahrns</name>
        </author>
        <date>
            <month>July</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24750</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
            <kw>Client</kw>
            <kw>Server</kw>
        </keywords>
        <abstract>The behavior described in this document reflects the practice of some existing servers or behavior that the consensus of the IMAP mailing list has deemed to be reasonable. The behavior described within this document is believed to be [RFC-2060] compliant. However, this document is not meant to define IMAP4 compliance, nor is it an exhaustive list of valid IMAP4 behavior. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2181</doc-id>
        <title>Clarifications to the DNS Specification</title>
        <author>
            <name>R. Elz</name>
        </author>
        <author>
            <name>R. Bush</name>
        </author>
        <date>
            <month>July</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36989</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>DNS-CLAR</kw>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
        </keywords>
        <abstract>This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS TRACK] </abstract>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
            <doc-id>RFC1123</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC2535</doc-id>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4035</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2182</doc-id>
        <title>Selection and Operation of Secondary DNS Servers</title>
        <author>
            <name>R. Elz</name>
        </author>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>S. Bradner</name>
        </author>
        <author>
            <name>M. Patton</name>
        </author>
        <date>
            <month>July</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27456</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
            <kw>delegated</kw>
            <kw>zone</kw>
        </keywords>
        <abstract>This document discusses the selection of secondary servers for DNS zones.The number of servers appropriate for a zone is also discussed, and some general secondary server maintenance issues considered. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <is-also>
            <doc-id>BCP0016</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2183</doc-id>
        <title>Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</title>
        <author>
            <name>R. Troost</name>
        </author>
        <author>
            <name>S. Dorner</name>
        </author>
        <author>
            <name>K. Moore</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23150</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>inline</kw>
            <kw>attachment</kw>
            <kw>MIME</kw>
            <kw>Mail</kw>
            <kw>Multimedia</kw>
            <kw>EMail</kw>
        </keywords>
        <abstract>This memo provides a mechanism whereby messages conforming to the MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049] can convey presentational information. It specifies the "Content- Disposition" header field, which is optional and valid for any MIME entity ("message" or "body part"). [STANDARDS-TRACK] </abstract>
        <updates>
            <doc-id>RFC1806</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC2184</doc-id>
            <doc-id>RFC2231</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2184</doc-id>
        <title>MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations</title>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>K. Moore</name>
        </author>
        <date>
            <month>August</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17635</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>mail</kw>
            <kw>Multimedia</kw>
            <kw>EMail</kw>
        </keywords>
        <abstract>This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2231</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2045</doc-id>
            <doc-id>RFC2047</doc-id>
            <doc-id>RFC2183</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2185</doc-id>
        <title>Routing Aspects of IPv6 Transition</title>
        <author>
            <name>R. Callon</name>
        </author>
        <author>
            <name>D. Haskin</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31281</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>address</kw>
            <kw>network</kw>
            <kw>tunneling</kw>
        </keywords>
        <abstract>This document gives an overview of the routing aspects of the IPv6 transition. It is based on the protocols defined in the document "Transition Mechanisms for IPv6 Hosts and Routers." Readers should be familiar with the transition mechanisms before reading this document. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2186</doc-id>
        <title>Internet Cache Protocol (ICP), version 2</title>
        <author>
            <name>D. Wessels</name>
        </author>
        <author>
            <name>K. Claffy</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18808</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>ICP</kw>
            <kw>www</kw>
            <kw>web</kw>
            <kw>http</kw>
            <kw>hypertext</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document describes version 2 of the Internet Cache Protocol (ICPv2) as currently implemented in two World-Wide Web proxy cache packages. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2187</doc-id>
        <title>Application of Internet Cache Protocol (ICP), version 2</title>
        <author>
            <name>D. Wessels</name>
        </author>
        <author>
            <name>K. Claffy</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51662</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>web</kw>
            <kw>www</kw>
            <kw>url</kw>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>identifier</kw>
        </keywords>
        <abstract>This document describes the application of ICPv2 (Internet Cache Protocol version 2, RFC2186) to Web caching. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2188</doc-id>
        <title>AT&amp;T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2</title>
        <author>
            <name>M. Banan</name>
        </author>
        <author>
            <name>M. Taylor</name>
        </author>
        <author>
            <name>J. Cheng</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>118374</char-count>
            <page-count>57</page-count>
        </format>
        <keywords>
            <kw>ESRO</kw>
            <kw>RPC</kw>
            <kw>Remote</kw>
            <kw>Procedure</kw>
            <kw>Call</kw>
            <kw>Wireless</kw>
        </keywords>
        <abstract>This document specifies the service model, the notation and protocol for Efficient Short Remote Operations (ESRO). This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2189</doc-id>
        <title>Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification --</title>
        <author>
            <name>A. Ballardie</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52043</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>Inter-Domain-Protocol</kw>
            <kw>IDMR</kw>
        </keywords>
        <abstract>This document describes the Core Based Tree (CBT version 2) network layer multicast routing protocol. CBT builds a shared multicast distribution tree per group, and is suited to inter- and intra-domain multicast routing. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2190</doc-id>
        <title>RTP Payload Format for H.263 Video Streams</title>
        <author>
            <name>C. Zhu</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26409</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>real-time</kw>
            <kw>transfer</kw>
        </keywords>
        <abstract>This document specifies the payload format for encapsulating an H.263 bitstream in the Real-Time Transport Protocol (RTP). [STANDARDS TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2191</doc-id>
        <title>VENUS - Very Extensive Non-Unicast Service</title>
        <author>
            <name>G. Armitage</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31316</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>multicast</kw>
            <kw>IP</kw>
            <kw>ATM</kw>
        </keywords>
        <abstract>This document focuses exclusively on the problems associated with extending the MARS model to cover multiple clusters or clusters spanning more than one subnet. It describes a hypothetical solution, dubbed "Very Extensive NonUnicast Service" (VENUS), and shows how complex such a service would be. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2192</doc-id>
        <title>IMAP URL Scheme</title>
        <author>
            <name>C. Newman</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31426</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>IMAP-URL</kw>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
            <kw>Uniform</kw>
            <kw>Resource</kw>
            <kw>Identifiers</kw>
        </keywords>
        <abstract>This document defines a URL scheme for referencing objects on an IMAP server. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2193</doc-id>
        <title>IMAP4 Mailbox Referrals</title>
        <author>
            <name>M. Gahrns</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16248</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>IMAP4MAIL</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
            <kw>messages</kw>
        </keywords>
        <abstract>Mailbox referrals allow clients to seamlessly access mailboxes that are distributed across several IMAP4 servers. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2194</doc-id>
        <title>Review of Roaming Implementations</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>J. Lu</name>
        </author>
        <author>
            <name>J. Alsop</name>
        </author>
        <author>
            <name>J. Ding</name>
        </author>
        <author>
            <name>W. Wang</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>81533</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
            <kw>ISP</kw>
            <kw>Internet</kw>
            <kw>Server</kw>
            <kw>Provider</kw>
        </keywords>
        <abstract>This document reviews the design and functionality of existing roaming implementations. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2195</doc-id>
        <title>IMAP/POP AUTHorize Extension for Simple Challenge/Response</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>R. Catoe</name>
        </author>
        <author>
            <name>P. Krumviede</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10468</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>IMAPPOPAU</kw>
            <kw>Post</kw>
            <kw>Office</kw>
            <kw>Protocol</kw>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
        </keywords>
        <abstract>This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. [STANDARDS TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2095</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2196</doc-id>
        <title>Site Security Handbook</title>
        <author>
            <name>B. Fraser</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>191772</char-count>
            <page-count>75</page-count>
        </format>
        <abstract>This handbook is a guide to developing computer security policies and procedures for sites that have systems on the Internet. The purpose of this handbook is to provide practical guidance to administrators trying to secure their information and services. The subjects covered include policy content and formation, a broad range of technical system and network security topics, and security incident response. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1244</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>FYI0008</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2197</doc-id>
        <title>SMTP Service Extension for Command Pipelining</title>
        <author>
            <name>N. Freed</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15003</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>SMTP-Pipe</kw>
            <kw>simple</kw>
            <kw>mail</kw>
            <kw>transfer</kw>
            <kw>TCP</kw>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1854</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2920</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2198</doc-id>
        <title>RTP Payload for Redundant Audio Data</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>I. Kouvelas</name>
        </author>
        <author>
            <name>O. Hodson</name>
        </author>
        <author>
            <name>V. Hardman</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>J.C. Bolot</name>
        </author>
        <author>
            <name>A. Vega-Garcia</name>
        </author>
        <author>
            <name>S. Fosse-Parisis</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25166</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>RTP-RAD</kw>
        </keywords>
        <abstract>This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2199</doc-id>
        <title>Request for Comments Summary RFC Numbers 2100-2199</title>
        <author>
            <name>A. Ramos</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47664</char-count>
            <page-count>23</page-count>
        </format>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2200</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>June</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>94506</char-count>
            <page-count>39</page-count>
        </format>
        <keywords>
            <kw>IAB</kw>
            <kw>official</kw>
            <kw>protocol</kw>
            <kw>standards</kw>
        </keywords>
        <abstract>A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1250</doc-id>
            <doc-id>RFC2000</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2300</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2201</doc-id>
        <title>Core Based Trees (CBT) Multicast Routing Architecture</title>
        <author>
            <name>A. Ballardie</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38040</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>IP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>IDMR</kw>
            <kw>Inter-Domain</kw>
        </keywords>
        <abstract>CBT is a multicast routing architecture that builds a single delivery tree per group which is shared by all of the group's senders and receivers. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2202</doc-id>
        <title>Test Cases for HMAC-MD5 and HMAC-SHA-1</title>
        <author>
            <name>P. Cheng</name>
        </author>
        <author>
            <name>R. Glenn</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11945</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>Hash</kw>
            <kw>Message</kw>
            <kw>Authentications</kw>
            <kw>Codes</kw>
            <kw>message</kw>
            <kw>digest</kw>
            <kw>secure</kw>
        </keywords>
        <abstract>This document provides two sets of test cases for HMAC-MD5 and HMAC- SHA-1, respectively. HMAC-MD5 and HMAC-SHA-1 are two constructs of the HMAC [HMAC] message authentication function using the MD5 [MD5] hash function and the SHA-1 [SHA] hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2203</doc-id>
        <title>RPCSEC_GSS Protocol Specification</title>
        <author>
            <name>M. Eisler</name>
        </author>
        <author>
            <name>A. Chiu</name>
        </author>
        <author>
            <name>L. Ling</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>50937</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>RPCSEC-GSS</kw>
            <kw>Remote</kw>
            <kw>Procedure</kw>
            <kw>Call</kw>
            <kw>Generic</kw>
            <kw>Security</kw>
            <kw>Services</kw>
            <kw>API</kw>
            <kw>Application</kw>
            <kw>Programming</kw>
            <kw>Interface</kw>
        </keywords>
        <abstract>This memo describes an ONC/RPC security flavor that allows RPC protocols to access the Generic Security Services Application Programming Interface (referred to henceforth as GSS-API). [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2204</doc-id>
        <title>ODETTE File Transfer Protocol</title>
        <author>
            <name>D. Nash</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>151857</char-count>
            <page-count>74</page-count>
        </format>
        <keywords>
            <kw>ODETTE</kw>
            <kw>FTP</kw>
            <kw>Internet</kw>
            <kw>Motor</kw>
            <kw>Industry</kw>
            <kw>data</kw>
            <kw>exchange</kw>
        </keywords>
        <abstract>This memo describes a file transfer protocol to facilitate electronic data interchange between trading partners. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2205</doc-id>
        <title>Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification</title>
        <author>
            <name>R. Braden</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Zhang</name>
        </author>
        <author>
            <name>S. Berson</name>
        </author>
        <author>
            <name>S. Herzog</name>
        </author>
        <author>
            <name>S. Jamin</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>223974</char-count>
            <page-count>112</page-count>
        </format>
        <keywords>
            <kw>RSVP</kw>
            <kw>integrated</kw>
            <kw>services</kw>
            <kw>multicast</kw>
            <kw>unicast</kw>
            <kw>QoS</kw>
            <kw>signaling</kw>
        </keywords>
        <abstract>This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. [STANDARDS-TRACK] </abstract>
        <updated-by>
            <doc-id>RFC2750</doc-id>
            <doc-id>RFC3936</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2206</doc-id>
        <title>RSVP Management Information Base using SMIv2</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>J. Krawczyk</name>
        </author>
        <author>
            <name>A. Sastry</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>112937</char-count>
            <page-count>64</page-count>
        </format>
        <keywords>
            <kw>RSVP-MIB</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Resource Reservation Protocol (RSVP) within the interface attributes defined in the Integrated Services Model. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2207</doc-id>
        <title>RSVP Extensions for IPSEC Data Flows</title>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>T. O'Malley</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30473</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>RSVP-IPSEC</kw>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>QoS</kw>
            <kw>IP</kw>
            <kw>Security</kw>
        </keywords>
        <abstract>This document presents extensions to Version 1 of RSVP. These extensions permit support of individual data flows using RFC 1826, IP Authentication Header (AH) or RFC 1827, IP Encapsulating Security Payload (ESP). [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2208</doc-id>
        <title>Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment</title>
        <author>
            <name>A. Mankin</name>
            <title>Editor</title>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>B. Braden</name>
        </author>
        <author>
            <name>S. Bradner</name>
        </author>
        <author>
            <name>M. O`Dell</name>
        </author>
        <author>
            <name>A. Romanow</name>
        </author>
        <author>
            <name>A. Weinrib</name>
        </author>
        <author>
            <name>L. Zhang</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14289</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>RSVP</kw>
        </keywords>
        <abstract>This document describes the applicability of RSVP along with the Integrated Services protocols and other components of resource reservation and offers guidelines for deployment of resource reservation at this time. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2209</doc-id>
        <title>Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules</title>
        <author>
            <name>R. Braden</name>
        </author>
        <author>
            <name>L. Zhang</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51690</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>RSVP-MPR</kw>
            <kw>QoS</kw>
            <kw>implementation</kw>
            <kw>algorithms</kw>
        </keywords>
        <abstract>This memo contains an algorithmic description of the rules used by an RSVP implementation for processing messages. It is intended to clarify the version 1 RSVP protocol specification. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2210</doc-id>
        <title>The Use of RSVP with IETF Integrated Services</title>
        <author>
            <name>J. Wroclawski</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>77613</char-count>
            <page-count>33</page-count>
        </format>
        <keywords>
            <kw>RSVP-IS</kw>
            <kw>Resource</kw>
            <kw>Reservation</kw>
            <kw>Controlled</kw>
            <kw>Load</kw>
            <kw>QOS: Quality of Service</kw>
        </keywords>
        <abstract>This note describes the use of the RSVP resource reservation protocol with the Controlled-Load and Guaranteed QoS control services. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2211</doc-id>
        <title>Specification of the Controlled-Load Network Element Service</title>
        <author>
            <name>J. Wroclawski</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46523</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>QOS: Quality of Service</kw>
            <kw>integrated services</kw>
        </keywords>
        <abstract>This memo specifies the network element behavior required to deliver Controlled-Load service in the Internet. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2212</doc-id>
        <title>Specification of Guaranteed Quality of Service</title>
        <author>
            <name>S. Shenker</name>
        </author>
        <author>
            <name>C. Partridge</name>
        </author>
        <author>
            <name>R. Guerin</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52330</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>GQOS</kw>
            <kw>QOS</kw>
            <kw>quality of service</kw>
            <kw>integrated services</kw>
        </keywords>
        <abstract>This memo describes the network element behavior required to deliver a guaranteed service (guaranteed delay and bandwidth) in the Internet. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2213</doc-id>
        <title>Integrated Services Management Information Base using SMIv2</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>J. Krawczyk</name>
        </author>
        <author>
            <name>A. Sastry</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36147</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the the interface attributes defined in the Integrated Services Model. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2214</doc-id>
        <title>Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>J. Krawczyk</name>
        </author>
        <author>
            <name>A. Sastry</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15971</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>attributes</kw>
            <kw>interface</kw>
            <kw>network</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the the interface attributes defined in the Guaranteed Service of the Integrated Services Model. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2215</doc-id>
        <title>General Characterization Parameters for Integrated Service Network Elements</title>
        <author>
            <name>S. Shenker</name>
        </author>
        <author>
            <name>J. Wroclawski</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39552</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>QOS</kw>
            <kw>Quality of service</kw>
        </keywords>
        <abstract>This memo defines a set of general control and characterization parameters for network elements supporting the IETF integrated services QoS control framework. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2216</doc-id>
        <title>Network Element Service Specification Template</title>
        <author>
            <name>S. Shenker</name>
        </author>
        <author>
            <name>J. Wroclawski</name>
        </author>
        <date>
            <month>September</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53655</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>QOS</kw>
            <kw>Quality</kw>
            <kw>of</kw>
            <kw>Service</kw>
            <kw>Control</kw>
        </keywords>
        <abstract>This document defines a framework for specifying services provided by network elements, and available to applications, in an internetwork which offers multiple qualities of service. The document first provides some necessary context -- including relevant definitions and suggested data formats -- and then specifies a "template" which service specification documents should follow. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2217</doc-id>
        <title>Telnet Com Port Control Option</title>
        <author>
            <name>G. Clark</name>
        </author>
        <date>
            <month>October</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31664</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>TOPT-COMPORT</kw>
            <kw>remote</kw>
            <kw>login</kw>
            <kw>host</kw>
        </keywords>
        <abstract>This memo proposes a protocol to allow greater use of modems attached to a network for outbound dialing purposes. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2218</doc-id>
        <title>A Common Schema for the Internet White Pages Service</title>
        <author>
            <name>T. Genovese</name>
        </author>
        <author>
            <name>B. Jennings</name>
        </author>
        <date>
            <month>October</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16258</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>IWPS</kw>
            <kw>information</kw>
            <kw>user</kw>
        </keywords>
        <abstract>This document specifies the minimum set of core attributes of a White Pages entry for an individual and describes how new objects with those attributes can be defined and published. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2219</doc-id>
        <title>Use of DNS Aliases for Network Services</title>
        <author>
            <name>M. Hamilton</name>
        </author>
        <author>
            <name>R. Wright</name>
        </author>
        <date>
            <month>October</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17858</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>symbolic</kw>
        </keywords>
        <abstract>It has become a common practice to use symbolic names (usually CNAMEs) in the Domain Name Service (DNS - [RFC-1034, RFC-1035]) to refer to network services such as anonymous FTP [RFC-959] servers, Gopher [RFC- 1436] servers, and most notably World-Wide Web HTTP [RFC-1945] servers. This is desirable for a number of reasons. It provides a way of moving services from one machine to another transparently, and a mechanism by which people or agents may programmatically discover that an organization runs, say, a World-Wide Web server. Although this approach has been almost universally adopted, there is no standards document or similar specification for these commonly used names. This document seeks to rectify this situation by gathering together the extant 'folklore' on naming conventions, and proposes a mechanism for accommodating new protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <is-also>
            <doc-id>BCP0017</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2220</doc-id>
        <title>The Application/MARC Content-type</title>
        <author>
            <name>R. Guenther</name>
        </author>
        <date>
            <month>October</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7025</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>APP-MARC</kw>
            <kw>media-type</kw>
            <kw>machine</kw>
            <kw>readable</kw>
            <kw>cataloging</kw>
            <kw>records</kw>
        </keywords>
        <abstract>This memorandum provides a mechanism for representing objects which are files of Machine-Readable Cataloging records (MARC). The MARC formats are standards for the representation and communication of bibliographic and related information. A MARC record contains metadata for an information resource following MARC format specifications. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2221</doc-id>
        <title>IMAP4 Login Referrals</title>
        <author>
            <name>M. Gahrns</name>
        </author>
        <date>
            <month>October</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9251</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>IMAP4LOGIN</kw>
            <kw>Internet</kw>
            <kw>Message</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
            <kw>server</kw>
        </keywords>
        <abstract>When dealing with large amounts of users and many IMAP4 [RFC-2060] servers, it is often necessary to move users from one IMAP4 server to another. Login referrals allow clients to transparently connect to an alternate IMAP4 server, if their home IMAP4 server has changed. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2222</doc-id>
        <title>Simple Authentication and Security Layer (SASL)</title>
        <author>
            <name>J. Myers</name>
        </author>
        <date>
            <month>October</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35010</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>SASL</kw>
            <kw>encryption</kw>
            <kw>protocol</kw>
            <kw>specific</kw>
        </keywords>
        <abstract>This document describes a method for adding authentication support to connection-based protocols. [STANDARDS-TRACK] </abstract>
        <updated-by>
            <doc-id>RFC2444</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2223</doc-id>
        <title>Instructions to RFC Authors</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J. Reynolds</name>
        </author>
        <date>
            <month>October</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37948</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>Request</kw>
            <kw>For</kw>
            <kw>Comment</kw>
        </keywords>
        <abstract>This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC1543</doc-id>
            <doc-id>RFC1111</doc-id>
            <doc-id>RFC0825</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2224</doc-id>
        <title>NFS URL Scheme</title>
        <author>
            <name>B. Callaghan</name>
        </author>
        <date>
            <month>October</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22726</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>NFS-URL</kw>
            <kw>Universal</kw>
            <kw>Resource</kw>
            <kw>Locators</kw>
            <kw>Network</kw>
            <kw>File</kw>
            <kw>System</kw>
            <kw>syntax</kw>
            <kw>directories</kw>
        </keywords>
        <abstract>A new URL scheme, 'nfs' is defined. It is used to refer to files and directories on NFS servers using the general URL syntax defined in RFC 1738, "Uniform Resource Locators (URL)". This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2225</doc-id>
        <title>Classical IP and ARP over ATM</title>
        <author>
            <name>M. Laubach</name>
        </author>
        <author>
            <name>J. Halpern</name>
        </author>
        <date>
            <month>April</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>65779</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>IP-ATM</kw>
            <kw>Internet</kw>
            <kw>protocol</kw>
            <kw>address</kw>
            <kw>resolution</kw>
            <kw>asynchronous,transfer</kw>
            <kw>mode</kw>
        </keywords>
        <abstract>This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS). [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1626</doc-id>
            <doc-id>RFC1577</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2226</doc-id>
        <title>IP Broadcast over ATM Networks</title>
        <author>
            <name>T. Smith</name>
        </author>
        <author>
            <name>G. Armitage</name>
        </author>
        <date>
            <month>October</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30661</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>Asynchronous</kw>
            <kw>Transfer</kw>
            <kw>Mode</kw>
        </keywords>
        <abstract>This memo describes how the IP multicast service being developed by the IP over ATM working group may be used to support IP broadcast transmission. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2227</doc-id>
        <title>Simple Hit-Metering and Usage-Limiting for HTTP</title>
        <author>
            <name>J. Mogul</name>
        </author>
        <author>
            <name>P. Leach</name>
        </author>
        <date>
            <month>October</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>85127</char-count>
            <page-count>37</page-count>
        </format>
        <keywords>
            <kw>Hypertext</kw>
            <kw>Transfer</kw>
            <kw>Protocol</kw>
            <kw>extension</kw>
        </keywords>
        <abstract>This document proposes a simple extension to HTTP, using a new "Meter" header. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2228</doc-id>
        <title>FTP Security Extensions</title>
        <author>
            <name>M. Horowitz</name>
        </author>
        <author>
            <name>S. Lunt</name>
        </author>
        <date>
            <month>October</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>58733</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>FTPSECEXT</kw>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>authentication</kw>
            <kw>encoding</kw>
        </keywords>
        <abstract>This document defines extensions to the FTP specification STD 9, RFC </abstract>
        <updates>
            <doc-id>RFC0959</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2229</doc-id>
        <title>A Dictionary Server Protocol</title>
        <author>
            <name>R. Faith</name>
        </author>
        <author>
            <name>B. Martin</name>
        </author>
        <date>
            <month>October</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59551</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>DSP</kw>
            <kw>DICT</kw>
            <kw>TCP</kw>
            <kw>Transmission</kw>
            <kw>Control</kw>
            <kw>Protocol</kw>
            <kw>database</kw>
            <kw>definitions</kw>
        </keywords>
        <abstract>The Dictionary Server Protocol (DICT) is a TCP transaction based query/response protocol that allows a client to access dictionary definitions from a set of natural language dictionary databases. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2230</doc-id>
        <title>Key Exchange Delegation Record for the DNS</title>
        <author>
            <name>R. Atkinson</name>
        </author>
        <date>
            <month>November</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25563</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>KEYX-DNS</kw>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
            <kw>RR</kw>
            <kw>Resource</kw>
            <kw>Record</kw>
            <kw>KX</kw>
        </keywords>
        <abstract>This note describes a mechanism whereby authorisation for one node to act as key exchanger for a second node is delegated and made available via the Secure DNS. This mechanism is intended to be used only with the Secure DNS. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2231</doc-id>
        <title>MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations</title>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>K. Moore</name>
        </author>
        <date>
            <month>November</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19280</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>MIME-EXT</kw>
            <kw>Mail</kw>
            <kw>Multimedia</kw>
            <kw>EMail</kw>
        </keywords>
        <abstract>This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2184</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2045</doc-id>
            <doc-id>RFC2047</doc-id>
            <doc-id>RFC2183</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2232</doc-id>
        <title>Definitions of Managed Objects for DLUR using SMIv2</title>
        <author>
            <name>B. Clouston</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Moore</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37955</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>DLUR-MIB</kw>
            <kw>Management</kw>
            <kw>Information Base</kw>
            <kw>MIB</kw>
            <kw>Dependent LU Requester</kw>
            <kw>APPN</kw>
            <kw>Advanced</kw>
            <kw>Peek</kw>
            <kw>to Peek Networking</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with DLUR (Dependent LU Requester) capabilities. This memo identifies managed objects for the DLUR protocol. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2233</doc-id>
        <title>The Interfaces Group MIB using SMIv2</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>F. Kastenholz</name>
        </author>
        <date>
            <month>November</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>148033</char-count>
            <page-count>66</page-count>
        </format>
        <keywords>
            <kw>INTERGRMIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>Network</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1573</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2863</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2234</doc-id>
        <title>Augmented BNF for Syntax Specifications: ABNF</title>
        <author>
            <name>D. Crocker</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Overell</name>
        </author>
        <date>
            <month>November</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24265</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>ABNF</kw>
            <kw>Augmented</kw>
            <kw>Backus-Naur</kw>
            <kw>Form</kw>
            <kw>electronic</kw>
            <kw>mail</kw>
        </keywords>
        <abstract>In the early days of the Arpanet, each specification contained its own definition of ABNF. This included the email specifications, RFC733 and then RFC822 which have come to be the common citations for defining ABNF. The current document separates out that definition, to permit selective reference. Predictably, it also provides some modifications and enhancements. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2235</doc-id>
        <title>Hobbes' Internet Timeline</title>
        <author>
            <name>R. Zakon</name>
        </author>
        <date>
            <month>November</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43060</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>events</kw>
            <kw>technologies</kw>
            <kw>history</kw>
        </keywords>
        <abstract>This document presents a history of the Internet in timeline fashion, highlighting some of the key events and technologies which helped shape the Internet as we know it today. A growth summary of the Internet and some associated technologies is also included. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <is-also>
            <doc-id>FYI0032</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2236</doc-id>
        <title>Internet Group Management Protocol, Version 2</title>
        <author>
            <name>W. Fenner</name>
        </author>
        <date>
            <month>November</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51048</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>IGMP</kw>
            <kw>IGMP</kw>
            <kw>multicast</kw>
            <kw>routing</kw>
            <kw>IP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This memo documents IGMPv2, used by IP hosts to report their multicast group memberships to routers. It updates STD 5, RFC 1112. [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3376</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1112</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2237</doc-id>
        <title>Japanese Character Encoding for Internet Messages</title>
        <author>
            <name>K. Tamaru</name>
        </author>
        <date>
            <month>November</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11628</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>eletronic</kw>
            <kw>mail</kw>
            <kw>character</kw>
            <kw>set</kw>
            <kw>scheme</kw>
        </keywords>
        <abstract>This memo defines an encoding scheme for the Japanese Characters, describes "ISO-2022-JP-1", which is used in electronic mail [RFC-822], and network news [RFC 1036]. Also this memo provides a listing of the Japanese Character Set that can be used in this encoding scheme. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2238</doc-id>
        <title>Definitions of Managed Objects for HPR using SMIv2</title>
        <author>
            <name>B. Clouston</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Moore</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>65498</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
            <kw>HPR-MIB</kw>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>high</kw>
            <kw>performance</kw>
            <kw>routing</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with HPR (High Performance Routing) capabilities. This memo identifies managed objects for the HPR protocol. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2239</doc-id>
        <title>Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2</title>
        <author>
            <name>K. de Graaf</name>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <author>
            <name>D. McMaster</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>S. Roberts</name>
        </author>
        <date>
            <month>November</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>80651</char-count>
            <page-count>43</page-count>
        </format>
        <keywords>
            <kw>MAUS-MIB</kw>
        </keywords>
        <abstract>This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing 10 and 100 Mb/second Medium Attachment Units (MAUs) based on IEEE Std 802.3 Section 30, "10 &amp; 100 Mb/s Management," October 26, 1995. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2668</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2240</doc-id>
        <title>A Legal Basis for Domain Name Allocation</title>
        <author>
            <name>O. Vaughan</name>
        </author>
        <date>
            <month>November</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13602</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>DNS</kw>
        </keywords>
        <abstract>The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC2352</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2241</doc-id>
        <title>DHCP Options for Novell Directory Services</title>
        <author>
            <name>D. Provan</name>
        </author>
        <date>
            <month>November</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8419</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>DHCP-NDS</kw>
            <kw>NDS</kw>
        </keywords>
        <abstract>This document defines three new DHCP options for delivering configuration information to clients of the Novell Directory Services. This document defines three new DHCP options for delivering configuration information to clients of the Novell Directory Services. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2242</doc-id>
        <title>NetWare/IP Domain Name and Information</title>
        <author>
            <name>R. Droms</name>
        </author>
        <author>
            <name>K. Fong</name>
        </author>
        <date>
            <month>November</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10653</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>NETWAREIP</kw>
            <kw>DHCP</kw>
        </keywords>
        <abstract>This document defines options that carry NetWare/IP domain name and NetWare/IP sub-options to DHCP clients. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2243</doc-id>
        <title>OTP Extended Responses</title>
        <author>
            <name>C. Metz</name>
        </author>
        <date>
            <month>November</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19730</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>OTP-ER</kw>
            <kw>One</kw>
            <kw>Time</kw>
            <kw>Password</kw>
        </keywords>
        <abstract>This document provides a specification for a type of response to an OTP [RFC 1938] challenge that carries explicit indication of the response's encoding. This document also provides a specification for a response that allows an OTP generator to request that a server re-initialize a sequence and change parameters such as the secret pass phrase. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2244</doc-id>
        <title>ACAP -- Application Configuration Access Protocol</title>
        <author>
            <name>C. Newman</name>
        </author>
        <author>
            <name>J. G. Myers</name>
        </author>
        <date>
            <month>November</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>154610</char-count>
            <page-count>71</page-count>
        </format>
        <keywords>
            <kw>ACAP</kw>
            <kw>URL</kw>
            <kw>Uniform</kw>
            <kw>Resource</kw>
            <kw>Locator</kw>
        </keywords>
        <abstract>The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2245</doc-id>
        <title>Anonymous SASL Mechanism</title>
        <author>
            <name>C. Newman</name>
        </author>
        <date>
            <month>November</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9974</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>SASL-ANON</kw>
            <kw>Simple</kw>
            <kw>Authentication</kw>
            <kw>Security</kw>
            <kw>Layer</kw>
        </keywords>
        <abstract>As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the SASL [SASL] framework. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2246</doc-id>
        <title>The TLS Protocol Version 1.0</title>
        <author>
            <name>T. Dierks</name>
        </author>
        <author>
            <name>C. Allen</name>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>170401</char-count>
            <page-count>80</page-count>
        </format>
        <keywords>
            <kw>transport</kw>
            <kw>protocol</kw>
            <kw>layer</kw>
            <kw>authentication</kw>
            <kw>privacy</kw>
        </keywords>
        <abstract>This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] </abstract>
        <updated-by>
            <doc-id>RFC3546</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2247</doc-id>
        <title>Using Domains in LDAP/X.500 Distinguished Names</title>
        <author>
            <name>S. Kille</name>
        </author>
        <author>
            <name>M. Wahl</name>
        </author>
        <author>
            <name>A. Grimstad</name>
        </author>
        <author>
            <name>R. Huber</name>
        </author>
        <author>
            <name>S. Sataluri</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12411</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>DNS</kw>
            <kw>Domain</kw>
            <kw>name</kw>
            <kw>system</kw>
        </keywords>
        <abstract>This document defines an algorithm by which a name registered with the Internet Domain Name Service [2] can be represented as an LDAP distinguished name. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2248</doc-id>
        <title>Network Services Monitoring MIB</title>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34106</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>NSM-MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>SNMP</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This MIB may be used on its own for any application, and for most simple applications this will suffice. This MIB is also designed to serve as a building block which can be used in conjunction with application- specific monitoring and management. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1565</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2788</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2249</doc-id>
        <title>Mail Monitoring MIB</title>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52334</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>MAIL-MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>Message</kw>
            <kw>Transfer</kw>
            <kw>Agents</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB [8] to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS- TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1566</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2789</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2250</doc-id>
        <title>RTP Payload Format for MPEG1/MPEG2 Video</title>
        <author>
            <name>D. Hoffman</name>
        </author>
        <author>
            <name>G. Fernando</name>
        </author>
        <author>
            <name>V. Goyal</name>
        </author>
        <author>
            <name>M. Civanlar</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34293</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>RTP-MPEG</kw>
            <kw>Real-Time</kw>
            <kw>Transport</kw>
            <kw>Protocol</kw>
            <kw>Audio</kw>
            <kw>System</kw>
            <kw>Streams</kw>
        </keywords>
        <abstract>This memo describes a packetization scheme for MPEG video and audio streams. [STANDARDS-TRACK] The purpose of this document is to express the general Internet community's expectations of Computer Security Incident Response Teams (CSIRTs). It is not possible to define a set of requirements that would be appropriate for all teams, but it is possible and helpful to list and describe the general set of topics and issues which are of concern and interest to constituent communities. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <obsoletes>
            <doc-id>RFC2038</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2251</doc-id>
        <title>Lightweight Directory Access Protocol (v3)</title>
        <author>
            <name>M. Wahl</name>
        </author>
        <author>
            <name>T. Howes</name>
        </author>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>December</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>114488</char-count>
            <page-count>50</page-count>
        </format>
        <keywords>
            <kw>LDAPV3</kw>
            <kw>LDAv3</kw>
            <kw>x.500</kw>
        </keywords>
        <abstract>The protocol described in this document is designed to provide access to directories supporting the X.500 models, while not incurring the resource requirements of the X.500 Directory Access Protocol (DAP). [STANDARDS-TRACK] </abstract>
        <updated-by>
            <doc-id>RFC3377</doc-id>
            <doc-id>RFC3771</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2252</doc-id>
        <title>Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions</title>
        <author>
            <name>M. Wahl</name>
        </author>
        <author>
            <name>A. Coulbeck</name>
        </author>
        <author>
            <name>T. Howes</name>
        </author>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>December</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>60204</char-count>
            <page-count>32</page-count>
        </format>
        <keywords>
            <kw>LDAP3-ATD</kw>
            <kw>LDAv3</kw>
            <kw>x.500</kw>
            <kw>syntax</kw>
        </keywords>
        <abstract>This document defines a set of syntaxes for LDAPv3, and the rules by which attribute values of these syntaxes are represented as octet strings for transmission in the LDAP protocol. [STANDARDS-TRACK] </abstract>
        <updated-by>
            <doc-id>RFC3377</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2253</doc-id>
        <title>Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names</title>
        <author>
            <name>M. Wahl</name>
        </author>
        <author>
            <name>S. Kille</name>
        </author>
        <author>
            <name>T. Howes</name>
        </author>
        <date>
            <month>December</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18226</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>LDAP3-UTF8</kw>
            <kw>LDAPv3</kw>
            <kw>x.500</kw>
            <kw>ASN.1</kw>
            <kw>string</kw>
            <kw>format</kw>
        </keywords>
        <abstract>This specification defines the string format for representing names, which is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1779</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3377</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2254</doc-id>
        <title>The String Representation of LDAP Search Filters</title>
        <author>
            <name>T. Howes</name>
        </author>
        <date>
            <month>December</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13511</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>STR-LDAP</kw>
            <kw>LDAPv3</kw>
            <kw>x.500</kw>
            <kw>ASN.1</kw>
            <kw>string</kw>
            <kw>format</kw>
        </keywords>
        <abstract>This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1960</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3377</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2255</doc-id>
        <title>The LDAP URL Format</title>
        <author>
            <name>T. Howes</name>
        </author>
        <author>
            <name>M. Smith</name>
        </author>
        <date>
            <month>December</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20685</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>LDAP-URL</kw>
            <kw>Lightweight</kw>
            <kw>Directory</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
            <kw>Universal</kw>
            <kw>Resource</kw>
            <kw>Locator</kw>
        </keywords>
        <abstract>This document describes a format for an LDAP Uniform Resource Locator. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1959</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3377</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2256</doc-id>
        <title>A Summary of the X.500(96) User Schema for use with LDAPv3</title>
        <author>
            <name>M. Wahl</name>
        </author>
        <date>
            <month>December</month>
            <year>1997</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32377</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>Lightweight</kw>
            <kw>Directory</kw>
            <kw>Access</kw>
            <kw>Protocol</kw>
            <kw>syntax</kw>
        </keywords>
        <abstract>This document provides an overview of the attribute types and object classes defined by the ISO and ITU-T committees in the X.500 documents, in particular those intended for use by directory clients. [STANDARDS- TRACK] </abstract>
        <updated-by>
            <doc-id>RFC3377</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2257</doc-id>
        <title>Agent Extensibility (AgentX) Protocol Version 1</title>
        <author>
            <name>M. Daniele</name>
        </author>
        <author>
            <name>B. Wijnen</name>
        </author>
        <author>
            <name>D. Francisco</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>177452</char-count>
            <page-count>80</page-count>
        </format>
        <keywords>
            <kw>AGENTX</kw>
            <kw>SNMP</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>MIB</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>This memo defines a standardized framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processes SNMP protocol messages. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2741</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2258</doc-id>
        <title>Internet Nomenclator Project</title>
        <author>
            <name>J. Ordille</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34871</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>Database</kw>
            <kw>Server</kw>
            <kw>CCSO</kw>
            <kw>Computer</kw>
            <kw>Communications</kw>
            <kw>Services</kw>
            <kw>Office</kw>
        </keywords>
        <abstract>The goal of the Internet Nomenclator Project is to integrate the hundreds of publicly available CCSO servers from around the world. This document provides an overview of the Nomenclator system, describes how to register a CCSO server in the Internet Nomenclator Project, and how to use the Nomenclator search engine to find people on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2259</doc-id>
        <title>Simple Nomenclator Query Protocol (SNQP)</title>
        <author>
            <name>J. Elliott</name>
        </author>
        <author>
            <name>J. Ordille</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>58508</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>SNQP</kw>
            <kw>Data</kw>
            <kw>Repositories</kw>
            <kw>Client</kw>
            <kw>Server</kw>
        </keywords>
        <abstract>The Simple Nomenclator Query Protocol (SNQP) allows a client to communicate with a descriptive name service or other relational-style query service. This memo provides information for the Internet community. It does not specify an Internet standard of any kind </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2260</doc-id>
        <title>Scalable Support for Multi-homed Multi-provider Connectivity</title>
        <author>
            <name>T. Bates</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28085</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>ISP</kw>
            <kw>Internet</kw>
            <kw>Service</kw>
            <kw>Provider</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract>This document describes addressing and routing strategies for multi- homed enterprises attached to multiple Internet Service Providers (ISPs) that are intended to reduce the routing overhead due to these enterprises in the global Internet routing system. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2261</doc-id>
        <title>An Architecture for Describing SNMP Management Frameworks</title>
        <author>
            <name>D. Harrington</name>
        </author>
        <author>
            <name>R. Presuhn</name>
        </author>
        <author>
            <name>B. Wijnen</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>128036</char-count>
            <page-count>56</page-count>
        </format>
        <keywords>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Message</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>security</kw>
            <kw>access</kw>
            <kw>control</kw>
            <kw>snmpv3</kw>
        </keywords>
        <abstract>This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2271</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2262</doc-id>
        <title>Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>D. Harrington</name>
        </author>
        <author>
            <name>R. Presuhn</name>
        </author>
        <author>
            <name>B. Wijnen</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>88254</char-count>
            <page-count>39</page-count>
        </format>
        <keywords>
            <kw>architecture</kw>
            <kw>SNMPv3</kw>
            <kw>multiple</kw>
            <kw>versions</kw>
        </keywords>
        <abstract>This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2261]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2272</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2263</doc-id>
        <title>SNMPv3 Applications</title>
        <author>
            <name>D. Levi</name>
        </author>
        <author>
            <name>P. Meyer</name>
        </author>
        <author>
            <name>B. Stewart</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>143493</char-count>
            <page-count>70</page-count>
        </format>
        <keywords>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>operations</kw>
            <kw>notification</kw>
            <kw>filtering</kw>
            <kw>proxy</kw>
            <kw>forwarding</kw>
        </keywords>
        <abstract>This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2261]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2273</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2264</doc-id>
        <title>User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)</title>
        <author>
            <name>U. Blumenthal</name>
        </author>
        <author>
            <name>B. Wijnen</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>168759</char-count>
            <page-count>76</page-count>
        </format>
        <keywords>
            <kw>architecture</kw>
            <kw>message</kw>
            <kw>level</kw>
        </keywords>
        <abstract>This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2274</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2265</doc-id>
        <title>View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)</title>
        <author>
            <name>B. Wijnen</name>
        </author>
        <author>
            <name>R. Presuhn</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>77807</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>SNMPV3</kw>
            <kw>Architecture</kw>
        </keywords>
        <abstract>This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2275</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2266</doc-id>
        <title>Definitions of Managed Objects for IEEE 802.12 Repeater Devices</title>
        <author>
            <name>J. Flick</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>134027</char-count>
            <page-count>56</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing network repeaters based on IEEE 802.12. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2267</doc-id>
        <title>Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing</title>
        <author>
            <name>P. Ferguson</name>
        </author>
        <author>
            <name>D. Senie</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21032</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>ISP</kw>
            <kw>Internet</kw>
            <kw>Service</kw>
            <kw>Provider</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>DOS</kw>
        </keywords>
        <abstract>This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC2827</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2268</doc-id>
        <title>A Description of the RC2(r) Encryption Algorithm</title>
        <author>
            <name>R. Rivest</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19048</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>RC2-ENCRP</kw>
            <kw>encryption</kw>
            <kw>secre</kw>
            <kw>key rsa</kw>
        </keywords>
        <abstract>This memo describes a conventional (secret-key) block encryption algorithm, called RC2, which may be considered as a proposal for a DES replacement. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2269</doc-id>
        <title>Using the MARS Model in non-ATM NBMA Networks</title>
        <author>
            <name>G. Armitage</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12094</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>Asynchronous</kw>
            <kw>Transfer</kw>
            <kw>Mode</kw>
            <kw>Multicast</kw>
            <kw>Address</kw>
            <kw>Resolution</kw>
            <kw>Server</kw>
            <kw>IP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document is intended to state the obvious equivalences, and explain the less obvious implications. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2270</doc-id>
        <title>Using a Dedicated AS for Sites  Homed to a Single Provider</title>
        <author>
            <name>J. Stewart</name>
        </author>
        <author>
            <name>T. Bates</name>
        </author>
        <author>
            <name>R. Chandra</name>
        </author>
        <author>
            <name>E. Chen</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12063</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>Autonomous</kw>
            <kw>System</kw>
            <kw>BGP4</kw>
            <kw>Border</kw>
            <kw>Gateway</kw>
            <kw>Protocol</kw>
            <kw>ISP</kw>
            <kw>Internet</kw>
            <kw>Service</kw>
        </keywords>
        <abstract>With the increased growth of the Internet, the number of customers using BGP4 has grown significantly. RFC1930 outlines a set of guidelines for when one needs and should use an AS. However, the customer and service provider (ISP) are left with a problem as a result of this in that while there is no need for an allocated AS under the guidelines, certain conditions make the use of BGP4 a very pragmatic and perhaps only way to connect a customer homed to a single ISP. This paper proposes a solution to this problem in line with recommendations set forth in RFC1930. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2271</doc-id>
        <title>An Architecture for Describing SNMP Management Frameworks</title>
        <author>
            <name>D. Harrington</name>
        </author>
        <author>
            <name>R. Presuhn</name>
        </author>
        <author>
            <name>B. Wijnen</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>128227</char-count>
            <page-count>56</page-count>
        </format>
        <keywords>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Message</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>security</kw>
            <kw>access</kw>
            <kw>control</kw>
            <kw>snmpv3</kw>
        </keywords>
        <abstract>This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2261</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2571</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2272</doc-id>
        <title>Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>D. Harrington</name>
        </author>
        <author>
            <name>R. Presuhn</name>
        </author>
        <author>
            <name>B. Wijnen</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>88445</char-count>
            <page-count>39</page-count>
        </format>
        <keywords>
            <kw>SNMPv3</kw>
            <kw>architecture</kw>
            <kw>SNMPv3</kw>
            <kw>multiple</kw>
            <kw>versions</kw>
        </keywords>
        <abstract>This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2271]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2262</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2572</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2273</doc-id>
        <title>SNMPv3 Applications</title>
        <author>
            <name>D. Levi</name>
        </author>
        <author>
            <name>P. Meyer</name>
        </author>
        <author>
            <name>B. Stewart</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>143754</char-count>
            <page-count>70</page-count>
        </format>
        <keywords>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>operations</kw>
            <kw>notification</kw>
            <kw>filtering</kw>
            <kw>proxy</kw>
            <kw>forwarding</kw>
        </keywords>
        <abstract>This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2261]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2263</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2573</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2274</doc-id>
        <title>User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)</title>
        <author>
            <name>U. Blumenthal</name>
        </author>
        <author>
            <name>B. Wijnen</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>168950</char-count>
            <page-count>76</page-count>
        </format>
        <keywords>
            <kw>architecture</kw>
            <kw>message</kw>
            <kw>level</kw>
        </keywords>
        <abstract>This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2264</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2574</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2275</doc-id>
        <title>View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)</title>
        <author>
            <name>B. Wijnen</name>
        </author>
        <author>
            <name>R. Presuhn</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>77998</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>SNMPV3</kw>
            <kw>Architecture</kw>
        </keywords>
        <abstract>This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2265</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2575</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2276</doc-id>
        <title>Architectural Principles of Uniform Resource Name Resolution</title>
        <author>
            <name>K. Sollins</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>64811</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>URCs</kw>
            <kw>URN</kw>
            <kw>URLs</kw>
            <kw>Uniform</kw>
            <kw>Resource</kw>
            <kw>Locators</kw>
            <kw>Characteristics</kw>
        </keywords>
        <abstract>This document addresses the issues of the discovery of URN (Uniform Resource Name) resolver services that in turn will directly translate URNs into URLs (Uniform Resource Locators) and URCs (Uniform Resource Characteristics). This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <updated-by>
            <doc-id>RFC3401</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2277</doc-id>
        <title>IETF Policy on Character Sets and Languages</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16622</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>charset</kw>
        </keywords>
        <abstract>This document is the current policies being applied by the Internet Engineering Steering Group (IESG) towards the standardization efforts in the Internet Engineering Task Force (IETF) in order to help Internet protocols fulfill these requirements. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <is-also>
            <doc-id>BCP0018</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2278</doc-id>
        <title>IANA Charset Registration Procedures</title>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18881</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>character</kw>
            <kw>set</kw>
            <kw>mime</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various other modern Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <notes>Status changed from BCP for consistency 10Feb01</notes>
        <obsoleted-by>
            <doc-id>RFC2978</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2279</doc-id>
        <title>UTF-8, a transformation format of ISO 10646</title>
        <author>
            <name>F. Yergeau</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21634</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>UTF-8</kw>
            <kw>UCS</kw>
            <kw>Transformation</kw>
            <kw>Format</kw>
        </keywords>
        <abstract>UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo updates and replaces RFC 2044, in particular addressing the question of versions of the relevant standards. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2044</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3629</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2280</doc-id>
        <title>Routing Policy Specification Language (RPSL)</title>
        <author>
            <name>C. Alaettinoglu</name>
        </author>
        <author>
            <name>T. Bates</name>
        </author>
        <author>
            <name>E. Gerich</name>
        </author>
        <author>
            <name>D. Karrenberg</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>M. Terpstra</name>
        </author>
        <author>
            <name>C. Villamizar</name>
        </author>
        <date>
            <month>January</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>114985</char-count>
            <page-count>53</page-count>
        </format>
        <keywords>
            <kw>RPSL</kw>
            <kw>network</kw>
            <kw>operator</kw>
            <kw>AS</kw>
            <kw>autonomous</kw>
            <kw>system</kw>
            <kw>database</kw>
        </keywords>
        <abstract>This memo is the reference document for the Routing Policy Specification Language (RPSL). RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2622</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2281</doc-id>
        <title>Cisco Hot Standby Router Protocol (HSRP)</title>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>B. Cole</name>
        </author>
        <author>
            <name>P. Morton</name>
        </author>
        <author>
            <name>D. Li</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35161</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>HSRP</kw>
        </keywords>
        <abstract>The memo specifies the Hot Standby Router Protocol (HSRP). The goal of the protocol is to allow hosts to appear to use a single router and to maintain connectivity even if the actual first hop router they are using fails. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2282</doc-id>
        <title>IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees</title>
        <author>
            <name>J. Galvin</name>
        </author>
        <date>
            <month>February</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29852</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Architecture</kw>
            <kw>Board</kw>
            <kw>Engineering</kw>
            <kw>Steering</kw>
            <kw>Group</kw>
        </keywords>
        <abstract>The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <obsoletes>
            <doc-id>RFC2027</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2727</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2283</doc-id>
        <title>Multiprotocol Extensions for BGP-4</title>
        <author>
            <name>T. Bates</name>
        </author>
        <author>
            <name>R. Chandra</name>
        </author>
        <author>
            <name>D. Katz</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>February</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18946</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>MEXT-BGP4</kw>
            <kw>Border</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
            <kw>router</kw>
            <kw>network</kw>
            <kw>layer</kw>
        </keywords>
        <abstract>This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2858</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2284</doc-id>
        <title>PPP Extensible Authentication Protocol (EAP)</title>
        <author>
            <name>L. Blunk</name>
        </author>
        <author>
            <name>J. Vollbrecht</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29452</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>PPP-EAP</kw>
            <kw>point-to-point</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. This document defines the PPP Extensible Authentication Protocol. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3748</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC2484</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2285</doc-id>
        <title>Benchmarking Terminology for LAN Switching Devices</title>
        <author>
            <name>R. Mandeville</name>
        </author>
        <date>
            <month>February</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43130</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>local</kw>
            <kw>area</kw>
            <kw>network</kw>
            <kw>MAC</kw>
            <kw>Medium</kw>
            <kw>Access</kw>
            <kw>Control</kw>
            <kw>layer</kw>
        </keywords>
        <abstract>This document is intended to provide terminology for the benchmarking of local area network (LAN) switching devices. It extends the terminology already defined for benchmarking network interconnect devices in RFCs 1242 and 1944 to switching devices. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2286</doc-id>
        <title>Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128</title>
        <author>
            <name>J. Kapp</name>
        </author>
        <date>
            <month>February</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11849</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>has</kw>
            <kw>authentication</kw>
            <kw>message</kw>
            <kw>IP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>codes</kw>
        </keywords>
        <abstract>This document provides two sets of test cases for HMAC-RIPEMD160 and HMAC-RIPEMD128. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2287</doc-id>
        <title>Definitions of System-Level Managed Objects for Applications</title>
        <author>
            <name>C. Krupczak</name>
        </author>
        <author>
            <name>J. Saperia</name>
        </author>
        <date>
            <month>February</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>98210</char-count>
            <page-count>44</page-count>
        </format>
        <keywords>
            <kw>SLM-APP</kw>
            <kw>mib</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a basic set of managed objects for fault, configuration and performance management of applications from a systems perspective. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2288</doc-id>
        <title>Using Existing Bibliographic Identifiers as Uniform Resource Names</title>
        <author>
            <name>C. Lynch</name>
        </author>
        <author>
            <name>C. Preston</name>
        </author>
        <author>
            <name>R. Daniel</name>
        </author>
        <date>
            <month>February</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21628</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>URNs</kw>
            <kw>Syntax</kw>
            <kw>framework</kw>
        </keywords>
        <abstract>This document discusses how three major bibliographic identifiers (the ISBN, ISSN and SICI) can be supported within the URN framework and the currently proposed syntax for URNs. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2289</doc-id>
        <title>A One-Time Password System</title>
        <author>
            <name>N. Haller</name>
        </author>
        <author>
            <name>C. Metz</name>
        </author>
        <author>
            <name>P. Nesser</name>
        </author>
        <author>
            <name>M. Straw</name>
        </author>
        <date>
            <month>February</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>56495</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>ONE-PASS</kw>
            <kw>authentication</kw>
            <kw>OTP</kw>
            <kw>replay</kw>
            <kw>attach</kw>
        </keywords>
        <abstract>This document describes a one-time password authentication system (OTP). The system provides authentication for system access (login) and other applications requiring authentication that is secure against passive attacks based on replaying captured reusable passwords. [STANDARDS- TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1938</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0061</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2290</doc-id>
        <title>Mobile-IPv4 Configuration Option for PPP IPCP</title>
        <author>
            <name>J. Solomon</name>
        </author>
        <author>
            <name>S. Glass</name>
        </author>
        <date>
            <month>February</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39421</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>protocol</kw>
            <kw>point-to-point</kw>
            <kw>control</kw>
            <kw>address</kw>
        </keywords>
        <abstract>Mobile IP [RFC 2002] defines media-independent procedures by which a Mobile Node can maintain existing transport and application-layer connections despite changing its point-of-attachment to the Internet and without changing its IP address. PPP [RFC 1661] provides a standard method for transporting multi-protocol packets over point-to-point links. As currently specified, Mobile IP Foreign Agents which support Mobile Node connections via PPP can do so only by first assigning unique addresses to those Mobile Nodes, defeating one of the primary advantages of Foreign Agents. This documents corrects this problem by defining the Mobile-IPv4 Configuration Option to the Internet Protocol Control Protocol (IPCP) [RFC 1332]. Using this option, two peers can communicate their support for Mobile IP during the IPCP phase of PPP. Familiarity with Mobile IP [RFC 2002], IPCP [RFC 1332], and PPP [RFC 1661] is assumed. [STANDARDS-TRACK] </abstract>
        <updates>
            <doc-id>RFC2002</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC2794</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2291</doc-id>
        <title>Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web</title>
        <author>
            <name>J. Slein</name>
        </author>
        <author>
            <name>F. Vitali</name>
        </author>
        <author>
            <name>E. Whitehead</name>
        </author>
        <author>
            <name>D. Durand</name>
        </author>
        <date>
            <month>February</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44036</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>WWW</kw>
            <kw>remote</kw>
            <kw>editing</kw>
            <kw>locking</kw>
            <kw>mechanism</kw>
        </keywords>
        <abstract>This document presents a list of features in the form of requirements for a Web Distributed Authoring and Versioning protocol which, if implemented, would improve the efficiency of common remote editing operations, provide a locking mechanism to prevent overwrite conflicts, improve link management support between non-HTML data types, provide a simple attribute-value metadata facility, provide for the creation and reading of container data types, and integrate versioning into the WWW. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2292</doc-id>
        <title>Advanced Sockets API for IPv6</title>
        <author>
            <name>W. Stevens</name>
        </author>
        <author>
            <name>M. Thomas</name>
        </author>
        <date>
            <month>February</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>152077</char-count>
            <page-count>67</page-count>
        </format>
        <keywords>
            <kw>application</kw>
            <kw>program</kw>
            <kw>interface</kw>
        </keywords>
        <abstract>The current document defines some the "advanced" features of the sockets API that are required for applications to take advantage of additional features of IPv6. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC3542</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2293</doc-id>
        <title>Representing Tables and Subtrees in the X.500 Directory</title>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12539</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>SUBTABLE</kw>
            <kw>mapping</kw>
            <kw>distinguished</kw>
            <kw>name</kw>
        </keywords>
        <abstract>This document defines techniques for representing two types of information mapping in the OSI Directory: Mapping from a key to a value (or set of values), as might be done in a table lookup, and mapping from a distinguished name to an associated value (or values), where the values are not defined by the owner of the entry. This is achieved by use of a directory subtree. [STANDARDS-TRCK] </abstract>
        <obsoletes>
            <doc-id>RFC1837</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2294</doc-id>
        <title>Representing the O/R Address hierarchy in the X.500 Directory Information Tree</title>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22059</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>OR-ADD</kw>
            <kw>routing</kw>
            <kw>mapping</kw>
            <kw>dit</kw>
        </keywords>
        <abstract>This document defines a representation of the O/R Address hierarchy in the Directory Information Tree. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1836</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2295</doc-id>
        <title>Transparent Content Negotiation in HTTP</title>
        <author>
            <name>K. Holtman</name>
        </author>
        <author>
            <name>A. Mutz</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>125130</char-count>
            <page-count>58</page-count>
        </format>
        <keywords>
            <kw>TCN-HTTP</kw>
            <kw>Hyper</kw>
            <kw>Text</kw>
            <kw>Transfer</kw>
            <kw>protocol</kw>
            <kw>URL</kw>
            <kw>Uniform</kw>
            <kw>Resource</kw>
            <kw>Locators</kw>
        </keywords>
        <abstract>HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2296</doc-id>
        <title>HTTP Remote Variant Selection Algorithm -- RVSA/1.0</title>
        <author>
            <name>K. Holtman</name>
        </author>
        <author>
            <name>A. Mutz</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26932</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>HTTP-RVSA</kw>
            <kw>Hyper</kw>
            <kw>Text</kw>
            <kw>Transfer</kw>
            <kw>protocol</kw>
            <kw>URL</kw>
            <kw>Uniform</kw>
            <kw>Resource</kw>
            <kw>Locators</kw>
        </keywords>
        <abstract>HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is a mechanism for automatically selecting the best version when the URL is accessed. A remote variant selection algorithm can be used to speed up the transparent negotiation process. This document defines the remote variant selection algorithm with the version number 1.0. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2297</doc-id>
        <title>Ipsilon's General Switch Management Protocol Specification Version 2.0</title>
        <author>
            <name>P. Newman</name>
        </author>
        <author>
            <name>W. Edwards</name>
        </author>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>E. Hoffman</name>
        </author>
        <author>
            <name>F. Ching Liaw</name>
        </author>
        <author>
            <name>T. Lyon</name>
        </author>
        <author>
            <name>G. Minshall</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>280484</char-count>
            <page-count>109</page-count>
        </format>
        <keywords>
            <kw>GSMP</kw>
            <kw>gsmp</kw>
            <kw>atm</kw>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
        </keywords>
        <abstract>This memo specifies enhancements to the General Switch Management Protocol (GSMP) [RFC1987]. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <updates>
            <doc-id>RFC1987</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2298</doc-id>
        <title>An Extensible Message Format for Message Disposition Notifications</title>
        <author>
            <name>R. Fajman</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>62059</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>EMF-MDN</kw>
            <kw>MDN</kw>
            <kw>media-type</kw>
            <kw>MIME</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This memo defines a MIME content-type that may be used by a mail user agent (UA) or electronic mail gateway to report the disposition of a message after it has been sucessfully delivered to a recipient. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3798</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2299</doc-id>
        <title>Request for Comments Summary</title>
        <author>
            <name>A. Ramos</name>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51234</char-count>
            <page-count>24</page-count>
        </format>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2300</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>May</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>128322</char-count>
            <page-count>59</page-count>
        </format>
        <keywords>
            <kw>IAB</kw>
            <kw>official</kw>
            <kw>protocol</kw>
            <kw>standards</kw>
        </keywords>
        <abstract>A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2200</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2400</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2301</doc-id>
        <title>File Format for Internet Fax</title>
        <author>
            <name>L. McIntyre</name>
        </author>
        <author>
            <name>S. Zilles</name>
        </author>
        <author>
            <name>R. Buckley</name>
        </author>
        <author>
            <name>D. Venable</name>
        </author>
        <author>
            <name>G. Parsons</name>
        </author>
        <author>
            <name>J. Rafferty</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>200525</char-count>
            <page-count>77</page-count>
        </format>
        <keywords>
            <kw>FFIF</kw>
            <kw>TIFF</kw>
            <kw>Tag</kw>
            <kw>Image</kw>
            <kw>facsimile</kw>
            <kw>MIME</kw>
            <kw>multipurpose</kw>
            <kw>Internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3949</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2302</doc-id>
        <title>Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration</title>
        <author>
            <name>G. Parsons</name>
        </author>
        <author>
            <name>J. Rafferty</name>
        </author>
        <author>
            <name>S. Zilles</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14375</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>TIFF</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document describes the registration of the MIME sub-type image/tiff. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3302</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2303</doc-id>
        <title>Minimal PSTN address format in Internet Mail</title>
        <author>
            <name>C. Allocchio</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14625</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>MIN-PSTN</kw>
            <kw>e-mail</kw>
            <kw>service</kw>
        </keywords>
        <abstract>This memo describes the MINIMAL addressing method to encode PSTN addresses into e-mail addresses and the standard extension mechanism to allow definition of further standard elements. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3191</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2304</doc-id>
        <title>Minimal FAX address format in Internet Mail</title>
        <author>
            <name>C. Allocchio</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13236</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>MINFAX-IM</kw>
            <kw>encoding</kw>
            <kw>facsimile</kw>
            <kw>e-mail</kw>
        </keywords>
        <abstract>This memo describes the MINIMAL addressing method and standard extensions to encode FAX addresses in e-mail addresses. [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3192</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2305</doc-id>
        <title>A Simple Mode of Facsimile Using Internet Mail</title>
        <author>
            <name>K. Toyoda</name>
        </author>
        <author>
            <name>H. Ohno</name>
        </author>
        <author>
            <name>J. Murai</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24624</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>SMFAX-IM</kw>
            <kw>data</kw>
            <kw>file</kw>
            <kw>format</kw>
            <kw>e-mail</kw>
        </keywords>
        <abstract>This specification provides for "simple mode" carriage of facsimile data over the Internet. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3965</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2306</doc-id>
        <title>Tag Image File Format (TIFF) - F Profile for Facsimile</title>
        <author>
            <name>G. Parsons</name>
        </author>
        <author>
            <name>J. Rafferty</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59358</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>file</kw>
            <kw>format</kw>
            <kw>storage</kw>
        </keywords>
        <abstract>This document describes in detail the definition of TIFF-F that is used to store facsimile images. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2307</doc-id>
        <title>An Approach for Using LDAP as a Network Information Service</title>
        <author>
            <name>L. Howard</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41396</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>LDAP-NIS</kw>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>unix</kw>
            <kw>mapping</kw>
        </keywords>
        <abstract>This document describes an experimental mechanism for mapping entities related to TCP/IP and the UNIX system into X.500 entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC2251]. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2308</doc-id>
        <title>Negative Caching of DNS Queries (DNS NCACHE)</title>
        <author>
            <name>M. Andrews</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41428</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>DNS-NCACHE</kw>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
            <kw>negative</kw>
        </keywords>
        <abstract>RFC1034 provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK] </abstract>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4035</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2309</doc-id>
        <title>Recommendations on Queue Management and Congestion Avoidance in the Internet</title>
        <author>
            <name>B. Braden</name>
        </author>
        <author>
            <name>D. Clark</name>
        </author>
        <author>
            <name>J. Crowcroft</name>
        </author>
        <author>
            <name>B. Davie</name>
        </author>
        <author>
            <name>S. Deering</name>
        </author>
        <author>
            <name>D. Estrin</name>
        </author>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>V. Jacobson</name>
        </author>
        <author>
            <name>G. Minshall</name>
        </author>
        <author>
            <name>C. Partridge</name>
        </author>
        <author>
            <name>L. Peterson</name>
        </author>
        <author>
            <name>K. Ramakrishnan</name>
        </author>
        <author>
            <name>S. Shenker</name>
        </author>
        <author>
            <name>J. Wroclawski</name>
        </author>
        <author>
            <name>L. Zhang</name>
        </author>
        <date>
            <month>April</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38079</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>performance</kw>
            <kw>router</kw>
            <kw>deployment</kw>
        </keywords>
        <abstract>This memo presents two recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management in routers, to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of router mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2310</doc-id>
        <title>The Safe Response Header Field</title>
        <author>
            <name>K. Holtman</name>
        </author>
        <date>
            <month>April</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8091</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>http</kw>
            <kw>hyper</kw>
            <kw>text</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document defines a HTTP response header field called Safe, which can be used to indicate that repeating a HTTP request is safe. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2311</doc-id>
        <title>S/MIME Version 2 Message Specification</title>
        <author>
            <name>S. Dusse</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>B. Ramsdell</name>
        </author>
        <author>
            <name>L. Lundblade</name>
        </author>
        <author>
            <name>L. Repka</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>70901</char-count>
            <page-count>37</page-count>
        </format>
        <keywords>
            <kw>SMIME-MSG</kw>
            <kw>secure</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document describes a protocol for adding cryptographic signature and encryption services to MIME data. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2312</doc-id>
        <title>S/MIME Version 2 Certificate Handling</title>
        <author>
            <name>S. Dusse</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>B. Ramsdell</name>
        </author>
        <author>
            <name>J. Weinstein</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39829</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>SMIME-CERT</kw>
            <kw>secure</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This memo describes the mechanisms S/MIME uses to create and validate keys using certificates. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2313</doc-id>
        <title>PKCS #1: RSA Encryption Version 1.5</title>
        <author>
            <name>B. Kaliski</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37777</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>PKCS-1</kw>
            <kw>data</kw>
            <kw>public</kw>
            <kw>key</kw>
            <kw>cryptosystem</kw>
        </keywords>
        <abstract>This document describes a method for encrypting data using the RSA public-key cryptosystem. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC2437</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2314</doc-id>
        <title>PKCS #10: Certification Request Syntax Version 1.5</title>
        <author>
            <name>B. Kaliski</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15814</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>PKCS-10</kw>
            <kw>public</kw>
            <kw>key</kw>
            <kw>distinguished</kw>
            <kw>name</kw>
            <kw>encryption</kw>
            <kw>data</kw>
        </keywords>
        <abstract>This document describes a syntax for certification requests. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC2986</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2315</doc-id>
        <title>PKCS #7: Cryptographic Message Syntax Version 1.5</title>
        <author>
            <name>B. Kaliski</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>69679</char-count>
            <page-count>32</page-count>
        </format>
        <keywords>
            <kw>PKCS-7</kw>
            <kw>data</kw>
            <kw>authentication</kw>
            <kw>PEM</kw>
            <kw>privacy</kw>
            <kw>enhanced</kw>
            <kw>mail</kw>
        </keywords>
        <abstract>This document describes a general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2316</doc-id>
        <title>Report of the IAB Security Architecture Workshop</title>
        <author>
            <name>S. Bellovin</name>
        </author>
        <date>
            <month>April</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19733</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Board</kw>
            <kw>protocols</kw>
            <kw>tools</kw>
        </keywords>
        <abstract>On 3-5 March 1997, the IAB held a security architecture workshop at Bell Labs in Murray Hill, NJ. We identified the core security components of the architecture, and specified several documents that need to be written. Most importantly, we agreed that security was not optional, and that it needed to be designed in from the beginning. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2317</doc-id>
        <title>Classless IN-ADDR.ARPA delegation</title>
        <author>
            <name>H. Eidnes</name>
        </author>
        <author>
            <name>G. de Groot</name>
        </author>
        <author>
            <name>P. Vixie</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17744</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>routing</kw>
            <kw>mapping</kw>
            <kw>addresses</kw>
            <kw>zone</kw>
            <kw>files</kw>
        </keywords>
        <abstract>This document describes a way to do IN-ADDR.ARPA delegation on non-octet boundaries for address spaces covering fewer than 256 addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <is-also>
            <doc-id>BCP0020</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2318</doc-id>
        <title>The text/css Media Type</title>
        <author>
            <name>H. Lie</name>
        </author>
        <author>
            <name>B. Bos</name>
        </author>
        <author>
            <name>C. Lilley</name>
        </author>
        <date>
            <month>March</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7819</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>TEXT-CSS</kw>
            <kw>MIME</kw>
            <kw>multipurpose</kw>
            <kw>Internet</kw>
            <kw>mail</kw>
            <kw>extension</kw>
        </keywords>
        <abstract>This memo provides information about the text/css Media Type. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2319</doc-id>
        <title>Ukrainian Character Set KOI8-U</title>
        <author>
            <name>KOI8-U Working Group</name>
        </author>
        <date>
            <month>April</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18042</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>KOI8-U</kw>
            <kw>encoding</kw>
            <kw>mail</kw>
            <kw>information</kw>
            <kw>resources</kw>
        </keywords>
        <abstract>This document provides information about character encoding KOI8-U (KOI8 Ukrainian) wich is a de-facto standard in Ukrainian Internet community. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2320</doc-id>
        <title>Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB)</title>
        <author>
            <name>M. Greene</name>
        </author>
        <author>
            <name>J. Luciani</name>
        </author>
        <author>
            <name>K. White</name>
        </author>
        <author>
            <name>T. Kuo</name>
        </author>
        <date>
            <month>April</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>102116</char-count>
            <page-count>52</page-count>
        </format>
        <keywords>
            <kw>IPOA-MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>address</kw>
            <kw>resolution</kw>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
        </keywords>
        <abstract>The purpose of this memo is to define the Management Information Base (MIB) for supporting Classical IP and ARP over ATM as specified in Classical IP and ARP over ATM. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2321</doc-id>
        <title>RITA -- The Reliable Internetwork Troubleshooting Agent</title>
        <author>
            <name>A. Bressen</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12302</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>networking</kw>
            <kw>environments</kw>
        </keywords>
        <abstract>A Description of the usage of Nondeterministic Troubleshooting and Diagnostic Methodologies as applied to today's complex nondeterministic networks and environments. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2322</doc-id>
        <title>Management of IP numbers by peg-dhcp</title>
        <author>
            <name>K. van den Hout</name>
        </author>
        <author>
            <name>A. Koopal</name>
        </author>
        <author>
            <name>R. van Mook</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12665</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>HIP</kw>
            <kw>Hacking</kw>
            <kw>in</kw>
            <kw>progress</kw>
        </keywords>
        <abstract>This RFC describes a protocol to dynamically hand out ip-numbers on field networks and small events that don't necessarily have a clear organisational body. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2323</doc-id>
        <title>IETF Identification and Security Guidelines</title>
        <author>
            <name>A. Ramos</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9257</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>facial</kw>
            <kw>hairius</kw>
            <kw>extremis</kw>
            <kw>FHE</kw>
        </keywords>
        <abstract>This RFC is meant to represent a guideline by which the IETF conferences may run more effeciently with regards to identification and security protocols, with specific attention paid to a particular sub-group within the IETF: "facial hairius extremis". This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2324</doc-id>
        <title>Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)</title>
        <author>
            <name>L. Masinter</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19610</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>controlling</kw>
            <kw>monitoring</kw>
            <kw>diagnosing</kw>
        </keywords>
        <abstract>This document describes HTCPCP, a protocol for controlling, monitoring, and diagnosing coffee pots. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2325</doc-id>
        <title>Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2</title>
        <author>
            <name>M. Slavitch</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12726</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>coffee</kw>
            <kw>brewing      </kw>
        </keywords>
        <abstract>This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of coffee-brewing and maintenance devices. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2326</doc-id>
        <title>Real Time Streaming Protocol (RTSP)</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>A. Rao</name>
        </author>
        <author>
            <name>R. Lanphier</name>
        </author>
        <date>
            <month>April</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>195010</char-count>
            <page-count>92</page-count>
        </format>
        <keywords>
            <kw>RTSP</kw>
            <kw>audio</kw>
            <kw>video</kw>
            <kw>data</kw>
            <kw>delivery</kw>
            <kw>application</kw>
            <kw>level,</kw>
        </keywords>
        <abstract>The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2327</doc-id>
        <title>SDP: Session Description Protocol</title>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>V. Jacobson</name>
        </author>
        <date>
            <month>April</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>87096</char-count>
            <page-count>42</page-count>
        </format>
        <keywords>
            <kw>SDP</kw>
            <kw>mbone</kw>
            <kw>internet</kw>
            <kw>multicast</kw>
            <kw>backbone</kw>
            <kw>multimedia</kw>
        </keywords>
        <abstract>This document defines the Session Description Protocol, SDP. SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS-TRACK] </abstract>
        <updated-by>
            <doc-id>RFC3266</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2328</doc-id>
        <title>OSPF Version 2</title>
        <author>
            <name>J. Moy</name>
        </author>
        <date>
            <month>April</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>447367</char-count>
            <page-count>244</page-count>
        </format>
        <keywords>
            <kw>OSPF2</kw>
            <kw>Open</kw>
            <kw>Shortest</kw>
            <kw>Path</kw>
            <kw>First</kw>
            <kw>routing</kw>
            <kw>Autonomous</kw>
            <kw>system</kw>
            <kw>AS</kw>
        </keywords>
        <abstract>This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2178</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0054</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2329</doc-id>
        <title>OSPF Standardization Report</title>
        <author>
            <name>J. Moy</name>
        </author>
        <date>
            <month>April</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15130</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>open</kw>
            <kw>shortest</kw>
            <kw>path</kw>
            <kw>first</kw>
        </keywords>
        <abstract>This memo documents how the requirements for advancing a routing protocol to Full Standard have been met for OSPFv2. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2330</doc-id>
        <title>Framework for IP Performance Metrics</title>
        <author>
            <name>V. Paxson</name>
        </author>
        <author>
            <name>G. Almes</name>
        </author>
        <author>
            <name>J. Mahdavi</name>
        </author>
        <author>
            <name>M. Mathis</name>
        </author>
        <date>
            <month>May</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>94387</char-count>
            <page-count>40</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>measurement</kw>
            <kw>statistics</kw>
        </keywords>
        <abstract>The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2331</doc-id>
        <title>ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update</title>
        <author>
            <name>M. Maher</name>
        </author>
        <date>
            <month>April</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>61119</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>UNI-SIG</kw>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo describes how to efficiently use the ATM call control signalling procedures defined in UNI Signalling 4.0 to support IP over ATM environments as described in RFC 2225 and in RFC 2332. [STANDARDS- TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2332</doc-id>
        <title>NBMA Next Hop Resolution Protocol (NHRP)</title>
        <author>
            <name>J. Luciani</name>
        </author>
        <author>
            <name>D. Katz</name>
        </author>
        <author>
            <name>D. Piscitello</name>
        </author>
        <author>
            <name>B. Cole</name>
        </author>
        <author>
            <name>N. Doraswamy</name>
        </author>
        <date>
            <month>April</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>126978</char-count>
            <page-count>52</page-count>
        </format>
        <keywords>
            <kw>NHRP</kw>
            <kw>internetworking</kw>
            <kw>layer</kw>
            <kw>address</kw>
            <kw>subnetwork</kw>
            <kw>multiprotocol</kw>
            <kw>non-broadcast</kw>
            <kw>multiple</kw>
            <kw>access</kw>
        </keywords>
        <abstract>This document describes the NBMA Next Hop Resolution Protocol (NHRP). NHRP can be used by a source station (host or router) connected to a Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the internetworking layer address and NBMA subnetwork addresses of the "NBMA next hop" towards a destination station. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2333</doc-id>
        <title>NHRP Protocol Applicability Statement</title>
        <author>
            <name>D. Cansever</name>
        </author>
        <date>
            <month>April</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20164</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>next</kw>
            <kw>hop</kw>
            <kw>resolution</kw>
            <kw>protocol</kw>
            <kw>routing</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>As required by the Routing Protocol Criteria [RFC 1264], this memo discusses the applicability of the Next Hop Resolution Protocol (NHRP) in routing of IP datagrams over Non-Broadcast Multiple Access (NBMA) networks, such as ATM, SMDS and X.25. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2334</doc-id>
        <title>Server Cache Synchronization Protocol (SCSP)</title>
        <author>
            <name>J. Luciani</name>
        </author>
        <author>
            <name>G. Armitage</name>
        </author>
        <author>
            <name>J. Halpern</name>
        </author>
        <author>
            <name>N. Doraswamy</name>
        </author>
        <date>
            <month>April</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>98161</char-count>
            <page-count>40</page-count>
        </format>
        <keywords>
            <kw>SCSP</kw>
            <kw>cache</kw>
            <kw>synchronization</kw>
            <kw>replication</kw>
            <kw>NBMA</kw>
            <kw>non</kw>
            <kw>broadcast</kw>
            <kw>multiple</kw>
            <kw>access</kw>
        </keywords>
        <abstract>This document describes the Server Cache Synchronization Protocol (SCSP) and is written in terms of SCSP's use within Non Broadcast Multiple Access (NBMA) networks; although, a somewhat straight forward usage is applicable to BMA networks. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2335</doc-id>
        <title>A Distributed NHRP Service Using SCSP</title>
        <author>
            <name>J. Luciani</name>
        </author>
        <date>
            <month>April</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14007</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>NHRP-SCSP</kw>
            <kw>next</kw>
            <kw>hop</kw>
            <kw>resolution</kw>
            <kw>protocol</kw>
            <kw>server</kw>
            <kw>cache</kw>
            <kw>sychronization</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document describes a method for distributing an NHRP service within a LIS. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2336</doc-id>
        <title>Classical IP to NHRP Transition</title>
        <author>
            <name>J. Luciani</name>
        </author>
        <date>
            <month>July</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10500</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>This document describes methods and procedures for the graceful transition from an ATMARP LIS to an NHRP LIS network model over ATM. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2337</doc-id>
        <title>Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM</title>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>April</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16357</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
        </keywords>
        <abstract>This document describes how intra-LIS IP multicast can be efficiently supported among routers over ATM without using the Multicast Address Resolution Server (MARS). This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2338</doc-id>
        <title>Virtual Router Redundancy Protocol</title>
        <author>
            <name>S. Knight</name>
        </author>
        <author>
            <name>D. Weaver</name>
        </author>
        <author>
            <name>D. Whipple</name>
        </author>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>D. Mitzel</name>
        </author>
        <author>
            <name>P. Hunt</name>
        </author>
        <author>
            <name> P. Higginson</name>
        </author>
        <author>
            <name>M. Shand</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <date>
            <month>April</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59871</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>VRRP</kw>
            <kw>vrrp</kw>
            <kw>lan</kw>
            <kw>local</kw>
            <kw>area</kw>
            <kw>network</kw>
            <kw>ip</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3768</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2339</doc-id>
        <title>An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols</title>
        <author>
            <name>The Internet Society</name>
        </author>
        <author>
            <name>Sun Microsystems</name>
        </author>
        <date>
            <month>May</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10745</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>ISOC</kw>
            <kw>network</kw>
            <kw>file</kw>
            <kw>system</kw>
            <kw>internet</kw>
            <kw>engineering</kw>
            <kw>task</kw>
            <kw>force</kw>
        </keywords>
        <abstract>This Request for Comments records an agreement between Sun Microsystems, Inc. and the Internet Society to permit the flow of Sun's Network File System specifications into the Internet Standards process conducted by the Internet Engineering Task Force. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2340</doc-id>
        <title>Nortel's Virtual Network Switching (VNS) Overview</title>
        <author>
            <name>B. Jamoussi</name>
        </author>
        <author>
            <name>D. Jamieson</name>
        </author>
        <author>
            <name>D. Williston</name>
        </author>
        <author>
            <name>S. Gabe</name>
        </author>
        <date>
            <month>May</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30731</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>routing</kw>
            <kw>packet</kw>
            <kw>switching</kw>
            <kw>multi-protocol</kw>
        </keywords>
        <abstract>This document provides an overview of Virtual Network Switching (VNS). This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2341</doc-id>
        <title>Cisco Layer Two Forwarding (Protocol) "L2F"</title>
        <author>
            <name>A. Valencia</name>
        </author>
        <author>
            <name>M. Littlewood</name>
        </author>
        <author>
            <name>T. Kolar</name>
        </author>
        <date>
            <month>May</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>66592</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>L2F</kw>
            <kw>tunneling</kw>
            <kw>dial-up</kw>
            <kw>network</kw>
        </keywords>
        <abstract>This document describes the Layer Two Forwarding protocol (L2F) which permits the tunneling of the link layer (i.e., HDLC, async HDLC, or SLIP frames) of higher level protocols. This memo describes a historic protocol for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2342</doc-id>
        <title>IMAP4 Namespace</title>
        <author>
            <name>M. Gahrns</name>
        </author>
        <author>
            <name>C. Newman</name>
        </author>
        <date>
            <month>May</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19489</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>IMAP4NAME</kw>
            <kw>internet</kw>
            <kw>message</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>mailbox</kw>
        </keywords>
        <abstract>This document defines a NAMESPACE command that allows a client to discover the prefixes of namespaces used by a server for personal mailboxes, other users' mailboxes, and shared mailboxes. [STANDARDS- TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2343</doc-id>
        <title>RTP Payload Format for Bundled MPEG</title>
        <author>
            <name>M. Civanlar</name>
        </author>
        <author>
            <name>G. Cash</name>
        </author>
        <author>
            <name>B. Haskell</name>
        </author>
        <date>
            <month>May</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16557</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>RTP-MPEG</kw>
            <kw>real-time</kw>
            <kw>transport</kw>
            <kw>protocol</kw>
            <kw>audio</kw>
            <kw>video</kw>
        </keywords>
        <abstract>This document describes a payload type for bundled, MPEG-2 encoded video and audio data that may be used with RTP, version 2. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2344</doc-id>
        <title>Reverse Tunneling for Mobile IP</title>
        <author>
            <name>G. Montenegro</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39468</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>MOBILIPREV</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>extensions</kw>
            <kw>home</kw>
            <kw>foreign</kw>
            <kw>agent</kw>
            <kw>encapsulating</kw>
            <kw>delivery</kw>
            <kw>style</kw>
        </keywords>
        <abstract>This document proposes backwards-compatible extensions to Mobile IP in order to support topologically correct reverse tunnels. [STANDARDS- TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3024</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2345</doc-id>
        <title>Domain Names and Company Name Retrieval</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>T. Wolf</name>
        </author>
        <author>
            <name>G. Oglesby</name>
        </author>
        <date>
            <month>May</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29707</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>URL</kw>
            <kw>mapping</kw>
            <kw>service</kw>
            <kw>whois</kw>
            <kw>dns</kw>
        </keywords>
        <abstract>This document proposes a company name to URL mapping service based on the oldest and least complex of Internet directory protocols, whois, in order to explore whether an extremely simple and widely-deployed protocol can succeed where more complex and powerful options have failed or been excessively delayed. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2346</doc-id>
        <title>Making Postscript and PDF International</title>
        <author>
            <name>J. Palme</name>
        </author>
        <date>
            <month>May</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12382</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>portable</kw>
            <kw>document</kw>
            <kw>format</kw>
            <kw>document</kw>
        </keywords>
        <abstract>Certain text formats, for example Postscript (MIME-Type: application/postscript; file extension .ps) and Portable Document Format (MIME-Type: application/pdf; file extension .pdf) specify exactly the page layout of the printed document. The commonly used paper format is different in North America and the rest of the world. North America uses the 'Letter' format, while the rest of the world mostly uses the ISO-standard 'A4' format. This means that documents formatted on one continent may not be easily printable on another continent. This memo gives advice on how to produce documents which are equally well printable with the Letter and the A4 formats. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2347</doc-id>
        <title>TFTP Option Extension</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <author>
            <name>A. Harkin</name>
        </author>
        <date>
            <month>May</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13060</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>TFTP-Ext</kw>
            <kw>trivial</kw>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>booting</kw>
            <kw>client</kw>
            <kw>server</kw>
        </keywords>
        <abstract>The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1782</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC1350</doc-id>
        </updates>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2348</doc-id>
        <title>TFTP Blocksize Option</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <author>
            <name>A. Harkin</name>
        </author>
        <date>
            <month>May</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9515</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>TFTP-Blk</kw>
            <kw>trivial</kw>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>booting</kw>
            <kw>client</kw>
            <kw>server</kw>
            <kw>extension</kw>
        </keywords>
        <abstract>The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1783</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC1350</doc-id>
        </updates>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2349</doc-id>
        <title>TFTP Timeout Interval and Transfer Size Options</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <author>
            <name>A. Harkin</name>
        </author>
        <date>
            <month>May</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7848</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>TFTP-Opt</kw>
            <kw>trivial</kw>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>booting</kw>
            <kw>client</kw>
            <kw>server</kw>
            <kw>extension</kw>
        </keywords>
        <abstract>The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes two TFTP options. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1784</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC1350</doc-id>
        </updates>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2350</doc-id>
        <title>Expectations for Computer Security Incident Response</title>
        <author>
            <name>N. Brownlee</name>
        </author>
        <author>
            <name>E. Guttman</name>
        </author>
        <date>
            <month>June</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>86545</char-count>
            <page-count>38</page-count>
        </format>
        <keywords>
            <kw>CSIRT</kw>
            <kw>guidelines</kw>
            <kw>user</kw>
        </keywords>
        <is-also>
            <doc-id>BCP0021</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2351</doc-id>
        <title>Mapping of Airline Reservation, Ticketing, and Messaging Traffic over IP</title>
        <author>
            <name>A. Robert</name>
        </author>
        <date>
            <month>May</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43440</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw></kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>encapsulation</kw>
            <kw>transactional</kw>
            <kw>traffic</kw>
            <kw>messaging</kw>
        </keywords>
        <abstract>This memo specifies a protocol for the encapsulation of the airline specific protocol over IP. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2352</doc-id>
        <title>A Convention For Using Legal Names as Domain Names</title>
        <author>
            <name>O. Vaughan</name>
        </author>
        <date>
            <month>May</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16354</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>DNS</kw>
        </keywords>
        <abstract>The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <obsoletes>
            <doc-id>RFC2240</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2353</doc-id>
        <title>APPN/HPR in IP Networks APPN Implementers' Workshop Closed Pages Document</title>
        <author>
            <name>G. Dudley</name>
        </author>
        <date>
            <month>May</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>116972</char-count>
            <page-count>48</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>advanced</kw>
            <kw>peer-to-peer</kw>
            <kw>networking</kw>
            <kw>high</kw>
            <kw>performance</kw>
            <kw>routing</kw>
        </keywords>
        <abstract>This memo defines a method with which HPR nodes can use IP networks for communication, and the enhancements to APPN required by this method. This memo also describes an option set that allows the use of the APPN connection network model to allow HPR nodes to use IP networks for communication without having to predefine link connections. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2354</doc-id>
        <title>Options for Repair of Streaming Media</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>O. Hodson</name>
        </author>
        <date>
            <month>June</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28876</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>packets</kw>
            <kw>UDP</kw>
            <kw>user</kw>
            <kw>datagram</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document summarizes a range of possible techniques for the repair of continuous media streams subject to packet loss. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2355</doc-id>
        <title>TN3270 Enhancements</title>
        <author>
            <name>B. Kelly</name>
        </author>
        <date>
            <month>June</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>89394</char-count>
            <page-count>38</page-count>
        </format>
        <keywords>
            <kw>TN3270E</kw>
            <kw>Telnet</kw>
            <kw>option</kw>
            <kw>client</kw>
        </keywords>
        <abstract>This document describes a protocol that more fully supports 3270 devices than do traditional tn3270 practices. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1647</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2356</doc-id>
        <title>Sun's SKIP Firewall Traversal for Mobile IP</title>
        <author>
            <name>G. Montenegro</name>
        </author>
        <author>
            <name>V. Gupta</name>
        </author>
        <date>
            <month>June</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53198</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>security</kw>
            <kw>traffic</kw>
        </keywords>
        <abstract>The Mobile IP specification establishes the mechanisms that enable a mobile host to maintain and use the same IP address as it changes its point of attachment to the network. The mechanisms described in this document allow a mobile node out on a public sector of the internet to negotiate access past a SKIP firewall, and construct a secure channel into its home network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2357</doc-id>
        <title>IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols</title>
        <author>
            <name>A. Mankin</name>
        </author>
        <author>
            <name>A. Romanow</name>
        </author>
        <author>
            <name>S. Bradner</name>
        </author>
        <author>
            <name>V. Paxson</name>
        </author>
        <date>
            <month>June</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24130</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>engineering</kw>
            <kw>task</kw>
            <kw>force</kw>
            <kw>rmtp</kw>
            <kw>procedures</kw>
        </keywords>
        <abstract>This memo describes the procedures and criteria for reviewing reliable multicast protocols within the Transport Area (TSV) of the IETF. Within today's Internet, important applications exist for a reliable multicast service. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2358</doc-id>
        <title>Definitions of Managed Objects for the Ethernet-like Interface Types</title>
        <author>
            <name>J. Flick</name>
        </author>
        <author>
            <name>J. Johnson</name>
        </author>
        <date>
            <month>June</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>87891</char-count>
            <page-count>39</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>802.3</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo obsoletes RFC 1650 "Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2". This memo extends that specification by including management information useful for the management of 100 Mb/s Ethernet interfaces. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1650</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2665</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2359</doc-id>
        <title>IMAP4 UIDPLUS extension</title>
        <author>
            <name>J. Myers</name>
        </author>
        <date>
            <month>June</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10862</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>IMAP4UIDPL</kw>
            <kw>internet</kw>
            <kw>message</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>disconnected</kw>
            <kw>operation</kw>
        </keywords>
        <abstract>The UIDPLUS extension of the Internet Message Access Protocol [IMAP4] provides a set of features intended to reduce the amount of time and resources used by some client operations. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2360</doc-id>
        <title>Guide for Internet Standards Writers</title>
        <author>
            <name>G. Scott</name>
        </author>
        <date>
            <month>June</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47280</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>specification</kw>
            <kw>multiple</kw>
            <kw>implementations</kw>
        </keywords>
        <abstract>This document is a guide for Internet standard writers. It defines those characteristics that make standards coherent, unambiguous, and easy to interpret. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <is-also>
            <doc-id>BCP0022</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2361</doc-id>
        <title>WAVE and AVI Codec Registries</title>
        <author>
            <name>E. Fleischman</name>
        </author>
        <date>
            <month>June</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>97796</char-count>
            <page-count>71</page-count>
        </format>
        <keywords>
            <kw>multimedia</kw>
            <kw>parameter</kw>
            <kw>audio</kw>
            <kw>video</kw>
            <kw>microsoft</kw>
        </keywords>
        <abstract>The purpose of this paper is to establish a mechanism by which codecs registered within Microsoft's WAVE and AVI Registries may be referenced within the IANA Namespace by Internet applications. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2362</doc-id>
        <title>Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification</title>
        <author>
            <name>D.  Estrin</name>
        </author>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>A. Helmy</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>S. Deering</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>V. Jacobson</name>
        </author>
        <author>
            <name>C. Liu</name>
        </author>
        <author>
            <name>P. Sharma</name>
        </author>
        <author>
            <name>L. Wei</name>
        </author>
        <date>
            <month>June</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>159833</char-count>
            <page-count>66</page-count>
        </format>
        <keywords>
            <kw>PIM-SM</kw>
            <kw>routing</kw>
            <kw>message</kw>
            <kw>type</kw>
            <kw>timers</kw>
            <kw>flags</kw>
        </keywords>
        <abstract>This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. </abstract>
        <obsoletes>
            <doc-id>RFC2117</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2363</doc-id>
        <title>PPP Over FUNI</title>
        <author>
            <name>G. Gross</name>
        </author>
        <author>
            <name>M. Kaycee</name>
        </author>
        <author>
            <name>A. Li</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <author>
            <name>J. Stephens</name>
        </author>
        <date>
            <month>July</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22576</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>PPP-FUNI</kw>
            <kw>point-to-point</kw>
            <kw>protocol</kw>
            <kw>atm</kw>
            <kw>synchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>frame</kw>
            <kw>user</kw>
            <kw>network</kw>
            <kw>interface</kw>
        </keywords>
        <abstract>This document describes the use of ATM Frame User Network Interface (FUNI) for framing PPP encapsulated packets. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2364</doc-id>
        <title>PPP Over AAL5</title>
        <author>
            <name>G. Gross</name>
        </author>
        <author>
            <name>M. Kaycee</name>
        </author>
        <author>
            <name>A. Li</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <author>
            <name>J. Stephens</name>
        </author>
        <date>
            <month>July</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23539</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>PPP-AAL</kw>
            <kw>point-to-point</kw>
            <kw>protocol</kw>
            <kw>link</kw>
            <kw>control</kw>
            <kw>network-layer</kw>
            <kw>authentication</kw>
            <kw>compression</kw>
        </keywords>
        <abstract>This document describes the use of ATM Adaptation Layer 5 (AAL5) for framing PPP encapsulated packets. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2365</doc-id>
        <title>Administratively Scoped IP Multicast</title>
        <author>
            <name>D. Meyer</name>
        </author>
        <date>
            <month>July</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17770</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>IPv4</kw>
            <kw>ipv6</kw>
            <kw>address</kw>
            <kw>classes</kw>
        </keywords>
        <abstract>This document defines the "administratively scoped IPv4 multicast space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it describes a simple set of semantics for the implementation of Administratively Scoped IP Multicast. Finally, it provides a mapping between the IPv6 multicast address classes [RFC1884] and IPv4 multicast address classes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <is-also>
            <doc-id>BCP0023</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2366</doc-id>
        <title>Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks</title>
        <author>
            <name>C. Chung</name>
        </author>
        <author>
            <name>M. Greene</name>
        </author>
        <date>
            <month>July</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>134312</char-count>
            <page-count>76</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for IP hosts and routers that use a Multicast Address Resolution Server (MARS) to support IP multicast over ATM, as described in 'Support for Multicast over UNI 3.0/3.1 based ATM Networks'. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC2417</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2367</doc-id>
        <title>PF_KEY Key Management API, Version 2</title>
        <author>
            <name>D. McDonald</name>
        </author>
        <author>
            <name>C. Metz</name>
        </author>
        <author>
            <name>B. Phan</name>
        </author>
        <date>
            <month>July</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>146754</char-count>
            <page-count>68</page-count>
        </format>
        <keywords>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>security</kw>
            <kw>application</kw>
            <kw>programming</kw>
            <kw>interface</kw>
        </keywords>
        <abstract>A generic key management API that can be used not only for IP Security but also for other network security services is presented in this document. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2368</doc-id>
        <title>The mailto URL scheme</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>L. Masinter</name>
        </author>
        <author>
            <name>J. Zawinski</name>
        </author>
        <date>
            <month>July</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16502</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>URLMAILTO</kw>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>locator</kw>
            <kw>electronic</kw>
            <kw>mail</kw>
            <kw>addresses</kw>
        </keywords>
        <abstract>This document defines the format of Uniform Resource Locators (URL) for designating electronic mail addresses. [STANDARDS-TRACK] </abstract>
        <updates>
            <doc-id>RFC1738</doc-id>
            <doc-id>RFC1808</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2369</doc-id>
        <title>The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields</title>
        <author>
            <name>G. Neufeld</name>
        </author>
        <author>
            <name>J. Baer</name>
        </author>
        <date>
            <month>July</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30853</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>locator</kw>
            <kw>email</kw>
            <kw>header</kw>
            <kw>fields</kw>
        </keywords>
        <abstract>The mailing list command specification header fields are a set of structured fields to be added to email messages sent by email distribution lists. By including these header fields, list servers can make it possible for mail clients to provide automated tools for users to perform list functions. This could take the form of a menu item, push button, or other user interface element. The intent is to simplify the user experience, providing a common interface to the often cryptic and varied mailing list manager commands. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2370</doc-id>
        <title>The OSPF Opaque LSA Option</title>
        <author>
            <name>R. Coltun</name>
        </author>
        <date>
            <month>July</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33789</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>OSPF-LSA</kw>
            <kw>open-shortest</kw>
            <kw>path</kw>
            <kw>first</kw>
            <kw>ink</kw>
            <kw>state</kw>
            <kw>advertisement</kw>
        </keywords>
        <abstract>This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. [STANDARDS-TRACK] </abstract>
        <updated-by>
            <doc-id>RFC3630</doc-id>
        </updated-by>
        <see-also>
            <doc-id>RFC2328</doc-id>
        </see-also>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2371</doc-id>
        <title>Transaction Internet Protocol Version 3.0</title>
        <author>
            <name>J. Lyon</name>
        </author>
        <author>
            <name>K. Evans</name>
        </author>
        <author>
            <name>J. Klein</name>
        </author>
        <date>
            <month>July</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>71399</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>TIPV3</kw>
            <kw>TIP</kw>
            <kw>commit</kw>
            <kw>protocol</kw>
            <kw>electronic</kw>
            <kw>commerce</kw>
        </keywords>
        <abstract>In many applications where different nodes cooperate on some work, there is a need to guarantee that the work happens atomically. That is, each node must reach the same conclusion as to whether the work is to be completed, even in the face of failures. This document proposes a simple, easily-implemented protocol for achieving this end. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2372</doc-id>
        <title>Transaction Internet Protocol - Requirements and Supplemental Information</title>
        <author>
            <name>K. Evans</name>
        </author>
        <author>
            <name>J. Klein</name>
        </author>
        <author>
            <name>J. Lyon</name>
        </author>
        <date>
            <month>July</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53699</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>TIP</kw>
            <kw>commit</kw>
            <kw>protocol</kw>
            <kw>electronic</kw>
            <kw>commerce</kw>
        </keywords>
        <abstract>This document describes the purpose (usage scenarios), and requirements for the Transaction Internet Protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2373</doc-id>
        <title>IP Version 6 Addressing Architecture</title>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>S. Deering</name>
        </author>
        <date>
            <month>July</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52526</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>unicast</kw>
            <kw>anycast</kw>
            <kw>multicast</kw>
            <kw>node</kw>
        </keywords>
        <abstract>This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1884</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3513</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2374</doc-id>
        <title>An IPv6 Aggregatable Global Unicast Address Format</title>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>M. O'Dell</name>
        </author>
        <author>
            <name>S. Deering</name>
        </author>
        <date>
            <month>July</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25068</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>architecture</kw>
            <kw>routing</kw>
        </keywords>
        <abstract>This document defines an IPv6 aggregatable global unicast address format for use in the Internet. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2073</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3587</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2375</doc-id>
        <title>IPv6 Multicast Address Assignments</title>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>S. Deering</name>
        </author>
        <date>
            <month>July</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14356</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>multicast</kw>
            <kw>scope</kw>
            <kw>value</kw>
        </keywords>
        <abstract>This document defines the initial assignment of IPv6 multicast addresses. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2376</doc-id>
        <title>XML Media Types</title>
        <author>
            <name>E. Whitehead</name>
        </author>
        <author>
            <name>M. Murata</name>
        </author>
        <date>
            <month>July</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32143</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>extensible</kw>
            <kw>markup</kw>
            <kw>language</kw>
            <kw>web</kw>
            <kw>authority</kw>
            <kw>hypertext</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document proposes two new media subtypes, text/xml and application/xml, for use in exchanging network entities which are conforming Extensible Markup Language (XML). This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <obsoleted-by>
            <doc-id>RFC3023</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2377</doc-id>
        <title>Naming Plan for Internet Directory-Enabled Applications</title>
        <author>
            <name>A. Grimstad</name>
        </author>
        <author>
            <name>R. Huber</name>
        </author>
        <author>
            <name>S. Sataluri</name>
        </author>
        <author>
            <name>M. Wahl</name>
        </author>
        <date>
            <month>September</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38274</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>x.500</kw>
            <kw>applications</kw>
            <kw>iwps</kw>
            <kw>white</kw>
            <kw>pages</kw>
            <kw>service</kw>
        </keywords>
        <abstract>Application of the conventional X.500 approach to naming has heretofore, in the experience of the authors, proven to be an obstacle to the wide deployment of directory-enabled applications on the Internet. We propose a new directory naming plan that leverages the strengths of the most popular and successful Internet naming schemes for naming objects in a hierarchical directory. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2378</doc-id>
        <title>The CCSO Nameserver (Ph) Architecture</title>
        <author>
            <name>R. Hedberg</name>
        </author>
        <author>
            <name>P. Pomes</name>
        </author>
        <date>
            <month>September</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38960</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>computing</kw>
            <kw>communications</kw>
            <kw>services</kw>
            <kw>office</kw>
            <kw>database</kw>
        </keywords>
        <abstract>The Ph Nameserver from the Computing and Communications Services Office (CCSO), University of Illinois at Urbana-Champaign has for some time now been used by several organizations as their choice of publicly available database for information about people as well as other things. This document provides a formal definition of the client-server protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2379</doc-id>
        <title>RSVP over ATM Implementation Guidelines</title>
        <author>
            <name>L. Berger</name>
        </author>
        <date>
            <month>August</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15174</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
            <kw>switched</kw>
            <kw>circuits</kw>
        </keywords>
        <abstract>This memo presents specific implementation guidelines for running RSVP over ATM switched virtual circuits (SVCs). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <is-also>
            <doc-id>BCP0024</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2380</doc-id>
        <title>RSVP over ATM Implementation Requirements</title>
        <author>
            <name>L. Berger</name>
        </author>
        <date>
            <month>August</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31234</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>switched</kw>
            <kw>circuits</kw>
        </keywords>
        <abstract>This memo presents specific implementation requirements for running RSVP over ATM switched virtual circuits (SVCs). It presents requirements that ensure interoperability between multiple implementations and conformance to the RSVP and Integrated Services specifications. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2381</doc-id>
        <title>Interoperation of Controlled-Load Service and Guaranteed Service with ATM</title>
        <author>
            <name>M. Garrett</name>
        </author>
        <author>
            <name>M. Borden</name>
        </author>
        <date>
            <month>August</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>107299</char-count>
            <page-count>43</page-count>
        </format>
        <keywords>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>mapping</kw>
            <kw>traffic</kw>
            <kw>parameters</kw>
        </keywords>
        <abstract>This document provides guidelines for mapping service classes, and traffic management features and parameters between Internet and ATM technologies. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2382</doc-id>
        <title>A Framework for Integrated Services and RSVP over ATM</title>
        <author>
            <name>E. Crawley</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>S. Berson</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>M. Borden</name>
        </author>
        <author>
            <name>J. Krawczyk</name>
        </author>
        <date>
            <month>August</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>73865</char-count>
            <page-count>30</page-count>
        </format>
        <abstract>This document outlines the issues and framework related to providing IP Integrated Services with RSVP over ATM. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2383</doc-id>
        <title>ST2+ over ATM Protocol Specification - UNI 3.1 Version</title>
        <author>
            <name>M. Suzuki</name>
        </author>
        <date>
            <month>August</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>99889</char-count>
            <page-count>50</page-count>
        </format>
        <keywords>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>stream</kw>
            <kw>resource</kw>
            <kw>reservation</kw>
        </keywords>
        <abstract>This document specifies an ATM-based protocol for communication between ST2+ agents. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2384</doc-id>
        <title>POP URL Scheme</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <date>
            <month>August</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13649</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>POP-URL</kw>
            <kw>post</kw>
            <kw>office</kw>
            <kw>protocol</kw>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>identifier</kw>
            <kw>string</kw>
            <kw>encapsulation</kw>
        </keywords>
        <abstract>This memo defines a URL scheme for referencing a POP mailbox. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2385</doc-id>
        <title>Protection of BGP Sessions via the TCP MD5 Signature Option</title>
        <author>
            <name>A. Heffernan</name>
        </author>
        <date>
            <month>August</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12315</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>border</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>message</kw>
            <kw>digest</kw>
            <kw>algorithm</kw>
        </keywords>
        <abstract>This memo describes a TCP extension to enhance security for BGP. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2386</doc-id>
        <title>A Framework for QoS-based Routing in the Internet</title>
        <author>
            <name>E. Crawley</name>
        </author>
        <author>
            <name>R. Nair</name>
        </author>
        <author>
            <name>B. Rajagopalan</name>
        </author>
        <author>
            <name>H. Sandick</name>
        </author>
        <date>
            <month>August</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>93459</char-count>
            <page-count>37</page-count>
        </format>
        <keywords>
            <kw>quality of service</kw>
            <kw>interdomain</kw>
            <kw>intradomain</kw>
        </keywords>
        <abstract>This document describes some of the QoS-based routing issues and requirements, and proposes a framework for QoS-based routing in the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2387</doc-id>
        <title>The MIME Multipart/Related Content-type</title>
        <author>
            <name>E. Levinson</name>
        </author>
        <date>
            <month>August</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18864</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>MIME-RELAT</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>body</kw>
            <kw>parts</kw>
            <kw>media-type</kw>
        </keywords>
        <abstract>This document defines the Multipart/Related content-type and provides examples of its use. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2112</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2388</doc-id>
        <title>Returning Values from Forms: multipart/form-data</title>
        <author>
            <name>L. Masinter</name>
        </author>
        <date>
            <month>August</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16531</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>media-type</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This specification defines an Internet Media Type, multipart/form-data, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2389</doc-id>
        <title>Feature negotiation mechanism for the File Transfer Protocol</title>
        <author>
            <name>P. Hethmon</name>
        </author>
        <author>
            <name>R. Elz</name>
        </author>
        <date>
            <month>August</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18536</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>FTP</kw>
            <kw>catalogue</kw>
        </keywords>
        <abstract>This document provides a mechanism by which clients of the FTP protocol can discover which new features are supported by a particular FTP server. [STANDARDS-TRACK] </abstract>
        <see-also>
            <doc-id>RFC0959</doc-id>
        </see-also>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2390</doc-id>
        <title>Inverse Address Resolution Protocol</title>
        <author>
            <name>T. Bradley</name>
        </author>
        <author>
            <name>C. Brown</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <date>
            <month>September</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20849</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>IARP</kw>
            <kw>iarp</kw>
            <kw>hardware</kw>
            <kw>frame</kw>
            <kw>relay</kw>
        </keywords>
        <abstract>This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1293</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2391</doc-id>
        <title>Load Sharing using IP Network Address Translation (LSNAT)</title>
        <author>
            <name>P. Srisuresh</name>
        </author>
        <author>
            <name>D. Gan</name>
        </author>
        <date>
            <month>August</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44884</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>datagram</kw>
            <kw>server</kw>
        </keywords>
        <abstract>In this document, we extend the use of NATs to offer Load share feature, where session load can be distributed across a pool of servers, instead of directing to a single server. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2392</doc-id>
        <title>Content-ID and Message-ID Uniform Resource Locators</title>
        <author>
            <name>E. Levinson</name>
        </author>
        <date>
            <month>August</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11141</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>CIDMID-URL</kw>
            <kw>Hyper</kw>
            <kw>Text</kw>
            <kw>Markup</kw>
            <kw>Language</kw>
            <kw>URL</kw>
            <kw>MIME</kw>
        </keywords>
        <abstract>The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. [STANDARDS- TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2111</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2393</doc-id>
        <title>IP Payload Compression Protocol (IPComp)</title>
        <author>
            <name>A. Shacham</name>
        </author>
        <author>
            <name>R. Monsour</name>
        </author>
        <author>
            <name>R. Pereira</name>
        </author>
        <author>
            <name>M. Thomas</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20757</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>IPCOMP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>datagram</kw>
            <kw>lossless</kw>
        </keywords>
        <abstract>This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3173</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2394</doc-id>
        <title>IP Payload Compression Using DEFLATE</title>
        <author>
            <name>R. Pereira</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11053</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>algorithm</kw>
            <kw>datagram</kw>
            <kw>format</kw>
        </keywords>
        <abstract>This document describes a compression method based on the DEFLATE compression algorithm. This document defines the application of the DEFLATE algorithm to the IP Payload Compression Protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2395</doc-id>
        <title>IP Payload Compression Using LZS</title>
        <author>
            <name>R. Friend</name>
        </author>
        <author>
            <name>R. Monsour</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14882</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>algorithm</kw>
            <kw>datagram</kw>
            <kw>lossless</kw>
        </keywords>
        <abstract>This document describes a compression method based on the LZS compression algorithm. This document defines the application of the LZS algorithm to the IP Payload Compression Protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2396</doc-id>
        <title>Uniform Resource Identifiers (URI): Generic Syntax</title>
        <author>
            <name>T. Berners-Lee</name>
        </author>
        <author>
            <name>R. Fielding</name>
        </author>
        <author>
            <name>L. Masinter</name>
        </author>
        <date>
            <month>August</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>83639</char-count>
            <page-count>40</page-count>
        </format>
        <keywords>
            <kw>URI-GEN</kw>
            <kw>characters</kw>
            <kw>string</kw>
            <kw>absolute</kw>
            <kw>relative</kw>
        </keywords>
        <abstract>This document defines a grammar that is a superset of all valid URI, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier type. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3986</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1808</doc-id>
            <doc-id>RFC1738</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC2732</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2397</doc-id>
        <title>The "data" URL scheme</title>
        <author>
            <name>L. Masinter</name>
        </author>
        <date>
            <month>August</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9514</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>DATA-URL</kw>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>identifiers</kw>
            <kw>media</kw>
            <kw>type</kw>
        </keywords>
        <abstract>A new URL scheme, "data", is defined. It allows inclusion of small data items as "immediate" data, as if it had been included externally. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2398</doc-id>
        <title>Some Testing Tools for TCP Implementors</title>
        <author>
            <name>S. Parker</name>
        </author>
        <author>
            <name>C. Schmechel</name>
        </author>
        <date>
            <month>August</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24107</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
            <kw>catalogue</kw>
        </keywords>
        <abstract>This document lists only tools which can evaluate one or more TCP implementations, or which can privde some specific results which describe or evaluate the TCP being tested. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. </abstract>
        <is-also>
            <doc-id>FYI0033</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2399</doc-id>
        <title>Request for Comments Summary</title>
        <author>
            <name>A. Ramos</name>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45853</char-count>
            <page-count>23</page-count>
        </format>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2400</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Postel</name>
        </author>
        <author>
            <name>J. Reynolds</name>
        </author>
        <date>
            <month>September</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>110969</char-count>
            <page-count>47</page-count>
        </format>
        <keywords>
            <kw>IAB</kw>
            <kw>official</kw>
            <kw>protocol</kw>
            <kw>standards</kw>
        </keywords>
        <abstract>This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2300</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2500</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2401</doc-id>
        <title>Security Architecture for the Internet Protocol</title>
        <author>
            <name>S. Kent</name>
        </author>
        <author>
            <name>R. Atkinson</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>168162</char-count>
            <page-count>66</page-count>
        </format>
        <keywords>
            <kw>IPSEC</kw>
            <kw>ipsec</kw>
            <kw>authentication</kw>
            <kw>encapsulation</kw>
            <kw>IP</kw>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
            <kw>IP-layer</kw>
        </keywords>
        <abstract>This memo specifies the base architecture for IPsec compliant systems. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1825</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3168</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2402</doc-id>
        <title>IP Authentication Header</title>
        <author>
            <name>S. Kent</name>
        </author>
        <author>
            <name>R. Atkinson</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52831</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>IP-AUTH</kw>
            <kw>ipsec</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>AH</kw>
            <kw>security</kw>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
        </keywords>
        <abstract>The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "authentication"), and to provide protection against replays. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1826</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2403</doc-id>
        <title>The Use of HMAC-MD5-96 within ESP and AH</title>
        <author>
            <name>C. Madson</name>
        </author>
        <author>
            <name>R. Glenn</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13578</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>ipsec</kw>
            <kw>authentication</kw>
            <kw>mechanism</kw>
            <kw>header</kw>
            <kw>security</kw>
            <kw>architecture</kw>
        </keywords>
        <abstract>This memo describes the use of the HMAC algorithm in conjunction with the MD5 algorithm as an authentication mechanism within the revised IPSEC Encapsulating Security Payload and the revised IPSEC Authentication Header. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2404</doc-id>
        <title>The Use of HMAC-SHA-1-96 within ESP and AH</title>
        <author>
            <name>C. Madson</name>
        </author>
        <author>
            <name>R. Glenn</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13089</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>ipsec</kw>
            <kw>authentication</kw>
            <kw>mechanism</kw>
            <kw>header</kw>
            <kw>security</kw>
            <kw>architecture</kw>
            <kw>payload</kw>
        </keywords>
        <abstract>This memo describes the use of the HMAC algorithm in conjunction with the SHA-1 algorithm as an authentication mechanism within the revised IPSEC Encapsulating Security Payload and the revised IPSEC Authentication Header. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2405</doc-id>
        <title>The ESP DES-CBC Cipher Algorithm With Explicit IV</title>
        <author>
            <name>C. Madson</name>
        </author>
        <author>
            <name>N. Doraswamy</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20208</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>ESPDES-CBC</kw>
            <kw>ipsec</kw>
            <kw>payload</kw>
            <kw>security</kw>
            <kw>architecture</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract>This document describes the use of the DES Cipher algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPSec Encapsulating Security Payload (ESP). [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2406</doc-id>
        <title>IP Encapsulating Security Payload (ESP)</title>
        <author>
            <name>S. Kent</name>
        </author>
        <author>
            <name>R. Atkinson</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54202</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>ESP</kw>
            <kw>ipsec</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>encapsulating</kw>
            <kw>security</kw>
            <kw>ipv4</kw>
            <kw>ipv6</kw>
        </keywords>
        <abstract>The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1827</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2407</doc-id>
        <title>The Internet IP Security Domain of Interpretation for ISAKMP</title>
        <author>
            <name>D. Piper</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>67878</char-count>
            <page-count>32</page-count>
        </format>
        <keywords>
            <kw>ISAKMPSEC</kw>
            <kw>ipsec</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>security</kw>
            <kw>association</kw>
            <kw>key</kw>
            <kw>management</kw>
        </keywords>
        <abstract>This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2408</doc-id>
        <title>Internet Security Association and Key Management Protocol (ISAKMP)</title>
        <author>
            <name>D. Maughan</name>
        </author>
        <author>
            <name>M. Schertler</name>
        </author>
        <author>
            <name>M. Schneider</name>
        </author>
        <author>
            <name>J. Turner</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>209175</char-count>
            <page-count>86</page-count>
        </format>
        <keywords>
            <kw>ISAKMP</kw>
            <kw>ipsec</kw>
            <kw>cryptography</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2409</doc-id>
        <title>The Internet Key Exchange (IKE)</title>
        <author>
            <name>D. Harkins</name>
        </author>
        <author>
            <name>D. Carrel</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>94949</char-count>
            <page-count>41</page-count>
        </format>
        <keywords>
            <kw>IKE</kw>
            <kw>ipsec</kw>
            <kw>oakley</kw>
            <kw>authentication</kw>
            <kw>isakmp</kw>
            <kw>internet</kw>
            <kw>security</kw>
            <kw>key</kw>
            <kw>management</kw>
        </keywords>
        <abstract>This memo describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2410</doc-id>
        <title>The NULL Encryption Algorithm and Its Use With IPsec</title>
        <author>
            <name>R. Glenn</name>
        </author>
        <author>
            <name>S. Kent</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11239</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>ipsec</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>security</kw>
            <kw>esp</kw>
            <kw>encapsulating</kw>
            <kw>payload</kw>
        </keywords>
        <abstract>This memo defines the NULL encryption algorithm and its use with the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2411</doc-id>
        <title>IP Security Document Roadmap</title>
        <author>
            <name>R. Thayer</name>
        </author>
        <author>
            <name>N. Doraswamy</name>
        </author>
        <author>
            <name>R. Glenn</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22983</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>ipsec</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>privacy</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This document is intended to provide guidelines for the development of collateral specifications describing the use of new encryption and authentication algorithms with the ESP protocol, described in and new authentication algorithms used with the AH protocol. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2412</doc-id>
        <title>The OAKLEY Key Determination Protocol</title>
        <author>
            <name>H. Orman</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>118649</char-count>
            <page-count>55</page-count>
        </format>
        <keywords>
            <kw>ipsec</kw>
            <kw>authentication</kw>
            <kw>crytographic</kw>
            <kw>secure</kw>
            <kw>scalable</kw>
        </keywords>
        <abstract>This document describes a protocol, named OAKLEY, by which two authenticated parties can agree on secure and secret keying material. The basic mechanism is the Diffie-Hellman key exchange algorithm. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2413</doc-id>
        <title>Dublin Core Metadata for Resource Discovery</title>
        <author>
            <name>S. Weibel</name>
        </author>
        <author>
            <name>J. Kunze</name>
        </author>
        <author>
            <name>C. Lagoze</name>
        </author>
        <author>
            <name>M. Wolf</name>
        </author>
        <date>
            <month>September</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15501</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>workshop</kw>
            <kw>electronic</kw>
            <kw>librarians</kw>
            <kw>network</kw>
        </keywords>
        <abstract>This is the first of a set of Informational RFCs describing the Dublin Core. Its purpose is to introduce the Dublin Core and to describe the consensus reached on the semantics of each of the 15 elements. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2414</doc-id>
        <title>Increasing TCP's Initial Window</title>
        <author>
            <name>M. Allman</name>
        </author>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>C. Partridge</name>
        </author>
        <date>
            <month>September</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32019</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>TCP-WIN</kw>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document specifies an increase in the permitted initial window for TCP from one segment to roughly 4K bytes. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC3390</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2415</doc-id>
        <title>Simulation Studies of Increased Initial TCP Window Size</title>
        <author>
            <name>K. Poduri</name>
        </author>
        <author>
            <name>K. Nichols</name>
        </author>
        <date>
            <month>September</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24205</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
            <kw>file</kw>
            <kw>transfer</kw>
        </keywords>
        <abstract>This document covers some simulation studies of the effects of increasing the initial window size of TCP. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2416</doc-id>
        <title>When TCP Starts Up With Four Packets Into Only Three Buffers</title>
        <author>
            <name>T. Shepard</name>
        </author>
        <author>
            <name>C. Partridge</name>
        </author>
        <date>
            <month>September</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12663</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
            <kw>performance</kw>
        </keywords>
        <abstract>This memo is to document a simple experiment. The experiment showed that in the case of a TCP receiver behind a 9600 bps modem link at the edge of a fast Internet where there are only 3 buffers before the modem (and the fourth packet of a four-packet start will surely be dropped), no significant degradation in performance is experienced by a TCP sending with a four-packet start when compared with a normal slow start (which starts with just one packet). This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2417</doc-id>
        <title>Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks</title>
        <author>
            <name>C. Chung</name>
        </author>
        <author>
            <name>M. Greene</name>
        </author>
        <date>
            <month>September</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>134862</char-count>
            <page-count>76</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
        </keywords>
        <abstract>This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2366</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2418</doc-id>
        <title>IETF Working Group Guidelines and Procedures</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <date>
            <month>September</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>62857</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>BCP</kw>
            <kw>WG</kw>
            <kw>escape</kw>
            <kw>clause</kw>
            <kw>procedures</kw>
        </keywords>
        <abstract>This document describes the guidelines and procedures for formation and operation of IETF working groups. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <obsoletes>
            <doc-id>RFC1603</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3934</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0025</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2419</doc-id>
        <title>The PPP DES Encryption Protocol, Version 2 (DESE-bis)</title>
        <author>
            <name>K. Sklower</name>
        </author>
        <author>
            <name>G. Meyer</name>
        </author>
        <date>
            <month>September</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24414</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>DESE-bis</kw>
            <kw>point-to-point</kw>
            <kw>protocol</kw>
            <kw>ecp</kw>
            <kw>control</kw>
        </keywords>
        <abstract>This document provides specific details for the use of the DES standard for encrypting PPP encapsulated packets. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1969</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2420</doc-id>
        <title>The PPP Triple-DES Encryption Protocol (3DESE)</title>
        <author>
            <name>H. Kummert</name>
        </author>
        <date>
            <month>September</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16729</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>3DESE</kw>
            <kw>point-to-point</kw>
            <kw>protocol</kw>
            <kw>ecp</kw>
            <kw>control</kw>
        </keywords>
        <abstract>This document provides specific details for the use of the Triple-DES standard (3DES) for encrypting PPP encapsulated packets. [STANDARDS- TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2421</doc-id>
        <title>Voice Profile for Internet Mail - version 2</title>
        <author>
            <name>G. Vaudreuil</name>
        </author>
        <author>
            <name>G. Parsons</name>
        </author>
        <date>
            <month>September</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>123663</char-count>
            <page-count>56</page-count>
        </format>
        <keywords>
            <kw>MIME-VP2</kw>
            <kw>vpim</kw>
            <kw>messaging</kw>
        </keywords>
        <abstract>This document profiles Internet mail for voice messaging. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1911</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3801</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2422</doc-id>
        <title>Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration</title>
        <author>
            <name>G. Vaudreuil</name>
        </author>
        <author>
            <name>G. Parsons</name>
        </author>
        <date>
            <month>September</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10157</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>MIME-ADPCM</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>audio</kw>
        </keywords>
        <abstract>This document describes the registration of the MIME sub-type audio/32KADPCM for toll quality audio. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1911</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3802</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2423</doc-id>
        <title>VPIM Voice Message MIME Sub-type Registration</title>
        <author>
            <name>G. Vaudreuil</name>
        </author>
        <author>
            <name>G. Parsons</name>
        </author>
        <date>
            <month>September</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10729</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>MIME-VPIM</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>profiles</kw>
        </keywords>
        <abstract>This document describes the registration of the MIME sub-type multipart/voice-message for use with the Voice Profile for Internet Mail (VPIM). [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1911</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3801</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2424</doc-id>
        <title>Content Duration MIME Header Definition</title>
        <author>
            <name>G. Vaudreuil</name>
        </author>
        <author>
            <name>G. Parsons</name>
        </author>
        <date>
            <month>September</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7116</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>CONT-DUR</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>time</kw>
            <kw>media</kw>
        </keywords>
        <abstract>This document describes the MIME header Content-Duration that is intended for use with any timed media content (typically audio/* or video/*). [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3803</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2425</doc-id>
        <title>A MIME Content-Type for Directory Information</title>
        <author>
            <name>T. Howes</name>
        </author>
        <author>
            <name>M. Smith</name>
        </author>
        <author>
            <name>F. Dawson</name>
        </author>
        <date>
            <month>September</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>64478</char-count>
            <page-count>33</page-count>
        </format>
        <keywords>
            <kw>TXT-DIR</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>profiles</kw>
        </keywords>
        <abstract>This document defines a MIME Content-Type for holding directory information. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2426</doc-id>
        <title>vCard MIME Directory Profile</title>
        <author>
            <name>F. Dawson</name>
        </author>
        <author>
            <name>T. Howes</name>
        </author>
        <date>
            <month>September</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>74646</char-count>
            <page-count>42</page-count>
        </format>
        <keywords>
            <kw>MIME-VCARD</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>white-pages</kw>
            <kw>electronic</kw>
            <kw>business</kw>
            <kw>card</kw>
        </keywords>
        <abstract>This memo defines the profile of the MIME Content-Type for directory information for a white-pages person object, based on a vCard electronic business card. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2427</doc-id>
        <title>Multiprotocol Interconnect over Frame Relay</title>
        <author>
            <name>C. Brown</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <date>
            <month>September</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>74671</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>IP-FR</kw>
            <kw>standard</kw>
            <kw>standards</kw>
            <kw>IP</kw>
            <kw>over</kw>
        </keywords>
        <abstract>This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1490</doc-id>
            <doc-id>RFC1294</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0055</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2428</doc-id>
        <title>FTP Extensions for IPv6 and NATs</title>
        <author>
            <name>M. Allman</name>
        </author>
        <author>
            <name>S. Ostermann</name>
        </author>
        <author>
            <name>C. Metz</name>
        </author>
        <date>
            <month>September</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16028</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>internet</kw>
            <kw>network</kw>
            <kw>address</kw>
            <kw>translators</kw>
        </keywords>
        <abstract>This paper specifies extensions to FTP that will allow the protocol to work over IPv4 and IPv6. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2429</doc-id>
        <title>RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>L. Cline</name>
        </author>
        <author>
            <name>G. Deisher</name>
        </author>
        <author>
            <name>T. Gardos</name>
        </author>
        <author>
            <name>C. Maciocco</name>
        </author>
        <author>
            <name>D. Newell</name>
        </author>
        <author>
            <name>J. Ott</name>
        </author>
        <author>
            <name>G. Sullivan</name>
        </author>
        <author>
            <name>S. Wenger</name>
        </author>
        <author>
            <name>C. Zhu</name>
        </author>
        <date>
            <month>October</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43166</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>real</kw>
            <kw>time</kw>
            <kw>transport</kw>
            <kw>protocol</kw>
            <kw>multicast</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract>This document specifies an RTP payload header format applicable to the transmission of video streams generated based on the 1998 version of ITU-T Recommendation H.263. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2430</doc-id>
        <title>A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)</title>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>October</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40148</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>isp</kw>
            <kw>internet</kw>
            <kw>service</kw>
            <kw>provider</kw>
            <kw>packet</kw>
            <kw>flow</kw>
            <kw>multiprotocol</kw>
            <kw>label</kw>
            <kw>switching</kw>
            <kw>mpls</kw>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
            <kw>rsvp</kw>
        </keywords>
        <abstract>This document describes the Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) for Internet Service Providers (ISPs). This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2431</doc-id>
        <title>RTP Payload Format for BT.656 Video Encoding</title>
        <author>
            <name>D. Tynan</name>
        </author>
        <date>
            <month>October</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22323</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>real</kw>
            <kw>time</kw>
            <kw>transport</kw>
            <kw>protocol</kw>
            <kw>itu</kw>
            <kw>multicast</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract>This document specifies the RTP payload format for encapsulating ITU Recommendation BT.656-3 video streams in the Real-Time Transport Protocol (RTP). [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2432</doc-id>
        <title>Terminology for IP Multicast Benchmarking</title>
        <author>
            <name>K. Dubray</name>
        </author>
        <date>
            <month>October</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29758</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>network</kw>
            <kw>forwarding</kw>
            <kw>devices</kw>
        </keywords>
        <abstract>The purpose of this document is to define terminology specific to the benchmarking of multicast IP forwarding devices. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2433</doc-id>
        <title>Microsoft PPP CHAP Extensions</title>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>S. Cobb</name>
        </author>
        <date>
            <month>October</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34502</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>point to point</kw>
            <kw>protocol</kw>
            <kw>challenge</kw>
            <kw>handshake</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2434</doc-id>
        <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
        <author>
            <name>T. Narten</name>
        </author>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>October</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25092</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>assigned</kw>
            <kw>numbers</kw>
            <kw>authority</kw>
            <kw>values</kw>
            <kw>implementations</kw>
        </keywords>
        <abstract>This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <updated-by>
            <doc-id>RFC3692</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0026</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2435</doc-id>
        <title>RTP Payload Format for JPEG-compressed Video</title>
        <author>
            <name>L. Berc</name>
        </author>
        <author>
            <name>W. Fenner</name>
        </author>
        <author>
            <name>R. Frederick</name>
        </author>
        <author>
            <name>S. McCanne</name>
        </author>
        <author>
            <name>P. Stewart</name>
        </author>
        <date>
            <month>October</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54173</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>Real</kw>
            <kw>Time</kw>
            <kw>Transport</kw>
            <kw>Protocol</kw>
            <kw>Joint</kw>
            <kw>Photographic</kw>
            <kw>Experts</kw>
            <kw>Group</kw>
        </keywords>
        <abstract>This memo describes the RTP payload format for JPEG video streams. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2035</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2436</doc-id>
        <title>Collaboration between ISOC/IETF and ITU-T</title>
        <author>
            <name>R. Brett</name>
        </author>
        <author>
            <name>S. Bradner</name>
        </author>
        <author>
            <name>G. Parsons</name>
        </author>
        <date>
            <month>October</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31154</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>society</kw>
            <kw>engineering</kw>
            <kw>task</kw>
            <kw>force</kw>
        </keywords>
        <abstract>This document describes the collaboration process between the ITU-T and ISOC/IETF. This memo provides information for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC3356</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2437</doc-id>
        <title>PKCS #1: RSA Cryptography Specifications Version 2.0</title>
        <author>
            <name>B. Kaliski</name>
        </author>
        <author>
            <name>J. Staddon</name>
        </author>
        <date>
            <month>October</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>73529</char-count>
            <page-count>39</page-count>
        </format>
        <keywords>
            <kw>data</kw>
            <kw>public</kw>
            <kw>key</kw>
            <kw>cryptosystem</kw>
        </keywords>
        <abstract>This memo is the successor to RFC 2313. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm. This memo provides information for the Internet community. </abstract>
        <obsoletes>
            <doc-id>RFC2313</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3447</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2438</doc-id>
        <title>Advancement of MIB specifications on the IETF Standards Track</title>
        <author>
            <name>M. O'Dell</name>
        </author>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <author>
            <name>B. Wijnen</name>
        </author>
        <author>
            <name>S. Bradner</name>
        </author>
        <date>
            <month>October</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13633</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>internet</kw>
            <kw>engineering</kw>
            <kw>task</kw>
            <kw>force</kw>
        </keywords>
        <abstract>This document specifies the process which the IESG will use to determine if a MIB specification document meets these requirements. It also discusses the rationale for this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <is-also>
            <doc-id>BCP0027</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2439</doc-id>
        <title>BGP Route Flap Damping</title>
        <author>
            <name>C. Villamizar</name>
        </author>
        <author>
            <name>R. Chandra</name>
        </author>
        <author>
            <name>R. Govindan</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>86376</char-count>
            <page-count>37</page-count>
        </format>
        <keywords>
            <kw>Border</kw>
            <kw>Gateway</kw>
            <kw>Protocol</kw>
            <kw>IDRP</kw>
            <kw>Internet-Domain</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract>A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2440</doc-id>
        <title>OpenPGP Message Format</title>
        <author>
            <name>J. Callas</name>
        </author>
        <author>
            <name>L. Donnerhacke</name>
        </author>
        <author>
            <name>H. Finney</name>
        </author>
        <author>
            <name>R. Thayer</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>141371</char-count>
            <page-count>65</page-count>
        </format>
        <keywords>
            <kw>pretty</kw>
            <kw>good</kw>
            <kw>privacy</kw>
            <kw>encryption</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2441</doc-id>
        <title>Working with Jon, Tribute delivered at UCLA, October 30, 1998</title>
        <author>
            <name>D. Cohen</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11992</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>Jonathan B Postel</kw>
        </keywords>
        <abstract>This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2442</doc-id>
        <title>The Batch SMTP Media Type</title>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>D. Newman</name>
        </author>
        <author>
            <name>J. Belissent</name>
        </author>
        <author>
            <name>M. Hoy</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18384</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>simple</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>mime</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>tunneling</kw>
        </keywords>
        <abstract>This document defines a MIME content type suitable for tunneling an ESMTP transaction through any MIME-capable transport. This memo provides information for the Internet community </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2443</doc-id>
        <title>A Distributed MARS Service Using SCSP</title>
        <author>
            <name>J. Luciani</name>
        </author>
        <author>
            <name>A. Gallo</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41451</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>MARS-SCSP</kw>
            <kw>server</kw>
            <kw>cache</kw>
            <kw>syncronization</kw>
            <kw>protocol</kw>
            <kw>atm</kw>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
        </keywords>
        <abstract>This document describes a method for distributing a MARS service within a LIS. This method uses the Server Cache Synchronization Protocol (SCSP) to synchronize the MARS Server databases within a LIS. When SCSP is used to synchronize the caches of MARS Servers in a LIS, the LIS defines the boundary of an SCSP Server Group (SG). [STANDARDS-TRACK] </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2444</doc-id>
        <title>The One-Time-Password SASL Mechanism</title>
        <author>
            <name>C. Newman</name>
        </author>
        <date>
            <month>October</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13408</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>OTP-SASL</kw>
            <kw>otp</kw>
            <kw>simple</kw>
            <kw>authentication</kw>
            <kw>security</kw>
            <kw>layer</kw>
        </keywords>
        <abstract>OTP provides a useful authentication mechanism for situations where there is limited client or server trust. Currently, OTP is added to protocols in an ad-hoc fashion with heuristic parsing. This specification defines an OTP SASL mechanism so it can be easily and formally integrated into many application protocols. [STANDARDS-TRACK] </abstract>
        <updates>
            <doc-id>RFC2222</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2445</doc-id>
        <title>Internet Calendaring and Scheduling Core Object Specification (iCalendar)</title>
        <author>
            <name>F. Dawson</name>
        </author>
        <author>
            <name>D. Stenerson</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>291838</char-count>
            <page-count>148</page-count>
        </format>
        <keywords>
            <kw>ICALENDAR</kw>
            <kw>internet</kw>
            <kw>interoperable</kw>
            <kw>mime</kw>
            <kw>multipurpose</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across the Internet. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2446</doc-id>
        <title>iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries</title>
        <author>
            <name>S. Silverberg</name>
        </author>
        <author>
            <name>S. Mansour</name>
        </author>
        <author>
            <name>F. Dawson</name>
        </author>
        <author>
            <name>R. Hopson</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>225964</char-count>
            <page-count>109</page-count>
        </format>
        <keywords>
            <kw>ITIP</kw>
            <kw>internet</kw>
            <kw>systems</kw>
            <kw>interoperability</kw>
        </keywords>
        <abstract>This document specifies how calendaring systems use iCalendar objects to interoperate with other calendar systems. It does so in a general way so as to allow multiple methods of communication between systems. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2447</doc-id>
        <title>iCalendar Message-Based Interoperability Protocol (iMIP)</title>
        <author>
            <name>F. Dawson</name>
        </author>
        <author>
            <name>S. Mansour</name>
        </author>
        <author>
            <name>S. Silverberg</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33480</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>IMIP</kw>
            <kw>internet</kw>
            <kw>electronic</kw>
            <kw>mail</kw>
            <kw>transport</kw>
        </keywords>
        <abstract>This document specifies a binding from the iCalendar Transport- independent Interoperability Protocol (iTIP) to Internet email-based transports. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2448</doc-id>
        <title>AT&amp;T's Error Resilient Video Transmission Technique</title>
        <author>
            <name>M. Civanlar</name>
        </author>
        <author>
            <name>G. Cash</name>
        </author>
        <author>
            <name>B. Haskell</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14655</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>packets</kw>
            <kw>network</kw>
            <kw>bitstreams</kw>
        </keywords>
        <abstract>This document describes a set of techniques for packet loss resilient transmission of compressed video bitstreams based on reliable delivery of their vital information-carrying segments. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2449</doc-id>
        <title>POP3 Extension Mechanism</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <author>
            <name>C. Newman</name>
        </author>
        <author>
            <name>L. Lundblade</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36017</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>POP3-EXT</kw>
            <kw>post</kw>
            <kw>office</kw>
            <kw>protocol</kw>
            <kw>server</kw>
        </keywords>
        <abstract>This memo updates RFC 1939 to define a mechanism to announce support for optional commands, extensions, and unconditional server behavior. [STANDARDS-TRACK] </abstract>
        <updates>
            <doc-id>RFC1939</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2450</doc-id>
        <title>Proposed TLA and NLA Assignment Rule</title>
        <author>
            <name>R. Hinden</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24486</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>top-level</kw>
            <kw>aggregation</kw>
            <kw>identifiers</kw>
            <kw>next-level</kw>
            <kw>ipv6</kw>
            <kw>internet</kw>
            <kw>protocols</kw>
            <kw>addresses</kw>
        </keywords>
        <abstract>This document proposes rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID). This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2451</doc-id>
        <title>The ESP CBC-Mode Cipher Algorithms</title>
        <author>
            <name>R. Pereira</name>
        </author>
        <author>
            <name>R. Adams</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26400</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>ipsec</kw>
            <kw>encapsulating</kw>
            <kw>security</kw>
            <kw>payload</kw>
        </keywords>
        <abstract>This document describes how to use CBC-mode cipher algorithms with the IPSec ESP (Encapsulating Security Payload) Protocol. It not only clearly states how to use certain cipher algorithms, but also how to use all CBC-mode cipher algorithms. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2452</doc-id>
        <title>IP Version 6 Management Information Base for the Transmission Control Protocol</title>
        <author>
            <name>M. Daniele</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19066</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>tcp</kw>
            <kw>ipv6</kw>
        </keywords>
        <abstract>This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the Transmission Control Protocol (TCP) over IP Version 6 (IPv6). [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC4022</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2453</doc-id>
        <title>RIP Version 2</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>98462</char-count>
            <page-count>39</page-count>
        </format>
        <keywords>
            <kw>RIP2</kw>
            <kw>RIP-2</kw>
        </keywords>
        <abstract>This document specifies an extension of the Routing Information Protocol (RIP) to expand the amount of useful information carried in RIP messages and to add a measure of security. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1723</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0056</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2454</doc-id>
        <title>IP Version 6 Management Information Base for the User Datagram Protocol</title>
        <author>
            <name>M. Daniele</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15862</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>udp</kw>
            <kw>ipv6</kw>
        </keywords>
        <abstract>This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the User Datagram Protocol (UDP) over IP Version 6 (IPv6). [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2455</doc-id>
        <title>Definitions of Managed Objects for APPN</title>
        <author>
            <name>B. Clouston</name>
        </author>
        <author>
            <name>B. Moore</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>251061</char-count>
            <page-count>140</page-count>
        </format>
        <keywords>
            <kw>APPN-MIB</kw>
            <kw>mib</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>advanced</kw>
            <kw>peer-to-peer</kw>
            <kw>networking</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol. [STANDARDS- TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2155</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2456</doc-id>
        <title>Definitions of Managed Objects for APPN TRAPS</title>
        <author>
            <name>B. Clouston</name>
        </author>
        <author>
            <name>B. Moore</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44023</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>advanced</kw>
            <kw>peer-to-peer</kw>
            <kw>networking</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for receiving notifications from network devices with APPN (Advanced Peer-to-Peer Network) and DLUR (Dependent LU Requester) capabilities. This memo identifies notifications for the APPN and DLUR architecture. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2457</doc-id>
        <title>Definitions of Managed Objects for Extended Border Node</title>
        <author>
            <name>B. Clouston</name>
        </author>
        <author>
            <name>B. Moore</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54380</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>EBN-MIB</kw>
            <kw>mib</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>ebn</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Network) EBN (Extended Border Node) capabilities. This memo identifies managed objects for the EBN architecture. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2458</doc-id>
        <title>Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations</title>
        <author>
            <name>H. Lu</name>
        </author>
        <author>
            <name>M. Krishnaswamy</name>
        </author>
        <author>
            <name>L. Conroy</name>
        </author>
        <author>
            <name>S. Bellovin</name>
        </author>
        <author>
            <name>F. Burg</name>
        </author>
        <author>
            <name>A. DeSimone</name>
        </author>
        <author>
            <name>K. Tewani</name>
        </author>
        <author>
            <name>P. Davidson</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>K. Vishwanathan</name>
        </author>
        <date>
            <month>November</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>139100</char-count>
            <page-count>60</page-count>
        </format>
        <abstract>This document contains the information relevant to the development of the inter-networking interfaces underway in the Public Switched Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working Group. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2459</doc-id>
        <title>Internet X.509 Public Key Infrastructure Certificate and CRL Profile</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>W. Ford</name>
        </author>
        <author>
            <name>W. Polk</name>
        </author>
        <author>
            <name>D. Solo</name>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>278438</char-count>
            <page-count>129</page-count>
        </format>
        <keywords>
            <kw>digital</kw>
            <kw>signatures</kw>
            <kw>encryption</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3280</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2460</doc-id>
        <title>Internet Protocol, Version 6 (IPv6) Specification</title>
        <author>
            <name>S. Deering</name>
        </author>
        <author>
            <name>R. Hinden</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>85490</char-count>
            <page-count>39</page-count>
        </format>
        <keywords>
            <kw>IPV6</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>next</kw>
            <kw>generation</kw>
            <kw>ipng</kw>
        </keywords>
        <abstract>This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1883</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2461</doc-id>
        <title>Neighbor Discovery for IP Version 6 (IPv6)</title>
        <author>
            <name>T. Narten</name>
        </author>
        <author>
            <name>E. Nordmark</name>
        </author>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>222516</char-count>
            <page-count>93</page-count>
        </format>
        <keywords>
            <kw>IPV6-ND</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>link-layer</kw>
        </keywords>
        <abstract>This document specifies the Neighbor Discovery protocol for IP Version 6. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1970</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2462</doc-id>
        <title>IPv6 Stateless Address Autoconfiguration</title>
        <author>
            <name>S. Thomson</name>
        </author>
        <author>
            <name>T. Narten</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>61210</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>IPV6-AUTO</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>host</kw>
            <kw>link-local</kw>
        </keywords>
        <abstract>This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1971</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2463</doc-id>
        <title>Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification</title>
        <author>
            <name>A. Conta</name>
        </author>
        <author>
            <name>S. Deering</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34190</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>ICMPv6</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>link-local</kw>
            <kw>autoconfigured</kw>
            <kw>addresses</kw>
        </keywords>
        <abstract>This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1885</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2464</doc-id>
        <title>Transmission of IPv6 Packets over Ethernet Networks</title>
        <author>
            <name>M. Crawford</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12725</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>link-local</kw>
            <kw>autoconfigured</kw>
            <kw>addresses</kw>
        </keywords>
        <abstract>This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1972</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2465</doc-id>
        <title>Management Information Base for IP Version 6: Textual Conventions and General Group</title>
        <author>
            <name>D. Haskin</name>
        </author>
        <author>
            <name>S. Onishi</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>77339</char-count>
            <page-count>38</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>ipv6</kw>
        </keywords>
        <abstract>This document is one in the series of documents that provide MIB definitions for for IP Version 6. Specifically, the IPv6 MIB textual conventions as well as the IPv6 MIB General group is defined in this document. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2466</doc-id>
        <title>Management Information Base for IP Version 6: ICMPv6 Group</title>
        <author>
            <name>D. Haskin</name>
        </author>
        <author>
            <name>S. Onishi</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27547</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>ICMPv6-MIB</kw>
            <kw>mib</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>ipv6</kw>
        </keywords>
        <abstract>This document is one in the series of documents that define various MIB object groups for IPv6. Specifically, the ICMPv6 group is defined in this document. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2467</doc-id>
        <title>Transmission of IPv6 Packets over FDDI Networks</title>
        <author>
            <name>M. Crawford</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16028</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>link-local</kw>
            <kw>addresses</kw>
            <kw>autoconfiguration</kw>
        </keywords>
        <abstract>This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on FDDI networks. [STANDARDS- TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2019</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2468</doc-id>
        <title>I REMEMBER IANA</title>
        <author>
            <name>V. Cerf</name>
        </author>
        <date>
            <month>October</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8543</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>jonathan b postel</kw>
        </keywords>
        <abstract>A long time ago, in a network, far far away, a great adventure took place!. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2469</doc-id>
        <title>A Caution On The Canonical Ordering Of Link-Layer Addresses</title>
        <author>
            <name>T. Narten</name>
        </author>
        <author>
            <name>C. Burton</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9948</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>address</kw>
            <kw>resolution</kw>
            <kw>protocol</kw>
            <kw>data</kw>
            <kw>fields</kw>
        </keywords>
        <abstract>Protocols such as ARP and Neighbor Discovery have data fields that contain link-layer addresses. In order to interoperate properly, a sender setting such a field must insure that the receiver extracts those bits and interprets them correctly. In most cases, such fields must be in "canonical form". Unfortunately, not all LAN adaptors are consistent in their use of canonical form, and implementations may need to explicitly bit swap individual bytes in order to obtain the correct format. This document provides information to implementors to help them avoid the pitfall of using non-canonical forms when canonical forms are required. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2470</doc-id>
        <title>Transmission of IPv6 Packets over Token Ring Networks</title>
        <author>
            <name>M. Crawford</name>
        </author>
        <author>
            <name>T. Narten</name>
        </author>
        <author>
            <name>S. Thomas</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21677</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>frame</kw>
            <kw>format</kw>
            <kw>link-local</kw>
            <kw>addresses</kw>
        </keywords>
        <abstract>This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2471</doc-id>
        <title>IPv6 Testing Address Allocation</title>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>R. Fink</name>
        </author>
        <author>
            <name>J. Postel (deceased)</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8031</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>protocotype</kw>
            <kw>software</kw>
            <kw>architecture</kw>
        </keywords>
        <abstract>This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoletes>
            <doc-id>RFC1897</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3701</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2472</doc-id>
        <title>IP Version 6 over PPP</title>
        <author>
            <name>D. Haskin</name>
        </author>
        <author>
            <name>E. Allen</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29696</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>IPv6-PPP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>point-to-point</kw>
            <kw>ipv6</kw>
        </keywords>
        <abstract>This document defines the method for transmission of IP Version 6 packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. [STANDARDS- TRACK] </abstract>
        <draft>ietf-snmpv3-mpc-05</draft>
        <obsoletes>
            <doc-id>RFC2023</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2473</doc-id>
        <title>Generic Packet Tunneling in IPv6 Specification</title>
        <author>
            <name>A. Conta</name>
        </author>
        <author>
            <name>S. Deering</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>77956</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>encapsulation</kw>
        </keywords>
        <abstract>This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. [STANDARDS- TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2474</doc-id>
        <title>Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers</title>
        <author>
            <name>K. Nichols</name>
        </author>
        <author>
            <name>S. Blake</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>D. Black</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>50576</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>network</kw>
            <kw>nodes</kw>
        </keywords>
        <abstract>This document defines the IP header field, called the DS (for differentiated services) field. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1455</doc-id>
            <doc-id>RFC1349</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3168</doc-id>
            <doc-id>RFC3260</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2475</doc-id>
        <title>An Architecture for Differentiated Service</title>
        <author>
            <name>S. Blake</name>
        </author>
        <author>
            <name>D. Black</name>
        </author>
        <author>
            <name>M. Carlson</name>
        </author>
        <author>
            <name>E. Davies</name>
        </author>
        <author>
            <name>Z. Wang</name>
        </author>
        <author>
            <name>W. Weiss</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>94786</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>DIFFSRV]</kw>
            <kw>scalability</kw>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community. </abstract>
        <updated-by>
            <doc-id>RFC3260</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2476</doc-id>
        <title>Message Submission</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30050</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>smtp</kw>
            <kw>simple</kw>
            <kw>mail</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>user</kw>
            <kw>agent</kw>
        </keywords>
        <abstract>This memo describes a low cost, deterministic means for messages to be identified as submissions, and specifies what actions are to be taken by a submission server. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2477</doc-id>
        <title>Criteria for Evaluating Roaming Protocols</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23530</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>ISP</kw>
            <kw>internet</kw>
            <kw>service</kw>
            <kw>providers</kw>
            <kw>operations</kw>
        </keywords>
        <abstract>This document describes requirements for the provisioning of "roaming capability" for dialup Internet users. "Roaming capability" is defined as the ability to use multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2478</doc-id>
        <title>The Simple and Protected GSS-API Negotiation Mechanism</title>
        <author>
            <name>E. Baize</name>
        </author>
        <author>
            <name>D. Pinkas</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35581</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>generic</kw>
            <kw>service</kw>
            <kw>application</kw>
            <kw>security</kw>
            <kw>program</kw>
            <kw>interface</kw>
        </keywords>
        <abstract>This document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API). [STANDARDS- TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2479</doc-id>
        <title>Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API)</title>
        <author>
            <name>C. Adams</name>
        </author>
        <date>
            <month>December</month>
            <year>1998</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>156070</char-count>
            <page-count>70</page-count>
        </format>
        <keywords>
            <kw>data</kw>
            <kw>unit</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>The IDUP-GSS-API extends the GSS-API for applications requiring protection of a generic data unit (such as a file or message) in a way which is independent of the protection of any other data unit and independent of any concurrent contact with designated "receivers" of the data unit. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2480</doc-id>
        <title>Gateways and MIME Security Multiparts</title>
        <author>
            <name>N. Freed</name>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11751</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>mutltipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document examines the problems associated with use of MIME security multiparts and gateways to non-MIME environments. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2481</doc-id>
        <title>A Proposal to add Explicit Congestion Notification (ECN) to IP</title>
        <author>
            <name>K. Ramakrishnan</name>
        </author>
        <author>
            <name>S. Floyd</name>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>64559</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>ECN-IP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>tcp</kw>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>transport</kw>
        </keywords>
        <abstract>This note describes a proposed addition of ECN (Explicit Congestion Notification) to IP. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC3168</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2482</doc-id>
        <title>Language Tagging in Unicode Plain Text</title>
        <author>
            <name>K. Whistler</name>
        </author>
        <author>
            <name>G. Adams</name>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27800</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>characters</kw>
            <kw>strings</kw>
            <kw>ASCII</kw>
        </keywords>
        <abstract>This document proposed a mechanism for language tagging in plain text. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2483</doc-id>
        <title>URI Resolution Services Necessary for URN Resolution</title>
        <author>
            <name>M. Mealling</name>
        </author>
        <author>
            <name>R. Daniel</name>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30518</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>identifier</kw>
            <kw>names</kw>
            <kw>locators</kw>
            <kw>characteristics</kw>
        </keywords>
        <abstract>Retrieving the resource identified by a Uniform Resource Identifier (URI) is only one of the operations that can be performed on a URI. One might also ask for and get a list of other identifiers that are aliases for the original URI or a bibliographic description of the resource the URI denotes, for example. This applies to both Uniform Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform Resource Characteristics (URCs) are discussed in this document but only as descriptions of resources rather than identifiers. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2484</doc-id>
        <title>PPP LCP Internationalization Configuration Option</title>
        <author>
            <name>G. Zorn</name>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8330</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>point-to-point</kw>
            <kw>protocol</kw>
            <kw>link</kw>
            <kw>control</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. [STANDARDS-TRACK] </abstract>
        <updates>
            <doc-id>RFC2284</doc-id>
            <doc-id>RFC1994</doc-id>
            <doc-id>RFC1570</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2485</doc-id>
        <title>DHCP Option for The Open Group's User Authentication Protocol</title>
        <author>
            <name>S. Drach</name>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7205</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>dynamic</kw>
            <kw>host</kw>
            <kw>configuration</kw>
            <kw>UAP</kw>
        </keywords>
        <abstract>This document defines a DHCP option that contains a list of pointers to User Authentication Protocol servers that provide user authentication services for clients that conform to The Open Group Network Computing Client Technical Standard. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2486</doc-id>
        <title>The Network Access Identifier</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>M. Beadles</name>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14261</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>NAI</kw>
            <kw>NAI</kw>
            <kw>tunneling</kw>
            <kw>roaming</kw>
        </keywords>
        <abstract>This document proposes syntax for the Network Access Identifier (NAI), the userID submitted by the client during PPP authentication. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2487</doc-id>
        <title>SMTP Service Extension for Secure SMTP over TLS</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15120</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>simple</kw>
            <kw>mail</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>transport</kw>
            <kw>layer</kw>
            <kw>security</kw>
            <kw>ssl</kw>
        </keywords>
        <abstract>This document describes an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3207</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2488</doc-id>
        <title>Enhancing TCP Over Satellite Channels using Standard Mechanisms</title>
        <author>
            <name>M. Allman</name>
        </author>
        <author>
            <name>D. Glover</name>
        </author>
        <author>
            <name>L. Sanchez</name>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47857</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
            <kw>network</kw>
        </keywords>
        <abstract>The Transmission Control Protocol (TCP) provides reliable delivery of data across any network path, including network paths containing satellite channels. While TCP works over satellite channels there are several IETF standardized mechanisms that enable TCP to more effectively utilize the available capacity of the network path. This document outlines some of these TCP mitigations. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <is-also>
            <doc-id>BCP0028</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2489</doc-id>
        <title>Procedure for Defining New DHCP Options</title>
        <author>
            <name>R. Droms</name>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10484</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>mutipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document describes the procedure for defining new DHCP options. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <obsoleted-by>
            <doc-id>RFC2939</doc-id>
        </obsoleted-by>
        <is-also>
            <doc-id>BCP0029</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2490</doc-id>
        <title>A Simulation Model for IP Multicast with RSVP</title>
        <author>
            <name>M. Pullen</name>
        </author>
        <author>
            <name>R. Malghan</name>
        </author>
        <author>
            <name>L. Lavu</name>
        </author>
        <author>
            <name>G. Duan</name>
        </author>
        <author>
            <name>J. Ma</name>
        </author>
        <author>
            <name>H. Nah</name>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>74936</char-count>
            <page-count>31</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>1956365</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>135368</char-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>ipv4</kw>
        </keywords>
        <abstract>This document describes a detailed model of IPv4 multicast with RSVP that has been developed using the OPNET simulation package, with protocol procedures defined in the C language. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2491</doc-id>
        <title>IPv6 over Non-Broadcast Multiple Access (NBMA) networks</title>
        <author>
            <name>G. Armitage</name>
        </author>
        <author>
            <name>P. Schulter</name>
        </author>
        <author>
            <name>M. Jork</name>
        </author>
        <author>
            <name>G. Harter</name>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>100782</char-count>
            <page-count>44</page-count>
        </format>
        <keywords>
            <kw>IPv6-NBMA</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>routing</kw>
            <kw>host</kw>
        </keywords>
        <abstract>This document describes a general architecture for IPv6 over NBMA networks. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2492</doc-id>
        <title>IPv6 over ATM Networks</title>
        <author>
            <name>G. Armitage</name>
        </author>
        <author>
            <name>P. Schulter</name>
        </author>
        <author>
            <name>M. Jork</name>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21199</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>IPv6ATMNET</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>host</kw>
        </keywords>
        <abstract>This document is a companion to the ION working group's architecture document, "IPv6 over Non Broadcast Multiple Access (NBMA) networks". It provides specific details on how to apply the IPv6 over NBMA architecture to ATM networks. This architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' ATM forwarding paths (when using SVCs). Operation over administratively configured Point to Point PVCs is also supported. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2493</doc-id>
        <title>Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals</title>
        <author>
            <name>K. Tesink</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18749</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>data</kw>
        </keywords>
        <abstract>This document defines a set of Textual Conventions for MIB modules which make use of performance history data based on 15 minute intervals. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3593</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2494</doc-id>
        <title>Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type</title>
        <author>
            <name>D. Fowler</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47208</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS0 and DS0 Bundle interfaces. This document is a companion document with Definitions of Managed Objects for the DS1/E1/DS2/E2 (RFC 2495), DS3/E3 (RFC 2496), and the work in progress, SONET/SDH Interface Types. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2495</doc-id>
        <title>Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types</title>
        <author>
            <name>D. Fowler</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>155560</char-count>
            <page-count>75</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion document with Definitions of Managed Objects for the DS0 (RFC 2494), DS3/E3 (RFC 2496), and the work in progress, SONET/SDH Interface Types. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1406</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3895</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2496</doc-id>
        <title>Definitions of Managed Object for the DS3/E3 Interface Type</title>
        <author>
            <name>D. Fowler</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>124251</char-count>
            <page-count>60</page-count>
        </format>
        <keywords>
            <kw>DS3-E3-MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS3 and E3 interfaces. This document is a companion document with Definitions of Managed Objects for the DS0 (RFC 2494), DS1/E1/DS2/E2 (RFC 2495), and the work in progress SONET/SDH Interface Types. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC1407</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3896</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2497</doc-id>
        <title>Transmission of IPv6 Packets over ARCnet Networks</title>
        <author>
            <name>I. Souvatzis</name>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10304</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>frame</kw>
            <kw>format</kw>
            <kw>link-local</kw>
        </keywords>
        <abstract>This memo specifies a frame format for transmission of IPv6 packets and the method of forming IPv6 link-local and statelessly autoconfigured addresses on ARCnet networks. It also specifies the content of the Source/Target Link-layer Address option used by the Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages described in, when those messages are transmitted on an ARCnet. [STANDARDS-TRACK] </abstract>
        <draft>souvatzis-ipv6-arcnet-05</draft>
        <see-also>
            <doc-id>RFC1201</doc-id>
        </see-also>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2498</doc-id>
        <title>IPPM Metrics for Measuring Connectivity</title>
        <author>
            <name>J. Mahdavi</name>
        </author>
        <author>
            <name>V. Paxson</name>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17869</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>IPPM-MET</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>performance</kw>
            <kw>metrics</kw>
        </keywords>
        <abstract>This memo defines a series of metrics for connectivity between a pair of Internet hosts. It builds on notions introduced and discussed in RFC 2330, the IPPM framework document. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <obsoleted-by>
            <doc-id>RFC2678</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2499</doc-id>
        <title>Request for Comments Summary</title>
        <author>
            <name>A. Ramos</name>
        </author>
        <date>
            <month>July</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43431</char-count>
            <page-count>22</page-count>
        </format>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2500</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Reynolds</name>
        </author>
        <author>
            <name>R. Braden</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>78845</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>IAB</kw>
            <kw>official</kw>
            <kw>protocol</kw>
            <kw>standards</kw>
        </keywords>
        <abstract>This memo summarizes the status of Internet protocols and specifications. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2400</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2600</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2501</doc-id>
        <title>Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations</title>
        <author>
            <name>S. Corson</name>
        </author>
        <author>
            <name>J. Macker</name>
        </author>
        <date>
            <month>January</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28912</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>MANET</kw>
            <kw>packet</kw>
            <kw>network</kw>
            <kw>hardwire</kw>
            <kw>wireless</kw>
        </keywords>
        <abstract>This memo first describes the characteristics of Mobile Ad hoc Networks (MANETs), and their idiosyncrasies with respect to traditional, hardwired packet networks. It then discusses the effect these differences have on the design and evaluation of network control protocols with an emphasis on routing performance evaluation considerations. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2502</doc-id>
        <title>Limitations of Internet Protocol Suite for Distributed Simulation the Large Multicast Environment</title>
        <author>
            <name>M. Pullen</name>
        </author>
        <author>
            <name>M. Myjak</name>
        </author>
        <author>
            <name>C. Bouwens</name>
        </author>
        <date>
            <month>February</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28190</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>IP</kw>
            <kw>DIS</kw>
            <kw>distributed</kw>
            <kw>applications</kw>
        </keywords>
        <abstract>This memo defines services that LSMA has found to be required, and aspects of the Internet protocols that LSMA has found to need further development in order to meet these requirements. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2503</doc-id>
        <title>MIME Types for Use with the ISO ILL Protocol</title>
        <author>
            <name>R. Moulton</name>
        </author>
        <author>
            <name>M. Needleman</name>
        </author>
        <date>
            <month>February</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9078</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>multipurpose</kw>
            <kw>mail</kw>
            <kw>internet</kw>
            <kw>extensions</kw>
            <kw>media</kw>
            <kw>type</kw>
            <kw>interlibrary</kw>
            <kw>loan</kw>
        </keywords>
        <abstract>This memorandum describes a set of MIME types for use with the ISO Interlibrary Loan Protocol (ISO 10160/10161). This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2504</doc-id>
        <title>Users' Security Handbook</title>
        <author>
            <name>E. Guttman</name>
        </author>
        <author>
            <name>L. Leong</name>
        </author>
        <author>
            <name>G. Malkin</name>
        </author>
        <date>
            <month>February</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>74036</char-count>
            <page-count>33</page-count>
        </format>
        <keywords>
            <kw>encryption</kw>
            <kw>networks</kw>
            <kw>systems</kw>
        </keywords>
        <abstract>The Users' Security Handbook is the companion to the Site Security Handbook (SSH). It is intended to provide users with the information they need to help keep their networks and systems secure. This memo provides information for the Internet community. </abstract>
        <is-also>
            <doc-id>FYI0034</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2505</doc-id>
        <title>Anti-Spam Recommendations for SMTP MTAs</title>
        <author>
            <name>G. Lindberg</name>
        </author>
        <date>
            <month>February</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53597</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>simple</kw>
            <kw>mail</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>agents</kw>
            <kw>sendmail</kw>
        </keywords>
        <abstract>This memo gives a number of implementation recommendations for SMTP, MTAs (Mail Transfer Agents, e.g. sendmail,) to make them more capable of reducing the impact of spam. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>lindberg-anti-spam-mta-08</draft>
        <is-also>
            <doc-id>BCP0030</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2506</doc-id>
        <title>Media Feature Tag Registration Procedure</title>
        <author>
            <name>K. Holtman</name>
        </author>
        <author>
            <name>A. Mutz</name>
        </author>
        <author>
            <name>T. Hardie</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24892</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>data</kw>
            <kw>formats</kw>
            <kw>vocabulary</kw>
            <kw>negotiation</kw>
            <kw>mechanism</kw>
        </keywords>
        <abstract>This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-conneg-feature-reg-03</draft>
        <is-also>
            <doc-id>BCP0031</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2507</doc-id>
        <title>IP Header Compression</title>
        <author>
            <name>M. Degermark</name>
        </author>
        <author>
            <name>B. Nordgren</name>
        </author>
        <author>
            <name>S. Pink</name>
        </author>
        <date>
            <month>February</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>106292</char-count>
            <page-count>47</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>tcp</kw>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>bandwidth</kw>
        </keywords>
        <abstract>This document describes how to compress multiple IP headers and TCP and UDP headers per hop over point to point links. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2508</doc-id>
        <title>Compressing IP/UDP/RTP Headers for Low-Speed Serial Links</title>
        <author>
            <name>S. Casner</name>
        </author>
        <author>
            <name>V. Jacobson</name>
        </author>
        <date>
            <month>February</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>60474</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>user</kw>
            <kw>datagram</kw>
            <kw>real-timetransport</kw>
            <kw>interoperability</kw>
        </keywords>
        <abstract>This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2509</doc-id>
        <title>IP Header Compression over PPP</title>
        <author>
            <name>M. Engan</name>
        </author>
        <author>
            <name>S. Casner</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>February</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18676</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>IPCOM-PPP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>point-to-point</kw>
            <kw>datagrams</kw>
        </keywords>
        <abstract>This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol. It defines extensions to the PPP Control Protocols for IPv4 and IPv6. [STANDARDS-TRACK] </abstract>
        <obsoleted-by>
            <doc-id>RFC3544</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2510</doc-id>
        <title>Internet X.509 Public Key Infrastructure Certificate Management Protocols</title>
        <author>
            <name>C. Adams</name>
        </author>
        <author>
            <name>S. Farrell</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>158178</char-count>
            <page-count>72</page-count>
        </format>
        <keywords>
            <kw>PKICMP</kw>
            <kw>pki</kw>
            <kw>security</kw>
            <kw>cryptographic</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocols. [STANDARDS-TRACK] </abstract>
        <draft>ietf-pkix-ipki3cmp-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2511</doc-id>
        <title>Internet X.509 Certificate Request Message Format</title>
        <author>
            <name>M. Myers</name>
        </author>
        <author>
            <name>C. Adams</name>
        </author>
        <author>
            <name>D. Solo</name>
        </author>
        <author>
            <name>D. Kemp</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48278</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>X.509-CRMF</kw>
            <kw>crmf</kw>
            <kw>security</kw>
            <kw>encryption</kw>
            <kw>authenticaion</kw>
        </keywords>
        <abstract>This document describes the Certificate Request Message Format (CRMF). [STANDARDS-TRACK] </abstract>
        <draft>ietf-pkix-crmf-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2512</doc-id>
        <title>Accounting Information for ATM Networks</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>J. Heinanen</name>
        </author>
        <author>
            <name>W. Greene</name>
        </author>
        <author>
            <name>A. Prasad</name>
        </author>
        <date>
            <month>February</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29119</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>autonomous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo defines a set of ATM-specific accounting information which can be collected for connections on ATM networks. [STANDARDS-TRACK] </abstract>
        <draft>ietf-atommib-atmaact-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2513</doc-id>
        <title>Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>J. Heinanen</name>
        </author>
        <author>
            <name>W. Greene</name>
        </author>
        <author>
            <name>A. Prasad</name>
        </author>
        <date>
            <month>February</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>60789</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for controlling the collection and storage of accounting information for connection-oriented networks such as ATM. [STANDARDS-TRACK] </abstract>
        <draft>ietf-atommib-acct-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2514</doc-id>
        <title>Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management</title>
        <author>
            <name>M. Noto</name>
        </author>
        <author>
            <name>E. Spiegel</name>
        </author>
        <author>
            <name>K. Tesink</name>
        </author>
        <date>
            <month>February</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37583</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>ATM-TC-OID</kw>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo describes Textual Conventions and OBJECT-IDENTITIES used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK] </abstract>
        <draft>ietf-atommib-atm2TC-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2515</doc-id>
        <title>Definitions of Managed Objects for ATM Management</title>
        <author>
            <name>K. Tesink</name>
        </author>
        <author>
            <name>Ed</name>
        </author>
        <date>
            <month>February</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>179993</char-count>
            <page-count>87</page-count>
        </format>
        <keywords>
            <kw>ATM-MIBMAN</kw>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK] </abstract>
        <draft>ietf-atommib-atm1ng-06</draft>
        <obsoletes>
            <doc-id>RFC1695</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2516</doc-id>
        <title>A Method for Transmitting PPP Over Ethernet (PPPoE)</title>
        <author>
            <name>L. Mamakos</name>
        </author>
        <author>
            <name>K. Lidl</name>
        </author>
        <author>
            <name>J. Evarts</name>
        </author>
        <author>
            <name>D. Carrel</name>
        </author>
        <author>
            <name>D. Simone</name>
        </author>
        <author>
            <name>R. Wheeler</name>
        </author>
        <date>
            <month>February</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32537</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>PPPOE</kw>
            <kw>point-to-point</kw>
            <kw>protocol</kw>
            <kw>link</kw>
            <kw>control</kw>
            <kw>network</kw>
            <kw>layer</kw>
        </keywords>
        <abstract>This document describes how to build PPP sessions and encapsulate PPP packets over Ethernet. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2517</doc-id>
        <title>Building Directories from DNS: Experiences from WWWSeeker</title>
        <author>
            <name>R. Moats</name>
        </author>
        <author>
            <name>R. Huber</name>
        </author>
        <date>
            <month>February</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14001</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>internet</kw>
            <kw>world</kw>
            <kw>wide</kw>
            <kw>web</kw>
        </keywords>
        <abstract>This memo discusses lessons that were learned during InterNIC Directory and Database Services' development and operation of WWWSeeker, an application that finds a web site given information about the name and location of an organization. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2518</doc-id>
        <title>HTTP Extensions for Distributed Authoring -- WEBDAV</title>
        <author>
            <name>Y. Goland</name>
        </author>
        <author>
            <name>E. Whitehead</name>
        </author>
        <author>
            <name>A. Faizi</name>
        </author>
        <author>
            <name>S. Carter</name>
        </author>
        <author>
            <name>D. Jensen</name>
        </author>
        <date>
            <month>February</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>202829</char-count>
            <page-count>94</page-count>
        </format>
        <keywords>
            <kw>WEBDAV</kw>
            <kw>hypertext</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>web</kw>
            <kw>content</kw>
        </keywords>
        <abstract>This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2519</doc-id>
        <title>A Framework for Inter-Domain Route Aggregation</title>
        <author>
            <name>E. Chen</name>
        </author>
        <author>
            <name>J. Stewart</name>
        </author>
        <date>
            <month>February</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25394</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>IDRA</kw>
            <kw>bgp</kw>
            <kw>border</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
            <kw>address</kw>
            <kw>ip</kw>
            <kw>internet</kw>
        </keywords>
        <abstract>This document presents a framework for inter-domain route aggregation and shows an example router configuration which 'implements' this framework. This memo provides information for the Internet community </abstract>
        <draft>ietf-idr-aggregation-framework-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2520</doc-id>
        <title>NHRP with Mobile NHCs</title>
        <author>
            <name>J. Luciani</name>
        </author>
        <author>
            <name>H. Suzuki</name>
        </author>
        <author>
            <name>N. Doraswamy</name>
        </author>
        <author>
            <name>D. Horton</name>
        </author>
        <date>
            <month>February</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16763</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>NHRP-MNHCS</kw>
            <kw>next</kw>
            <kw>hop</kw>
            <kw>resolution</kw>
            <kw>protocol</kw>
            <kw>authentication</kw>
            <kw>extension</kw>
        </keywords>
        <abstract>is document describes an extension to NHRP which would allow Mobile NHCs to perform a registration with and attach to an NHS in their home LIS in an authenticated manner. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-ion-nhrp-mobile-nhc-01</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2521</doc-id>
        <title>ICMP Security Failures Messages</title>
        <author>
            <name>P. Karn</name>
        </author>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14637</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>ICMP-SEC</kw>
            <kw>internet</kw>
            <kw>control</kw>
            <kw>message</kw>
            <kw>protocol</kw>
            <kw>ip</kw>
        </keywords>
        <abstract>This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH and ESP). This document defines an Experimental Protocol for the Internet community. </abstract>
        <draft>simpson-icmp-ipsec-fail-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2522</doc-id>
        <title>Photuris: Session-Key Management Protocol</title>
        <author>
            <name>P. Karn</name>
        </author>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>157224</char-count>
            <page-count>80</page-count>
        </format>
        <keywords>
            <kw>PHOTURIS-S</kw>
            <kw>ip</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>ah</kw>
            <kw>esp</kw>
        </keywords>
        <abstract>This document defines the basic protocol mechanisms. This document defines an Experimental Protocol for the Internet community. </abstract>
        <draft>simpson-photouris-18</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2523</doc-id>
        <title> Photuris: Extended Schemes and Attributes</title>
        <author>
            <name>P. Karn</name>
        </author>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38166</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>PHOTURIS-E</kw>
            <kw>ip</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>security</kw>
        </keywords>
        <abstract>Photuris is a session-key management protocol. Extensible Exchange- Schemes are provided to enable future implementation changes without affecting the basic protocol. This document defines an Experimental Protocol for the Internet community. </abstract>
        <draft>simpson-photouris-schemes-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2524</doc-id>
        <title>Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3</title>
        <author>
            <name>M. Banan</name>
        </author>
        <date>
            <month>February</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>153171</char-count>
            <page-count>83</page-count>
        </format>
        <keywords>
            <kw>EMSD</kw>
            <kw>wireless</kw>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This specification narrowly focuses on submission and delivery of short mail messages with a clear emphasis on efficiency. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2525</doc-id>
        <title>Known TCP Implementation Problems</title>
        <author>
            <name>V. Paxson</name>
        </author>
        <author>
            <name>M. Allman</name>
        </author>
        <author>
            <name>S. Dawson</name>
        </author>
        <author>
            <name>W. Fenner</name>
        </author>
        <author>
            <name>J. Griner</name>
        </author>
        <author>
            <name>I. Heavens</name>
        </author>
        <author>
            <name>K. Lahey</name>
        </author>
        <author>
            <name>J. Semke</name>
        </author>
        <author>
            <name>B. Volz</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>137201</char-count>
            <page-count>61</page-count>
        </format>
        <keywords>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo catalogs a number of known TCP implementation problems. This memo provides information for the Internet community. </abstract>
        <draft>ietf-tcpimpl-prob-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2526</doc-id>
        <title>Reserved IPv6 Subnet Anycast Addresses</title>
        <author>
            <name>D. Johnson</name>
        </author>
        <author>
            <name>S. Deering</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14555</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>routing</kw>
            <kw>architecture</kw>
        </keywords>
        <abstract>This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses. [STANDARDS-TRACK] </abstract>
        <draft>ietf-ipngwg-resv-anycast-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2527</doc-id>
        <title>Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework</title>
        <author>
            <name>S. Chokhani</name>
        </author>
        <author>
            <name>W. Ford</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>91860</char-count>
            <page-count>45</page-count>
        </format>
        <keywords>
            <kw>pkix</kw>
            <kw>encryption</kw>
            <kw>security</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This document presents a framework to assist the writers of certificate policies or certification practice statements for certification authorities and public key infrastructures. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy definition or a certification practice statement. This memo provides information for the Internet community. </abstract>
        <draft>ietf-pkix-ipki-part4-03</draft>
        <obsoleted-by>
            <doc-id>RFC3647</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2528</doc-id>
        <title>Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>W. Polk</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18273</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>authentication</kw>
            <kw>cryptology</kw>
        </keywords>
        <abstract>This specification contains guidance on the use of the Internet Public Key Infrastructure certificates to convey Key Exchange Algorithm (KEA) keys. This memo provides information for the Internet community. </abstract>
        <draft>ietf-pkix-ipki-kea-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2529</doc-id>
        <title>Transmission of IPv6 over IPv4 Domains without Explicit Tunnels</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>C. Jung</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21049</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>link-local</kw>
            <kw>link</kw>
            <kw>local</kw>
            <kw>addresses</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>ip</kw>
        </keywords>
        <abstract>This memo specifies the frame format for transmission of IPv6 (IPV6) packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link-layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement and Redirect messages, when those messages are transmitted on an IPv4 multicast network. [STANDARDS-TRACK] </abstract>
        <draft>ietf-ipngwg-6over4-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2530</doc-id>
        <title>Indicating Supported Media Features Using Extensions to DSN and MDN</title>
        <author>
            <name>D. Wing</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7824</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>message</kw>
            <kw>disposition</kw>
            <kw>notification</kw>
            <kw>delivery</kw>
            <kw>status</kw>
        </keywords>
        <abstract>This memo describes a format for generating Message Disposition Notifications and Delivery Status Notifications which contain such information. [STANDARDS-TRACK] </abstract>
        <draft>ietf-fax-reporting-extensions-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2531</doc-id>
        <title>Content Feature Schema for Internet Fax</title>
        <author>
            <name>G. Klyne</name>
        </author>
        <author>
            <name>L. McIntyre</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>88295</char-count>
            <page-count>51</page-count>
        </format>
        <keywords>
            <kw>media</kw>
            <kw>features</kw>
            <kw>mechanism</kw>
        </keywords>
        <abstract>This document defines a content feature schema that is a profile of the media feature registration mechanisms for use in performing capability identification between extended Internet fax systems. [STANDARDS-TRACK] </abstract>
        <draft>ietf-fax-feature-schema-05</draft>
        <obsoleted-by>
            <doc-id>RFC2879</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2532</doc-id>
        <title> Extended Facsimile Using Internet Mail</title>
        <author>
            <name>L. Masinter</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22717</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>mail</kw>
            <kw>user</kw>
            <kw>fax</kw>
        </keywords>
        <abstract>This document describes extensions to "Simple Mode of Facsimile Using Internet Mail", and describes additional features, including transmission of enhanced document characteristics (higher resolution, color) and confirmation of delivery and processing. [STANDARDS-TRACK] </abstract>
        <draft>ietf-fax-eifax-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2533</doc-id>
        <title>A Syntax for Describing Media Feature Sets</title>
        <author>
            <name>G. Klyne</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>79057</char-count>
            <page-count>37</page-count>
        </format>
        <keywords>
            <kw>message</kw>
            <kw>senders</kw>
            <kw>recipients</kw>
            <kw>file</kw>
            <kw>format</kw>
        </keywords>
        <abstract>This document introduces and describes a syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. [STANDARDS-TRACK] </abstract>
        <draft>ietf-conneg-feature-syntax-04</draft>
        <updated-by>
            <doc-id>RFC2738</doc-id>
            <doc-id>RFC2938</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2534</doc-id>
        <title>Media Features for Display, Print, and Fax</title>
        <author>
            <name>L. Masinter</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <author>
            <name>A. Mutz</name>
        </author>
        <author>
            <name>K. Holtman</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15466</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>data</kw>
            <kw>format</kw>
            <kw>vocabulary</kw>
            <kw>negotiation</kw>
            <kw>mechanisms</kw>
        </keywords>
        <abstract>This specification defines some common media features for describing image resolution, size, color, and image representation methods that are common to web browsing, printing, and facsimile applications. [STANDARDS-TRACK] </abstract>
        <draft>ietf-conneg-media-features-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2535</doc-id>
        <title>Domain Name System Security Extensions</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>110958</char-count>
            <page-count>47</page-count>
        </format>
        <keywords>
            <kw>DNS-SECEXT</kw>
            <kw>dns</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This document incorporates feedback on RFC 2065 from early implementers and potential users. [STANDARDS-TRACK] </abstract>
        <draft>ietf-dnssec-secext2-07</draft>
        <obsoletes>
            <doc-id>RFC2065</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4035</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2181</doc-id>
            <doc-id>RFC1035</doc-id>
            <doc-id>RFC1034</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC2931</doc-id>
            <doc-id>RFC3007</doc-id>
            <doc-id>RFC3008</doc-id>
            <doc-id>RFC3090</doc-id>
            <doc-id>RFC3226</doc-id>
            <doc-id>RFC3445</doc-id>
            <doc-id>RFC3597</doc-id>
            <doc-id>RFC3655</doc-id>
            <doc-id>RFC3658</doc-id>
            <doc-id>RFC3755</doc-id>
            <doc-id>RFC3757</doc-id>
            <doc-id>RFC3845</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2536</doc-id>
        <title>DSA KEYs and SIGs in the Domain Name System (DNS)</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11121</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>digital</kw>
            <kw>signature</kw>
            <kw>algorithm</kw>
            <kw>signatures</kw>
            <kw>cryptology</kw>
        </keywords>
        <abstract>A standard method for storing US Government Digital Signature Algorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. [STANDARDS-TRACK] </abstract>
        <draft>ietf-dnssec-dss-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2537</doc-id>
        <title>RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10810</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>message</kw>
            <kw>digest</kw>
            <kw>signatures</kw>
            <kw>cryptology</kw>
            <kw>security</kw>
        </keywords>
        <abstract>A standard method for storing RSA keys and and RSA/MD5 based signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. [STANDARDS-TRACK] </abstract>
        <draft>ietf-dnsssec-rsa-01</draft>
        <obsoleted-by>
            <doc-id>RFC3110</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2538</doc-id>
        <title>Storing Certificates in the Domain Name System (DNS)</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>O. Gudmundsson</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19857</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>SC-DNS</kw>
            <kw>cryptology</kw>
            <kw>authenticity</kw>
        </keywords>
        <abstract>Cryptographic public key are frequently published and their authenticity demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). [STANDARDS-TRACK] </abstract>
        <draft>ietf-dnssec-certs-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2539</doc-id>
        <title>Storage of Diffie-Hellman Keys in the Domain Name System (DNS)</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21049</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>DHK-DNS</kw>
            <kw>cryptology</kw>
            <kw>authentication</kw>
            <kw>security</kw>
            <kw>signatures</kw>
            <kw>digital</kw>
        </keywords>
        <abstract>A standard method for storing Diffie-Hellman keys in the Domain Name System is described which utilizes DNS KEY resource records. [STANDARDS-TRACK] </abstract>
        <draft>ietf-dnssec-dhk-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2540</doc-id>
        <title>Detached Domain Name System (DNS) Information</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12546</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>DNS-INFO</kw>
            <kw>security</kw>
            <kw>digital</kw>
            <kw>signatures</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>A standard format is defined for representing detached DNS information. This is anticipated to be of use for storing information retrieved from the Domain Name System (DNS), including security information, in archival contexts or contexts not connected to the Internet. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-dnssec-ddi-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2541</doc-id>
        <title>DNS Security Operational Considerations</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14498</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>DNS-SOC</kw>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>cryptology</kw>
            <kw>resource</kw>
            <kw>records</kw>
            <kw>rrs</kw>
        </keywords>
        <abstract>This document discusses these operational aspects for keys and signatures used in connection with the KEY and SIG DNS resource records. This memo provides information for the Internet community. </abstract>
        <draft>ietf-dnssec-secops-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2542</doc-id>
        <title>Terminology and Goals for Internet Fax</title>
        <author>
            <name>L. Masinter</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46372</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>real-time</kw>
            <kw>real</kw>
            <kw>time</kw>
            <kw>session</kw>
            <kw>store</kw>
            <kw>forward</kw>
        </keywords>
        <abstract>This document defines a number of terms useful for the discussion of Internet Fax. In addition, it describes the goals of the Internet Fax working group and establishes a baseline of desired functionality against which protocols for Internet Fax can be judged. This memo provides information for the Internet community. </abstract>
        <draft>ietf-fax-goals-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2543</doc-id>
        <title>SIP: Session Initiation Protocol</title>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>E. Schooler</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>338861</char-count>
            <page-count>151</page-count>
        </format>
        <keywords>
            <kw>SIP</kw>
            <kw>application-layer</kw>
            <kw>application</kw>
            <kw>layer</kw>
            <kw>multimedia</kw>
            <kw>multicast</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract>The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. [STANDARDS-TRACK] </abstract>
        <draft>ietf-mmusic-sip-12</draft>
        <obsoleted-by>
            <doc-id>RFC3261</doc-id>
            <doc-id>RFC3262</doc-id>
            <doc-id>RFC3263</doc-id>
            <doc-id>RFC3264</doc-id>
            <doc-id>RFC3265</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2544</doc-id>
        <title>Benchmarking Methodology for Network Interconnect Devices</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <author>
            <name>J. McQuaid</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>66688</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>testing</kw>
            <kw>performance</kw>
        </keywords>
        <abstract>This document is a republication of RFC 1944 correcting the values for the IP addresses which were assigned to be used as the default addresses for networking test equipment. This memo provides information for the Internet community. </abstract>
        <obsoletes>
            <doc-id>RFC1944</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2545</doc-id>
        <title>Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing</title>
        <author>
            <name>P. Marques</name>
        </author>
        <author>
            <name>F. Dupont</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10209</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>border</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
            <kw>idr</kw>
            <kw>internet</kw>
            <kw>routing</kw>
        </keywords>
        <abstract>BGP-4 Multiprotocol Extensions (BGP-MP) defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information. [STANDARDS-TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2546</doc-id>
        <title>6Bone Routing Practice</title>
        <author>
            <name>A. Durand</name>
        </author>
        <author>
            <name>B. Buclin</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17844</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>IPv6</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract>This memo identifies guidelines on how 6Bone sites might operate, so that the 6Bone can remain a quality experimentation environment and to avoid pathological situations that have been encountered in the past. It defines the 'best current practice' acceptable in the 6Bone for the configuration of both Interior Gateway Protocols and Exterior Gateway Protocols. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ngtrans-6bone-routing-01</draft>
        <obsoleted-by>
            <doc-id>RFC2772</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2547</doc-id>
        <title>BGP/MPLS VPNs</title>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63270</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>border</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
            <kw>multiprotocol</kw>
            <kw>label</kw>
            <kw>switching</kw>
            <kw>architecture</kw>
            <kw>virtual</kw>
            <kw>private</kw>
            <kw>networks</kw>
        </keywords>
        <abstract>This document describes a method by which a Service Provider with an IP backbone may provide VPNs (Virtual Private Networks) for its customers. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2548</doc-id>
        <title>Microsoft Vendor-specific RADIUS Attributes    </title>
        <author>
            <name>G. Zorn</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>80763</char-count>
            <page-count>41</page-count>
        </format>
        <keywords>
            <kw>attributes</kw>
            <kw>remote</kw>
            <kw>access</kw>
            <kw>dialin</kw>
            <kw>user</kw>
            <kw>service</kw>
            <kw>dial-in</kw>
        </keywords>
        <abstract>This document describes the set of Microsoft vendor-specific RADIUS attributes. This memo provides information for the Internet community. </abstract>
        <draft>ietf-radius-ms-vsa-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2549</doc-id>
        <title>IP over Avian Carriers with Quality of Service</title>
        <author>
            <name>D. Waitzman</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9519</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>avian</kw>
            <kw>carrier</kw>
            <kw>april</kw>
            <kw>fools</kw>
            <kw>qos</kw>
        </keywords>
        <abstract>This memo amends RFC 1149, "A Standard for the Transmission of IP Datagrams on Avian Carriers", with Quality of Service information. This is an experimental, not recommended standard. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <updates>
            <doc-id>RFC1149</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2550</doc-id>
        <title>Y10K and Beyond</title>
        <author>
            <name>S. Glassman</name>
        </author>
        <author>
            <name>M. Manasse</name>
        </author>
        <author>
            <name>J. Mogul</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28011</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>years</kw>
            <kw>dates</kw>
            <kw>formats</kw>
            <kw>april</kw>
            <kw>fools </kw>
        </keywords>
        <abstract>This specification provides a solution to the "Y10K" problem which has also been called the "YAK" problem (hex) and the "YXK" problem (Roman numerals). This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2551</doc-id>
        <title>The Roman Standards Process -- Revision III</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28054</char-count>
            <page-count>37</page-count>
        </format>
        <keywords>
            <kw>numerals</kw>
            <kw>protocols</kw>
            <kw>procedures</kw>
            <kw>april</kw>
            <kw>fools</kw>
        </keywords>
        <abstract>This memo documents the process used by the Roman community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2552</doc-id>
        <title>Architecture for the Information Brokerage in the ACTS Project GAIA</title>
        <author>
            <name>M. Blinov</name>
        </author>
        <author>
            <name>M. Bessonov</name>
        </author>
        <author>
            <name>C. Clissmann</name>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>65172</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>electronic</kw>
            <kw>systems</kw>
            <kw>products</kw>
        </keywords>
        <abstract>This memo introduces a domain and supplier independent generic architecture for information brokerage, designed as part of the ACTS project GAIA (Generic Architecture for Information Availability). This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2553</doc-id>
        <title>Basic Socket Interface Extensions for IPv6 </title>
        <author>
            <name>R. Gilligan</name>
        </author>
        <author>
            <name>S. Thomson</name>
        </author>
        <author>
            <name>J. Bound</name>
        </author>
        <author>
            <name>W. Stevens</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>89215</char-count>
            <page-count>41</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>api</kw>
            <kw>application</kw>
            <kw>program</kw>
            <kw>interface</kw>
            <kw>tcp</kw>
            <kw>transmission control</kw>
        </keywords>
        <abstract>TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ipngwg-bsd-api-new-06</draft>
        <obsoletes>
            <doc-id>RFC2133</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3493</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3152</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2554</doc-id>
        <title>SMTP Service Extension for Authentication</title>
        <author>
            <name>J. Myers</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20534</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>simple</kw>
            <kw>mail</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>security</kw>
            <kw>layer</kw>
            <kw>sasl</kw>
        </keywords>
        <abstract>This document defines an SMTP service extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions. [STANDARDS-TRACK] </abstract>
        <draft>myers-smtp-auth-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2555</doc-id>
        <title>30 Years of RFCs</title>
        <author>
            <name>RFC Editor</name>
        </author>
        <author>
            <name>et al.</name>
        </author>
        <date>
            <month>April</month>
            <day>07</day>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42902</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>request</kw>
            <kw>for</kw>
            <kw>comments</kw>
            <kw>series</kw>
            <kw>documents</kw>
            <kw>publication</kw>
        </keywords>
        <abstract>The rest of this document contains a brief recollection from the present RFC Editor Joyce K. Reynolds, followed by recollections from three pioneers: Steve Crocker who wrote RFC 1, Vint Cerf whose long-range vision continues to guide us, and Jake Feinler who played a key role in the middle years of the RFC series. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2556</doc-id>
        <title>OSI connectionless transport services on top of UDP Applicability Statement for Historic Status</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5864</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>user</kw>
            <kw>datagram</kw>
            <kw>protocol</kw>
            <kw>ISO</kw>
            <kw>international</kw>
            <kw>organization for standardization </kw>
        </keywords>
        <abstract>RFC 1240, "OSI connectionless transport services on top of UDP", was published as a Proposed Standard in June 1991 but at this time there do not seem to be any implementations which follow RFC 1240. In addition there is a growing concern over using UDP-based transport protocols in environments where congestion is a possibility This memo provides information for the Internet community. </abstract>
        <draft>bradner-1240.his-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2557</doc-id>
        <title>MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)</title>
        <author>
            <name>J. Palme</name>
        </author>
        <author>
            <name>A. Hopmann</name>
        </author>
        <author>
            <name>N. Shelness</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>61854</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>MHTML</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>multimedia</kw>
            <kw>uri</kw>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>identifiers</kw>
        </keywords>
        <abstract>This document a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies a MIME content-header (Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure. [STANDARDS-TRACK] </abstract>
        <draft>ietf-mhtml-rev-07</draft>
        <obsoletes>
            <doc-id>RFC2110</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2558</doc-id>
        <title>Definitions of Managed Objects for the SONET/SDH Interface Type</title>
        <author>
            <name>K. Tesink</name>
        </author>
        <date>
            <month>March</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>138550</char-count>
            <page-count>74</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types. [STANDARDS-TRACK] </abstract>
        <draft>ietf-atommib-sonetng-05</draft>
        <obsoletes>
            <doc-id>RFC1595</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3592</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2559</doc-id>
        <title>Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2</title>
        <author>
            <name>S. Boeyen</name>
        </author>
        <author>
            <name>T. Howes</name>
        </author>
        <author>
            <name>P. Richard</name>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22889</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>X.500</kw>
            <kw>LDAP</kw>
            <kw>lightweight directory protocol</kw>
        </keywords>
        <abstract>Specifically, this document addresses requirements to provide access to Public Key Infrastructure (PKI) repositories for the purposes of retrieving PKI information and managing that same information. [STANDARDS-TRACK] </abstract>
        <draft>ietf-pkix-ipki2opp-08</draft>
        <obsoleted-by>
            <doc-id>RFC3494</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC1778</doc-id>
        </updates>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2560</doc-id>
        <title>X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP</title>
        <author>
            <name>M. Myers</name>
        </author>
        <author>
            <name>R. Ankney</name>
        </author>
        <author>
            <name>A. Malpani</name>
        </author>
        <author>
            <name>S. Galperin</name>
        </author>
        <author>
            <name>C. Adams</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43243</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>PKIX</kw>
            <kw>digital</kw>
            <kw>security </kw>
        </keywords>
        <abstract>This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. [STANDARDS- TRACK] </abstract>
        <draft>ietf-pkix-ocsp-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2561</doc-id>
        <title>Base Definitions of Managed Objects for TN3270E Using SMIv2</title>
        <author>
            <name>K. White</name>
        </author>
        <author>
            <name>R. Moore</name>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>113705</char-count>
            <page-count>56</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>structure</kw>
            <kw>telnet</kw>
        </keywords>
        <abstract>This memo defines a Management Information Base (MIB) for configuring and managing TN3270E servers. The MIB defined by this memo provides generic support for both host and gateway TN3270E server implementations. [STANDARDS-TRACK] </abstract>
        <draft>ietf-tn327oe-tn3270-mib-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2562</doc-id>
        <title>Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB)</title>
        <author>
            <name>K. White</name>
        </author>
        <author>
            <name>R. Moore</name>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>110633</char-count>
            <page-count>49</page-count>
        </format>
        <keywords>
            <kw>TN2370E-RT-MIB</kw>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>structure</kw>
            <kw>telnet</kw>
        </keywords>
        <abstract>This memo defines the protocol and the Management Information Base (MIB) for performing response time data collection on TN3270 and TN3270E sessions by a TN3270E server. [STANDARDS-TRACK] </abstract>
        <draft>ietf-tn327oe-rt-mib-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2563</doc-id>
        <title>DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients</title>
        <author>
            <name>R. Troll</name>
        </author>
        <date>
            <month>May</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17838</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>dynamic</kw>
            <kw>host</kw>
            <kw>configuration</kw>
            <kw>protocol</kw>
            <kw>internet</kw>
            <kw>address</kw>
        </keywords>
        <abstract>This document describes a mechanism by which DHCP servers are able to tell clients that they do not have an IP address to offer, and that the client should not generate an IP address it's own. [STANDARDS-TRACK] </abstract>
        <draft>ietf-dhc-autoconfig-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2564</doc-id>
        <title>Application Management MIB</title>
        <author>
            <name>C. Kalbfleisch</name>
        </author>
        <author>
            <name>C. Krupczak</name>
        </author>
        <author>
            <name>R. Presuhn</name>
        </author>
        <author>
            <name>J. Saperia</name>
        </author>
        <date>
            <month>May</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>183314</char-count>
            <page-count>86</page-count>
        </format>
        <keywords>
            <kw>APP-MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a standards track portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of applications. [STANDARDS-TRACK] </abstract>
        <draft>ietf-applmib-mib-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2565</doc-id>
        <title>Internet Printing Protocol/1.0: Encoding and Transport</title>
        <author>
            <name>R. Herriot</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Butler</name>
        </author>
        <author>
            <name>P. Moore</name>
        </author>
        <author>
            <name>R. Turner</name>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>80439</char-count>
            <page-count>37</page-count>
        </format>
        <keywords>
            <kw>IPP-E-T</kw>
            <kw>IPP</kw>
            <kw>application</kw>
            <kw>media-type</kw>
            <kw>media</kw>
            <kw>type</kw>
        </keywords>
        <abstract>This document defines the rules for encoding IPP operations and IPP attributes into a new Internet mime media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp". This document defines an Experimental protocol for the Internet community. </abstract>
        <draft>ietf-ipp-protocol-07</draft>
        <obsoleted-by>
            <doc-id>RFC2910</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2566</doc-id>
        <title>Internet Printing Protocol/1.0: Model and Semantics</title>
        <author>
            <name>R. deBry</name>
        </author>
        <author>
            <name>T. Hastings</name>
        </author>
        <author>
            <name>R. Herriot</name>
        </author>
        <author>
            <name>S. Isaacson</name>
        </author>
        <author>
            <name>P. Powell</name>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>438887</char-count>
            <page-count>173</page-count>
        </format>
        <keywords>
            <kw>IPP-M-S</kw>
            <kw>IPP</kw>
            <kw>application</kw>
            <kw>media-type</kw>
            <kw>job</kw>
        </keywords>
        <abstract>This document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport. This document also addresses security, internationalization, and directory issues. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-ipp-model-11</draft>
        <obsoleted-by>
            <doc-id>RFC2911</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2567</doc-id>
        <title>Design Goals for an Internet Printing Protocol</title>
        <author>
            <name>F. Wright</name>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>90260</char-count>
            <page-count>43</page-count>
        </format>
        <keywords>
            <kw>IPP-DG</kw>
            <kw>IPP</kw>
            <kw>application</kw>
            <kw>media-type</kw>
            <kw>media</kw>
            <kw>type</kw>
        </keywords>
        <abstract>This document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-ipp-req-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2568</doc-id>
        <title>Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol</title>
        <author>
            <name>S. Zilles</name>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23547</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>IPP-RAT</kw>
            <kw>IPP</kw>
            <kw>application</kw>
            <kw>media-type</kw>
            <kw>media</kw>
            <kw>type</kw>
        </keywords>
        <abstract>This document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for the IETF working group's major decisions. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-ipp-rat-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2569</doc-id>
        <title>Mapping between LPD and IPP Protocols</title>
        <author>
            <name>R. Herriot</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Hastings</name>
        </author>
        <author>
            <name>N. Jacobs</name>
        </author>
        <author>
            <name>J. Martin</name>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>57886</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>application</kw>
            <kw>media-type</kw>
            <kw>media</kw>
            <kw>type</kw>
            <kw>internet</kw>
            <kw>printing</kw>
            <kw>protocol</kw>
            <kw>line</kw>
            <kw>printer</kw>
            <kw>daemon</kw>
        </keywords>
        <abstract>This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). One of the purposes of this document is to compare the functionality of the two protocols. Another purpose is to facilitate implementation of gateways between LPD and IPP. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-ipp-lpd-ipp-map-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2570</doc-id>
        <title>Introduction to Version 3 of the Internet-standard Network Management Framework</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>R. Mundy</name>
        </author>
        <author>
            <name>D. Partain</name>
        </author>
        <author>
            <name>B. Stewart</name>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>50381</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>snmp</kw>
            <kw>simple</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>The purpose of this document is to provide an overview of the third version of the Internet-standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This memo provides information for the Internet community. </abstract>
        <draft>ietf-snmpv3-intro-04</draft>
        <obsoleted-by>
            <doc-id>RFC3410</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2571</doc-id>
        <title>An Architecture for Describing SNMP Management Frameworks</title>
        <author>
            <name>B. Wijnen</name>
        </author>
        <author>
            <name>D. Harrington</name>
        </author>
        <author>
            <name>R. Presuhn</name>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>139260</char-count>
            <page-count>62</page-count>
        </format>
        <keywords>
            <kw>ARCH-SNMP</kw>
            <kw>simple</kw>
            <kw>protocol</kw>
            <kw>network</kw>
            <kw>management</kw>
        </keywords>
        <abstract>This document describes an architecture for describing SNMP Management Frameworks. [STANDARDS-TRACK] </abstract>
        <draft>ietf-snmpv3-arch-05</draft>
        <obsoletes>
            <doc-id>RFC2271</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3411</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2572</doc-id>
        <title>Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>D. Harrington</name>
        </author>
        <author>
            <name>R. Presuhn</name>
        </author>
        <author>
            <name>B. Wijnen</name>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>96035</char-count>
            <page-count>44</page-count>
        </format>
        <keywords>
            <kw>MPD-SNMP</kw>
            <kw>processing</kw>
            <kw>models</kw>
            <kw>multiple</kw>
        </keywords>
        <abstract>This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2272</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3412</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2573</doc-id>
        <title>SNMP Applications</title>
        <author>
            <name>D. Levi</name>
        </author>
        <author>
            <name>P. Meyer</name>
        </author>
        <author>
            <name>B. Stewart</name>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>150427</char-count>
            <page-count>72</page-count>
        </format>
        <keywords>
            <kw>SNMP-APP</kw>
            <kw>simple</kw>
            <kw>network</kw>
            <kw>management</kw>
            <kw>protocol</kw>
            <kw>proxy</kw>
            <kw>operations</kw>
            <kw>command</kw>
        </keywords>
        <abstract>This memo describes five types of SNMP applications which make use of an SNMP engine. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy fowarding. [STANDARDS-TRACK] </abstract>
        <draft>ietf-snmpv3-appl-v2-03</draft>
        <obsoletes>
            <doc-id>RFC2273</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3413</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2574</doc-id>
        <title>User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)</title>
        <author>
            <name>U. Blumenthal</name>
        </author>
        <author>
            <name>B. Wijnen</name>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>190755</char-count>
            <page-count>86</page-count>
        </format>
        <keywords>
            <kw>USM-SNMPV3</kw>
            <kw>message</kw>
            <kw>level</kw>
            <kw>mib</kw>
            <kw>information</kw>
            <kw>base </kw>
        </keywords>
        <abstract>This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. [STANDARDS-TRACK] </abstract>
        <draft>ietf-snmpv3-usm-v2-05</draft>
        <obsoletes>
            <doc-id>RFC2274</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3414</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2575</doc-id>
        <title>View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)</title>
        <author>
            <name>B. Wijnen</name>
        </author>
        <author>
            <name>R. Presuhn</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>79642</char-count>
            <page-count>38</page-count>
        </format>
        <keywords>
            <kw>VACM-SNMP</kw>
            <kw>mib</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This document describes the View-based Access Control Model for use in the SNMP architecture (RFC2571). It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. [STANDARDS-TRACK] </abstract>
        <draft>ietf-snmpv3-vacm-04</draft>
        <obsoletes>
            <doc-id>RFC2275</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3415</doc-id>
        </obsoleted-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2576</doc-id>
        <title>Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework</title>
        <author>
            <name>R. Frye</name>
        </author>
        <author>
            <name>D. Levi</name>
        </author>
        <author>
            <name>S. Routhier</name>
        </author>
        <author>
            <name>B. Wijnen</name>
        </author>
        <date>
            <month>March</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>98589</char-count>
            <page-count>44</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
            <kw>simple network</kw>
            <kw>management protocol</kw>
            <kw>mib</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). [STANDARDS TRACK] </abstract>
        <draft>ietf-snmpv3-coex-08</draft>
        <obsoletes>
            <doc-id>RFC1908</doc-id>
            <doc-id>RFC2089</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3584</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2577</doc-id>
        <title>FTP Security Considerations</title>
        <author>
            <name>M. Allman</name>
        </author>
        <author>
            <name>S. Ostermann</name>
        </author>
        <date>
            <month>May</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17870</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>FTP-SEC</kw>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>bounce</kw>
            <kw>attack</kw>
            <kw>password</kw>
            <kw>server </kw>
        </keywords>
        <abstract>This document provides suggestions for system administrators and those implementing FTP servers that will decrease the security problems associated with FTP. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ftpext-sec-consider-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2578</doc-id>
        <title>Structure of Management Information Version 2 (SMIv2)</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>D. Perkins</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>89712</char-count>
            <page-count>42</page-count>
        </format>
        <keywords>
            <kw>SMIv2</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version</kw>
            <kw>2</kw>
        </keywords>
        <abstract>It is the purpose of this document, the Structure of Management Information Version 2 (SMIv2), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK] </abstract>
        <draft>ops-smiv2-smi-01</draft>
        <obsoletes>
            <doc-id>RFC1902</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0058</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2579</doc-id>
        <title>Textual Conventions for SMIv2</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>D. Perkins</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59039</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>CONV-MIB</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version</kw>
            <kw>2</kw>
        </keywords>
        <abstract>It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK] </abstract>
        <draft>ops-smiv2-tc-01</draft>
        <obsoletes>
            <doc-id>RFC1903</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0058</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2580</doc-id>
        <title>Conformance Statements for SMIv2</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>D. Perkins</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54253</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>CONF-MIB</kw>
            <kw>simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version</kw>
            <kw>2</kw>
        </keywords>
        <abstract>Collections of related objects are defined in MIB modules. It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK] </abstract>
        <draft>ops-smiv2-conf-01</draft>
        <obsoletes>
            <doc-id>RFC1904</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0058</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2581</doc-id>
        <title>TCP Congestion Control </title>
        <author>
            <name>M. Allman</name>
        </author>
        <author>
            <name>V. Paxson</name>
        </author>
        <author>
            <name>W. Stevens</name>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31351</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>TCP-CC</kw>
        </keywords>
        <abstract>This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. [STANDARDS-TRACK] </abstract>
        <draft>ietf-tcpimpl-cong-control-05</draft>
        <obsoletes>
            <doc-id>RFC2001</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3390</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2582</doc-id>
        <title>The NewReno Modification to TCP's Fast Recovery Algorithm</title>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>T. Henderson</name>
        </author>
        <date>
            <month>April</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29393</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>Transmission</kw>
            <kw>Control</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-tcpimpl-newreno-02</draft>
        <obsoleted-by>
            <doc-id>RFC3782</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2583</doc-id>
        <title>Guidelines for Next Hop Client (NHC) Developers</title>
        <author>
            <name>R. Carlson</name>
        </author>
        <author>
            <name>L. Winkler</name>
        </author>
        <date>
            <month>May</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21338</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>NHRP</kw>
            <kw>resolution</kw>
            <kw>protocol</kw>
            <kw>IP</kw>
            <kw>internet</kw>
        </keywords>
        <abstract>This document provides guidelines for developers of the Next Hop Resolution Protocol Clients (NHC). The intent is to define the interaction between the NHC code and the TCP/IP protocol stack of the local host operating system. This memo provides information for the Internet community. </abstract>
        <draft>carlson-nhrp-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2584</doc-id>
        <title>Definitions of Managed Objects for APPN/HPR in IP Networks</title>
        <author>
            <name>B. Clouston</name>
        </author>
        <author>
            <name>B. Moore</name>
        </author>
        <date>
            <month>May</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40187</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>high</kw>
            <kw>performance</kw>
            <kw>routing</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling HPR (High Performance Routing) network devices which have the capability to communicate in IP (Internet Protocol) networks. [STANDARDS-TRACK] </abstract>
        <draft>ietf-snaunau-hpripmib-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2585</doc-id>
        <title>Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>May</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14813</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>hypertext</kw>
            <kw>PKI</kw>
        </keywords>
        <abstract>The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP) to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. [STANDARDS-TRACK] </abstract>
        <draft>ietf-pkix-opp-ftp-http-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2586</doc-id>
        <title>The Audio/L16 MIME content type</title>
        <author>
            <name>J. Salsman</name>
        </author>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>May</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8694</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>AUDIO/L16</kw>
            <kw>media-type</kw>
            <kw>application</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document defines the audio/L16 MIME type, a reasonable quality audio format for use in Internet applications. This memo provides information for the Internet community. </abstract>
        <draft>alvestrand-audio-l16-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2587</doc-id>
        <title>Internet X.509 Public Key Infrastructure LDAPv2 Schema</title>
        <author>
            <name>S. Boeyen</name>
        </author>
        <author>
            <name>T. Howes</name>
        </author>
        <author>
            <name>P. Richard</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15102</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>pkix</kw>
        </keywords>
        <abstract>The schema defined in this document is a minimal schema to support PKIX in an LDAPv2 environment, as defined in RFC 2559. Only PKIX-specific components are specified here. [STANDARDS-TRACK] </abstract>
        <draft>ietf-pkix-ldap2-schema-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2588</doc-id>
        <title>IP Multicast and Firewalls</title>
        <author>
            <name>R. Finlayson</name>
        </author>
        <date>
            <month>May</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28622</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>security</kw>
            <kw>gateway</kw>
            <kw>traffic</kw>
        </keywords>
        <abstract>In this document, we discuss the issues surrounding the traversal of IP multicast traffic across a firewall, and describe possible ways in which a firewall can implement and control this traversal. We also explain why some firewall mechanisms - such as SOCKS - that were designed specifically for unicast traffic, are less appropriate for multicast. This memo provides information for the Internet community. </abstract>
        <draft>ietf-mboned-mcast-firewall-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2589</doc-id>
        <title>Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services</title>
        <author>
            <name>Y. Yaacovi</name>
        </author>
        <author>
            <name>M. Wahl</name>
        </author>
        <author>
            <name>T. Genovese</name>
        </author>
        <date>
            <month>May</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26855</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>LDAPv3</kw>
            <kw>request</kw>
            <kw>response</kw>
            <kw>operations </kw>
        </keywords>
        <abstract>This document defines the requirements for dynamic directory services and specifies the format of request and response extended operations for supporting client-server interoperation in a dynamic directories environment. [STANDARDS-TRACK] </abstract>
        <draft>ietf-asid-ldapv3-dynamic-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2590</doc-id>
        <title>Transmission of IPv6 Packets over Frame Relay Networks Specification</title>
        <author>
            <name>A. Conta</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <author>
            <name>M. Mueller</name>
        </author>
        <date>
            <month>May</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41817</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>Protocol</kw>
            <kw>format</kw>
            <kw>link-local</kw>
        </keywords>
        <abstract>This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks. [STANDARDS-TRACK] </abstract>
        <draft>ietf-ion-ipv6-fr-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2591</doc-id>
        <title>Definitions of Managed Objects for Scheduling Management Operations</title>
        <author>
            <name>D. Levi</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>May</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52920</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK] </abstract>
        <draft>ietf-disman-schedule-mib-06</draft>
        <obsoleted-by>
            <doc-id>RFC3231</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2592</doc-id>
        <title>Definitions of Managed Objects for the Delegation of Management Script</title>
        <author>
            <name>D. Levi</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>May</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>110629</char-count>
            <page-count>53</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow the delegation of management scripts to distributed managers. [STANDARDS-TRACK] </abstract>
        <draft>ietf-disman-script-mib-08</draft>
        <obsoleted-by>
            <doc-id>RFC3165</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2593</doc-id>
        <title>Script MIB Extensibility Protocol Version 1.0</title>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <author>
            <name>J. Quittek</name>
        </author>
        <date>
            <month>May</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49663</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>smx</kw>
            <kw>language</kw>
            <kw>specific</kw>
        </keywords>
        <abstract>The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>schoenw-smx-00</draft>
        <obsoleted-by>
            <doc-id>RFC3179</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2594</doc-id>
        <title>Definitions of Managed Objects for WWW Services</title>
        <author>
            <name>H. Hazewinkel</name>
        </author>
        <author>
            <name>C. Kalbfleisch</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>May</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>88876</char-count>
            <page-count>43</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>mib</kw>
            <kw>world</kw>
            <kw>wide</kw>
            <kw>web</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular it describes a set of objects for managing World Wide Web (WWW) services. [STANDARDS-TRACK] </abstract>
        <draft>ietf-applmib-wwwmib-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2595</doc-id>
        <title>Using TLS with IMAP, POP3 and ACAP</title>
        <author>
            <name>C. Newman</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32440</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>application</kw>
            <kw>configuration</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>post</kw>
            <kw>office</kw>
            <kw>internet</kw>
            <kw>message</kw>
            <kw>transport</kw>
            <kw>layer</kw>
            <kw>security</kw>
        </keywords>
        <abstract>Recognizing that such sites will desire simple password authentication in combination with TLS encryption, this specification defines the PLAIN SASL mechanism for use with protocols which lack a simple password authentication command such as ACAP and SMTP. [STANDARDS-TRACK] </abstract>
        <draft>newman-tls-imappop-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2596</doc-id>
        <title>Use of Language Codes in LDAP</title>
        <author>
            <name>M. Wahl</name>
        </author>
        <author>
            <name>T. Howes</name>
        </author>
        <date>
            <month>May</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17413</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>servers</kw>
        </keywords>
        <abstract>This document describes how language codes are carried in LDAP and are to be interpreted by LDAP servers. [STANDARDS-TRACK] </abstract>
        <draft>ietf-ldapext-lang-01</draft>
        <obsoleted-by>
            <doc-id>RFC3866</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2597</doc-id>
        <title>Assured Forwarding PHB Group</title>
        <author>
            <name>J. Heinanen</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>W. Weiss</name>
        </author>
        <author>
            <name>J. Wroclawski</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24068</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>per-hop-behaviour</kw>
            <kw>differentiated</kw>
            <kw>services</kw>
            <kw>af</kw>
            <kw>assumed</kw>
            <kw>forwarding</kw>
        </keywords>
        <abstract>This document defines a general use Differentiated Services (DS) Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). [STANDARDS-TRACK] </abstract>
        <draft>ietf-diffserv-af-06</draft>
        <updated-by>
            <doc-id>RFC3260</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2598</doc-id>
        <title>An Expedited Forwarding PHB</title>
        <author>
            <name>V. Jacobson</name>
        </author>
        <author>
            <name>K. Nichols</name>
        </author>
        <author>
            <name>K. Poduri</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23656</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>per-hop-forwarding</kw>
            <kw>behavior</kw>
            <kw>differentiated</kw>
            <kw>services</kw>
            <kw>ef</kw>
        </keywords>
        <abstract>The definition of PHBs (per-hop forwarding behaviors) is a critical part of the work of the Diffserv Working Group. This document describes a PHB called Expedited Forwarding. [STANDARDS-TRACK] </abstract>
        <draft>ietf-diffserv-phb-ef-02</draft>
        <obsoleted-by>
            <doc-id>RFC3246</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2599</doc-id>
        <title>Request for Comments Summary RFC Numbers 2500-2599</title>
        <author>
            <name>A. DeLaCruz</name>
        </author>
        <date>
            <month>March</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45845</char-count>
            <page-count>23</page-count>
        </format>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2600</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Reynolds</name>
        </author>
        <author>
            <name>R. Braden</name>
        </author>
        <date>
            <month>March</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>86139</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>IAB</kw>
            <kw>official</kw>
            <kw>protocol</kw>
            <kw>standards</kw>
        </keywords>
        <abstract>This memo is published by the RFC Editor in accordance with Section 2.1 of "The Internet Standards Process -- Revision 3", RFC 2026, which specifies the rules and procedures by which all Internet standards are set. This memo is prepared by the RFC Editor for the IESG and IAB. Please see http://www.rfc-editor.org for later updates to this document. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2500</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2700</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2601</doc-id>
        <title>ILMI-Based Server Discovery for ATMARP</title>
        <author>
            <name>M. Davison</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11820</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>integrated</kw>
            <kw>local</kw>
            <kw>management</kw>
            <kw>interface</kw>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>address</kw>
            <kw>resolution</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate ATMARP servers. [STANDARDS-TRACK] </abstract>
        <draft>ietf-ion-discov-atmarp-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2602</doc-id>
        <title>ILMI-Based Server Discovery for MARS</title>
        <author>
            <name>M. Davison</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12031</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>integrated</kw>
            <kw>local</kw>
            <kw>management</kw>
            <kw>interface</kw>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>address</kw>
            <kw>resolution</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate MARS servers. [STANDARDS-TRACK] </abstract>
        <draft>ietf-ion-discov-mars-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2603</doc-id>
        <title>ILMI-Based Server Discovery for NHRP</title>
        <author>
            <name>M. Davison</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11865</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>integrated</kw>
            <kw>local</kw>
            <kw>management</kw>
            <kw>interface</kw>
            <kw>next</kw>
            <kw>hop</kw>
            <kw>resolution</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate NHRP servers. [STANDARDS-TRACK] </abstract>
        <draft>ietf-discov-nhrp-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2604</doc-id>
        <title>Wireless Device Configuration (OTASP/OTAPA) via ACAP</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>65329</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>over-the-air</kw>
            <kw>ota</kw>
            <kw>application</kw>
            <kw>configuration</kw>
            <kw>access</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using the ACAP protocol. This memo provides information for the Internet community. </abstract>
        <draft>gellens-otasp-acap-01</draft>
        <obsoleted-by>
            <doc-id>RFC2636</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2605</doc-id>
        <title>Directory Server Monitoring MIB</title>
        <author>
            <name>G. Mansfield</name>
        </author>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49166</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>management information base</kw>
            <kw>network</kw>
            <kw>services</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK] </abstract>
        <draft>ietf-madman-dsa-mib-10</draft>
        <obsoletes>
            <doc-id>RFC1567</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2606</doc-id>
        <title>Reserved Top Level DNS Names</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>A. Panitz</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8008</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>private</kw>
        </keywords>
        <abstract>To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-dnsind-test-tlds-13</draft>
        <is-also>
            <doc-id>BCP0032</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2607</doc-id>
        <title>Proxy Chaining and Policy Implementation in Roaming</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>J. Vollbrecht</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33271</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>network</kw>
            <kw>access</kw>
            <kw>server</kw>
            <kw>identifier</kw>
            <kw>radius</kw>
        </keywords>
        <abstract>This document describes how proxy chaining and policy implementation can be supported in roaming systems. This memo provides information for the Internet community. </abstract>
        <draft>ietf-roamops-auth-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2608</doc-id>
        <title>Service Location Protocol, Version 2 </title>
        <author>
            <name>E. Guttman</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>J. Veizades</name>
        </author>
        <author>
            <name>M. Day</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>129475</char-count>
            <page-count>54</page-count>
        </format>
        <keywords>
            <kw>SLP</kw>
            <kw>network</kw>
            <kw>services</kw>
        </keywords>
        <abstract>The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet need little or no static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. [STANDARDS-TRACK] </abstract>
        <draft>ietf-svrloc-protocol-v2-15</draft>
        <updates>
            <doc-id>RFC2165</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC3224</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2609</doc-id>
        <title>Service Templates and Service: Schemes</title>
        <author>
            <name>E. Guttman</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>J. Kempf</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>72842</char-count>
            <page-count>33</page-count>
        </format>
        <keywords>
            <kw>service</kw>
            <kw>location</kw>
            <kw>protocol</kw>
            <kw>slp</kw>
            <kw>url</kw>
            <kw>universal</kw>
            <kw>resource</kw>
            <kw>locator</kw>
        </keywords>
        <abstract>This document describes a formal procedure for defining and standardizing new service types and attributes for use with the "service:" scheme. [STANDARDS-TRACK] </abstract>
        <draft>ietf-svrloc-service-scheme-14</draft>
        <updates>
            <doc-id>RFC2165</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2610</doc-id>
        <title>DHCP Options for Service Location Protocol</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>E. Guttman</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10859</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>slp</kw>
            <kw>dynamic</kw>
            <kw>host</kw>
            <kw>configuration</kw>
            <kw>protocol </kw>
        </keywords>
        <abstract>The Dynamic Host Configuration Protocol provides a framework for passing configuration information to hosts on a TCP/IP network. Entities using the Service Location Protocol need to find out the address of Directory Agents in order to transact messages. Another option provides an assignment of scope for configuration of SLP User and Service Agents. [STANDARDS-TRACK] </abstract>
        <draft>ietf-dhc-slp-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2611</doc-id>
        <title>URN Namespace Definition Mechanisms</title>
        <author>
            <name>L. Daigle</name>
        </author>
        <author>
            <name>D. van Gulik</name>
        </author>
        <author>
            <name>R. Iannella</name>
        </author>
        <author>
            <name>P. Falstrom</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26916</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>names</kw>
            <kw>namespaces</kw>
            <kw>syntax</kw>
        </keywords>
        <abstract>This document lays out general definitions of and mechanisms for establishing URN "namespaces". This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-urn-nid-req-08</draft>
        <obsoleted-by>
            <doc-id>RFC3406</doc-id>
        </obsoleted-by>
        <is-also>
            <doc-id>BCP0033</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2612</doc-id>
        <title>The CAST-256 Encryption Algorithm</title>
        <author>
            <name>C. Adams</name>
        </author>
        <author>
            <name>J. Gilchrist</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37468</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>cryptology</kw>
        </keywords>
        <abstract>This document describes an existing algorithm that can be used to satisfy this requirement. Included are a description of the cipher and the key scheduling algorithm, the s-boxes, and a set of test vectors (Appendix A). This memo provides information for the Internet community. </abstract>
        <draft>adams-cast-256-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2613</doc-id>
        <title>Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0</title>
        <author>
            <name>R. Waterman</name>
        </author>
        <author>
            <name>B. Lahaye</name>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>88701</char-count>
            <page-count>44</page-count>
        </format>
        <keywords>
            <kw>smon</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices in switched networks environments. [STANDARDS-TRACK] </abstract>
        <draft>ietf-rmonmib-smon-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2614</doc-id>
        <title>An API for Service Location</title>
        <author>
            <name>J. Kempf</name>
        </author>
        <author>
            <name>E. Guttman</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>164002</char-count>
            <page-count>91</page-count>
        </format>
        <keywords>
            <kw>slp</kw>
            <kw>application</kw>
            <kw>program</kw>
            <kw>interface</kw>
        </keywords>
        <abstract>This document describes standardized APIs for SLP in C and Java. This memo provides information for the Internet community. </abstract>
        <draft>ietf-svrloc-api-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2615</doc-id>
        <title>PPP over SONET/SDH</title>
        <author>
            <name>A. Malis</name>
        </author>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18708</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>point-to-point protocol</kw>
            <kw>synchronous</kw>
            <kw>optical</kw>
            <kw>network</kw>
            <kw>digital</kw>
            <kw>heirarchy</kw>
        </keywords>
        <abstract>This document describes the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. [STANDARDS- TRACK] </abstract>
        <draft>ietf-pppext-pppoversonet-update-04</draft>
        <obsoletes>
            <doc-id>RFC1619</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2616</doc-id>
        <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
        <author>
            <name> R. Fielding</name>
        </author>
        <author>
            <name>J. Gettys</name>
        </author>
        <author>
            <name>J. Mogul</name>
        </author>
        <author>
            <name>H. Frystyk</name>
        </author>
        <author>
            <name>L. Masinter</name>
        </author>
        <author>
            <name>P. Leach</name>
        </author>
        <author>
            <name>T. Berners-Lee</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>422317</char-count>
            <page-count>176</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>5529857</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>550558</char-count>
        </format>
        <keywords>
            <kw>HTTP</kw>
            <kw>World</kw>
            <kw>Wide</kw>
            <kw>Web</kw>
            <kw>WWW</kw>
            <kw>hypermedia</kw>
        </keywords>
        <abstract>HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068. [STANDARDS-TRACK] </abstract>
        <draft>ietf-http-v11-spec-rev-06</draft>
        <obsoletes>
            <doc-id>RFC2068</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC2817</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2617</doc-id>
        <title>HTTP Authentication: Basic and Digest Access Authentication</title>
        <author>
            <name>J. Franks</name>
        </author>
        <author>
            <name>P. Hallam-Baker</name>
        </author>
        <author>
            <name>J. Hostetler</name>
        </author>
        <author>
            <name>S. Lawrence</name>
        </author>
        <author>
            <name>P. Leach</name>
        </author>
        <author>
            <name>A. Luotonen</name>
        </author>
        <author>
            <name>L. Stewart</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>77638</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>encryption</kw>
            <kw>hypertext</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as "Digest Access Authentication". [STANDARDS-TRACK] </abstract>
        <draft>ietf-http-authentication-03</draft>
        <obsoletes>
            <doc-id>RFC2069</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2618</doc-id>
        <title>RADIUS Authentication Client MIB</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26889</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>security</kw>
            <kw>remote</kw>
            <kw>access</kw>
            <kw>dialin</kw>
            <kw>user</kw>
            <kw>service</kw>
        </keywords>
        <abstract>This memo defines a set of extensions which instrument RADIUS authentication client functions. [STANDARDS-TRACK] </abstract>
        <draft>ietf-radius-auth-clientmib-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2619</doc-id>
        <title>RADIUS Authentication Server MIB</title>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>B. Aboba</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30464</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>security</kw>
            <kw>remote</kw>
            <kw>access</kw>
            <kw>dialin</kw>
            <kw>user</kw>
            <kw>service</kw>
        </keywords>
        <abstract>This memo defines a set of extensions which instrument RADIUS authentication server functions. [STANDARDS-TRACK] </abstract>
        <draft>ietf-radius-auth-servmib-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2620</doc-id>
        <title>RADIUS Accounting Client MIB</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23960</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>security</kw>
            <kw>remote</kw>
            <kw>access</kw>
            <kw>dialin</kw>
            <kw>user</kw>
            <kw>service</kw>
        </keywords>
        <abstract>This memo defines a set of extensions which instrument RADIUS accounting client functions. This memo provides information for the Internet community. </abstract>
        <draft>ietf-radius-acc-clientmib-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2621</doc-id>
        <title>RADIUS Accounting Server MIB</title>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>B. Aboba</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27768</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>security</kw>
            <kw>remote</kw>
            <kw>access,dialin</kw>
            <kw>user</kw>
            <kw>service</kw>
        </keywords>
        <abstract>This memo defines a set of extensions which instrument RADIUS accounting server functions. This memo provides information for the Internet community. </abstract>
        <draft>ietf-radius-acc-servmib-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2622</doc-id>
        <title>Routing Policy Specification Language (RPSL)</title>
        <author>
            <name>C. Alaettinoglu</name>
        </author>
        <author>
            <name>C. Villamizar</name>
        </author>
        <author>
            <name>E. Gerich</name>
        </author>
        <author>
            <name>D. Kessens</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>T. Bates</name>
        </author>
        <author>
            <name>D. Karrenberg</name>
        </author>
        <author>
            <name>M. Terpstra</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>140811</char-count>
            <page-count>69</page-count>
        </format>
        <keywords>
            <kw>RPSL</kw>
            <kw>internet</kw>
            <kw>policy</kw>
            <kw>hierarchy</kw>
            <kw>network</kw>
            <kw>configuration</kw>
        </keywords>
        <abstract>RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK] </abstract>
        <draft>ietf-rps-rpsl-v2-03</draft>
        <obsoletes>
            <doc-id>RFC2280</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC4012</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2623</doc-id>
        <title>NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5</title>
        <author>
            <name>M. Eisler</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42521</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>network</kw>
            <kw>file</kw>
            <kw>system</kw>
            <kw>remote</kw>
            <kw>procedure</kw>
            <kw>call</kw>
            <kw>architecture</kw>
        </keywords>
        <abstract>This memorandum clarifies various security issues involving the NFS protocol (Version 2 and Version 3 only) and then describes how the Version 2 and Version 3 of the NFS protocol use the RPCSEC_GSS security flavor protocol and Kerberos V5. [STANDARDS-TRACK] </abstract>
        <draft>ietf-nfsv4-nfssec-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2624</doc-id>
        <title>NFS Version 4 Design Considerations</title>
        <author>
            <name>S. Shepler</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52891</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>network</kw>
            <kw>file</kw>
            <kw>system</kw>
        </keywords>
        <abstract>This design considerations document is meant to present more detail than the working group charter. Specifically, it presents the areas that the working group will investigate and consider while developing a protocol specification for NFS version 4. This memo provides information for the Internet community. </abstract>
        <draft>ietf-nfsv4-designconsider-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2625</doc-id>
        <title>IP and ARP over Fibre Channel</title>
        <author>
            <name>M. Rajagopal</name>
        </author>
        <author>
            <name>R. Bhagwat</name>
        </author>
        <author>
            <name>W. Rickard</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>137741</char-count>
            <page-count>63</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocal</kw>
            <kw>address</kw>
            <kw>resolution</kw>
        </keywords>
        <abstract>The purpose of this document is to specify a way of encapsulating IP and Address Resolution Protocol(ARP) over Fibre Channel and also to describe a mechanism(s) for IP address resolution. [STANDARDS-TRACK] </abstract>
        <draft>ietf-ipfc-fibre-channel-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2626</doc-id>
        <title>The Internet and the Millennium Problem (Year 2000)</title>
        <author>
            <name>P. Nesser II</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>547560</char-count>
            <page-count>275</page-count>
        </format>
        <keywords>
            <kw>Y2K</kw>
        </keywords>
        <abstract>The Year 2000 Working Group (WG) has conducted an investigation into the millennium problem as it regards Internet related protocols. This investigation only targeted the protocols as documented in the Request For Comments Series (RFCs). This investigation discovered little reason for concern with regards to the functionality of the protocols. A few minor cases of older implementations still using two digit years (ala RFC 850) were discovered, but almost all Internet protocols were given a clean bill of health. Several cases of "period" problems were discovered, where a time field would "roll over" as the size of field was reached. In particular, there are several protocols, which have 32 bit, signed integer representations of the number of seconds since January 1, 1970 which will turn negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols will be effected by such problems have been notified so that new revisions will remove this limitation. This memo provides information for the Internet community. </abstract>
        <draft>ietf-2000-issue-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2627</doc-id>
        <title>Key Management for Multicast: Issues and Architectures</title>
        <author>
            <name>D. Wallner</name>
        </author>
        <author>
            <name>E. Harder</name>
        </author>
        <author>
            <name>R. Agee</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59263</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>communication</kw>
            <kw>sessions</kw>
            <kw>net key</kw>
            <kw>rekey</kw>
        </keywords>
        <abstract>This report contains a discussion of the difficult problem of key management for multicast communication sessions. It focuses on two main areas of concern with respect to key management, which are, initializing the multicast group with a common net key and rekeying the multicast group. This memo provides information for the Internet community. </abstract>
        <draft>wallner-key-arch-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2628</doc-id>
        <title>Simple Cryptographic Program Interface (Crypto API)</title>
        <author>
            <name>V. Smyslov</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>60070</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>application</kw>
            <kw>security</kw>
        </keywords>
        <abstract>This document describes a simple Application Program Interface to cryptographic functions. This memo provides information for the Internet community. </abstract>
        <draft>smyslov-crypto-cpi-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2629</doc-id>
        <title>Writing I-Ds and RFCs using XML</title>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48677</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>internet-drafts</kw>
            <kw>extensible markup</kw>
            <kw>language</kw>
            <kw>source format</kw>
        </keywords>
        <abstract>This memo presents a technique for using XML (Extensible Markup Language) as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series. This memo provides information for the Internet community. </abstract>
        <draft>mrose-writing-rfcs-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2630</doc-id>
        <title>Cryptographic Message Syntax</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>128599</char-count>
            <page-count>60</page-count>
        </format>
        <keywords>
            <kw>encryption</kw>
            <kw>certificate</kw>
            <kw>key</kw>
            <kw>management</kw>
        </keywords>
        <abstract>This document describes the Cryptographic Message Syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages. [STANDARDS-TRACK] </abstract>
        <draft>ietf-smime-cms-13</draft>
        <obsoleted-by>
            <doc-id>RFC3369</doc-id>
            <doc-id>RFC3370</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2631</doc-id>
        <title>Diffie-Hellman Key Agreement Method</title>
        <author>
            <name>E. Rescorla</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25932</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>encryption</kw>
            <kw>management</kw>
            <kw>certificate</kw>
        </keywords>
        <abstract>This document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. [STANDARDS-TRACK] </abstract>
        <draft>ietf-smime-x942-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2632</doc-id>
        <title>S/MIME Version 3 Certificate Handling</title>
        <author>
            <name>B. Ramsdell</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27925</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>encryption</kw>
            <kw>certificate</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>secure</kw>
        </keywords>
        <abstract>S/MIME (Secure/Multipurpose Internet Mail Extensions), provides a method to send and receive secure MIME messages. Before using a public key to provide security services, the S/MIME agent MUST certify that the public key is valid. S/MIME agents MUST use PKIX certificates to validate public keys as described in the Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Profile. [STANDARDS-TRACK] </abstract>
        <draft>ietf-smime-cert-08</draft>
        <obsoleted-by>
            <doc-id>RFC3850</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2633</doc-id>
        <title>S/MIME Version 3 Message Specification</title>
        <author>
            <name>B. Ramsdell</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>67870</char-count>
            <page-count>32</page-count>
        </format>
        <keywords>
            <kw>secure</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract>This document describes a protocol for adding cryptographic signature and encryption services to MIME data. [STANDARDS-TRACK] </abstract>
        <draft>ietf-smime-msg-08</draft>
        <obsoleted-by>
            <doc-id>RFC3851</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2634</doc-id>
        <title>Enhanced Security Services for S/MIME</title>
        <author>
            <name>P. Hoffman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>131153</char-count>
            <page-count>58</page-count>
        </format>
        <keywords>
            <kw>secure</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract>This document describes four optional security service extensions for S/MIME. [STANDARDS-TRACK] </abstract>
        <draft>ietf-smime-ess-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2635</doc-id>
        <title>DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*)</title>
        <author>
            <name>S. Hambridge</name>
        </author>
        <author>
            <name>A. Lunde</name>
        </author>
        <date>
            <month>June</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44669</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>electronic</kw>
            <kw>mail</kw>
            <kw>email</kw>
            <kw>users</kw>
            <kw>administrators</kw>
            <kw>managers</kw>
        </keywords>
        <abstract>This document explains why mass unsolicited electronic mail messages are harmful in the Internetworking community. This memo provides information for the Internet community. </abstract>
        <draft>ietf-run-spew-08</draft>
        <is-also>
            <doc-id>FYI0035</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2636</doc-id>
        <title>Wireless Device Configuration (OTASP/OTAPA) via ACAP</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <date>
            <month>July</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>65288</char-count>
            <page-count>29</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>1120860</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>173655</char-count>
        </format>
        <keywords>
            <kw>over-the-air</kw>
            <kw>ota</kw>
            <kw>application</kw>
            <kw>configuration</kw>
            <kw>access</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using the ACAP protocol. This memo provides information for the Internet community. </abstract>
        <obsoletes>
            <doc-id>RFC2604</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2637</doc-id>
        <title>Point-to-Point Tunneling Protocol</title>
        <author>
            <name>K. Hamzeh</name>
        </author>
        <author>
            <name>G. Pall</name>
        </author>
        <author>
            <name>W. Verthein</name>
        </author>
        <author>
            <name>J. Taarud</name>
        </author>
        <author>
            <name>W. Little</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <date>
            <month>July</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>132565</char-count>
            <page-count>57</page-count>
        </format>
        <keywords>
            <kw>IP</kw>
            <kw>tunnel</kw>
            <kw>encapsulation</kw>
        </keywords>
        <abstract>This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network. This memo provides information for the Internet community. </abstract>
        <draft>ietf-pppext-pptp-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2638</doc-id>
        <title>A Two-bit Differentiated Services Architecture for the Internet</title>
        <author>
            <name>K. Nichols</name>
        </author>
        <author>
            <name>V. Jacobson</name>
        </author>
        <author>
            <name>L. Zhang</name>
        </author>
        <date>
            <month>July</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>72785</char-count>
            <page-count>26</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>1610846</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>315195</char-count>
        </format>
        <keywords>
            <kw>IP</kw>
            <kw>internet protocol</kw>
            <kw>header</kw>
            <kw>packets</kw>
        </keywords>
        <abstract>This document presents a differentiated services architecture for the internet. This memo provides information for the Internet community. </abstract>
        <draft>nichols-diff-svc-arch-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2639</doc-id>
        <title>Internet Printing Protocol/1.0: Implementer's Guide</title>
        <author>
            <name>T. Hastings</name>
        </author>
        <author>
            <name>C. Manros</name>
        </author>
        <date>
            <month>July</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>145086</char-count>
            <page-count>64</page-count>
        </format>
        <keywords>
            <kw>IPP</kw>
            <kw>client</kw>
            <kw>object</kw>
        </keywords>
        <abstract>This document contains information that supplements the IPP Model and Semantics and the IPP Transport and Encoding documents. It is intended to help implementers understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ipp-implementers-guide-01</draft>
        <obsoleted-by>
            <doc-id>RFC3196</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2640</doc-id>
        <title>Internationalization of the File Transfer Protocol</title>
        <author>
            <name>B. Curtin</name>
        </author>
        <date>
            <month>July</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>57204</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>ftp</kw>
            <kw>character sets</kw>
            <kw>languages </kw>
        </keywords>
        <abstract>This document addresses the internationalization (I18n) of FTP, which includes supporting the multiple character sets and languages found throughout the Internet community. This is achieved by extending the FTP specification and giving recommendations for proper internationalization support. [STANDARDS-TRACK] </abstract>
        <draft>ietf-ftpext-intl-ftp-06</draft>
        <updates>
            <doc-id>RFC0959</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2641</doc-id>
        <title>Cabletron's VlanHello Protocol Specification Version 4</title>
        <author>
            <name>D. Hamilton</name>
        </author>
        <author>
            <name>D. Ruffen</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34686</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>ISMP</kw>
            <kw>inter switch</kw>
            <kw>message</kw>
            <kw>protocol</kw>
            <kw>switches</kw>
        </keywords>
        <abstract>The VlanHello protocol is part of the InterSwitch Message Protocol (ISMP) which provides interswitch communication between switches running Cabletron's SecureFast VLAN (SFVLAN) product. Switches use the VlanHello protocol to discover their neighboring switches and establish the topology of the switch fabric. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2642</doc-id>
        <title>Cabletron's VLS Protocol Specification</title>
        <author>
            <name>L. Kane</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>204347</char-count>
            <page-count>95</page-count>
        </format>
        <keywords>
            <kw>Virtual</kw>
            <kw>LAN</kw>
            <kw>link</kw>
            <kw>ISMP</kw>
            <kw>inter switch</kw>
            <kw>message</kw>
            <kw>routing</kw>
        </keywords>
        <abstract>VLSP provides support for equal-cost multipath routing, and recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2643</doc-id>
        <title>Cabletron's SecureFast VLAN Operational Model </title>
        <author>
            <name>D. Ruffen</name>
        </author>
        <author>
            <name>T. Len</name>
        </author>
        <author>
            <name>J. Yanacek</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>121786</char-count>
            <page-count>60</page-count>
        </format>
        <keywords>
            <kw>SFVLAN</kw>
            <kw>switching</kw>
            <kw>data packets</kw>
            <kw>vitrual LANs</kw>
        </keywords>
        <abstract>Cabletron's SecureFast VLAN (SFVLAN) product implements a distributed connection-oriented switching protocol that provides fast forwarding of data packets at the MAC layer. The product uses the concept of virtual LANs (VLANs) to determine the validity of call connection requests and to scope the broadcast of certain flooded messages. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2644</doc-id>
        <title>Changing the Default for Directed Broadcasts in Routers</title>
        <author>
            <name>D. Senie</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6820</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>smurf</kw>
            <kw>amplifiers</kw>
            <kw>denial of service</kw>
        </keywords>
        <abstract>This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. This memo provides information for the Internet community. </abstract>
        <draft>senie-directed-broadcast-03</draft>
        <updates>
            <doc-id>RFC1812</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0034</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2645</doc-id>
        <title>ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16302</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>ODMR-SMTP</kw>
            <kw>simple mail</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>internet</kw>
        </keywords>
        <abstract>This memo proposes a new service, On-Demand Mail Relay (ODMR), which is a profile of SMTP, providing for a secure, extensible, easy to implement approach to the problem. [STANDARDS-TRACK] </abstract>
        <draft>gellens-on-demand-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2646</doc-id>
        <title>The Text/Plain Format Parameter</title>
        <author>
            <name>R. Gellens</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29175</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>media type</kw>
            <kw>mime</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extension</kw>
        </keywords>
        <abstract>This memo proposes a new parameter to be used with Text/Plain, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain. [STANDARDS-TRACK] </abstract>
        <draft>gellens-format-06</draft>
        <obsoleted-by>
            <doc-id>RFC3676</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2046</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2647</doc-id>
        <title>Benchmarking Terminology for Firewall Performance</title>
        <author>
            <name>D. Newman</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45374</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>routers</kw>
            <kw>switches</kw>
            <kw>measurement</kw>
        </keywords>
        <abstract>This document defines terms used in measuring the performance of firewalls. It extends the terminology already used for benchmarking routers and switches with definitions specific to firewalls. [STANDARDS-TRACK] </abstract>
        <draft>ietf-bmwg-secperf-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2648</doc-id>
        <title>A URN Namespace for IETF Documents</title>
        <author>
            <name>R. Moats</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46826</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>names</kw>
            <kw>internet</kw>
            <kw>engineering</kw>
            <kw>task</kw>
            <kw>force</kw>
        </keywords>
        <abstract>This document proposes the "ietf" namespace, which consists of the RFC family of documents (RFCs, STDs, FYIs, and BCPs) developed by the IETF and published by the RFC Editor and the minutes of working groups (WG) and birds of a feather (BOF) meetings that occur during IETF conferences. [STANDARDS-TRACK] </abstract>
        <draft>ietf-urn-ietf-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2649</doc-id>
        <title>An LDAP Control and Schema for Holding Operation Signatures</title>
        <author>
            <name>B. Greenblatt</name>
        </author>
        <author>
            <name>P. Richard</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20470</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access protocol</kw>
            <kw>client</kw>
            <kw>server</kw>
        </keywords>
        <abstract>This document describes an LDAP message control which allows for the retrieval of digitally signed information. This document defines an LDAP v3 based mechanism for signing directory operations in order to create a secure journal of changes that have been made to each directory entry. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-ldapext-sigops-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2650</doc-id>
        <title>Using RPSL in Practice</title>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>J. Schmitz</name>
        </author>
        <author>
            <name>C. Orange</name>
        </author>
        <author>
            <name>M. Prior</name>
        </author>
        <author>
            <name>C. Alaettinoglu</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>55272</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>routing policy</kw>
            <kw>specification language</kw>
            <kw>IRR</kw>
            <kw>internet routing</kw>
            <kw>registry</kw>
            <kw>configurations</kw>
        </keywords>
        <abstract>This document is a tutorial on using the Routing Policy Specification Language (RPSL) to describe routing policies in the Internet Routing Registry (IRR). This memo provides information for the Internet community. </abstract>
        <draft>ietf-rps-appl-rpsl-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2651</doc-id>
        <title>The Architecture of the Common Indexing Protocol (CIP)</title>
        <author>
            <name>J. Allen</name>
        </author>
        <author>
            <name>M. Mealling</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41933</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>CIP</kw>
            <kw>query</kw>
            <kw>routing</kw>
            <kw>database</kw>
            <kw>servers</kw>
        </keywords>
        <abstract>This document describes the CIP framework, including its architecture and the protocol specifics of exchanging indices. [STANDARDS-TRACK] </abstract>
        <draft>ietf-find-cip-arch-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2652</doc-id>
        <title>MIME Object Definitions for the Common Indexing Protocol (CIP)</title>
        <author>
            <name>J. Allen</name>
        </author>
        <author>
            <name>M. Mealling</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42464</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>database</kw>
        </keywords>
        <abstract>This document describes the definitions of those objects as well as the methods and requirements needed to define a new index type. [STANDARDS-TRACK] </abstract>
        <draft>ietf-find-cip-mime-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2653</doc-id>
        <title>CIP Transport Protocols</title>
        <author>
            <name>J. Allen</name>
        </author>
        <author>
            <name>P. Leach</name>
        </author>
        <author>
            <name>R. Hedberg</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22999</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>common indexing</kw>
            <kw>message</kw>
            <kw>formats</kw>
        </keywords>
        <abstract>This document specifies three protocols for transporting CIP requests, responses and index objects, utilizing TCP, mail, and HTTP. [STANDARDS-TRACK] </abstract>
        <draft>ietf-find-cip-trans-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2654</doc-id>
        <title>A Tagged Index Object for use in the Common Indexing Protocol</title>
        <author>
            <name>R. Hedberg</name>
        </author>
        <author>
            <name>B. Greenblatt</name>
        </author>
        <author>
            <name>R. Moats</name>
        </author>
        <author>
            <name>M. Wahl</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46739</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>CIP</kw>
            <kw>information</kw>
            <kw>servers</kw>
            <kw>database</kw>
        </keywords>
        <abstract>This document defines a mechanism by which information servers can exchange indices of information from their databases by making use of the Common Indexing Protocol (CIP). This document defines the structure of the index information being exchanged, as well as the appropriate meanings for the headers that are defined in the Common Indexing Protocol. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-find-cip-tagged-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2655</doc-id>
        <title>CIP Index Object Format for SOIF Objects</title>
        <author>
            <name>T. Hardie</name>
        </author>
        <author>
            <name>M. Bowman</name>
        </author>
        <author>
            <name>D. Hardy</name>
        </author>
        <author>
            <name>M. Schwartz</name>
        </author>
        <author>
            <name>D. Wessels</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34285</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>summary</kw>
            <kw>object</kw>
            <kw>interchange</kw>
            <kw>format</kw>
            <kw>common</kw>
            <kw>indexing</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document describes SOIF, the Summary Object Interchange Format, as an index object type in the context of the CIP framework. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-find-cip-soif-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2656</doc-id>
        <title>Registration Procedures for SOIF Template Types</title>
        <author>
            <name>T. Hardie</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17409</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>summary</kw>
            <kw>object</kw>
            <kw>interchange</kw>
            <kw>format</kw>
            <kw>stream</kw>
        </keywords>
        <abstract>The registration procedure described in this document is specific to SOIF template types. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-find-soif-registry-00</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2657</doc-id>
        <title>LDAPv2 Client vs. the Index Mesh</title>
        <author>
            <name>R. Hedberg</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19251</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>CIP</kw>
            <kw>common</kw>
            <kw>indexing</kw>
        </keywords>
        <abstract>LDAPv2 clients as implemented according to RFC 1777 have no notion on referral. The integration between such a client and an Index Mesh, as defined by the Common Indexing Protocol, heavily depends on referrals and therefore needs to be handled in a special way. This document defines one possible way of doing this. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-find-cip-ldapv2-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2658</doc-id>
        <title>RTP Payload Format for PureVoice(tm) Audio</title>
        <author>
            <name>K. McKay</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21895</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>real-time</kw>
            <kw>transport</kw>
            <kw>protocol</kw>
            <kw>packet</kw>
            <kw>end-to-end</kw>
        </keywords>
        <abstract>This document describes the RTP payload format for PureVoice(tm) Audio. [STANDARDS-TRACK] </abstract>
        <draft>mckay-qcelp-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2659</doc-id>
        <title>Security Extensions For HTML</title>
        <author>
            <name>E. Rescorla</name>
        </author>
        <author>
            <name>A. Schiffman</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8134</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>hyper-text</kw>
            <kw>markup language</kw>
            <kw>cryptology</kw>
        </keywords>
        <abstract>This memo describes a syntax for embedding S-HTTP negotiation parameters in HTML documents. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-wts-shtml-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2660</doc-id>
        <title>The Secure HyperText Transfer Protocol</title>
        <author>
            <name>E. Rescorla</name>
        </author>
        <author>
            <name>A. Schiffman</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>95645</char-count>
            <page-count>45</page-count>
        </format>
        <keywords>
            <kw>WWW</kw>
            <kw>world wide web</kw>
            <kw>http</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This memo describes a syntax for securing messages sent using the Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-wts-shttp-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2661</doc-id>
        <title>Layer Two Tunneling Protocol "L2TP"</title>
        <author>
            <name>W. Townsley</name>
        </author>
        <author>
            <name>A. Valencia</name>
        </author>
        <author>
            <name>A. Rubens</name>
        </author>
        <author>
            <name>G. Pall</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>B. Palter</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>168150</char-count>
            <page-count>80</page-count>
        </format>
        <keywords>
            <kw>L2TP</kw>
            <kw>ppp</kw>
            <kw>point-to-point</kw>
            <kw>protocol</kw>
            <kw>packets</kw>
        </keywords>
        <abstract>This document describes the Layer Two Tunneling Protocol (L2TP). [STANDARDS-TRACK] </abstract>
        <draft>ietf-pppext-l2tp-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2662</doc-id>
        <title>Definitions of Managed Objects for the ADSL Lines</title>
        <author>
            <name>G. Bathrick</name>
        </author>
        <author>
            <name>F. Ly</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>247122</char-count>
            <page-count>115</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>management information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This document defines a standard SNMP MIB for ADSL lines based on the ADSL Forum standard data model. [STANDARDS-TRACK] </abstract>
        <draft>ietf-adslmib-adsllinemib-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2663</doc-id>
        <title>IP Network Address Translator (NAT) Terminology and Considerations</title>
        <author>
            <name>P. Srisuresh</name>
        </author>
        <author>
            <name>M. Holdrege</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>72265</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>network address</kw>
            <kw>translator</kw>
            <kw>IP</kw>
            <kw>internet protocol</kw>
            <kw>addresses </kw>
        </keywords>
        <abstract>This document attempts to describe the operation of NAT devices and the associated considerations in general, and to define the terminology used to identify various flavors of NAT. This memo provides information for the Internet community. </abstract>
        <draft>ietf-nat-terminology-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2664</doc-id>
        <title>FYI on Questions and Answers - Answers to Commonly Asked "New Internet User" Questions</title>
        <author>
            <name>R. Plzak</name>
        </author>
        <author>
            <name>A. Wells</name>
        </author>
        <author>
            <name>E. Krol</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23640</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>documentation</kw>
            <kw>help</kw>
            <kw>information</kw>
            <kw>FAQ</kw>
        </keywords>
        <abstract>This memo provides an overview to the new Internet User. The intended audience is the common Internet user of today, thus it attempts to provide a more consumer oriented approach to the Internet rather than going into any depth about a topic. This memo provides information for the Internet community. </abstract>
        <draft>ietf-uswg-fyi4-bis-01</draft>
        <obsoletes>
            <doc-id>RFC1594</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>FYI0004</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2665</doc-id>
        <title>Definitions of Managed Objects for the Ethernet-like Interface Types</title>
        <author>
            <name>J. Flick</name>
        </author>
        <author>
            <name>J. Johnson</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>110038</char-count>
            <page-count>47</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK] </abstract>
        <draft>ietf-hubmib-etherif-mib-v2-04</draft>
        <obsoletes>
            <doc-id>RFC2358</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3635</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2666</doc-id>
        <title>Definitions of Object Identifiers for Identifying Ethernet Chip Sets</title>
        <author>
            <name>J. Flick</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37699</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines OBJECT IDENTIFIER values for use with network management protocols in the Internet community. This memo provides information for the Internet community. </abstract>
        <draft>ietf-hubmib-ether-chipsets-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2667</doc-id>
        <title>IP Tunnel MIB</title>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32770</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 networks. [STANDARDS-TRACK] </abstract>
        <draft>ietf-ifmib-tunnel-mib-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2668</doc-id>
        <title>Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)</title>
        <author>
            <name>A. Smith</name>
        </author>
        <author>
            <name>J. Flick</name>
        </author>
        <author>
            <name>K. de Graaf</name>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <author>
            <name>D. McMaster</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>S. Roberts</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>121843</char-count>
            <page-count>56</page-count>
        </format>
        <keywords>
            <kw>MAU-MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK] </abstract>
        <draft>ietf-hubmib-mau-mib-v2-04</draft>
        <obsoletes>
            <doc-id>RFC2239</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3636</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2669</doc-id>
        <title>DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems</title>
        <author>
            <name>M. St. Johns</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>112880</char-count>
            <page-count>55</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based management of DOCSIS 1.0 compliant Cable Modems and Cable Modem Termination Systems. [STANDARDS-TRACK] </abstract>
        <draft>ietf-ipcdn-rf-interface-mib-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2670</doc-id>
        <title>Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces</title>
        <author>
            <name>M. St. Johns</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>141077</char-count>
            <page-count>72</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based management of MCNS/DOCSIS compliant Radio Frequency (RF) interfaces. [STANDARDS-TRACK] </abstract>
        <draft>ietf-ipcdn-cable-device-mib-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2671</doc-id>
        <title>Extension Mechanisms for DNS (EDNS0)</title>
        <author>
            <name>P. Vixie</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15257</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>EDNS0</kw>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>resource</kw>
            <kw>records</kw>
            <kw>opt</kw>
        </keywords>
        <abstract>The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow. [STANDARDS-TRACK] </abstract>
        <draft>ietf-dnsind-edns0-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2672</doc-id>
        <title>Non-Terminal DNS Name Redirection</title>
        <author>
            <name>M. Crawford</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18321</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>dname</kw>
            <kw>resource</kw>
            <kw>records</kw>
        </keywords>
        <abstract>This document defines a new DNS Resource Record called "DNAME", which provides the capability to map an entire subtree of the DNS name space to another domain. [STANDARDS-TRACK] </abstract>
        <draft>ietf-dnsind-dname-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2673</doc-id>
        <title>Binary Labels in the Domain Name System</title>
        <author>
            <name>M. Crawford</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12379</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>DNS</kw>
            <kw>data</kw>
        </keywords>
        <abstract>This document defines a "Bit-String Label" which may appear within domain names. This new label type compactly represents a sequence of "One-Bit Labels" and enables resource records to be stored at any bit- boundary in a binary-named section of the domain name tree. [STANDARDS-TRACK] </abstract>
        <draft>ietf-dnsind-binary-labels-05</draft>
        <updated-by>
            <doc-id>RFC3363</doc-id>
            <doc-id>RFC3364</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2674</doc-id>
        <title>Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions</title>
        <author>
            <name>E. Bell</name>
        </author>
        <author>
            <name>A. Smith</name>
        </author>
        <author>
            <name>P. Langille</name>
        </author>
        <author>
            <name>A. Rijhsinghani</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>159971</char-count>
            <page-count>86</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>local</kw>
            <kw>area</kw>
            <kw>network</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. [STANDARDS-TRACK] </abstract>
        <draft>ietf-bridge-bridgemib-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2675</doc-id>
        <title>IPv6 Jumbograms</title>
        <author>
            <name>D. Borman</name>
        </author>
        <author>
            <name>S. Deering</name>
        </author>
        <author>
            <name>R. Hinden</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17320</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>packet</kw>
            <kw>payload</kw>
            <kw>link</kw>
        </keywords>
        <abstract>This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths. It also describes the changes needed to TCP and UDP to make use of jumbograms. [STANDARDS-TRACK] </abstract>
        <draft>ietf-ipngwg-jumbograms-01</draft>
        <obsoletes>
            <doc-id>RFC2147</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2676</doc-id>
        <title>QoS Routing Mechanisms and OSPF Extensions</title>
        <author>
            <name>G. Apostolopoulos</name>
        </author>
        <author>
            <name>S. Kama</name>
        </author>
        <author>
            <name>D. Williams</name>
        </author>
        <author>
            <name>R. Guerin</name>
        </author>
        <author>
            <name>A. Orda</name>
        </author>
        <author>
            <name>T. Przygienda</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>124563</char-count>
            <page-count>50</page-count>
        </format>
        <keywords>
            <kw>quality of service</kw>
            <kw>open shortest</kw>
            <kw>path first</kw>
            <kw>routing</kw>
        </keywords>
        <abstract>This memo describes extensions to the OSPF protocol to support QoS routes. The focus of this document is on the algorithms used to compute QoS routes and on the necessary modifications to OSPF to support this function, e.g., the information needed, its format, how it is distributed, and how it is used by the QoS path selection process. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>guerin-qos-routing-ospf-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2677</doc-id>
        <title>Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP)</title>
        <author>
            <name>M. Greene</name>
        </author>
        <author>
            <name>J. Cucchiara</name>
        </author>
        <author>
            <name>J. Luciani</name>
        </author>
        <date>
            <month>August</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>129699</char-count>
            <page-count>67</page-count>
        </format>
        <keywords>
            <kw>NHRP-MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK] </abstract>
        <draft>ietf-ion-nhrp-mib-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2678</doc-id>
        <title>IPPM Metrics for Measuring Connectivity</title>
        <author>
            <name>J. Mahdavi</name>
        </author>
        <author>
            <name>V. Paxson</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18087</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>IPPM-MET</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>performance</kw>
            <kw>metrics</kw>
        </keywords>
        <abstract>This memo defines a series of metrics for connectivity between a pair of Internet hosts. [STANDARDS-TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2498</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2679</doc-id>
        <title>A One-way Delay Metric for IPPM</title>
        <author>
            <name>G. Almes</name>
        </author>
        <author>
            <name>S. Kalidindi</name>
        </author>
        <author>
            <name>M. Zekauskas</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43542</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>performance</kw>
            <kw>metrics</kw>
            <kw>packets</kw>
        </keywords>
        <abstract>This memo defines a metric for one-way delay of packets across Internet paths. [STANDARDS-TRACK] </abstract>
        <draft>ietf-ippm-delay-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2680</doc-id>
        <title>A One-way Packet Loss Metric for IPPM</title>
        <author>
            <name>G. Almes</name>
        </author>
        <author>
            <name>S. Kalidindi</name>
        </author>
        <author>
            <name>M. Zekauskas</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32266</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>performance</kw>
            <kw>metrics</kw>
        </keywords>
        <abstract>This memo defines a metric for one-way packet loss across Internet paths. [STANDARDS-TRACK] </abstract>
        <draft>ietf-ippm-loss-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2681</doc-id>
        <title>A Round-trip Delay Metric for IPPM</title>
        <author>
            <name>G. Almes</name>
        </author>
        <author>
            <name>S. Kalidindi</name>
        </author>
        <author>
            <name>M. Zekauskas</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44357</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>performance</kw>
            <kw>metrics</kw>
            <kw>packets</kw>
        </keywords>
        <abstract>This memo defines a metric for round-trip delay of packets across Internet paths. [STANDARDS-TRACK] </abstract>
        <draft>ietf-ippm-rt-delay-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2682</doc-id>
        <title>Performance Issues in VC-Merge Capable ATM LSRs</title>
        <author>
            <name>I. Widjaja</name>
        </author>
        <author>
            <name>A. Elwalid</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29491</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>asynchronous</kw>
            <kw>transfer mode</kw>
            <kw>routing</kw>
        </keywords>
        <abstract>This document investigates the impact of VC merging on the additional buffer required for the reassembly buffers and other buffers. This memo provides information for the Internet community. </abstract>
        <draft>widjaja-mpls-vc-merge-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2683</doc-id>
        <title>IMAP4 Implementation Recommendations</title>
        <author>
            <name>B. Leiba</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>56300</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>message</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>clients</kw>
            <kw>servers</kw>
        </keywords>
        <abstract>The IMAP4 specification describes a rich protocol for use in building clients and servers for storage, retrieval, and manipulation of electronic mail. Because the protocol is so rich and has so many implementation choices, there are often trade-offs that must be made and issues that must be considered when designing such clients and servers. This document attempts to outline these issues and to make recommendations in order to make the end products as interoperable as possible. This memo provides information for the Internet community. </abstract>
        <draft>leiba-imap-implement-guide-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2684</doc-id>
        <title>Multiprotocol Encapsulation over ATM Adaptation Layer 5</title>
        <author>
            <name>D. Grossman</name>
        </author>
        <author>
            <name>J. Heinanen</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51390</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>asynchronous,transfer</kw>
            <kw>mode</kw>
            <kw>multiplexing</kw>
        </keywords>
        <abstract>This memo replaces RFC 1483. It describes two encapsulations methods for carrying network interconnect traffic over AAL type 5 over ATM. [STANDARDS-TRACK] </abstract>
        <draft>ietf-ion-multiprotocol-atm-04</draft>
        <obsoletes>
            <doc-id>RFC1483</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2685</doc-id>
        <title>Virtual Private Networks Identifier</title>
        <author>
            <name>B. Fox</name>
        </author>
        <author>
            <name>B. Gleeson</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11168</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>VPNI</kw>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>VPN</kw>
        </keywords>
        <abstract>This document proposes a format for a globally unique VPN identifier. [STANDARDS-TRACK] </abstract>
        <draft>ietf-ion-vpn-id-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2686</doc-id>
        <title>The Multi-Class Extension to Multi-Link PPP</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24192</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>point-to-point protocol</kw>
            <kw>encapsulation</kw>
        </keywords>
        <abstract>This document proposes the fragment-oriented solution for the real-time encapsulation format part of the architecture. [STANDARDS-TRACK] </abstract>
        <draft>ietf-issll-isslow-mcml-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2687</doc-id>
        <title>PPP in a Real-time Oriented HDLC-like Framing</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28699</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>point-to-point protocol</kw>
            <kw>encapsulation</kw>
            <kw>high-level</kw>
            <kw>data link</kw>
            <kw>control</kw>
        </keywords>
        <abstract>This document proposes the suspend/resume-oriented solution for the real-time encapsulation format part of the architecture. [STANDARDS- TRACK] </abstract>
        <draft>ietf-issll-isslow-rtf-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2688</doc-id>
        <title>Integrated Services Mappings for Low Speed Networks</title>
        <author>
            <name>S. Jackowski</name>
        </author>
        <author>
            <name>D. Putzolu</name>
        </author>
        <author>
            <name>E. Crawley</name>
        </author>
        <author>
            <name>B. Davie</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36685</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>controlled</kw>
            <kw>load</kw>
            <kw>guaranteed</kw>
            <kw>services</kw>
        </keywords>
        <abstract>This document defines the service mappings of the IETF Integrated Services for low-bitrate links, specifically the controlled load and guaranteed services. [STANDARDS-TRACK] </abstract>
        <draft>ietf-issll-isslow-svcmap-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2689</doc-id>
        <title>Providing Integrated Services over Low-bitrate Links</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34345</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>asynchronous</kw>
            <kw>synchronous</kw>
            <kw>real-time</kw>
        </keywords>
        <abstract>This document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B-channels, and sub-T1 links. This memo provides information for the Internet community. </abstract>
        <draft>ietf-issll-isslow-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2690</doc-id>
        <title>A Proposal for an MOU-Based ICANN Protocol Support Organization</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14221</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>pso</kw>
            <kw>memorandum of understanding</kw>
            <kw>internet</kw>
            <kw>corporation for assigned names and numbers</kw>
        </keywords>
        <abstract>This is a copy of the proposal for an MOU-based Protocol Supporting Organization that was submitted to ICANN on April 23, 1999. This memo provides information for the Internet community. </abstract>
        <draft>ietf-poisson-pso-mou-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2691</doc-id>
        <title>A Memorandum of Understanding for an ICANN Protocol Support Organization</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18940</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>mou</kw>
            <kw>pso</kw>
            <kw>internet</kw>
            <kw>corporation for assigned names and numbers</kw>
        </keywords>
        <abstract>This is the text of the Memorandum of Understanding (MoU) that was signed by ICANN, the IETF, the ITU-T, W3C and ETSI on July 14, 1999 in Oslo. This MoU creates the Protocol Support Organization (PSO) within the Internet Corporation for Assigned Names and Numbers (ICANN). This memo provides information for the Internet community. </abstract>
        <draft>ietf-poisson-mou-pso-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2692</doc-id>
        <title>SPKI Requirements</title>
        <author>
            <name>C. Ellison</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29569</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>SPKI</kw>
            <kw>simple public</kw>
            <kw>key</kw>
            <kw>infrastructure</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>The SPKI Working Group first established a list of things one might want to do with certificates (attached at the end of this document), and then summarized that list of desires into requirements. This document presents that summary of requirements. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-spki-cert-req-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2693</doc-id>
        <title>SPKI Certificate Theory</title>
        <author>
            <name>C. Ellison</name>
        </author>
        <author>
            <name>B. Frantz</name>
        </author>
        <author>
            <name>B. Lampson</name>
        </author>
        <author>
            <name>R. Rivest</name>
        </author>
        <author>
            <name>B. Thomas</name>
        </author>
        <author>
            <name>T. Ylonen</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>96699</char-count>
            <page-count>43</page-count>
        </format>
        <keywords>
            <kw>SPKI</kw>
            <kw>simple</kw>
            <kw>public</kw>
            <kw>key</kw>
            <kw>infrastructure</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This document gives the theory behind SPKI certificates and ACLs without going into technical detail about those structures or their uses. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-spki-cert-theory-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2694</doc-id>
        <title>DNS extensions to Network Address Translators (DNS_ALG)</title>
        <author>
            <name>P. Srisuresh</name>
        </author>
        <author>
            <name>G. Tsirtsis</name>
        </author>
        <author>
            <name>P. Akkiraju</name>
        </author>
        <author>
            <name>A. Heffernan</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>67720</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>domain name</kw>
            <kw>system</kw>
            <kw>NATs</kw>
            <kw>mapping</kw>
        </keywords>
        <abstract>This document identifies the need for DNS extensions to NATs and outlines how a DNS Application Level Gateway (DNS_ALG) can meet the need. This memo provides information for the Internet community. </abstract>
        <draft>ietf-nat-dns-alg-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2695</doc-id>
        <title>Authentication Mechanisms for ONC RPC</title>
        <author>
            <name>A. Chiu</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39286</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>remote procedure</kw>
            <kw>call</kw>
            <kw>open network</kw>
            <kw>computing</kw>
        </keywords>
        <abstract>This document describes two authentication mechanisms created by Sun Microsystems that are commonly used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocol. This memo provides information for the Internet community. </abstract>
        <draft>ietf-oncrpc-auth-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2696</doc-id>
        <title>LDAP Control Extension for Simple Paged Results Manipulation</title>
        <author>
            <name>C. Weider</name>
        </author>
        <author>
            <name>A. Herron</name>
        </author>
        <author>
            <name>A. Anantha</name>
        </author>
        <author>
            <name>T. Howes</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12809</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>client</kw>
            <kw>server</kw>
        </keywords>
        <abstract>This document describes an LDAPv3 control extension for simple paging of search results. This memo provides information for the Internet community. </abstract>
        <draft>ietf-asid-ldapv3-simplepaged-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2697</doc-id>
        <title>A Single Rate Three Color Marker</title>
        <author>
            <name>J. Heinanen</name>
        </author>
        <author>
            <name>R. Guerin</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10309</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>srtcm</kw>
            <kw>stream</kw>
            <kw>ip</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>packet</kw>
        </keywords>
        <abstract>This document defines a Single Rate Three Color Marker (srTCM), which can be used as component in a Diffserv traffic conditioner. This memo provides information for the Internet community. </abstract>
        <draft>heinanen-diffserv-srtcm-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2698</doc-id>
        <title>A Two Rate Three Color Marker</title>
        <author>
            <name>J. Heinanen</name>
        </author>
        <author>
            <name>R. Guerin</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9368</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>trTCM</kw>
            <kw>stream</kw>
            <kw>ip</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>packet</kw>
        </keywords>
        <abstract>This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner. This memo provides information for the Internet community. </abstract>
        <draft>heinanen-diffserv-trtcm-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2699</doc-id>
        <title>Request for Comments Summary RFC Numbers 2600-2699</title>
        <author>
            <name>S. Ginoza</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42462</char-count>
            <page-count>22</page-count>
        </format>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2700</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Reynolds</name>
        </author>
        <author>
            <name>R. Braden</name>
        </author>
        <date>
            <month>August</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>90213</char-count>
            <page-count>32</page-count>
        </format>
        <abstract>This memo describes the current state of standardization of protocols used in the Internet as determined by the Internet Engineering Task Force (IETF). [STANDARDS TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2600</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2800</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2701</doc-id>
        <title>Nortel Networks Multi-link Multi-node PPP Bundle Discovery Protocol</title>
        <author>
            <name>G. Malkin</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17571</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>point-to-point</kw>
            <kw>POP</kw>
            <kw>presence</kw>
            <kw>RAS</kw>
            <kw>remote access</kw>
            <kw>server</kw>
        </keywords>
        <abstract>This document specifies a standard way for Multi-link PPP to operate across multiple nodes. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2702</doc-id>
        <title>Requirements for Traffic Engineering Over MPLS</title>
        <author>
            <name>D. Awduche</name>
        </author>
        <author>
            <name>J. Malcolm</name>
        </author>
        <author>
            <name>J. Agogbua</name>
        </author>
        <author>
            <name>M. O'Dell</name>
        </author>
        <author>
            <name>J. McManus</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>68386</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>multiprotocol</kw>
            <kw>label</kw>
            <kw>switching</kw>
        </keywords>
        <abstract>This document presents a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS). It identifies the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. This memo provides information for the Internet community. </abstract>
        <draft>ietf-mpls-traffic-eng-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2703</doc-id>
        <title>Protocol-independent Content Negotiation Framework</title>
        <author>
            <name>G. Klyne</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42071</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>feature</kw>
            <kw>resource</kw>
            <kw>media</kw>
            <kw>syntax</kw>
        </keywords>
        <abstract>This memo sets out terminology, an abstract framework and goals for protocol-independent content negotiation, and identifies some technical issues which may need to be addressed. This memo provides information for the Internet community. </abstract>
        <draft>ietf-conneg-requirements-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2704</doc-id>
        <title>The KeyNote Trust-Management System Version 2</title>
        <author>
            <name>M. Blaze</name>
        </author>
        <author>
            <name>J. Feigenbaum</name>
        </author>
        <author>
            <name>J. Ioannidis</name>
        </author>
        <author>
            <name>A. Keromytis</name>
        </author>
        <date>
            <month>September</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>79998</char-count>
            <page-count>37</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>policy maker</kw>
            <kw>system</kw>
            <kw>credentials</kw>
        </keywords>
        <abstract>This memo describes version 2 of the KeyNote trust-management system.It specifies the syntax and semantics of KeyNote `assertions', describes `action attribute' processing, and outlines the application architecture into which a KeyNote implementation can be fit. This memo provides information for the Internet community. </abstract>
        <draft>blaze-ietf-trustmgt-keynote-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2705</doc-id>
        <title>Media Gateway Control Protocol (MGCP) Version 1.0</title>
        <author>
            <name>M. Arango</name>
        </author>
        <author>
            <name>A. Dugan</name>
        </author>
        <author>
            <name>I. Elliott</name>
        </author>
        <author>
            <name>C. Huitema</name>
        </author>
        <author>
            <name>S. Pickett</name>
        </author>
        <date>
            <month>October</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>304056</char-count>
            <page-count>134</page-count>
        </format>
        <keywords>
            <kw>voice</kw>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>VoIP</kw>
        </keywords>
        <abstract>This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP) Gateways from external call control elements. MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled by external call control elements. This memo provides information for the Internet community. </abstract>
        <draft>huitema-megaco-mgcp-v1-00</draft>
        <obsoleted-by>
            <doc-id>RFC3435</doc-id>
        </obsoleted-by>
        <updated-by>
            <doc-id>RFC3660</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2706</doc-id>
        <title>ECML v1: Field Names for E-Commerce</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>T. Goldstein</name>
        </author>
        <date>
            <month>October</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26135</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>electronic</kw>
            <kw>commerce</kw>
            <kw>modeling</kw>
            <kw>language</kw>
            <kw>merchant</kw>
            <kw>site. web</kw>
        </keywords>
        <abstract>A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. This memo provides information for the Internet community. </abstract>
        <draft>eastlake-ecom-fields-01</draft>
        <obsoleted-by>
            <doc-id>RFC3106</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2707</doc-id>
        <title>Job Monitoring MIB - V1.0</title>
        <author>
            <name>R. Bergman</name>
        </author>
        <author>
            <name>T. Hastings</name>
        </author>
        <author>
            <name>S. Isaacson</name>
        </author>
        <author>
            <name>H. Lewis</name>
        </author>
        <date>
            <month>November</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>255685</char-count>
            <page-count>114</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This document provides a printer industry standard SNMP MIB for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job. This memo provides information for the Internet community. </abstract>
        <draft>ietf-printmib-job-monitor-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2708</doc-id>
        <title>Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB</title>
        <author>
            <name>R. Bergman</name>
        </author>
        <date>
            <month>November</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>57489</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This document defines the recommended mapping for many currently popular Job submission protocols to objects and attributes in the Job Monitoring MIB. This memo provides information for the Internet community. </abstract>
        <draft>ietf-printmib-job-protomap-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2709</doc-id>
        <title>Security Model with Tunnel-mode IPsec for NAT Domains</title>
        <author>
            <name>P. Srisuresh</name>
        </author>
        <date>
            <month>October</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24552</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>internet protocol</kw>
            <kw>network address</kw>
            <kw>translator</kw>
        </keywords>
        <abstract>This document describes a security model by which tunnel-mode IPsec security can be architected on NAT devices. This memo provides information for the Internet community. </abstract>
        <draft>ietf-nat-security-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2710</doc-id>
        <title>Multicast Listener Discovery (MLD) for IPv6</title>
        <author>
            <name>S. Deering</name>
        </author>
        <author>
            <name>W. Fenner</name>
        </author>
        <author>
            <name>B. Haberman</name>
        </author>
        <date>
            <month>October</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46838</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>MLD-IPv6</kw>
            <kw>internet protocol</kw>
            <kw>routher</kw>
            <kw>packets</kw>
        </keywords>
        <abstract>This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. [STANDARDS TRACK] </abstract>
        <draft>ietf-ipngwg-mld-02</draft>
        <updated-by>
            <doc-id>RFC3590</doc-id>
            <doc-id>RFC3810</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2711</doc-id>
        <title>IPv6 Router Alert Option</title>
        <author>
            <name>C. Partridge</name>
        </author>
        <author>
            <name>A. Jackson</name>
        </author>
        <date>
            <month>October</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11973</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>internet protocol</kw>
            <kw>datagram</kw>
            <kw>routher</kw>
            <kw>hop-by-hop</kw>
        </keywords>
        <abstract>This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. [STANDARDS TRACK] </abstract>
        <draft>ietf-ipngwg-ipv6router-alert-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2712</doc-id>
        <title>Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)</title>
        <author>
            <name>A. Medvinsky</name>
        </author>
        <author>
            <name>M. Hur</name>
        </author>
        <date>
            <month>October</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13763</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>TLS</kw>
            <kw>authentication</kw>
            <kw>cryptography</kw>
        </keywords>
        <abstract>This document proposes the addition of new cipher suites to the TLS protocol to support Kerberos-based authentication. [STANDARDS TRACK] </abstract>
        <draft>ietf-tls-kerb-cipher-suites-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2713</doc-id>
        <title>Schema for Representing Java(tm) Objects in an LDAP Directory</title>
        <author>
            <name>V. Ryan</name>
        </author>
        <author>
            <name>S. Seligman</name>
        </author>
        <author>
            <name>R. Lee</name>
        </author>
        <date>
            <month>October</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40745</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document defines the schema for representing Java(tm) objects in an LDAP directory. This memo provides information for the Internet community. </abstract>
        <draft>ryan-java-schema-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2714</doc-id>
        <title>Schema for Representing CORBA Object References in an LDAP Directory</title>
        <author>
            <name>V. Ryan</name>
        </author>
        <author>
            <name>R. Lee</name>
        </author>
        <author>
            <name>S. Seligman</name>
        </author>
        <date>
            <month>October</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14709</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document defines the schema for representing CORBA object references in an LDAP directory. This memo provides information for the Internet community. </abstract>
        <draft>ryan-corba-schema-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2715</doc-id>
        <title>Interoperability Rules for Multicast Routing Protocols</title>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>October</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49638</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>border</kw>
            <kw>router</kw>
            <kw>MBRs</kw>
            <kw>autonomous</kw>
        </keywords>
        <abstract>The rules described in this document will allow efficient interoperation among multiple independent multicast routing domains. This memo provides information for the Internet community. </abstract>
        <draft>thaler-multicast-interop-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2716</doc-id>
        <title>PPP EAP TLS Authentication Protocol</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>D. Simon</name>
        </author>
        <date>
            <month>October</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>50108</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>point-to-point</kw>
            <kw>link control compression</kw>
            <kw>extensible</kw>
            <kw>transport level security</kw>
        </keywords>
        <abstract>The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-pppext-eaptls-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2717</doc-id>
        <title>Registration Procedures for URL Scheme Names</title>
        <author>
            <name>R. Petke</name>
        </author>
        <author>
            <name>I. King</name>
        </author>
        <date>
            <month>November</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19780</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>locator</kw>
            <kw>syntax</kw>
            <kw>semantics</kw>
        </keywords>
        <abstract>This document defines the process by which new URL scheme names are registered. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-urlreg-procedures-08</draft>
        <is-also>
            <doc-id>BCP0035</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2718</doc-id>
        <title>Guidelines for new URL Schemes</title>
        <author>
            <name>L. Masinter</name>
        </author>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <author>
            <name>D. Zigmond</name>
        </author>
        <author>
            <name>R. Petke</name>
        </author>
        <date>
            <month>November</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19208</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>locator</kw>
            <kw>syntax</kw>
            <kw>semantics</kw>
        </keywords>
        <abstract>This document provides guidelines for the definition of new URL schemes. This memo provides information for the Internet community. </abstract>
        <draft>ietf-urlreg-guide-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2719</doc-id>
        <title>Framework Architecture for Signaling Transport</title>
        <author>
            <name>L. Ong</name>
        </author>
        <author>
            <name>I. Rytina</name>
        </author>
        <author>
            <name>M. Garcia</name>
        </author>
        <author>
            <name>H. Schwarzbauer</name>
        </author>
        <author>
            <name>L. Coene</name>
        </author>
        <author>
            <name>H. Lin</name>
        </author>
        <author>
            <name>I. Juhasz</name>
        </author>
        <author>
            <name>M. Holdrege</name>
        </author>
        <author>
            <name>C. Sharp</name>
        </author>
        <date>
            <month>October</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48646</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>IP</kw>
            <kw>Internet Protocol</kw>
            <kw>gateway</kw>
            <kw>media</kw>
            <kw>circuit</kw>
        </keywords>
        <abstract>This document defines an architecture framework and functional requirements for transport of signaling information over IP. This memo provides information for the Internet community. </abstract>
        <draft>ietf-sigtran-framework-arch-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2720</doc-id>
        <title>Traffic Flow Measurement: Meter MIB</title>
        <author>
            <name>N. Brownlee</name>
        </author>
        <date>
            <month>October</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>103781</char-count>
            <page-count>55</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This document defines a Management Information Base (MIB) for use in controlling an RTFM Traffic Meter, in particular for specifying the flows to be measured. It also provides an efficient mechanism for retrieving flow data from the meter using SNMP. Security issues concerning the operation of traffic meters are summarised. [STANDARDS TRACK] </abstract>
        <draft>ietf-rtfm-meter-mib-11</draft>
        <obsoletes>
            <doc-id>RFC2064</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2721</doc-id>
        <title>RTFM: Applicability Statement</title>
        <author>
            <name>N. Brownlee</name>
        </author>
        <date>
            <month>October</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21200</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>real-time</kw>
            <kw>traffic flow</kw>
            <kw>measurement</kw>
        </keywords>
        <abstract>This document provides an overview covering all aspects of Realtime Traffic Flow Measurement, including its area of applicability and its limitations. This memo provides information for the Internet community. </abstract>
        <draft>ietf-rtfm-applicability-statement</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2722</doc-id>
        <title>Traffic Flow Measurement: Architecture</title>
        <author>
            <name>N. Brownlee</name>
        </author>
        <author>
            <name>C. Mills</name>
        </author>
        <author>
            <name>G. Ruth</name>
        </author>
        <date>
            <month>October</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>114064</char-count>
            <page-count>48</page-count>
        </format>
        <keywords>
            <kw>network</kw>
            <kw>meters</kw>
            <kw>data</kw>
        </keywords>
        <abstract>This document provides a general framework for describing network traffic flows, presents an architecture for traffic flow measurement and reporting, discusses how this relates to an overall network traffic flow architecture and indicates how it can be used within the Internet. This memo provides information for the Internet community. </abstract>
        <draft>ietf-rtfm-architecture-08</draft>
        <obsoletes>
            <doc-id>RFC2063</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2723</doc-id>
        <title>SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups</title>
        <author>
            <name>N. Brownlee</name>
        </author>
        <date>
            <month>October</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44406</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>simple</kw>
            <kw>ruleset</kw>
            <kw>RTFM</kw>
            <kw>real-time</kw>
            <kw>network</kw>
            <kw>measurement</kw>
        </keywords>
        <abstract>This document describes a language for specifying rulesets, i.e. configuration files which may be loaded into a traffic flow meter so as to specify which traffic flows are measured by the meter, and the information it will store for each flow. This memo provides information for the Internet community. </abstract>
        <draft>ietf-rtfm-ruleset-language-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2724</doc-id>
        <title>RTFM: New Attributes for Traffic Flow Measurement</title>
        <author>
            <name>S. Handelman</name>
        </author>
        <author>
            <name>S. Stibler</name>
        </author>
        <author>
            <name>N. Brownlee</name>
        </author>
        <author>
            <name>G. Ruth</name>
        </author>
        <date>
            <month>October</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37951</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>real-time</kw>
            <kw>network</kw>
        </keywords>
        <abstract>This document discusses RTFM flows and the attributes which they can have, so as to provide a logical framework for extending the architecture by adding new attributes. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-rtfm-new-traffic-flow-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2725</doc-id>
        <title>Routing Policy System Security</title>
        <author>
            <name>C. Villamizar</name>
        </author>
        <author>
            <name>C. Alaettinoglu</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>S. Murphy</name>
        </author>
        <date>
            <month>December</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>101649</char-count>
            <page-count>41</page-count>
        </format>
        <keywords>
            <kw>RPSL</kw>
            <kw>database</kw>
            <kw>registry</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any operational use. This document addresses the need to assure integrity of the data by providing an authentication and authorization model. [STANDARDS TRACK] </abstract>
        <draft>ietf-rps-auth-04</draft>
        <updated-by>
            <doc-id>RFC4012</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2726</doc-id>
        <title>PGP Authentication for RIPE Database Updates</title>
        <author>
            <name>J. Zsako</name>
        </author>
        <date>
            <month>December</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22594</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>pretty good</kw>
            <kw>privacy</kw>
            <kw>security</kw>
            <kw>digital</kw>
            <kw>signatures</kw>
        </keywords>
        <abstract>This document presents the proposal for a stronger authentication method of the updates of the RIPE database based on digital signatures. [STANDARDS TRACK] </abstract>
        <draft>ietf-rps-dbsec-pgp-authent-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2727</doc-id>
        <title>IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees</title>
        <author>
            <name>J. Galvin</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33396</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Architecture</kw>
            <kw>Board</kw>
            <kw>Engineering</kw>
            <kw>Steering</kw>
            <kw>Group</kw>
        </keywords>
        <abstract>The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self- consistent, organized compilation of the process as it was known at the time of publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-poisson-nomcom-v2-01</draft>
        <obsoletes>
            <doc-id>RFC2282</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3777</doc-id>
        </obsoleted-by>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2728</doc-id>
        <title>The Transmission of IP Over the Vertical Blanking Interval of a Television Signal</title>
        <author>
            <name>R. Panabaker</name>
        </author>
        <author>
            <name>S. Wegerif</name>
        </author>
        <author>
            <name>D. Zigmond</name>
        </author>
        <date>
            <month>November</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49099</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>IPVBI</kw>
        </keywords>
        <abstract>This document describes a method for broadcasting IP data in a unidirectional manner using the vertical blanking interval of television signals. [STANDARDS TRACK] </abstract>
        <draft>ietf-ipvbi-nabts-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2729</doc-id>
        <title>Taxonomy of Communication Requirements for Large-scale Multicast Applications</title>
        <author>
            <name>P. Bagnall</name>
        </author>
        <author>
            <name>R. Briscoe</name>
        </author>
        <author>
            <name>A. Poppitt</name>
        </author>
        <date>
            <month>December</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53322</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>LSMA</kw>
            <kw>dynamic</kw>
            <kw>protocol</kw>
            <kw>mapping</kw>
        </keywords>
        <abstract>The intention of this memo is to define a classification system for the communication requirements of any large-scale multicast application (LSMA). This memo provides information for the Internet community. </abstract>
        <draft>ietf-lsma-requirements-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2730</doc-id>
        <title>Multicast Address Dynamic Client Allocation Protocol (MADCAP)</title>
        <author>
            <name>S. Hanna</name>
        </author>
        <author>
            <name>B. Patel</name>
        </author>
        <author>
            <name>M. Shah</name>
        </author>
        <date>
            <month>December</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>120341</char-count>
            <page-count>53</page-count>
        </format>
        <keywords>
            <kw>MADCAP</kw>
            <kw>client</kw>
            <kw>server</kw>
            <kw>scope</kw>
            <kw>zone</kw>
            <kw>host</kw>
        </keywords>
        <abstract>This document defines a protocol, Multicast Address Dynamic Client Allocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers. [STANDARDS TRACK] </abstract>
        <draft>ietf-malloc-madcap-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2731</doc-id>
        <title>Encoding Dublin Core Metadata in HTML</title>
        <author>
            <name>J. Kunze</name>
        </author>
        <date>
            <month>December</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42450</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>hypertext</kw>
            <kw>markup</kw>
            <kw>language</kw>
            <kw>xml</kw>
            <kw>extensible</kw>
        </keywords>
        <abstract>The Dublin Core is a small set of metadata elements for describing information resources. This document explains how these elements are expressed using the META and LINK tags of HTML. This memo provides information for the Internet community. </abstract>
        <draft>kunze-dchtml-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2732</doc-id>
        <title>Format for Literal IPv6 Addresses in URL's</title>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>L. Masinter</name>
        </author>
        <date>
            <month>December</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7984</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>protocol</kw>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>identifier</kw>
            <kw>www</kw>
            <kw>world wide web</kw>
        </keywords>
        <abstract>This document defines the format for literal IPv6 Addresses in URL's for implementation in World Wide Web browsers. [STANDARDS TRACK] </abstract>
        <draft>ietf-ipngwg-url-literal-04</draft>
        <obsoleted-by>
            <doc-id>RFC3986</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2396</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2733</doc-id>
        <title>An RTP Payload Format for Generic Forward Error Correction</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>December</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53120</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>FEC</kw>
            <kw>real-time</kw>
            <kw>protocol</kw>
            <kw>stream</kw>
        </keywords>
        <abstract>This document specifies a payload format for generic forward error correction of media encapsulated in RTP. [STANDARDS TRACK] </abstract>
        <draft>ietf-avt-fec-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2734</doc-id>
        <title>IPv4 over IEEE 1394</title>
        <author>
            <name>P. Johansson</name>
        </author>
        <date>
            <month>December</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>69314</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>datagrams</kw>
            <kw>packet</kw>
            <kw>encapsulation</kw>
            <kw>ARP</kw>
            <kw>address</kw>
            <kw>resolution</kw>
            <kw>multicast</kw>
        </keywords>
        <abstract>This document specifies how to use IEEE Std 1394-1995, Standard for a High Performance Serial Bus (and its supplements), for the transport of Internet Protocol Version 4 (IPv4) datagrams; it defines the necessary methods, data structures and codes for that purpose. [STANDARDS TRACK] </abstract>
        <draft>ietf-ip1394-ipv4-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2735</doc-id>
        <title>NHRP Support for Virtual Private Networks</title>
        <author>
            <name>B. Fox</name>
        </author>
        <author>
            <name>B. Petri</name>
        </author>
        <date>
            <month>December</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26451</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>next hop</kw>
            <kw>resolution</kw>
            <kw>protocol</kw>
            <kw>VPN</kw>
            <kw>addresses</kw>
        </keywords>
        <abstract>The NBMA Next Hop Resolution Protocol (NHRP) is used to determine the NBMA subnetwork addresses of the "NBMA next hop" towards a public internetworking layer address. This document describes the enhancements necessary to enable NHRP to perform the same function for private internetworking layer addresses available within the framework of a Virtual Private Network (VPN) service on a shared NBMA network. [STANDARDS TRACK] </abstract>
        <draft>ietf-ion-nhrp-vpn-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2736</doc-id>
        <title>Guidelines for Writers of RTP Payload Format Specifications</title>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>December</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24143</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>real-time</kw>
            <kw>transport</kw>
            <kw>protocol</kw>
            <kw>data types</kw>
            <kw>audio</kw>
            <kw>video</kw>
            <kw>codecs</kw>
        </keywords>
        <abstract>This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifications in deciding on good formats. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-avt-rtp-format-guidelines-04</draft>
        <is-also>
            <doc-id>BCP0036</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2737</doc-id>
        <title>Entity MIB (Version 2)</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>A. Bierman</name>
        </author>
        <date>
            <month>December</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>125141</char-count>
            <page-count>56</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>SNMP</kw>
            <kw>simple</kw>
            <kw>network</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (M for use with network management protocols in the Internet communi In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. [STANDARDS TRACK] </abstract>
        <draft>ietf-entmib-v2-06</draft>
        <obsoletes>
            <doc-id>RFC2037</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2738</doc-id>
        <title>Corrections to "A Syntax for Describing Media Feature Sets"</title>
        <author>
            <name>G. Klyne</name>
        </author>
        <date>
            <month>December</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8353</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>FEC</kw>
            <kw>real-time</kw>
            <kw>protocol</kw>
            <kw>stream</kw>
        </keywords>
        <abstract>In RFC 2533, "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags. This memo contains two corrections to that specification: one fixes an error in the formal syntax specification, and the other fixes an error in the rules for reducing feature comparison predicates. [STANDARDS TRACK] </abstract>
        <draft>ietf-conneg-feature-syntax-er-00</draft>
        <updates>
            <doc-id>RFC2533</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2739</doc-id>
        <title>Calendar Attributes for vCard and LDAP</title>
        <author>
            <name>T. Small</name>
        </author>
        <author>
            <name>D. Hennessy</name>
        </author>
        <author>
            <name>F. Dawson</name>
        </author>
        <date>
            <month>January</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25892</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo defines three mechanisms for obtaining a URI to a user's calendar and free/busy time. [STANDARDS TRACK] </abstract>
        <draft>ietf-calsch-locating-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2740</doc-id>
        <title>OSPF for IPv6</title>
        <author>
            <name>R. Coltun</name>
        </author>
        <author>
            <name>D. Ferguson</name>
        </author>
        <author>
            <name>J. Moy</name>
        </author>
        <date>
            <month>December</month>
            <year>1999</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>189810</char-count>
            <page-count>80</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>open shortest</kw>
            <kw>path first</kw>
        </keywords>
        <abstract>This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). [STANDARDS TRACK] </abstract>
        <draft>ietf-ispf-ospfv6-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2741</doc-id>
        <title>Agent Extensibility (AgentX) Protocol Version 1</title>
        <author>
            <name>M. Daniele</name>
        </author>
        <author>
            <name>B. Wijnen</name>
        </author>
        <author>
            <name>M. Ellison</name>
        </author>
        <author>
            <name>D. Francisco</name>
        </author>
        <date>
            <month>January</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>199867</char-count>
            <page-count>91</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
            <kw>simple</kw>
            <kw>network</kw>
            <kw>management</kw>
        </keywords>
        <abstract>This memo defines a standardized framework for extensible SNMP agents. [STANDARDS TRACK] </abstract>
        <draft>ietf-agentx-rfc-update-03</draft>
        <obsoletes>
            <doc-id>RFC2257</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2742</doc-id>
        <title>Definitions of Managed Objects for Extensible SNMP Agents</title>
        <author>
            <name>L. Heintz</name>
        </author>
        <author>
            <name>S. Gudur</name>
        </author>
        <author>
            <name>M. Ellison</name>
        </author>
        <date>
            <month>January</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36644</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>simple</kw>
            <kw>network</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects managing SNMP agents that use the Agent Extensibility (AgentX) Protocol. [STANDARDS TRACK] </abstract>
        <draft>ietf-agentx-mib-05</draft>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2743</doc-id>
        <title>Generic Security Service Application Program Interface Version 2, Update 1</title>
        <author>
            <name>J. Linn</name>
        </author>
        <date>
            <month>January</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>229418</char-count>
            <page-count>101</page-count>
        </format>
        <keywords>
            <kw>GSS-API</kw>
            <kw>portability</kw>
            <kw>application</kw>
            <kw>authentication</kw>
            <kw>cryptology</kw>
        </keywords>
        <abstract>This memo obsoletes [RFC-2078], making specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track. [STANDARDS TRACK] </abstract>
        <draft>ietf-cat-rfc2078bis-08</draft>
        <obsoletes>
            <doc-id>RFC2078</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2744</doc-id>
        <title>Generic Security Service API Version 2 : C-bindings</title>
        <author>
            <name>J. Wray</name>
        </author>
        <date>
            <month>January</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>218572</char-count>
            <page-count>101</page-count>
        </format>
        <keywords>
            <kw>GSS-API</kw>
            <kw>cryptology</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This document specifies C language bindings for Version 2, Update 1 of the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in RFC 2743. [STANDARDS TRACK] </abstract>
        <draft>ietf-cat-gssv2-cbind-09</draft>
        <obsoletes>
            <doc-id>RFC1509</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2745</doc-id>
        <title>RSVP Diagnostic Messages</title>
        <author>
            <name>A. Terzis</name>
        </author>
        <author>
            <name>B. Braden</name>
        </author>
        <author>
            <name>S. Vincent</name>
        </author>
        <author>
            <name>L. Zhang</name>
        </author>
        <date>
            <month>January</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52256</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
            <kw>network</kw>
            <kw>management</kw>
        </keywords>
        <abstract>This document specifies the RSVP diagnostic facility, which allows a user to collect information about the RSVP state along a path. [STANDARDS TRACK] </abstract>
        <draft>ietf-rsvp-diagnostic-msgs-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2746</doc-id>
        <title>RSVP Operation Over IP Tunnels</title>
        <author>
            <name>A. Terzis</name>
        </author>
        <author>
            <name>J. Krawczyk</name>
        </author>
        <author>
            <name>J. Wroclawski</name>
        </author>
        <author>
            <name>L. Zhang</name>
        </author>
        <date>
            <month>January</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>58094</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
            <kw>internet</kw>
        </keywords>
        <abstract>This document describes an approach for providing RSVP protocol services over IP tunnels. [STANDARDS TRACK] </abstract>
        <draft>ietf-rsvp-tunnel-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2747</doc-id>
        <title>RSVP Cryptographic Authentication</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>B. Lindell</name>
        </author>
        <author>
            <name>M. Talwar</name>
        </author>
        <date>
            <month>January</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49477</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
            <kw>security</kw>
        </keywords>
        <abstract>This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages. [STANDARDS TRACK] </abstract>
        <draft>ietf-rsvp-md5-08</draft>
        <updated-by>
            <doc-id>RFC3097</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2748</doc-id>
        <title>The COPS (Common Open Policy Service) Protocol</title>
        <author>
            <name>D. Durham</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Boyle</name>
        </author>
        <author>
            <name>R. Cohen</name>
        </author>
        <author>
            <name>S. Herzog</name>
        </author>
        <author>
            <name>R. Rajan</name>
        </author>
        <author>
            <name>A. Sastry</name>
        </author>
        <date>
            <month>January</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>90906</char-count>
            <page-count>38</page-count>
        </format>
        <keywords>
            <kw>COPS</kw>
            <kw>qos</kw>
            <kw>quality of service</kw>
            <kw>signaling</kw>
        </keywords>
        <abstract>This document describes a simple client/server model for supporting policy control over QoS signaling protocols. [STANDARDS TRACK] </abstract>
        <draft>ietf-rap-cops-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2749</doc-id>
        <title>COPS usage for RSVP</title>
        <author>
            <name>S. Herzog</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Boyle</name>
        </author>
        <author>
            <name>R. Cohen</name>
        </author>
        <author>
            <name>D. Durham</name>
        </author>
        <author>
            <name>R. Rajan</name>
        </author>
        <author>
            <name>A. Sastry</name>
        </author>
        <date>
            <month>January</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33477</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>common</kw>
            <kw>open</kw>
            <kw>policy</kw>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document describes usage directives for supporting COPS policy services in RSVP environments. [STANDARDS TRACK] </abstract>
        <draft>ietf-rap-cops-rsvp-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2750</doc-id>
        <title>RSVP Extensions for Policy Control</title>
        <author>
            <name>S. Herzog</name>
        </author>
        <date>
            <month>January</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26379</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
            <kw>admission</kw>
        </keywords>
        <abstract>This memo presents a set of extensions for supporting generic policy based admission control in RSVP. [STANDARDS TRACK] </abstract>
        <draft>ietf-rap-rsvp-ext-06</draft>
        <updates>
            <doc-id>RFC2205</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2751</doc-id>
        <title>Signaled Preemption Priority Policy Element</title>
        <author>
            <name>S. Herzog</name>
        </author>
        <date>
            <month>January</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21451</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>RSVP</kw>
            <kw>COPS</kw>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
            <kw>common</kw>
            <kw>open</kw>
            <kw>service</kw>
        </keywords>
        <abstract>This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as RSVP and COPS). [STANDARDS TRACK] </abstract>
        <draft>ietf-rap-signaled-priority-04</draft>
        <obsoleted-by>
            <doc-id>RFC3181</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2752</doc-id>
        <title>Identity Representation for RSVP</title>
        <author>
            <name>S. Yadav</name>
        </author>
        <author>
            <name>R. Yavatkar</name>
        </author>
        <author>
            <name>R. Pabbati</name>
        </author>
        <author>
            <name>P. Ford</name>
        </author>
        <author>
            <name>T. Moore</name>
        </author>
        <author>
            <name>S. Herzog</name>
        </author>
        <date>
            <month>January</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33954</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
            <kw>admission</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This document describes the representation of identity information in POLICY_DATA object for supporting policy based admission control in RSVP. [STANDARDS TRACK] </abstract>
        <draft>ietf-rap-rsvp-identity-05</draft>
        <obsoleted-by>
            <doc-id>RFC3182</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2753</doc-id>
        <title>A Framework for Policy-based Admission Control</title>
        <author>
            <name>R. Yavatkar</name>
        </author>
        <author>
            <name>D. Pendarakis</name>
        </author>
        <author>
            <name>R. Guerin</name>
        </author>
        <date>
            <month>January</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49763</char-count>
            <page-count>20</page-count>
        </format>
        <abstract>This document is concerned with specifying a framework for providing policy-based control over admission control decisions. This memo provides information for the Internet community. </abstract>
        <draft>ietf-rap-framework-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2754</doc-id>
        <title>RPS IANA Issues</title>
        <author>
            <name>C. Alaettinoglu</name>
        </author>
        <author>
            <name>C. Villamizar</name>
        </author>
        <author>
            <name>R. Govindan</name>
        </author>
        <date>
            <month>January</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11582</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>assigned</kw>
            <kw>numbers</kw>
            <kw>authority</kw>
            <kw>routing</kw>
            <kw>policy</kw>
            <kw>specification</kw>
            <kw>system</kw>
            <kw>security</kw>
        </keywords>
        <abstract>RPS Security requires certain RPSL objects in the IRR to be hierarchically delegated. The set of objects that are at the root of this hierarchy needs to be created and digitally signed by IANA. This paper presents these seed objects and lists operations required from IANA. This memo provides information for the Internet community. </abstract>
        <draft>ietf-rps-iana-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2755</doc-id>
        <title>Security Negotiation for WebNFS</title>
        <author>
            <name>A. Chiu</name>
        </author>
        <author>
            <name>M. Eisler</name>
        </author>
        <author>
            <name>B. Callaghan</name>
        </author>
        <date>
            <month>January</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23493</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>RSVP</kw>
            <kw>QOS</kw>
            <kw>resource reservation</kw>
            <kw>protocol</kw>
            <kw>quality of service</kw>
        </keywords>
        <abstract>This document describes a protocol for a WebNFS client (RFC2054) to negotiate the desired security mechanism with a WebNFS server (RFC2055) before the WebNFS client falls back to the MOUNT v3 protocol (RFC1813). This document is provided so that people can write compatible implementations. This memo provides information for the Internet community. </abstract>
        <draft>chiu-network-wnfs-sec-nego-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2756</doc-id>
        <title>Hyper Text Caching Protocol (HTCP/0.0)</title>
        <author>
            <name>P. Vixie</name>
        </author>
        <author>
            <name>D. Wessels</name>
        </author>
        <date>
            <month>January</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32176</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>HTCP</kw>
            <kw>hypertext</kw>
            <kw>transfer protocol</kw>
            <kw>caches</kw>
            <kw>data</kw>
        </keywords>
        <abstract>This document describes HTCP, a protocol for discovering HTTP caches and cached data, managing sets of HTTP caches, and monitoring cache activity. This is an experimental protocol, one among several proposals to perform these functions. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>vixie-htcp-proto-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2757</doc-id>
        <title>Long Thin Networks</title>
        <author>
            <name>G. Montenegro</name>
        </author>
        <author>
            <name>S. Dawkins</name>
        </author>
        <author>
            <name>M. Kojo</name>
        </author>
        <author>
            <name>V. Magret</name>
        </author>
        <author>
            <name>N. Vaidya</name>
        </author>
        <date>
            <month>January</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>112988</char-count>
            <page-count>46</page-count>
        </format>
        <keywords>
            <kw>wireless</kw>
            <kw>WAN</kw>
            <kw>wide area</kw>
            <kw>networks</kw>
            <kw>TCP</kw>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol </kw>
        </keywords>
        <abstract>Our goal is to identify a TCP that works for all users, including users of long thin networks. This memo provides information for the Internet community. </abstract>
        <draft>montenegro-pilc-ltn-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2758</doc-id>
        <title>Definitions of Managed Objects for Service Level Agreements Performance Monitoring</title>
        <author>
            <name>K. White</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>145581</char-count>
            <page-count>71</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>SLAs</kw>
        </keywords>
        <abstract>This memo defines a Management Information Base (MIB) for performance monitoring of Service Level Agreements (SLAs) defined via policy definitions. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>white-slapm-mib-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2759</doc-id>
        <title>Microsoft PPP CHAP Extensions, Version 2</title>
        <author>
            <name>G. Zorn</name>
        </author>
        <date>
            <month>January</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34178</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>point-to-point</kw>
            <kw>protocol</kw>
            <kw>challenge</kw>
            <kw>handshake</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This document describes version two of Microsoft's PPP CHAP dialect (MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1). This memo provides information for the Internet community. </abstract>
        <draft>ietf-pppext-mschap-v2-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2760</doc-id>
        <title>Ongoing TCP Research Related to Satellites</title>
        <author>
            <name>M. Allman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Dawkins</name>
        </author>
        <author>
            <name>D. Glover</name>
        </author>
        <author>
            <name>J. Griner</name>
        </author>
        <author>
            <name>D. Tran</name>
        </author>
        <author>
            <name>T. Henderson</name>
        </author>
        <author>
            <name>J. Heidemann</name>
        </author>
        <author>
            <name>J. Touch</name>
        </author>
        <author>
            <name>H. Kruse</name>
        </author>
        <author>
            <name>S. Ostermann</name>
        </author>
        <author>
            <name>K. Scott</name>
        </author>
        <author>
            <name>J. Semke</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>111141</char-count>
            <page-count>46</page-count>
        </format>
        <keywords>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
            <kw>bandwidth</kw>
            <kw>network</kw>
            <kw>links</kw>
        </keywords>
        <abstract>This document outlines possible TCP enhancements that may allow TCP to better utilize the available bandwidth provided by networks containing satellite links. This memo provides information for the Internet community. </abstract>
        <draft>ietf-tcpsat-res-issues-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2761</doc-id>
        <title>Terminology for ATM Benchmarking</title>
        <author>
            <name>J. Dunn</name>
        </author>
        <author>
            <name>C. Martin</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>61219</char-count>
            <page-count>32</page-count>
        </format>
        <keywords>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>performance</kw>
        </keywords>
        <abstract>This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of Asynchronous Transfer Mode (ATM) based switching devices. This memo provides information for the Internet community. </abstract>
        <draft>ietf-bmwg-atm-term-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2762</doc-id>
        <title>Sampling of the Group Membership in RTP</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25796</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>real-time</kw>
            <kw>transport</kw>
            <kw>protocol</kw>
            <kw>packets</kw>
        </keywords>
        <abstract>This document discusses mechanisms for sampling of this group membership table in order to reduce the memory requirements. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-avt-rtpsample-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2763</doc-id>
        <title>Dynamic Hostname Exchange Mechanism for IS-IS</title>
        <author>
            <name>N. Shen</name>
        </author>
        <author>
            <name>H. Smit</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8593</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>intermediate</kw>
            <kw>system</kw>
            <kw>routers</kw>
            <kw>TLV</kw>
        </keywords>
        <abstract>This document defines a new TLV which allows the IS-IS routers to flood their name to system ID mapping information across the IS-IS network. This memo provides information for the Internet community. </abstract>
        <draft>ietf-isis-dyname-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2764</doc-id>
        <title>A Framework for IP Based Virtual Private Networks</title>
        <author>
            <name>B. Gleeson</name>
        </author>
        <author>
            <name>A. Lin</name>
        </author>
        <author>
            <name>J. Heinanen</name>
        </author>
        <author>
            <name>G. Armitage</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>163215</char-count>
            <page-count>62</page-count>
        </format>
        <keywords>
            <kw>VPN</kw>
            <kw>internet protocol</kw>
            <kw>backbone</kw>
        </keywords>
        <abstract>This document describes a framework for Virtual Private Networks (VPNs) running across IP backbones. This memo provides information for the Internet community. </abstract>
        <draft>gleeson-vpn-framework-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2765</doc-id>
        <title>Stateless IP/ICMP Translation Algorithm (SIIT)</title>
        <author>
            <name>E. Nordmark</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59465</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>SIIT</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>control</kw>
            <kw>message</kw>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
        </keywords>
        <abstract>This document specifies a transition mechanism algorithm in addition to the mechanisms already specified. [STANDARDS TRACK] </abstract>
        <draft>ietf-ngtrans-siit-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2766</doc-id>
        <title>Network Address Translation - Protocol Translation (NAT-PT)</title>
        <author>
            <name>G. Tsirtsis</name>
        </author>
        <author>
            <name>P. Srisuresh</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49836</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>NAT-PT</kw>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
            <kw>internet</kw>
        </keywords>
        <abstract>This document specifies an IPv4-to-IPv6 transition mechanism, in addition to those already specified. [STANDARDS TRACK] </abstract>
        <draft>ietf-ngtrans-natpt-07</draft>
        <updated-by>
            <doc-id>RFC3152</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2767</doc-id>
        <title>Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)</title>
        <author>
            <name>K. Tsuchiya</name>
        </author>
        <author>
            <name>H. Higuchi</name>
        </author>
        <author>
            <name>Y. Atarashi</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26402</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>IPv4</kw>
            <kw>IPv6</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>applications</kw>
        </keywords>
        <abstract>This memo proposes a mechanism of dual stack hosts using the technique called "Bump-in-the-Stack" in the IP security area. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ngtrans-bis-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2768</doc-id>
        <title>Network Policy and Services: A Report of a Workshop on Middleware</title>
        <author>
            <name>B. Aiken</name>
        </author>
        <author>
            <name>J. Strassner</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>I. Foster</name>
        </author>
        <author>
            <name>C. Lynch</name>
        </author>
        <author>
            <name>J. Mambretti</name>
        </author>
        <author>
            <name>R. Moore</name>
        </author>
        <author>
            <name>B. Teitelbaum</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>81034</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>protocols</kw>
            <kw>internet</kw>
            <kw>applications</kw>
        </keywords>
        <abstract>An ad hoc middleware workshop was held at the International Center for Advanced Internet Research in December 1998. The need for a more organized framework for middleware R&amp;D was recognized, and a list of specific topics needing further work was identified. This memo provides information for the Internet community. </abstract>
        <draft>aiken-middleware-reqndef-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2769</doc-id>
        <title>Routing Policy System Replication</title>
        <author>
            <name>C. Villamizar</name>
        </author>
        <author>
            <name>C. Alaettinoglu</name>
        </author>
        <author>
            <name>R. Govindan</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>95255</char-count>
            <page-count>42</page-count>
        </format>
        <keywords>
            <kw>RPSL</kw>
            <kw>database</kw>
            <kw>language</kw>
        </keywords>
        <abstract>This document addresses the need to distribute data over multiple repositories and delegate authority for data subsets to other repositories without compromising the authorization model established in Routing Policy System Security RFC. [STANDARDS TRACK] </abstract>
        <draft>ietf-rsp-dist-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2770</doc-id>
        <title>GLOP Addressing in 233/8</title>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>P. Lothberg</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8988</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>multicast</kw>
            <kw>allocation</kw>
            <kw>global</kw>
        </keywords>
        <abstract>This describes an experimental policy for use of the class D address space using 233/8 as the experimental statically assigned subset of the class D address space. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-mboned-glop-addressing-02</draft>
        <obsoleted-by>
            <doc-id>RFC3180</doc-id>
        </obsoleted-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2771</doc-id>
        <title>An Abstract API for Multicast Address Allocation</title>
        <author>
            <name>R. Finlayson</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20954</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>application</kw>
            <kw>programming</kw>
            <kw>interfaces</kw>
            <kw>service</kw>
        </keywords>
        <abstract>This document describes the "abstract service interface" for the dynamic multicast address allocation service, as seen by applications. This memo provides information for the Internet community. </abstract>
        <draft>ietf-malloc-api-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2772</doc-id>
        <title>6Bone Backbone Routing Guidelines</title>
        <author>
            <name>R. Rockell</name>
        </author>
        <author>
            <name>R. Fink</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28565</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>IP</kw>
            <kw>internet protocol</kw>
            <kw>routing</kw>
        </keywords>
        <abstract>This document provides a set of guidelines for all 6bone routing equipment operators to use as a reference for efficient and stable deployment of 6bone routing systems. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ngtrans-harden-04</draft>
        <obsoletes>
            <doc-id>RFC2546</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3152</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2773</doc-id>
        <title>Encryption using KEA and SKIPJACK</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>P. Yee</name>
        </author>
        <author>
            <name>W. Nace</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20008</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>key exchange algorithm</kw>
            <kw>symmetric</kw>
        </keywords>
        <abstract>This document defines a method to encrypt a file transfer using the FTP specification STD 9, RFC 959, "File Transfer Protocol (FTP)", (October </abstract>
        <draft>ietf-cat-ftpkeasj-01</draft>
        <updates>
            <doc-id>RFC0959</doc-id>
        </updates>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2774</doc-id>
        <title>An HTTP Extension Framework</title>
        <author>
            <name>H. Nielsen</name>
        </author>
        <author>
            <name>P. Leach</name>
        </author>
        <author>
            <name>S. Lawrence</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39719</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>hyper-text</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>frystyk-http-extensions-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2775</doc-id>
        <title>Internet Transparency</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42956</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>end-to-end</kw>
            <kw>network layer</kw>
            <kw>connectivity</kw>
        </keywords>
        <abstract>This document describes the current state of the Internet from the architectural viewpoint, concentrating on issues of end-to-end connectivity and transparency. </abstract>
        <draft>carpenter-transparency-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2776</doc-id>
        <title>Multicast-Scope Zone Announcement Protocol (MZAP)</title>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>R. Kermode</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>61628</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>MZAP</kw>
            <kw>packets</kw>
            <kw>addresses</kw>
            <kw>service</kw>
            <kw>location</kw>
        </keywords>
        <abstract>This document defines a protocol, the Multicast-Scope Zone Announcement Protocol (MZAP), for discovering the multicast administrative scope zones that are relevant at a particular location. [STANDARDS TRACK] </abstract>
        <draft>ietf-mboned-mzap-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2777</doc-id>
        <title>Publicly Verifiable Nomcom Random Selection</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30064</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Engineering</kw>
            <kw>Task Force</kw>
            <kw>IETF</kw>
        </keywords>
        <abstract>This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. This memo provides information for the Internet community. </abstract>
        <draft>eastlake-selection-04</draft>
        <obsoleted-by>
            <doc-id>RFC3797</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2778</doc-id>
        <title>A Model for Presence and Instant Messaging</title>
        <author>
            <name>M. Day</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>H. Sugano</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35153</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>service users</kw>
            <kw>MIME</kw>
            <kw>multipurpose</kw>
            <kw>Internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document defines an abstract model for a presence and instant messaging system. It defines the various entities involved, defines terminology, and outlines the services provided by the system. This memo provides information for the Internet community. </abstract>
        <draft>ietf-impp-model-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2779</doc-id>
        <title>Instant Messaging / Presence Protocol Requirements</title>
        <author>
            <name>M. Day</name>
        </author>
        <author>
            <name>S. Aggarwal</name>
        </author>
        <author>
            <name>G. Mohr</name>
        </author>
        <author>
            <name>J. Vincent</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47420</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>MIME</kw>
            <kw>multipurpose</kw>
            <kw>Internet</kw>
            <kw>mail extensions</kw>
            <kw>service</kw>
            <kw>users</kw>
        </keywords>
        <abstract>This document defines a minimal set of requirements that IMPP must meet. This memo provides information for the Internet community. </abstract>
        <draft>ietf-impp-reqts-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2780</doc-id>
        <title>IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <author>
            <name>V. Paxson</name>
        </author>
        <date>
            <month>March</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18954</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>assigned</kw>
            <kw>numbers</kw>
            <kw>authority</kw>
            <kw>IP</kw>
        </keywords>
        <abstract>This memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>bradner-iana-allocation-05</draft>
        <is-also>
            <doc-id>BCP0037</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2781</doc-id>
        <title>UTF-16, an encoding of ISO 10646</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>F. Yergeau</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29870</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>unicode</kw>
            <kw>character</kw>
            <kw>data</kw>
            <kw>code</kw>
            <kw>point</kw>
        </keywords>
        <abstract>This document describes the UTF-16 encoding of Unicode/ISO-10646, addresses the issues of serializing UTF-16 as an octet stream for transmission over the Internet, discusses MIME charset naming as described in [CHARSET-REG], and contains the registration for three MIME charset parameter values: UTF-16BE (big-endian), UTF-16LE (little- endian), and UTF-16. This memo provides information for the Internet community. </abstract>
        <draft>hoffman-utf16-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2782</doc-id>
        <title>A DNS RR for specifying the location of services (DNS SRV)</title>
        <author>
            <name>A. Gulbrandsen</name>
        </author>
        <author>
            <name>P. Vixie</name>
        </author>
        <author>
            <name>L. Esibov</name>
        </author>
        <date>
            <month>February</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24013</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>DNS-SRV</kw>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>resource</kw>
            <kw>record</kw>
        </keywords>
        <abstract>This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS TRACK] </abstract>
        <draft>ietf-dnsind-rfc2052bis-05</draft>
        <obsoletes>
            <doc-id>RFC2052</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2783</doc-id>
        <title>Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0</title>
        <author>
            <name>J. Mogul</name>
        </author>
        <author>
            <name>D. Mills</name>
        </author>
        <author>
            <name>J. Brittenson</name>
        </author>
        <author>
            <name>J. Stone</name>
        </author>
        <author>
            <name>U. Windl</name>
        </author>
        <date>
            <month>March</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>61421</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>NTP</kw>
            <kw>time</kw>
            <kw>clock</kw>
            <kw>synchronization</kw>
        </keywords>
        <abstract>RFC 1589 did not define an API for managing the PPS facility, leaving implementors without a portable means for using PPS sources. This document specifies such an API. This memo provides information for the Internet community. </abstract>
        <draft>mogul-pps-api-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2784</doc-id>
        <title>Generic Routing Encapsulation (GRE)</title>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>S. Hanks</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>P. Traina</name>
        </author>
        <date>
            <month>March</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16627</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>GRE</kw>
            <kw>packet</kw>
            <kw>size</kw>
            <kw>payload</kw>
        </keywords>
        <abstract>This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. [STANDARDS TRACK] </abstract>
        <draft>meyer-gre-update-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2785</doc-id>
        <title>Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME</title>
        <author>
            <name>R. Zuccherato</name>
        </author>
        <date>
            <month>March</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24415</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail extensions</kw>
        </keywords>
        <abstract>This document will describe the situations relevant to implementations of S/MIME version 3 in which protection is necessary and the methods that can be used to prevent these attacks. This memo provides information for the Internet community. </abstract>
        <draft>ietf-smime-small-subgroup-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2786</doc-id>
        <title>Diffie-Helman USM Key Management Information Base and Textual Convention</title>
        <author>
            <name>M. St. Johns</name>
        </author>
        <date>
            <month>March</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43280</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>security</kw>
            <kw>user-based</kw>
            <kw>model</kw>
            <kw>Hellman</kw>
        </keywords>
        <abstract>This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols the Internet community. In particular, it defines a textual convention for doing Diffie-Helman key agreement key exchanges an set of objects which extend the usmUserTable to permit the use of DH key exchange in addition to the key change method. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>stjohns-snmpv3-dhkeychang-mib-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2787</doc-id>
        <title>Definitions of Managed Objects for the Virtual Router Redundancy Protocol</title>
        <author>
            <name>B. Jewell</name>
        </author>
        <author>
            <name>D. Chuang</name>
        </author>
        <date>
            <month>March</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>56672</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol (VRRP). [STANDARDS TRACK] </abstract>
        <draft>ietf-vrrp-mib-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2788</doc-id>
        <title>Network Services Monitoring MIB</title>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>March</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43906</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This document defines a MIB which contains the elements common to the monitoring of any network service application. [STANDARDS TRACK] </abstract>
        <draft>ietf-madman-netsm-mib-07</draft>
        <obsoletes>
            <doc-id>RFC2248</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2789</doc-id>
        <title>Mail Monitoring MIB</title>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>S. Kille</name>
        </author>
        <date>
            <month>March</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>65671</char-count>
            <page-count>33</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB defined in RFC 2788 [16] to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS TRACK] </abstract>
        <draft>ietf-madman-email-mib-06</draft>
        <obsoletes>
            <doc-id>RFC2249</doc-id>
            <doc-id>RFC1566</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2790</doc-id>
        <title>Host Resources MIB</title>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <author>
            <name>P. Grillo</name>
        </author>
        <date>
            <month>March</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>95807</char-count>
            <page-count>50</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo obsoletes RFC 1514, the "Host Resources MIB". This memo extends that specification by clarifying changes based on implementation and deployment experience and documenting the Host Resources MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB. [STANDARDS TRACK] </abstract>
        <draft>ops-hostmib-01</draft>
        <obsoletes>
            <doc-id>RFC1514</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2791</doc-id>
        <title>Scalable Routing Design Principles</title>
        <author>
            <name>J. Yu</name>
        </author>
        <date>
            <month>July</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63416</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>network</kw>
            <kw>packets</kw>
        </keywords>
        <abstract>This document identifies major factors affecting routing scalability as well as basic principles of designing scalable routing for large networks. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2792</doc-id>
        <title>DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System</title>
        <author>
            <name>M. Blaze</name>
        </author>
        <author>
            <name>J. Ioannidis</name>
        </author>
        <author>
            <name>A. Keromytis</name>
        </author>
        <date>
            <month>March</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13461</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>cryptology</kw>
            <kw>digial</kw>
            <kw>signatures</kw>
        </keywords>
        <abstract>This memo describes RSA and DSA key and signature encoding, and binary key encoding for version 2 of the KeyNote trust-management system. This memo provides information for the Internet community. </abstract>
        <draft>angelos-keynote-dsa-rsa-encoding-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2793</doc-id>
        <title>RTP Payload for Text Conversation</title>
        <author>
            <name>G. Hellstrom</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20674</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>real-time</kw>
            <kw>applications</kw>
            <kw>video</kw>
            <kw>audio</kw>
            <kw>packets</kw>
        </keywords>
        <abstract>This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140. [STANDARDS TRACK] </abstract>
        <draft>ietf-avt-rtp-text-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2794</doc-id>
        <title>Mobile IP Network Access Identifier Extension for IPv4</title>
        <author>
            <name>P. Calhoun</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>March</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16960</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>NAI</kw>
        </keywords>
        <abstract>Our proposal defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request. This memo also updates RFC 2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero. [STANDARDS TRACK] </abstract>
        <draft>ietf-mobileip-mn-nai-07</draft>
        <updates>
            <doc-id>RFC2290</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2795</doc-id>
        <title>The Infinite Monkey Protocol Suite (IMPS)</title>
        <author>
            <name>S. Christey</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42902</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>control</kw>
            <kw>packet</kw>
            <kw>client</kw>
        </keywords>
        <abstract>This memo describes a protocol suite which supports an infinite number of monkeys that sit at an infinite number of typewriters in order to determine when they have either produced the entire works of William Shakespeare or a good television show. This memo provides information for the Internet community. </abstract>
        <draft>christey-imps-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2796</doc-id>
        <title>BGP Route Reflection - An Alternative to Full Mesh IBGP</title>
        <author>
            <name>T. Bates</name>
        </author>
        <author>
            <name>R. Chandra</name>
        </author>
        <author>
            <name>E. Chen</name>
        </author>
        <date>
            <month>April</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20174</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>border</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document describes the use and design of a method known as "Route Reflection" to alleviate the the need for "full mesh" IBGP. [STANDARDS TRACK] </abstract>
        <draft>ietf-idr-route-reflect-v2-03</draft>
        <updates>
            <doc-id>RFC1966</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2797</doc-id>
        <title>Certificate Management Messages over CMS</title>
        <author>
            <name>M. Myers</name>
        </author>
        <author>
            <name>X. Liu</name>
        </author>
        <author>
            <name>J. Schaad</name>
        </author>
        <author>
            <name>J. Weinstein</name>
        </author>
        <date>
            <month>April</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>103357</char-count>
            <page-count>47</page-count>
        </format>
        <keywords>
            <kw>certificate</kw>
            <kw>management</kw>
            <kw>protocol</kw>
            <kw>cryptology</kw>
            <kw>syntax</kw>
        </keywords>
        <abstract>This document defines a Certificate Management protocol using CMS (CMC). [STANDARDS TRACK] </abstract>
        <draft>ietf-pkix-cmc-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2798</doc-id>
        <title>Definition of the inetOrgPerson LDAP Object Class</title>
        <author>
            <name>M. Smith</name>
        </author>
        <date>
            <month>April</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32929</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>directory services</kw>
        </keywords>
        <abstract>We define a new object class called inetOrgPerson for use in LDAP and X.500 directory services that extends the X.521 standard organizationalPerson class to meet these needs. This memo provides information for the Internet community. </abstract>
        <draft>smith-ldap-inetorgperson-03</draft>
        <updated-by>
            <doc-id>RFC3698</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2799</doc-id>
        <title>Request for Comments Summary RFC Numbers 2700-2799</title>
        <author>
            <name>S. Ginoza</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42622</char-count>
            <page-count>23</page-count>
        </format>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2800</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Reynolds</name>
        </author>
        <author>
            <name>R. Braden</name>
        </author>
        <author>
            <name>S. Ginoza</name>
        </author>
        <date>
            <month>May</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>101648</char-count>
            <page-count>38</page-count>
        </format>
        <abstract>This memo contains a snapshot of the state of standardization of protocols used in the Internet as of April 17, 2001. It lists only official protocol standards RFCs; it is not a complete index to the RFC series. [STANDARDS TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2700</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC2900</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2801</doc-id>
        <title>Internet Open Trading Protocol - IOTP Version 1.0</title>
        <author>
            <name>D. Burdett</name>
        </author>
        <date>
            <month>April</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>598794</char-count>
            <page-count>290</page-count>
        </format>
        <keywords>
            <kw>commerce</kw>
            <kw>payment</kw>
            <kw>system</kw>
            <kw>merchant</kw>
        </keywords>
        <abstract>This document discusses the Internet Open Trading Protocol (IOTP) and its provision of an interoperable framework for Internet commerce. This memo provides information for the Internet community. </abstract>
        <draft>ietf-trade-iotp-v1.0-protocol-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2802</doc-id>
        <title>Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)</title>
        <author>
            <name>K. Davidson</name>
        </author>
        <author>
            <name>Y. Kawatsura</name>
        </author>
        <date>
            <month>April</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52756</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>commerce</kw>
            <kw>payment system</kw>
            <kw>xml</kw>
            <kw>extensible</kw>
            <kw>markup</kw>
            <kw>language</kw>
            <kw>security</kw>
        </keywords>
        <abstract>This document describes the syntax and procedures for the computation and verification of digital signatures for use within Version 1.0 of the Internet Open Trading Protocol (IOTP). This memo provides information for the Internet community. </abstract>
        <draft>ietf-trade-iotp-v1.0-dsig-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2803</doc-id>
        <title>Digest Values for DOM (DOMHASH)</title>
        <author>
            <name>H. Maruyama</name>
        </author>
        <author>
            <name>K. Tamura</name>
        </author>
        <author>
            <name>N. Uramoto</name>
        </author>
        <date>
            <month>April</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22552</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>xml</kw>
            <kw>extensible</kw>
            <kw>markup</kw>
            <kw>language</kw>
            <kw>secruity</kw>
        </keywords>
        <abstract>This memo defines a clear and unambiguous definition of digest (hash) values of the XML objects regardless of the surface string variation of XML. This memo provides information for the Internet community. </abstract>
        <draft>ietf-trade-hiroshi-dom-hash-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2804</doc-id>
        <title>IETF Policy on Wiretapping</title>
        <author>
            <name>IAB</name>
        </author>
        <author>
            <name>IESG</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18934</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>engineering</kw>
            <kw>task force</kw>
        </keywords>
        <abstract>This document describes the position that the Internet Engineering Task Force (IETF) has taken regarding the inclusion into IETF standards-track documents of functionality designed to facilitate wiretapping. This memo explains what the IETF thinks the question means, why its answer is "no", and what that answer means. This memo provides information for the Internet community. </abstract>
        <draft>iab-raven-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2805</doc-id>
        <title>Media Gateway Control Protocol Architecture and Requirements</title>
        <author>
            <name>N. Greene</name>
        </author>
        <author>
            <name>M. Ramalho</name>
        </author>
        <author>
            <name>B. Rosen</name>
        </author>
        <date>
            <month>April</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>88190</char-count>
            <page-count>45</page-count>
        </format>
        <keywords>
            <kw>MG</kw>
            <kw>mapping</kw>
            <kw>transcoding</kw>
            <kw>network</kw>
        </keywords>
        <abstract>This document describes protocol requirements for the Media Gateway Control Protocol between a Media Gateway Controller and a Media Gateway. This memo provides information for the Internet community. </abstract>
        <draft>ietf-megaco-reqs-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2806</doc-id>
        <title>URLs for Telephone Calls</title>
        <author>
            <name>A. Vaha-Sipila</name>
        </author>
        <date>
            <month>April</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>50647</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>locator</kw>
            <kw>schemes</kw>
        </keywords>
        <abstract>This document specifies URL (Uniform Resource Locator) schemes "tel", "fax" and "modem" for specifying the location of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that entity. [STANDARDS TRACK] </abstract>
        <draft>antti-telephony-url-12</draft>
        <obsoleted-by>
            <doc-id>RFC3966</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2807</doc-id>
        <title>XML Signature Requirements</title>
        <author>
            <name>J. Reagle</name>
        </author>
        <date>
            <month>July</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21973</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>digital</kw>
            <kw>extensible</kw>
            <kw>markup</kw>
            <kw>language</kw>
        </keywords>
        <abstract>This document lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination. This memo provides information for the Internet community. </abstract>
        <draft>ietf-xmldsig-requirements-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2808</doc-id>
        <title>The SecurID(r) SASL Mechanism</title>
        <author>
            <name>M. Nystrom</name>
        </author>
        <date>
            <month>April</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20342</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>simple</kw>
            <kw>authentication</kw>
            <kw>security</kw>
            <kw>layer</kw>
        </keywords>
        <abstract>This document defines a SASL (Simple Authentication and Security Layer) authentication mechanism using SecurID (a hardware token card product (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication), thereby providing a means for such tokens to be used in SASL environments. This mechanism is only is only for authentication, and has no effect on the protocol encoding and is not designed to provide integrity or confidentiality services. This memo provides information for the Internet community. </abstract>
        <draft>nystrom-securid-sasl-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2809</doc-id>
        <title>Implementation of L2TP Compulsory Tunneling via RADIUS</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <date>
            <month>April</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47259</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>remote</kw>
            <kw>authentication</kw>
            <kw>dial-in</kw>
            <kw>user</kw>
            <kw>service</kw>
            <kw>layer</kw>
            <kw>two</kw>
        </keywords>
        <abstract>This document discusses implementation issues arising in the provisioning of compulsory tunneling in dial-up networks using the L2TP (Layer Two Tunneling Protocol) protocol. This memo provides information for the Internet community. </abstract>
        <draft>ietf-radius-tunnel-imp-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2810</doc-id>
        <title>Internet Relay Chat: Architecture</title>
        <author>
            <name>C. Kalt</name>
        </author>
        <date>
            <month>April</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19087</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>IRC</kw>
            <kw>text based</kw>
            <kw>conferencing</kw>
        </keywords>
        <abstract>This document is an update describing the architecture of the current IRC protocol and the role of its different components. Other documents describe in detail the protocol used between the various components defined here. This memo provides information for the Internet community. </abstract>
        <draft>kalt-irc-arch-00</draft>
        <updates>
            <doc-id>RFC1459</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2811</doc-id>
        <title>Internet Relay Chat: Channel Management</title>
        <author>
            <name>C. Kalt</name>
        </author>
        <date>
            <month>April</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40788</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>IRC</kw>
            <kw>text based</kw>
            <kw>conferencing</kw>
        </keywords>
        <abstract>This document specifies how channels, their characteristics and properties are managed by IRC servers. This memo provides information for the Internet community. </abstract>
        <draft>kalt-irc-chan-01</draft>
        <updates>
            <doc-id>RFC1459</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2812</doc-id>
        <title>Internet Relay Chat: Client Protocol</title>
        <author>
            <name>C. Kalt</name>
        </author>
        <date>
            <month>April</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>122637</char-count>
            <page-count>63</page-count>
        </format>
        <keywords>
            <kw>IRC</kw>
            <kw>text based</kw>
            <kw>conferencing</kw>
        </keywords>
        <abstract>This document defines the Client Protocol, and assumes that the reader is familiar with the IRC Architecture. This memo provides information for the Internet community. </abstract>
        <draft>kalt-irc-client-03</draft>
        <updates>
            <doc-id>RFC1459</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2813</doc-id>
        <title>Internet Relay Chat: Server Protocol</title>
        <author>
            <name>C. Kalt</name>
        </author>
        <date>
            <month>April</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>56681</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>IRC</kw>
            <kw>text based</kw>
            <kw>conferencing</kw>
        </keywords>
        <abstract>This document defines the protocol used by servers to talk to each other. This memo provides information for the Internet community. </abstract>
        <draft>kalt-irc-server-02</draft>
        <updates>
            <doc-id>RFC1459</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2814</doc-id>
        <title>SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks</title>
        <author>
            <name>R. Yavatkar</name>
        </author>
        <author>
            <name>D. Hoffman</name>
        </author>
        <author>
            <name>Y. Bernet</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>M. Speer</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>141886</char-count>
            <page-count>60</page-count>
        </format>
        <keywords>
            <kw>LAN</kw>
            <kw>local area</kw>
            <kw>resource</kw>
            <kw>reservation</kw>
        </keywords>
        <abstract>This document describes a signaling method and protocol for RSVP-based admission control over IEEE 802-style LANs. [STANDARDS TRACK] </abstract>
        <draft>ietf-issll-is802-sbm-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2815</doc-id>
        <title>Integrated Service Mappings on IEEE 802 Networks</title>
        <author>
            <name>M. Seaman</name>
        </author>
        <author>
            <name>A. Smith</name>
        </author>
        <author>
            <name>E. Crawley</name>
        </author>
        <author>
            <name>J. Wroclawski</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42403</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>LAN</kw>
            <kw>local area</kw>
            <kw>resource</kw>
            <kw>reservation</kw>
        </keywords>
        <abstract>This document describes mappings of IETF Integrated Services over LANs built from IEEE 802 network segments which may be interconnected by IEEE 802.1D MAC Bridges (switches). [STANDARDS TRACK] </abstract>
        <draft>ietf-issll-is802-svc-mapping-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2816</doc-id>
        <title>A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies</title>
        <author>
            <name>A. Ghanwani</name>
        </author>
        <author>
            <name>J. Pace</name>
        </author>
        <author>
            <name>V. Srinivasan</name>
        </author>
        <author>
            <name>A. Smith</name>
        </author>
        <author>
            <name>M. Seaman</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>119043</char-count>
            <page-count>47</page-count>
        </format>
        <keywords>
            <kw>LAN</kw>
            <kw>local area</kw>
            <kw>network</kw>
            <kw>parameter</kw>
            <kw>switches</kw>
        </keywords>
        <abstract>This memo describes a framework for supporting IETF Integrated Services on shared and switched LAN infrastructure. This memo provides information for the Internet community. </abstract>
        <draft>ietf-issll-is802-framework-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2817</doc-id>
        <title>Upgrading to TLS Within HTTP/1.1</title>
        <author>
            <name>R. Khare</name>
        </author>
        <author>
            <name>S. Lawrence</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27598</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>hypertext</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>transport</kw>
            <kw>layer</kw>
            <kw>security</kw>
        </keywords>
        <abstract>This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. [STANDARDS TRACK] </abstract>
        <draft>ietf-tls-http-upgrade-05</draft>
        <updates>
            <doc-id>RFC2616</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2818</doc-id>
        <title>HTTP Over TLS</title>
        <author>
            <name>E. Rescorla</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15170</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>hypertext</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>transport</kw>
            <kw>layer</kw>
            <kw>security</kw>
        </keywords>
        <abstract>This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community. </abstract>
        <draft>ietf-tls-https-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2819</doc-id>
        <title>Remote Network Monitoring Management Information Base</title>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>198676</char-count>
            <page-count>98</page-count>
        </format>
        <keywords>
            <kw>RMON-MIB</kw>
            <kw>MIB</kw>
            <kw>RMON</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS TRACK] </abstract>
        <draft>ietf-rmonmib-rmonfull-02</draft>
        <obsoletes>
            <doc-id>RFC1757</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0059</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2820</doc-id>
        <title>Access Control Requirements for LDAP</title>
        <author>
            <name>E. Stokes</name>
        </author>
        <author>
            <name>D. Byrne</name>
        </author>
        <author>
            <name>B. Blakley</name>
        </author>
        <author>
            <name>P. Behera</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18172</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document describes the fundamental requirements of an access control list (ACL) model for the Lightweight Directory Application Protocol (LDAP) directory service. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ldapext-acl-reqts-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2821</doc-id>
        <title>Simple Mail Transfer Protocol</title>
        <author>
            <name>J. Klensin</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>192504</char-count>
            <page-count>79</page-count>
        </format>
        <keywords>
            <kw>SMTP</kw>
        </keywords>
        <abstract>This document is a self-contained specification of the basic protocol for the Internet electronic mail transport. [STANDARDS TRACK] </abstract>
        <draft>ietf-drums-smtpupd-13</draft>
        <obsoletes>
            <doc-id>RFC0821</doc-id>
            <doc-id>RFC0974</doc-id>
            <doc-id>RFC1869</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2822</doc-id>
        <title>Internet Message Format</title>
        <author>
            <name>P. Resnick</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>110695</char-count>
            <page-count>51</page-count>
        </format>
        <keywords>
            <kw>MAIL</kw>
        </keywords>
        <abstract>This document specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. [STANDARDS TRACK] </abstract>
        <draft>ietf-drums-msg-fmt-09</draft>
        <obsoletes>
            <doc-id>RFC0822</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2823</doc-id>
        <title>PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing</title>
        <author>
            <name>J. Carlson</name>
        </author>
        <author>
            <name>P. Langner</name>
        </author>
        <author>
            <name>E. Hernandez-Valencia</name>
        </author>
        <author>
            <name>J. Manchester</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>60049</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>PPP-SDL</kw>
            <kw>point-to-point</kw>
            <kw>protocol</kw>
            <kw>synchronous</kw>
            <kw>optical</kw>
            <kw>network</kw>
            <kw>digital</kw>
            <kw>hierarchy</kw>
            <kw>data link</kw>
            <kw>simple</kw>
        </keywords>
        <abstract>This document extends methods found in the Point-to-Point Protocol (PPP) and RFCs 1662 and 2615 to include a new encapsulation for PPP called Simple Data Link (SDL). SDL provides a standard method for transporting multi-protocol datagrams over point-to-point links, and RFCs 1662 and 2615 provide a means to carry PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. SDL provides a very low overhead alternative to HDLC-like encapsulation, and can also be used on SONET/SDH links. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-pppext-sdl-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2824</doc-id>
        <title>Call Processing Language Framework and Requirements</title>
        <author>
            <name>J. Lennox</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>58711</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>CPL-F</kw>
            <kw>telephony</kw>
            <kw>signalling</kw>
            <kw>network</kw>
            <kw>devices</kw>
        </keywords>
        <abstract>This document describes an architectural framework we call a processing language, as a simple and standardized way for implementing and deploying Internet telephony. A large number of the services we wish to make possible for Internet telephony require fairly elaborate combinations of signalling operations, often in network devices, to complete. It also outlines requirements for such a language. This memo provides information for the Internet community. </abstract>
        <draft>ietf-iptel-cpl-framework-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2825</doc-id>
        <title>A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols</title>
        <author>
            <name>IAB</name>
        </author>
        <author>
            <name>L. Daigle</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15612</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>character sets</kw>
            <kw>e-commerce</kw>
            <kw>interoperability</kw>
        </keywords>
        <abstract>This document is a statement by the Internet Architecture Board. It is not a protocol specification, but an attempt to clarify the range of architectural issues that the internationalization of domain names faces. This memo provides information for the Internet community. </abstract>
        <draft>iab-i18n-dns-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2826</doc-id>
        <title>IAB Technical Comment on the Unique DNS Root</title>
        <author>
            <name>Internet Architecture Board</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13400</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>Internet Architecture Board</kw>
            <kw>domain name</kw>
            <kw>system</kw>
        </keywords>
        <abstract>This document discusses the existence of a globally unique public name space in the Internet called the DNS (Domain Name System). This name space is a hierarchical name space derived from a single, globally unique root. It is a technical constraint inherent in the design of the DNS. One root must be supported by a set of coordinated root servers administered by a unique naming authority. It is not technically feasible for there to be more than one root in the public DNS. This memo provides information for the Internet community. </abstract>
        <draft>iab-unique-dns-root-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2827</doc-id>
        <title>Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing</title>
        <author>
            <name>P. Ferguson</name>
        </author>
        <author>
            <name>D. Senie</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21258</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>ISP</kw>
            <kw>Internet</kw>
            <kw>Service</kw>
            <kw>Provider</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>DOS</kw>
        </keywords>
        <abstract>This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <obsoletes>
            <doc-id>RFC2267</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3704</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0038</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2828</doc-id>
        <title>Internet Security Glossary</title>
        <author>
            <name>R. Shirey</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>489292</char-count>
            <page-count>212</page-count>
        </format>
        <keywords>
            <kw>information</kw>
            <kw>system</kw>
            <kw>ISD</kw>
            <kw>internet</kw>
            <kw>standard documents</kw>
        </keywords>
        <abstract>This Glossary provides abbreviations, explanations, and recommendations for use of information system security terminology. This memo provides information for the Internet community. </abstract>
        <draft>shirey-security-glossary-02</draft>
        <is-also>
            <doc-id>FYI0036</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2829</doc-id>
        <title>Authentication Methods for LDAP</title>
        <author>
            <name>M. Wahl</name>
        </author>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <author>
            <name>J. Hodges</name>
        </author>
        <author>
            <name>R. Morgan</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33471</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>security</kw>
        </keywords>
        <abstract>This document specifies particular combinations of security mechanisms which are required and recommended in LDAP implementations. [STANDARDS TRACK] </abstract>
        <draft>ietf-ldapext-authmeth-04</draft>
        <updated-by>
            <doc-id>RFC3377</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2830</doc-id>
        <title>Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security</title>
        <author>
            <name>J. Hodges</name>
        </author>
        <author>
            <name>R. Morgan</name>
        </author>
        <author>
            <name>M. Wahl</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24469</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>LDAP</kw>
            <kw>TLS</kw>
        </keywords>
        <abstract>This document defines the "Start Transport Layer Security (TLS) Operation" for LDAP. [STANDARDS TRACK] </abstract>
        <draft>ietf-ldapext-ldapv3-tls-06</draft>
        <updated-by>
            <doc-id>RFC3377</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2831</doc-id>
        <title>Using Digest Authentication as a SASL Mechanism</title>
        <author>
            <name>P. Leach</name>
        </author>
        <author>
            <name>C. Newman</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>58124</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>http</kw>
            <kw>hypertext</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>security</kw>
            <kw>simple</kw>
            <kw>layer</kw>
        </keywords>
        <abstract>This specification defines how HTTP Digest Authentication can be used as a SASL mechanism for any protocol that has a SASL (Simple Authentication and Security Layer) profile. [STANDARDS TRACK] </abstract>
        <draft>leach-digest-sasl-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2832</doc-id>
        <title>NSI Registry Registrar Protocol (RRP) Version 1.1.0</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <author>
            <name>M. Srivastava</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>77057</char-count>
            <page-count>39</page-count>
        </format>
        <keywords>
            <kw>RRP</kw>
            <kw>shared</kw>
            <kw>registration</kw>
            <kw>system</kw>
            <kw>gLTD</kw>
            <kw>ccTLD</kw>
            <kw>top level domain</kw>
        </keywords>
        <abstract>This document describes a protocol for the registration and management of second level domain names and associated name servers in both generic Top Level Domains (gTLDs) and country code Top Level Domains (ccTLDs). This memo provides information for the Internet community. </abstract>
        <draft>hollenbeck-rrp-01</draft>
        <updated-by>
            <doc-id>RFC3632</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2833</doc-id>
        <title>RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>S. Petrack</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>68786</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>real-time</kw>
            <kw>application</kw>
            <kw>protocol</kw>
            <kw>DTMF</kw>
            <kw>dual-tone</kw>
            <kw>multifrequency</kw>
        </keywords>
        <abstract>This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. [STANDARDS TRACK] </abstract>
        <draft>ietf-avt-tones-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2834</doc-id>
        <title>ARP and IP Broadcast over HIPPI-800</title>
        <author>
            <name>J.-M. Pittet</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>76243</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>address resolution</kw>
            <kw>protocol</kw>
            <kw>internet</kw>
            <kw>high-performance</kw>
            <kw>internface</kw>
            <kw>parallel</kw>
        </keywords>
        <abstract>This document specifies a method for resolving IP addresses to ANSI High-Performance Parallel Interface (HIPPI) hardware addresses and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP (hardware addresses). This memo defines a HARP that will interoperate between HIPPI-800 and HIPPI-6400 (also known as Gigabyte System Network, GSN). This document (when combined with RFC 2067 "IP over HIPPI") obsoletes RFC 1374. [STANDARDS TRACK] </abstract>
        <draft>pittet-hippiarp-05</draft>
        <obsoletes>
            <doc-id>RFC1374</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2835</doc-id>
        <title>IP and ARP over HIPPI-6400 (GSN)</title>
        <author>
            <name>J.-M. Pittet</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>74178</char-count>
            <page-count>33</page-count>
        </format>
        <keywords>
            <kw>GSN</kw>
            <kw>address resolution</kw>
            <kw>protocol</kw>
            <kw>internet</kw>
            <kw>high-performance</kw>
            <kw>internface</kw>
            <kw>parallel</kw>
        </keywords>
        <abstract>This document further specifies a method for resolving IP addresses to HIPPI-6400 (High-Performance Parallel Interface) hardware addresses (HARP) and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. Furthermore, it is the goal of this memo to define a IP and HARP that will allow interoperability for HIPPI-800 and HIPPI-6400 equipment both broadcast and non-broadcast capable networks. [STANDARDS TRACK] </abstract>
        <draft>pittet-gsnlan-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2836</doc-id>
        <title>Per Hop Behavior Identification Codes</title>
        <author>
            <name>S. Brim</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>F. Le Faucheur</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13399</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>PHB</kw>
            <kw>differentiated</kw>
            <kw>services</kw>
            <kw>codepoint</kw>
            <kw>DSCP</kw>
        </keywords>
        <abstract>This document defines a binary encoding to uniquely identify PHBs (Per Hop Behaviors) and/or sets of PHBs in protocol messages. [STANDARDS TRACK] </abstract>
        <draft>ietf-diffserv-phbid-00</draft>
        <obsoleted-by>
            <doc-id>RFC3140</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2837</doc-id>
        <title>Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard</title>
        <author>
            <name>K. Teow</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>87860</char-count>
            <page-count>48</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines the objects for managing the operations of the Fabric Element portion of the Fibre Channel Standards. [STANDARDS TRACK] </abstract>
        <draft>ietf-ipfc-fabric-element-mib-07</draft>
        <obsoleted-by>
            <doc-id>RFC4044</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2838</doc-id>
        <title>Uniform Resource Identifiers for Television Broadcasts</title>
        <author>
            <name>D. Zigmond</name>
        </author>
        <author>
            <name>M. Vickers</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11405</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>URI</kw>
            <kw>TV</kw>
            <kw>WWW</kw>
            <kw>world wide web </kw>
        </keywords>
        <abstract>This document describes a widely-implemented URI scheme, as World-Wide Web browsers are starting to appear on a variety of consumer electronic devices, such as television sets and television set-top boxes, which are capable of receiving television programming from either terrestrial broadcast, satellite broadcast, or cable. In this context there is a need to reference television broadcasts using the URI format described in RFC 2396. This memo provides information for the Internet community. </abstract>
        <draft>zigmond-tv-url-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2839</doc-id>
        <title>Internet Kermit Service</title>
        <author>
            <name>F. da Cruz</name>
        </author>
        <author>
            <name>J. Altman</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42726</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>file</kw>
            <kw>transfer</kw>
            <kw>management</kw>
            <kw>service</kw>
        </keywords>
        <abstract>This document describes a new file transfer service for the Internet based on Telnet Protocol for option negotiation and Kermit Protocol for file transfer and management. This memo provides information for the Internet community. </abstract>
        <draft>columbia-kermit-service-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2840</doc-id>
        <title>TELNET KERMIT OPTION</title>
        <author>
            <name>J. Altman</name>
        </author>
        <author>
            <name>F. da Cruz</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22519</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>file transfer</kw>
            <kw>management</kw>
            <kw>service</kw>
        </keywords>
        <abstract>This document describes an extension to the Telnet protocol to allow the negotiation, coordination, and use of the Kermit file transfer and management protocol over an existing Telnet protocol connection. This memo provides information for the Internet community. </abstract>
        <draft>altman-telnet-kermit-server-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2841</doc-id>
        <title>IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC)</title>
        <author>
            <name>P. Metzger</name>
        </author>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14139</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>IP-MAC</kw>
            <kw>encryption</kw>
            <kw>secure</kw>
            <kw>hash</kw>
            <kw>algorithm</kw>
        </keywords>
        <abstract>This document describes the use of keyed SHA1 (Secure Hash Algorithm) with the IP Authentication Header. This memo defines a Historic Document for the Internet community. </abstract>
        <draft>simpson-ah-sha-kdp-00</draft>
        <obsoletes>
            <doc-id>RFC1852</doc-id>
        </obsoletes>
        <current-status>HISTORIC</current-status>
        <publication-status>HISTORIC</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2842</doc-id>
        <title>Capabilities Advertisement with BGP-4</title>
        <author>
            <name>R. Chandra</name>
        </author>
        <author>
            <name>J. Scudder</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8366</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>border</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities in BGP by providing graceful capability advertisement without requiring that BGP peering be terminated. [STANDARDS TRACK] </abstract>
        <draft>ietf-idr-bgp4-cap-neg-06</draft>
        <obsoleted-by>
            <doc-id>RFC3392</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2843</doc-id>
        <title>Proxy-PAR</title>
        <author>
            <name>P. Droz</name>
        </author>
        <author>
            <name>T. Przygienda</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27891</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>PNNI augmented Routing</kw>
            <kw>ATM</kw>
            <kw>asynchronous</kw>
            <kw>transfer mode</kw>
        </keywords>
        <abstract>The intention of this document is to provide general information about Proxy-PAR (PNNI Augmented Routing). [STANDARDS TRACK] </abstract>
        <draft>ietf-ion-proxypar-arch-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2844</doc-id>
        <title>OSPF over ATM and Proxy-PAR</title>
        <author>
            <name>T. Przygienda</name>
        </author>
        <author>
            <name>P. Droz</name>
        </author>
        <author>
            <name>R. Haas</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32146</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>PNNI augmented Routing</kw>
            <kw>asynchronous transfer mode</kw>
            <kw>open shortest-path first</kw>
        </keywords>
        <abstract>This memo specifies, for OSPF implementors and users, mechanisms describing how the protocol operates in ATM networks over PVC (Permanent Virtual Connections) and SVC (Switched Virtual Circuit) meshes with the presence of Proxy-PAR (PNNI Augmented Routing). This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-ospf-atm-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2845</doc-id>
        <title>Secret Key Transaction Authentication for DNS (TSIG)</title>
        <author>
            <name>P. Vixie</name>
        </author>
        <author>
            <name>O. Gudmundsson</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>B. Wellington</name>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32272</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>TSIG</kw>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>transaction</kw>
            <kw>signature</kw>
        </keywords>
        <abstract>This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server. [STANDARDS TRACK] </abstract>
        <draft>ietf-dnsext-tsig-00</draft>
        <updates>
            <doc-id>RFC1035</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC3645</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2846</doc-id>
        <title>GSTN Address Element Extensions in E-mail Services</title>
        <author>
            <name>C. Allocchio</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54316</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
            <kw>global</kw>
            <kw>switched</kw>
            <kw>telephone</kw>
            <kw>network</kw>
        </keywords>
        <abstract>This memo defines a full syntax for a specific application in which there is a need to represent GSTN (Global Switched Telephone Network) addressing and Internet addressing. [STANDARDS TRACK] </abstract>
        <draft>ietf-fax-fulladdr-06</draft>
        <updated-by>
            <doc-id>RFC3191</doc-id>
            <doc-id>RFC3192</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2847</doc-id>
        <title>LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM</title>
        <author>
            <name>M. Eisler</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>50045</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>LIPKEY</kw>
            <kw>client</kw>
            <kw>server</kw>
            <kw>simple pubilc</kw>
            <kw>key mechanism</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This memorandum describes a method whereby one can use GSS-API (Generic Security Service Application Program Interface) to supply a secure channel between a client and server, authenticating the client with a password, and a server with a public key certificate. [STANDARDS TRACK] </abstract>
        <draft>ietf-cat-lipkey-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2848</doc-id>
        <title>The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services</title>
        <author>
            <name>S. Petrack</name>
        </author>
        <author>
            <name>L. Conroy</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>168851</char-count>
            <page-count>73</page-count>
        </format>
        <keywords>
            <kw>session</kw>
            <kw>initiation</kw>
            <kw>protocol</kw>
            <kw>internet</kw>
            <kw>description</kw>
        </keywords>
        <abstract>This document contains the specification of the PINT Service Protocol 1.0, which defines a protocol for invoking certain telephone services from an IP network. [STANDARDS TRACK] </abstract>
        <draft>ietf-pint-protocol-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2849</doc-id>
        <title>The LDAP Data Interchange Format (LDIF) - Technical Specification</title>
        <author>
            <name>G. Good</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26017</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>LDIF</kw>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol file</kw>
        </keywords>
        <abstract>This document describes a file format suitable for describing directory information or modifications made to directory information. [STANDARDS TRACK] </abstract>
        <draft>good-ldap-ldif-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2850</doc-id>
        <title>Charter of the Internet Architecture Board (IAB)</title>
        <author>
            <name>Internet Architecture Board</name>
        </author>
        <author>
            <name>B. Carpenter</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15984</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>ISOC</kw>
            <kw>Internet Society</kw>
            <kw>IETF</kw>
            <kw>IRTF</kw>
        </keywords>
        <abstract>This memo documents the composition, selection, roles, and organization of the Internet Architecture Board. It replaces RFC 1601. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>iab-rfc1601bis-04</draft>
        <obsoletes>
            <doc-id>RFC1601</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0039</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2851</doc-id>
        <title>Textual Conventions for Internet Network Addresses</title>
        <author>
            <name>M. Daniele</name>
        </author>
        <author>
            <name>B. Haberman</name>
        </author>
        <author>
            <name>S. Routhier</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32587</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>layer</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>inet</kw>
            <kw>address mib</kw>
        </keywords>
        <abstract>This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. [STANDARDS TRACK] </abstract>
        <draft>ops-endpoint-mib-08</draft>
        <obsoleted-by>
            <doc-id>RFC3291</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2852</doc-id>
        <title>Deliver By SMTP Service Extension</title>
        <author>
            <name>D. Newman</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29285</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>simple</kw>
            <kw>mail transfer</kw>
            <kw>protocol</kw>
            <kw>client server</kw>
        </keywords>
        <abstract>This memo defines a mechanism whereby a SMTP client can request, when transmitting a message to a SMTP server, that the server deliver the message within a prescribed period of time. [STANDARDS TRACK] </abstract>
        <draft>newman-deliver-03</draft>
        <updates>
            <doc-id>RFC1894</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2853</doc-id>
        <title>Generic Security Service API Version 2 : Java Bindings</title>
        <author>
            <name>J. Kabat</name>
        </author>
        <author>
            <name>M. Upadhyay</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>199512</char-count>
            <page-count>96</page-count>
        </format>
        <keywords>
            <kw>GSI</kw>
            <kw>application program</kw>
            <kw>interface</kw>
        </keywords>
        <abstract>This document specifies the Java bindings for GSS-API (Generic Security Service Application Program Interface) which is described at a language independent conceptual level in RFC 2743. [STANDARDS TRACK] </abstract>
        <draft>ietf-cat-gssv2-javabind-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2854</doc-id>
        <title>The 'text/html' Media Type</title>
        <author>
            <name>D. Connolly</name>
        </author>
        <author>
            <name>L. Masinter</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16135</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>HTML-INT</kw>
            <kw>HTML</kw>
            <kw>WWW</kw>
            <kw>World</kw>
            <kw>Wide</kw>
            <kw>Web</kw>
        </keywords>
        <abstract>This document summarizes the history of HTML development, and defines the "text/html" MIME type by pointing to the relevant W3C recommendations. This memo provides information for the Internet community. </abstract>
        <draft>connolly-text-html-02</draft>
        <obsoletes>
            <doc-id>RFC2070</doc-id>
            <doc-id>RFC1980</doc-id>
            <doc-id>RFC1942</doc-id>
            <doc-id>RFC1867</doc-id>
            <doc-id>RFC1866</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2855</doc-id>
        <title>DHCP for IEEE 1394</title>
        <author>
            <name>K. Fujisawa</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8070</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>dynamic</kw>
            <kw>host</kw>
            <kw>configuration</kw>
            <kw>protocol</kw>
            <kw>high performance</kw>
            <kw>serial bus</kw>
        </keywords>
        <abstract>This memo describes specific usage of some fields of DHCP (Dynamic Host Configuration Protocol) messages. IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. Since 1394 uses a different link-layer addressing method than conventional IEEE802/Ethernet, the usage of some fields must be clarified to achieve interoperability. [STANDARDS TRACK] </abstract>
        <draft>ietf-ip1394-dhcp-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2856</doc-id>
        <title>Textual Conventions for Additional High Capacity Data Types</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>R. Presuhn</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20954</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
            <kw>simple</kw>
            <kw>network</kw>
            <kw>management</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo specifies new textual conventions for additional high capacity data types, intended for SNMP implementations which already support the Counter64 data type. [STANDARDS TRACK] </abstract>
        <draft>kzm-hcdata-types-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2857</doc-id>
        <title>The Use of HMAC-RIPEMD-160-96 within ESP and AH</title>
        <author>
            <name>A. Keromytis</name>
        </author>
        <author>
            <name>N. Provos</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13544</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>ipsec</kw>
            <kw>encapsulating</kw>
            <kw>security</kw>
            <kw>payload</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This memo describes the use of the HMAC algorithm in conjunction with the RIPEMD-160 algorithm as an authentication mechanism within the revised IPSEC Encapsulating Security Payload (ESP) and the revised IPSEC Authentication Header (AH). [STANDARDS TRACK] </abstract>
        <draft>ietf-ipsec-auth-hmac-ripemd-160-96-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2858</doc-id>
        <title>Multiprotocol Extensions for BGP-4</title>
        <author>
            <name>T. Bates</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>R. Chandra</name>
        </author>
        <author>
            <name>D. Katz</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23305</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>MEXT-BGP4</kw>
            <kw>Border</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
            <kw>router</kw>
            <kw>network</kw>
            <kw>layer</kw>
        </keywords>
        <abstract>This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). [STANDARDS TRACK] </abstract>
        <draft>ietf-idr-bgp4-multiprotocol-v2-05</draft>
        <obsoletes>
            <doc-id>RFC2283</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2859</doc-id>
        <title>A Time Sliding Window Three Colour Marker (TSWTCM)</title>
        <author>
            <name>W. Fang</name>
        </author>
        <author>
            <name>N. Seddigh</name>
        </author>
        <author>
            <name>B. Nandy</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19203</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>TSWTCM</kw>
            <kw>packets</kw>
            <kw>traffic</kw>
            <kw>stream</kw>
            <kw>routers</kw>
        </keywords>
        <abstract>This memo defines a Time Sliding Window Three Colour Marker (TSWTCM), which can be used as a component in a Diff-Serv traffic conditioner. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>fang-diffserv-tc-tswtcm-01</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2860</doc-id>
        <title>Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>M. Roberts</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12361</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>mou</kw>
            <kw>iana</kw>
            <kw>ietf</kw>
            <kw>icann</kw>
            <kw>engineering</kw>
            <kw>task force</kw>
            <kw>corporation names</kw>
        </keywords>
        <abstract>This document places on record the text of the Memorandum of Understanding concerning the technical work of the IANA that was signed on March 1, 2000 between the IETF and ICANN, and ratified by the ICANN Board on March 10, 2000. This memo provides information for the Internet community. </abstract>
        <draft>iab-iana-mou-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2861</doc-id>
        <title>TCP Congestion Window Validation</title>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>J. Padhye</name>
        </author>
        <author>
            <name>S. Floyd</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26993</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document describes a simple modification to TCP's congestion control algorithms to decay the congestion window cwnd after the transition from a sufficiently-long application-limited period, while using the slow-start threshold ssthresh to save information about the previous value of the congestion window. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>handley-tcp-cwv-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2862</doc-id>
        <title>RTP Payload Format for Real-Time Pointers</title>
        <author>
            <name>M. Civanlar</name>
        </author>
        <author>
            <name>G. Cash</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12031</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>view graphs</kw>
            <kw>resolution</kw>
            <kw>audio</kw>
            <kw>video</kw>
            <kw>signals</kw>
        </keywords>
        <abstract>This document describes an RTP payload format for transporting the coordinates of a dynamic pointer that may be used during a presentation. [STANDARDS TRACK] </abstract>
        <draft>ietf-avt-pointer-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2863</doc-id>
        <title>The Interfaces Group MIB</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>F. Kastenholz</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>155014</char-count>
            <page-count>69</page-count>
        </format>
        <keywords>
            <kw>INTERGRMIB</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
            <kw>Network</kw>
        </keywords>
        <abstract>This memo discusses the 'interfaces' group of MIB-II, especially the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork-layer. It specifies clarifications to, and extensions of, the architectural issues within the MIB-II model of the 'interfaces' group. [STANDARDS TRACK] </abstract>
        <draft>ietf-ifmib-ifmib2-03</draft>
        <obsoletes>
            <doc-id>RFC2233</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2864</doc-id>
        <title>The Inverted Stack Table Extension to the Interfaces Group MIB</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>G. Hanson</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21445</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects which provide an inverted mapping of the interface stack table used for managing network interfaces. [STANDARDS TRACK] </abstract>
        <draft>ietf-ifmib-invstackmib-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2865</doc-id>
        <title>Remote Authentication Dial In User Service (RADIUS)</title>
        <author>
            <name>C. Rigney</name>
        </author>
        <author>
            <name>S. Willens</name>
        </author>
        <author>
            <name>A. Rubens</name>
        </author>
        <author>
            <name>W. Simpson</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>146456</char-count>
            <page-count>76</page-count>
        </format>
        <keywords>
            <kw>RADIUS</kw>
            <kw>encryption</kw>
            <kw>NAS</kw>
            <kw>Network</kw>
            <kw>Access</kw>
            <kw>Server</kw>
        </keywords>
        <abstract>This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS TRACK] </abstract>
        <draft>ietf-radius-radius-v2-06</draft>
        <obsoletes>
            <doc-id>RFC2138</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC2868</doc-id>
            <doc-id>RFC3575</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2866</doc-id>
        <title>RADIUS Accounting</title>
        <author>
            <name>C. Rigney</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51135</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>RADIUS-ACC</kw>
            <kw>remote</kw>
            <kw>authentication</kw>
            <kw>dial</kw>
            <kw>in</kw>
            <kw>user</kw>
            <kw>service</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract>This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community. </abstract>
        <draft>ietf-radius-accouting-v2-05</draft>
        <obsoletes>
            <doc-id>RFC2139</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC2867</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2867</doc-id>
        <title>RADIUS Accounting Modifications for Tunnel Protocol Support</title>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>D. Mitton</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51135</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>RADIUS]</kw>
            <kw>encryption</kw>
            <kw>NAS</kw>
            <kw>Network</kw>
            <kw>Access</kw>
            <kw>Server</kw>
        </keywords>
        <abstract>This document defines new RADIUS (Remote Authentication Dial In User Service) accounting Attributes and new values for the existing Acct- Status-Type Attribute designed to support the provision of compulsory tunneling in dial-up networks. This memo provides information for the Internet community. </abstract>
        <draft>ietf-radius-tunnel-acct-05</draft>
        <updates>
            <doc-id>RFC2866</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2868</doc-id>
        <title>RADIUS Attributes for Tunnel Protocol Support</title>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>D. Leifer</name>
        </author>
        <author>
            <name>A. Rubens</name>
        </author>
        <author>
            <name>J. Shriver</name>
        </author>
        <author>
            <name>M. Holdrege</name>
        </author>
        <author>
            <name>I. Goyret</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42609</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>RADIUS</kw>
            <kw>encryption</kw>
            <kw>NAS</kw>
            <kw>Network</kw>
            <kw>Access</kw>
            <kw>Server</kw>
        </keywords>
        <abstract>This document defines a set of RADIUS (Remote Authentication Dial In User Service) attributes designed to support the provision of compulsory tunneling in dial-up networks. This memo provides information for the Internet community. </abstract>
        <draft>ietf-radius-tunnel-auth-09</draft>
        <updates>
            <doc-id>RFC2865</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2869</doc-id>
        <title>RADIUS Extensions</title>
        <author>
            <name>C. Rigney</name>
        </author>
        <author>
            <name>W. Willats</name>
        </author>
        <author>
            <name>P. Calhoun</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>96854</char-count>
            <page-count>47</page-count>
        </format>
        <keywords>
            <kw>RADIUS</kw>
            <kw>encryption</kw>
            <kw>NAS</kw>
            <kw>Network</kw>
            <kw>Access</kw>
            <kw>Server</kw>
        </keywords>
        <abstract>This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC 2865 and RFC 2866. This memo provides information for the Internet community. </abstract>
        <draft>ietf-radius-ext-07</draft>
        <updated-by>
            <doc-id>RFC3579</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2870</doc-id>
        <title>Root Name Server Operational Requirements</title>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>D. Karrenberg</name>
        </author>
        <author>
            <name>M. Kosters</name>
        </author>
        <author>
            <name>R. Plzak</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21133</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>infrastructure</kw>
            <kw>domain names</kw>
            <kw>security</kw>
        </keywords>
        <abstract>The primary focus of this document is to provide guidelines for operation of the root name servers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-dnsop-root-opreq-05</draft>
        <obsoletes>
            <doc-id>RFC2010</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0040</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2871</doc-id>
        <title>A Framework for Telephony Routing over IP</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>60664</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>TRIP</kw>
            <kw>gateway</kw>
        </keywords>
        <abstract>This document serves as a framework for Telephony Routing over IP (TRIP), which supports the discovery and exchange of IP telephony gateway routing tables between providers. This memo provides information for the Internet community. </abstract>
        <draft>ietf-iptel-gwloc-framework-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2872</doc-id>
        <title>Application and Sub Application Identity Policy Element for Use with RSVP</title>
        <author>
            <name>Y. Bernet</name>
        </author>
        <author>
            <name>R. Pabbati</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10933</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>RSVP signaling messages typically include policy data objects, which in turn contain policy elements. Policy elements may describe user and/or application information, which may be used by RSVP aware network elements to apply appropriate policy decisions to a traffic flow. This memo details the usage of policy elements that provide application information. [STANDARDS TRACK] </abstract>
        <draft>ietf-rap-rsvp-appid-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2873</doc-id>
        <title>TCP Processing of the IPv4 Precedence Field</title>
        <author>
            <name>X. Xiao</name>
        </author>
        <author>
            <name>A. Hannan</name>
        </author>
        <author>
            <name>V. Paxson</name>
        </author>
        <author>
            <name>E. Crabbe</name>
        </author>
        <date>
            <month>June</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15565</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
            <kw>internet</kw>
        </keywords>
        <abstract>This memo describes a conflict between TCP and DiffServ on the use of the three leftmost bits in the TOS octet of an IPv4 header. [STANDARDS TRACK] </abstract>
        <draft>xiao-tcp-prec-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2874</doc-id>
        <title>DNS Extensions to Support IPv6 Address Aggregation and Renumbering</title>
        <author>
            <name>M. Crawford</name>
        </author>
        <author>
            <name>C. Huitema</name>
        </author>
        <date>
            <month>July</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44204</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
        </keywords>
        <abstract>This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. [STANDARDS TRACK] </abstract>
        <draft>ietf-ipngwg-dns-lookups-08</draft>
        <updates>
            <doc-id>RFC1886</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC3152</doc-id>
            <doc-id>RFC3226</doc-id>
            <doc-id>RFC3363</doc-id>
            <doc-id>RFC3364</doc-id>
        </updated-by>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2875</doc-id>
        <title>Diffie-Hellman Proof-of-Possession Algorithms</title>
        <author>
            <name>H. Prafullchandra</name>
        </author>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>July</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45231</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>certificate</kw>
            <kw>security</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract>This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair. [STANDARDS TRACK] </abstract>
        <draft>ietf-pkix-dhpop-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2876</doc-id>
        <title>Use of the KEA and SKIPJACK Algorithms in CMS</title>
        <author>
            <name>J. Pawling</name>
        </author>
        <date>
            <month>July</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29265</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>encryption</kw>
            <kw>cryptographic</kw>
            <kw>message</kw>
            <kw>syntax</kw>
        </keywords>
        <abstract>This document describes the conventions for using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted- data content types. This memo provides information for the Internet community. </abstract>
        <draft>ietf-smime-cmskea-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2877</doc-id>
        <title>5250 Telnet Enhancements</title>
        <author>
            <name>T. Murphy</name>
        </author>
        <author>
            <name>Jr.</name>
        </author>
        <author>
            <name>P. Rieth</name>
        </author>
        <author>
            <name>J. Stevens</name>
        </author>
        <date>
            <month>July</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>83369</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>client</kw>
            <kw>server</kw>
            <kw>printer</kw>
        </keywords>
        <abstract>This memo describes the interface to the IBM 5250 Telnet server that allows client Telnet to request a Telnet terminal or printer session using a specific device name. This memo provides information for the Internet community. </abstract>
        <draft>ietf-tn3270e-tn5250e-05</draft>
        <updates>
            <doc-id>RFC1205</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2878</doc-id>
        <title>PPP Bridging Control Protocol (BCP)</title>
        <author>
            <name>M. Higashiyama</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <date>
            <month>July</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>79527</char-count>
            <page-count>38</page-count>
        </format>
        <keywords>
            <kw>PPP-BCP</kw>
            <kw>point-to-point</kw>
            <kw>datagrams</kw>
            <kw>network</kw>
        </keywords>
        <abstract>This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. [STANDARDS TRACK] </abstract>
        <draft>ietf-pppext-bcp-04</draft>
        <obsoletes>
            <doc-id>RFC1638</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3518</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2879</doc-id>
        <title>Content Feature Schema for Internet Fax (V2)</title>
        <author>
            <name>G. Klyne</name>
        </author>
        <author>
            <name>L. McIntyre</name>
        </author>
        <date>
            <month>August</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>104032</char-count>
            <page-count>58</page-count>
        </format>
        <keywords>
            <kw>media</kw>
            <kw>features</kw>
            <kw>mechanism</kw>
        </keywords>
        <abstract>This document defines a content media feature schema for Internet fax. [STANDARDS TRACK] </abstract>
        <draft>ietf-fax-feature-schema-v2-01</draft>
        <obsoletes>
            <doc-id>RFC2531</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2880</doc-id>
        <title>Internet Fax T.30 Feature Mapping</title>
        <author>
            <name>L. McIntyre</name>
        </author>
        <author>
            <name>G. Klyne</name>
        </author>
        <date>
            <month>August</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>75973</char-count>
            <page-count>37</page-count>
        </format>
        <keywords>
            <kw>schema</kw>
            <kw>media</kw>
            <kw>tags</kw>
        </keywords>
        <abstract>This document describes how to map Group 3 fax capability identification bits, described in ITU T.30, into the Internet fax feature schema described in "Content feature schema for Internet fax". This memo provides information for the Internet community. </abstract>
        <draft>ietf-fax-feature-t30-mapping-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2881</doc-id>
        <title>Network Access Server Requirements Next Generation (NASREQNG) NAS Model</title>
        <author>
            <name>D. Mitton</name>
        </author>
        <author>
            <name>M. Beadles</name>
        </author>
        <date>
            <month>July</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45029</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>RADIUS</kw>
            <kw>remote</kw>
            <kw>authentication</kw>
            <kw>dial-up</kw>
            <kw>user service</kw>
        </keywords>
        <abstract>This document describes the terminology and gives a model of typical Network Access Server (NAS). This memo provides information for the Internet community. </abstract>
        <draft>ietf-nasreq-nasmodel-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2882</doc-id>
        <title>Network Access Servers Requirements: Extended RADIUS Practices</title>
        <author>
            <name>D. Mitton</name>
        </author>
        <date>
            <month>July</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31426</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>NAS</kw>
            <kw>remote</kw>
            <kw>authentication</kw>
            <kw>dial-in</kw>
            <kw>user service</kw>
        </keywords>
        <abstract>This document describes current practices implemented in NAS products that go beyond the scope of the RADIUS (Remote Authentication Dial In User Service) RFCs 2138, 2139. This memo provides information for the Internet community. </abstract>
        <draft>ietf-nasreq-ext-radiuspract-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2883</doc-id>
        <title>An Extension to the Selective Acknowledgement (SACK) Option for TCP</title>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>J. Mahdavi</name>
        </author>
        <author>
            <name>M. Mathis</name>
        </author>
        <author>
            <name>M. Podolsky</name>
        </author>
        <date>
            <month>July</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35794</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>SACK</kw>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
            <kw>packets</kw>
            <kw>sender</kw>
            <kw>receiver</kw>
        </keywords>
        <abstract>This note defines an extension of the Selective Acknowledgement (SACK) Option for TCP. [STANDARDS TRACK] </abstract>
        <draft>floyd-sack-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2884</doc-id>
        <title>Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks</title>
        <author>
            <name>J. Hadi Salim</name>
        </author>
        <author>
            <name>U. Ahmed</name>
        </author>
        <date>
            <month>July</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44647</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>end-to-end</kw>
            <kw>TCP</kw>
            <kw>transmission</kw>
            <kw>control</kw>
        </keywords>
        <abstract>This memo presents a performance study of the Explicit Congestion Notification (ECN) mechanism in the TCP/IP protocol using our implementation on the Linux Operating System. This memo provides information for the Internet community. </abstract>
        <draft>hadi-jhsua-ecnperf-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2885</doc-id>
        <title>Megaco Protocol version 0.8</title>
        <author>
            <name>F. Cuervo</name>
        </author>
        <author>
            <name>N. Greene</name>
        </author>
        <author>
            <name>C. Huitema</name>
        </author>
        <author>
            <name>A. Rayhan</name>
        </author>
        <author>
            <name>B. Rosen</name>
        </author>
        <author>
            <name>J. Segers</name>
        </author>
        <date>
            <month>August</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>344871</char-count>
            <page-count>170</page-count>
        </format>
        <keywords>
            <kw>H.248</kw>
            <kw>media</kw>
            <kw>gateway</kw>
            <kw>control</kw>
        </keywords>
        <abstract>This document is common text with Recommendation H.248 as redetermined in Geneva, February 2000. It must be read in conjunction with the Megaco Errata, RFC 2886. [STANDARDS TRACK] </abstract>
        <draft>ietf-megaco-protocol-08</draft>
        <obsoleted-by>
            <doc-id>RFC3015</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2886</doc-id>
        <title>Megaco Errata</title>
        <author>
            <name>T. Taylor</name>
        </author>
        <date>
            <month>August</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41311</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>H.248</kw>
            <kw>media</kw>
            <kw>gateway</kw>
            <kw>control</kw>
        </keywords>
        <abstract>This document records the errors found in the Megaco/H.248 protocol document, along with the changes proposed in the text of that document to resolve them. [STANDARDS TRACK] </abstract>
        <draft>ietf-megaco-errata-03</draft>
        <obsoleted-by>
            <doc-id>RFC3015</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2887</doc-id>
        <title>The Reliable Multicast Design Space for Bulk Data Transfer</title>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>B. Whetten</name>
        </author>
        <author>
            <name>R. Kermode</name>
        </author>
        <author>
            <name>L. Vicisano</name>
        </author>
        <author>
            <name>M. Luby</name>
        </author>
        <date>
            <month>August</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51135</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>application</kw>
            <kw>RM</kw>
            <kw>congestion</kw>
            <kw>control</kw>
            <kw>data</kw>
        </keywords>
        <abstract>This document provides an overview of the design space and the ways in which application constraints affect possible solutions. This memo provides information for the Internet community. </abstract>
        <draft>ietf-rmt-design-space-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2888</doc-id>
        <title>Secure Remote Access with L2TP</title>
        <author>
            <name>P. Srisuresh</name>
        </author>
        <date>
            <month>August</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41255</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>layer two</kw>
            <kw>tunneling</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>The objective of this document is to extend security characteristics of IPsec to remote access users, as they dial-in through the Internet. This memo provides information for the Internet community. </abstract>
        <draft>srisuresh-secure-ra-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2889</doc-id>
        <title>Benchmarking Methodology for LAN Switching Devices</title>
        <author>
            <name>R. Mandeville</name>
        </author>
        <author>
            <name>J. Perser</name>
        </author>
        <date>
            <month>August</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>73251</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
            <kw>local</kw>
            <kw>area</kw>
            <kw>network</kw>
            <kw>MAC</kw>
            <kw>medium</kw>
            <kw>access</kw>
            <kw>control</kw>
        </keywords>
        <abstract>This document is intended to provide methodology for the benchmarking of local area network (LAN) switching devices. This memo provides information for the Internet community. </abstract>
        <draft>ietf-bmwg-mswitch-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2890</doc-id>
        <title>Key and Sequence Number Extensions to GRE</title>
        <author>
            <name>G. Dommety</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14503</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>generic</kw>
            <kw>routing</kw>
            <kw>encapsulation</kw>
        </keywords>
        <abstract>This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header. [STANDARDS TRACK] </abstract>
        <draft>dommety-gre-ext-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2891</doc-id>
        <title>LDAP Control Extension for Server Side Sorting of Search Results</title>
        <author>
            <name>T. Howes</name>
        </author>
        <author>
            <name>M. Wahl</name>
        </author>
        <author>
            <name>A. Anantha</name>
        </author>
        <date>
            <month>August</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15833</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document describes two LDAPv3 control extensions for server side sorting of search results. These controls allows a client to specify the attribute types and matching rules a server should use when returning the results to an LDAP search request. [STANDARDS TRACK] </abstract>
        <draft>ietf-ldapext-sorting-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2892</doc-id>
        <title>The Cisco SRP MAC Layer Protocol</title>
        <author>
            <name>D. Tsiang</name>
        </author>
        <author>
            <name>G. Suwala</name>
        </author>
        <date>
            <month>August</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>107645</char-count>
            <page-count>52</page-count>
        </format>
        <keywords>
            <kw>spatial</kw>
            <kw>reuse</kw>
        </keywords>
        <abstract>This document specifies the MAC layer protocol, "Spatial Reuse Protocol" (SRP) for use with ring based media. This is a second version of the protocol (V2). This memo provides information for the Internet community. </abstract>
        <draft>tsiang-srp-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2893</doc-id>
        <title>Transition Mechanisms for IPv6 Hosts and Routers</title>
        <author>
            <name>R. Gilligan</name>
        </author>
        <author>
            <name>E. Nordmark</name>
        </author>
        <date>
            <month>August</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>62731</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>TRANS-IPV6</kw>
            <kw>IPv4</kw>
        </keywords>
        <abstract>This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. [STANDARDS TRACK] </abstract>
        <draft>ietf-ngtrans-mech-06</draft>
        <obsoletes>
            <doc-id>RFC1933</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2894</doc-id>
        <title>Router Renumbering for IPv6</title>
        <author>
            <name>M. Crawford</name>
        </author>
        <date>
            <month>August</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>69135</char-count>
            <page-count>32</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>operations</kw>
            <kw>scalability</kw>
            <kw>applicability</kw>
        </keywords>
        <abstract>This document defines a mechanism called Router Renumbering ("RR") which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. [STANDARDS TRACK] </abstract>
        <draft>ietf-ipngwg-router-renum-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2895</doc-id>
        <title>Remote Network Monitoring MIB Protocol Identifier Reference</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <author>
            <name>C. Bucci</name>
        </author>
        <author>
            <name>R. Iddon</name>
        </author>
        <date>
            <month>August</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>88094</char-count>
            <page-count>42</page-count>
        </format>
        <keywords>
            <kw>RMON-MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a notation describing protocol layers in a protocol encapsulation, specifically for use in encoding INDEX values for the protocolDirTable, found in the RMON-2 MIB. [STANDARDS TRACK] </abstract>
        <draft>ietf-rmonmib-rmonprot-ref-01</draft>
        <obsoletes>
            <doc-id>RFC2074</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3395</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2896</doc-id>
        <title>Remote Network Monitoring MIB Protocol Identifier Macros</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <author>
            <name>C. Bucci</name>
        </author>
        <author>
            <name>R. Iddon</name>
        </author>
        <date>
            <month>August</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>135768</char-count>
            <page-count>84</page-count>
        </format>
        <keywords>
            <kw>RMON</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo contains various protocol identifier examples, which can be used to produce valid protocolDirTable INDEX encodings, as defined by the Remote Network Monitoring MIB and the RMON Protocol Identifier Reference. This memo provides information for the Internet community. </abstract>
        <draft>ietf-rmonmib-rmonprot-mac-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2897</doc-id>
        <title>Proposal for an MGCP Advanced Audio Package</title>
        <author>
            <name>D. Cromwell</name>
        </author>
        <date>
            <month>August</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>67459</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>media</kw>
            <kw>gateway</kw>
            <kw>control</kw>
            <kw>protocol</kw>
            <kw>IVR</kw>
            <kw>interactive</kw>
            <kw>voice</kw>
            <kw>response</kw>
        </keywords>
        <abstract>This document is a proposal to add a new event/signal package to the MGCP (Media Gateway Control Protocol) protocol to control an ARF (Audio Resource Function) which may reside on a Media Gateway or specialized Audio Server. This memo provides information for the Internet community. </abstract>
        <draft>cromwell-mgcp-advanced-audio-pkg-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2898</doc-id>
        <title>PKCS #5: Password-Based Cryptography Specification Version 2.0</title>
        <author>
            <name>B. Kaliski</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>68692</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>public-key</kw>
            <kw>authentication</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract>This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques. This memo provides information for the Internet community. </abstract>
        <draft>kaliski-pcks5-v2-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2899</doc-id>
        <title>Request for Comments Summary RFC Numbers 2800-2899</title>
        <author>
            <name>S. Ginoza</name>
        </author>
        <date>
            <month>May</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43805</char-count>
            <page-count>22</page-count>
        </format>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2900</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Reynolds</name>
        </author>
        <author>
            <name>R. Braden</name>
        </author>
        <author>
            <name>S. Ginoza</name>
        </author>
        <date>
            <month>August</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>112809</char-count>
            <page-count>42</page-count>
        </format>
        <abstract>This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 17, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. This memo is an Internet Standard. </abstract>
        <obsoletes>
            <doc-id>RFC2800</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3000</doc-id>
        </obsoleted-by>
        <current-status>HISTORIC</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2901</doc-id>
        <title>Guide to Administrative Procedures of the Internet Infrastructure</title>
        <author>
            <name>Z. Wenzel</name>
        </author>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>S. Huter</name>
        </author>
        <date>
            <month>August</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63680</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>address space</kw>
            <kw>routing</kw>
            <kw>database</kw>
            <kw>domain name</kw>
            <kw>registration</kw>
        </keywords>
        <abstract>This document describes the administrative procedures for networks seeking to connect to the global Internet. This memo provides information for the Internet community. </abstract>
        <draft>wenzel-nsrc-02</draft>
        <is-also>
            <doc-id>FYI0037</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2902</doc-id>
        <title>Overview of the 1998 IAB Routing Workshop</title>
        <author>
            <name>S. Deering</name>
        </author>
        <author>
            <name>S. Hares</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>R. Perlman</name>
        </author>
        <date>
            <month>August</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32773</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>architecture</kw>
            <kw>board</kw>
        </keywords>
        <abstract>This document is an overview of a Routing workshop held by the Internet Architecture Board (IAB) during March 25-27, 1998. This memo provides information for the Internet community. </abstract>
        <draft>ietf-iab-rtrws-over-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2903</doc-id>
        <title>Generic AAA Architecture</title>
        <author>
            <name>C. de Laat</name>
        </author>
        <author>
            <name>G. Gross</name>
        </author>
        <author>
            <name>L. Gommans</name>
        </author>
        <author>
            <name>J. Vollbrecht</name>
        </author>
        <author>
            <name>D. Spence</name>
        </author>
        <date>
            <month>August</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>60627</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>authentication</kw>
            <kw>authorization</kw>
            <kw>accounting</kw>
        </keywords>
        <abstract>This memo proposes an Authentication, Authorization, Accounting (AAA) architecture that would incorporate a generic AAA server along with an application interface to a set of Application Specific Modules that could perform application specific AAA functions. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>irtf-aaaarch-generic-01</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2904</doc-id>
        <title>AAA Authorization Framework</title>
        <author>
            <name>J. Vollbrecht</name>
        </author>
        <author>
            <name>P. Calhoun</name>
        </author>
        <author>
            <name>S. Farrell</name>
        </author>
        <author>
            <name>L. Gommans</name>
        </author>
        <author>
            <name>G. Gross</name>
        </author>
        <author>
            <name>B. de Bruijn</name>
        </author>
        <author>
            <name>C. de Laat</name>
        </author>
        <author>
            <name>M. Holdrege</name>
        </author>
        <author>
            <name>D. Spence</name>
        </author>
        <date>
            <month>August</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>78098</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
            <kw>authentication</kw>
            <kw>authorization</kw>
            <kw>accounting</kw>
        </keywords>
        <abstract>This memo serves as the base requirements for Authorization of Internet Resources and Services (AIRS). It presents an architectural framework for understanding the authorization of Internet resources and services and derives requirements for authorization protocols. This memo provides information for the Internet community. </abstract>
        <draft>irtf-aaaarch-authorization-framework-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2905</doc-id>
        <title>AAA Authorization Application Examples</title>
        <author>
            <name>J. Vollbrecht</name>
        </author>
        <author>
            <name>P. Calhoun</name>
        </author>
        <author>
            <name>S. Farrell</name>
        </author>
        <author>
            <name>L. Gommans</name>
        </author>
        <author>
            <name>G. Gross</name>
        </author>
        <author>
            <name>B. de Bruijn</name>
        </author>
        <author>
            <name>C. de Laat</name>
        </author>
        <author>
            <name>M. Holdrege</name>
        </author>
        <author>
            <name>D. Spence</name>
        </author>
        <date>
            <month>August</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>118645</char-count>
            <page-count>53</page-count>
        </format>
        <keywords>
            <kw>authentication</kw>
            <kw>authorization</kw>
            <kw>accounting</kw>
        </keywords>
        <abstract>This memo describes several examples of applications requiring authorization. This memo provides information for the Internet community. </abstract>
        <draft>irtf-aaaarch-authorization-apps-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2906</doc-id>
        <title>AAA Authorization Requirements</title>
        <author>
            <name>S. Farrell</name>
        </author>
        <author>
            <name>J. Vollbrecht</name>
        </author>
        <author>
            <name>P. Calhoun</name>
        </author>
        <author>
            <name>L. Gommans</name>
        </author>
        <author>
            <name>G. Gross</name>
        </author>
        <author>
            <name>B. de Bruijn</name>
        </author>
        <author>
            <name>C. de Laat</name>
        </author>
        <author>
            <name>M. Holdrege</name>
        </author>
        <author>
            <name>D. Spence</name>
        </author>
        <date>
            <month>August</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48618</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>authentication</kw>
            <kw>authorization</kw>
            <kw>accounting</kw>
        </keywords>
        <abstract>This document specifies the requirements that Authentication Authorization Accounting (AAA) protocols must meet in order to support authorization services in the Internet. This memo provides information for the Internet community. </abstract>
        <draft>irtf-aaaarch-authorization-reqs-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2907</doc-id>
        <title>MADCAP Multicast Scope Nesting State Option</title>
        <author>
            <name>R. Kermode</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27572</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>address</kw>
            <kw>dynamic</kw>
            <kw>allocation</kw>
            <kw>client</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document defines a new option to the Multicast Address Dynamic Client Allocation Protocol (MADCAP) to support nested scoping. [STANDARDS TRACK] </abstract>
        <draft>ietf-malloc-madcap-nest-opt-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2908</doc-id>
        <title>The Internet Multicast Address Allocation Architecture</title>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>D. Estrin</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30515</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>MALLOC</kw>
            <kw>host server</kw>
            <kw>intra-domain</kw>
            <kw>inter-domain</kw>
        </keywords>
        <abstract>This document proposes a multicast address allocation architecture (MALLOC) for the Internet. This memo provides information for the Internet community. </abstract>
        <draft>ietf-malloc-arch-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2909</doc-id>
        <title>The Multicast Address-Set Claim (MASC) Protocol</title>
        <author>
            <name>P. Radoslavov</name>
        </author>
        <author>
            <name>D. Estrin</name>
        </author>
        <author>
            <name>R. Govindan</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>S. Kumar</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>127278</char-count>
            <page-count>56</page-count>
        </format>
        <keywords>
            <kw>MASC</kw>
            <kw>inter-domain</kw>
            <kw>router</kw>
        </keywords>
        <abstract>This document describes the Multicast Address-Set Claim (MASC) protocol which can be used for inter-domain multicast address set allocation. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-malloc-masc-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2910</doc-id>
        <title>Internet Printing Protocol/1.1: Encoding and Transport</title>
        <author>
            <name>R. Herriot</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Butler</name>
        </author>
        <author>
            <name>P. Moore</name>
        </author>
        <author>
            <name>R. Turner</name>
        </author>
        <author>
            <name>J. Wenn</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>100599</char-count>
            <page-count>46</page-count>
        </format>
        <keywords>
            <kw>IPP-E-T</kw>
            <kw>IPP</kw>
            <kw>application</kw>
            <kw>media-type</kw>
            <kw>media</kw>
            <kw>type</kw>
        </keywords>
        <abstract>This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). [STANDARDS TRACK] </abstract>
        <draft>ietf-ipp-protocol-v11-06</draft>
        <obsoletes>
            <doc-id>RFC2565</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3380</doc-id>
            <doc-id>RFC3381</doc-id>
            <doc-id>RFC3382</doc-id>
            <doc-id>RFC3510</doc-id>
            <doc-id>RFC3995</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2911</doc-id>
        <title>Internet Printing Protocol/1.1: Model and Semantics</title>
        <author>
            <name>T. Hastings</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Herriot</name>
        </author>
        <author>
            <name>R. deBry</name>
        </author>
        <author>
            <name>S. Isaacson</name>
        </author>
        <author>
            <name>P. Powell</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>575805</char-count>
            <page-count>224</page-count>
        </format>
        <keywords>
            <kw>IPP-M-S</kw>
            <kw>IPP</kw>
            <kw>application</kw>
            <kw>media-type</kw>
            <kw>job</kw>
        </keywords>
        <abstract>This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). [STANDARDS TRACK] </abstract>
        <draft>ietf-ipp-model-v11-07</draft>
        <obsoletes>
            <doc-id>RFC2566</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3380</doc-id>
            <doc-id>RFC3382</doc-id>
            <doc-id>RFC3996</doc-id>
            <doc-id>RFC3995</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2912</doc-id>
        <title>Indicating Media Features for MIME Content</title>
        <author>
            <name>G. Klyne</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20618</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>multipurpose</kw>
            <kw>mail extensions</kw>
            <kw>tag</kw>
            <kw>format</kw>
        </keywords>
        <abstract>This memo defines a Multipurpose Internet Mail Extensions (MIME) ' Content-features:' header that can be used to annotate a MIME message part using this expression format, and indicates some ways it might be used. [STANDARDS TRACK] </abstract>
        <draft>ietf-conneg-content-features-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2913</doc-id>
        <title>MIME Content Types in Media Feature Expressions</title>
        <author>
            <name>G. Klyne</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16095</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>multipurpose</kw>
            <kw>mail extensions</kw>
            <kw>tag</kw>
            <kw>format</kw>
        </keywords>
        <abstract>This memo defines a media feature tag whose value is a Multipurpose Internet Mail Extensions (MIME) content type. [STANDARDS TRACK] </abstract>
        <draft>ietf-conneg-feature-type-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2914</doc-id>
        <title>Congestion Control Principles</title>
        <author>
            <name>S. Floyd</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43823</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>end-to-end</kw>
        </keywords>
        <abstract>The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>floyd-cong-04</draft>
        <is-also>
            <doc-id>BCP0041</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2915</doc-id>
        <title>The Naming Authority Pointer (NAPTR) DNS Resource Record</title>
        <author>
            <name>M. Mealling</name>
        </author>
        <author>
            <name>R. Daniel</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41521</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>NAPTR</kw>
            <kw>domain name system</kw>
            <kw>RR</kw>
        </keywords>
        <abstract>This document describes a Domain Name System (DNS) resource record which specifies a regular expression based rewrite rule that, when applied to an existing string, will produce a new domain label or Uniform Resource Identifier (URI). [STANDARDS TRACK] </abstract>
        <draft>ietf-urn-naptr-rr-04</draft>
        <obsoleted-by>
            <doc-id>RFC3401</doc-id>
            <doc-id>RFC3402</doc-id>
            <doc-id>RFC3403</doc-id>
            <doc-id>RFC3404</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2168</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2916</doc-id>
        <title>E.164 number and DNS</title>
        <author>
            <name>P. Faltstrom</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18159</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>domain name system</kw>
        </keywords>
        <abstract>This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. [Standards Track] </abstract>
        <draft>ietf-enum-e164-dns-03</draft>
        <obsoleted-by>
            <doc-id>RFC3761</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2917</doc-id>
        <title>A Core MPLS IP VPN Architecture</title>
        <author>
            <name>K. Muthukrishnan</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35352</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>internet protocol</kw>
            <kw>virtual private networks</kw>
            <kw>multiprotocol label switching</kw>
        </keywords>
        <abstract>This memo presents an approach for building core Virtual Private Network (VPN) services in a service provider's MPLS backbone. This memo provides information for the Internet community. </abstract>
        <draft>muthurkrishnan-mpls-corevpn-arch-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2918</doc-id>
        <title>Route Refresh Capability for BGP-4</title>
        <author>
            <name>E. Chen</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7354</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>border</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document defines a new Border Gateway Protocol (BGP) capability termed 'Route Refresh Capability', which would allow the dynamic exchange of route refresh request between BGP speakers and subsequent re-advertisement of the respective Adj-RIB-Out. [STANDARDS TRACK] </abstract>
        <draft>ietf-idr-bgp-route-refresh-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2919</doc-id>
        <title>List-Id: A Structured Field and Namespace for the Identification of Mailing Lists</title>
        <author>
            <name>R. Chandhok</name>
        </author>
        <author>
            <name>G. Wenger</name>
        </author>
        <date>
            <month>March</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18480</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>server</kw>
            <kw>clients</kw>
            <kw>user agents</kw>
        </keywords>
        <abstract>Software that handles electronic mailing list messages (servers and user agents) needs a way to reliably identify messages that belong to a particular mailing list. With the advent of list management headers, it has become even more important to provide a unique identifier for a mailing list regardless of the particular host that serves as the list processor at any given time. [STANDARDS TRACK] </abstract>
        <draft>chandhok-listid-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2920</doc-id>
        <title>SMTP Service Extension for Command Pipelining</title>
        <author>
            <name>N. Freed</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17065</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>SMTP-Pipe</kw>
            <kw>simple</kw>
            <kw>mail</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>TCP</kw>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service whereby a server can indicate the extent of its ability to accept multiple commands in a single Transmission Control Protocol (TCP) send operation. [STANDARDS TRACK] </abstract>
        <draft>freed-smtp-pipe-01</draft>
        <obsoletes>
            <doc-id>RFC2197</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0060</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2921</doc-id>
        <title>6BONE pTLA and pNLA Formats (pTLA)</title>
        <author>
            <name>B. Fink</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14218</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>IPv6</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>pseudo</kw>
            <kw>top-level</kw>
            <kw>next-level</kw>
            <kw>aggregation</kw>
            <kw>identifiers</kw>
        </keywords>
        <abstract>This memo defines how the 6bone uses the 3FFE::/16 IPv6 address prefix, allocated in RFC 2471, "IPv6 Testing Address Allocation", to create pseudo Top-Level Aggregation Identifiers (pTLA's) and pseudo Next-Level Aggregation Identifiers (pNLA's). This memo provides information for the Internet community. </abstract>
        <draft>ietf-ngtrans-6bone-ptla-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2922</doc-id>
        <title>Physical Topology MIB</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <author>
            <name>K. Jones</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>66830</char-count>
            <page-count>32</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing physical topology identification and discovery. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ptopomib-mib-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2923</doc-id>
        <title>TCP Problems with Path MTU Discovery</title>
        <author>
            <name>K. Lahey</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30976</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
            <kw>maximum</kw>
            <kw>unit</kw>
        </keywords>
        <abstract>This memo catalogs several known Transmission Control Protocol (TCP) implementation problems dealing with Path Maximum Transmission Unit Discovery (PMTUD), including the long-standing black hole problem, stretch acknowlegements (ACKs) due to confusion between Maximum Segment Size (MSS) and segment size, and MSS advertisement based on PMTU. This memo provides information for the Internet community. </abstract>
        <draft>ietf-tcpimpl-pmtud-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2924</doc-id>
        <title>Accounting Attributes and Record Formats</title>
        <author>
            <name>N. Brownlee</name>
        </author>
        <author>
            <name>A. Blount</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>75561</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>data</kw>
            <kw>transport</kw>
            <kw>integrated</kw>
        </keywords>
        <abstract>This document summarises Internet Engineering Task Force (IETF) and International Telecommunication Union (ITU-T) documents related to Accounting. This memo provides information for the Internet community. </abstract>
        <draft>ietf-aaa-accounting-attribute-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2925</doc-id>
        <title>Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations</title>
        <author>
            <name>K. White</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>150691</char-count>
            <page-count>77</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. [STANDARDS TRACK] </abstract>
        <draft>ietf-disman-remops-mib-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2926</doc-id>
        <title>Conversion of LDAP Schemas to and from SLP Templates</title>
        <author>
            <name>J. Kempf</name>
        </author>
        <author>
            <name>R. Moats</name>
        </author>
        <author>
            <name>P. St. Pierre</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>55365</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>service location</kw>
            <kw>protocol</kw>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
        </keywords>
        <abstract>This document describes a procedure for mapping between Service Location Protocol (SLP) service advertisements and lightweight directory access protocol (LDAP) descriptions of services. This memo provides information for the Internet community. </abstract>
        <draft>ietf-svcloc-template-conversion-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2927</doc-id>
        <title>MIME Directory Profile for LDAP Schema</title>
        <author>
            <name>M. Wahl</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16122</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document defines a multipurpose internet mail extensions (MIME) directory profile for holding a lightweight directory access protocol (LDAP) schema. This memo provides information for the Internet community. </abstract>
        <draft>ietf-schema-ldap-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2928</doc-id>
        <title>Initial IPv6 Sub-TLA ID Assignments</title>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>S. Deering</name>
        </author>
        <author>
            <name>R. Fink</name>
        </author>
        <author>
            <name>T. Hain</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11882</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>internet protocol</kw>
            <kw>sub-top-level</kw>
            <kw>aggregation</kw>
            <kw>identifiers</kw>
            <kw>address</kw>
            <kw>registries</kw>
        </keywords>
        <abstract>This document defines initial assignments of IPv6 Sub-Top-Level Aggregation Identifiers (Sub-TLA ID) to the Address Registries. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ipngwg-iana-tla-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2929</doc-id>
        <title>Domain Name System (DNS) IANA Considerations</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>E. Brunner-Williams</name>
        </author>
        <author>
            <name>B. Manning</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22454</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>internet assigned numbers authority</kw>
            <kw>resource records</kw>
            <kw>RRs</kw>
        </keywords>
        <abstract>This document discusses the Internet Assigned Number Authority (IANA) parameter assignment considerations given for the allocation of Domain Name System (DNS) classes, Resource Record (RR) types, operation codes, error codes, etc. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-dnsext-iana-dns-01</draft>
        <is-also>
            <doc-id>BCP0042</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2930</doc-id>
        <title>Secret Key Establishment for DNS (TKEY RR)</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34894</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>TKEY-RR</kw>
            <kw>domain name system</kw>
            <kw>resource record</kw>
            <kw>transaction key</kw>
        </keywords>
        <abstract>This document describes a Transaction Key (TKEY) RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server. [STANDARDS TRACK] </abstract>
        <draft>ietf-dnsext-tkey-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2931</doc-id>
        <title>DNS Request and Transaction Signatures ( SIG(0)s )</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19073</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>domain name system</kw>
            <kw>data</kw>
            <kw>security</kw>
        </keywords>
        <abstract>This document describes the minor but non-interoperable changes in Request and Transaction signature resource records ( SIG(0)s ) that implementation experience has deemed necessary. [STANDARDS TRACK] </abstract>
        <draft>ietf-dnsext-sig-zero-02</draft>
        <updates>
            <doc-id>RFC2535</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2932</doc-id>
        <title>IPv4 Multicast Routing MIB</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>50430</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing IP Multicast Routing for IPv4, independent of the specific multicast routing protocol in use. [STANDARDS TRACK] </abstract>
        <draft>ietf-idmr-multicast-routmib-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2933</doc-id>
        <title>Internet Group Management Protocol MIB</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33406</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>igmp</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Internet Group Management Protocol (IGMP). [STANDARDS TRACK] </abstract>
        <draft>ietf-idmr-igmp-mib-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2934</doc-id>
        <title>Protocol Independent Multicast MIB for IPv4</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>B. Fenner</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48379</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocol for IPv4. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-idmr-pim-mib-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2935</doc-id>
        <title>Internet Open Trading Protocol (IOTP) HTTP Supplement</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>C. Smith</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16168</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>IOTP-HTTP</kw>
            <kw>hypertext</kw>
            <kw>XML</kw>
            <kw>extensible</kw>
            <kw>markup</kw>
            <kw>language</kw>
            <kw>transfer</kw>
        </keywords>
        <abstract>The goal of mapping to the transport layer is to ensure that the underlying XML documents are carried successfully between the various parties. This document describes that mapping for the Hyper Text Transport Protocol (HTTP), Versions 1.0 and 1.1. [STANDARDS TRACK] </abstract>
        <draft>ietf-trade-iotp-http-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2936</doc-id>
        <title>HTTP MIME Type Handler Detection</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>C. Smith</name>
        </author>
        <author>
            <name>D. Soroka</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25238</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>hypertext</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>Entities composing web pages to provide services over the Hypertext Transfer Protocol (HTTP) frequently have the problem of not knowing what Multipurpose Internet Mail Extensions (MIME) types have handlers installed at a user's browser. This document summarizes reasonable techniques to solve this problem for most of the browsers actually deployed on the Internet as of early 2000. This memo provides information for the Internet community. </abstract>
        <draft>ietf-trade-mime-detector-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2937</doc-id>
        <title>The Name Service Search Option for DHCP</title>
        <author>
            <name>C. Smith</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8368</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>dynamic</kw>
            <kw>host</kw>
            <kw>configuration</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to specify the order in which name services should be consulted when resolving hostnames and other information. [STANDARDS TRACK] </abstract>
        <draft>ietf-dhc-nsso-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2938</doc-id>
        <title>Identifying Composite Media Features</title>
        <author>
            <name>G. Klyne</name>
        </author>
        <author>
            <name>L. Masinter</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34451</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>tags</kw>
            <kw>expression</kw>
            <kw>hash</kw>
        </keywords>
        <abstract>This document describes an abbreviated format for a composite media feature set, based upon a hash of the feature expression describing that composite. [STANDARDS TRACK] </abstract>
        <draft>ietf-conneg-feature-hash-05</draft>
        <updates>
            <doc-id>RFC2533</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2939</doc-id>
        <title>Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types</title>
        <author>
            <name>R. Droms</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13631</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>dynamic</kw>
            <kw>host</kw>
            <kw>configuration</kw>
            <kw>protocol</kw>
            <kw>internet</kw>
            <kw>assigned</kw>
            <kw>numbers</kw>
            <kw>authority</kw>
        </keywords>
        <abstract>This document describes the procedure for defining new DHCP options and message types. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-dhc-new-opt-msg-02</draft>
        <obsoletes>
            <doc-id>RFC2489</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0043</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2940</doc-id>
        <title>Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients</title>
        <author>
            <name>A. Smith</name>
        </author>
        <author>
            <name>D. Partain</name>
        </author>
        <author>
            <name>J. Seligson</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52427</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>cops</kw>
            <kw>mib</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing a client of the Common Open Policy Service (COPS) protocol. [STANDARDS TRACK] </abstract>
        <draft>ietf-rap-cops-client-mib-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2941</doc-id>
        <title>Telnet Authentication Option</title>
        <author>
            <name>T. Ts'o</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Altman</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52427</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>TOPT-AUTH</kw>
            <kw>encryption</kw>
            <kw>Security</kw>
        </keywords>
        <abstract>This document describes the authentication option to the telnet protocol as a generic method for negotiating an authentication type and mode including whether encryption should be used and if credentials should be forwarded. [STANDARDS TRACK] </abstract>
        <draft>tso-telnet-auth-enc-05</draft>
        <obsoletes>
            <doc-id>RFC1416</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2942</doc-id>
        <title>Telnet Authentication: Kerberos Version 5</title>
        <author>
            <name>T. Ts'o</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14562</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>encryption</kw>
        </keywords>
        <abstract>This document describes how Kerberos Version 5 is used with the telnet protocol. It describes an telnet authentication suboption to be used with the telnet authentication option. [STANDARDS TRACK] </abstract>
        <draft>tso-telnet-krb5-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2943</doc-id>
        <title>TELNET Authentication Using DSA</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>T. Horting</name>
        </author>
        <author>
            <name>P. Yee</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21694</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>digital</kw>
            <kw>signature</kw>
            <kw>algorithm</kw>
        </keywords>
        <abstract>This document defines a telnet authentication mechanism using the Digital Signature Algorithm (DSA). It relies on the Telnet Authentication Option. [STANDARDS TRACK] </abstract>
        <draft>housley-telnet-auth-dsa-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2944</doc-id>
        <title>Telnet Authentication: SRP</title>
        <author>
            <name>T. Wu</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13933</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>secure</kw>
            <kw>remote</kw>
            <kw>password</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document specifies an authentication scheme for the Telnet protocol under the framework described in RFC 2941, using the Secure Remote Password Protocol (SRP) authentication mechanism. [STANDARDS TRACK] </abstract>
        <draft>wu-telnet-auth-srp-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2945</doc-id>
        <title>The SRP Authentication and Key Exchange System</title>
        <author>
            <name>T. Wu</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17843</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>secure</kw>
            <kw>remote</kw>
            <kw>password</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document describes a cryptographically strong network authentication mechanism known as the Secure Remote Password (SRP) protocol. [STANDARDS TRACK] </abstract>
        <draft>wu-srp-auth-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2946</doc-id>
        <title>Telnet Data Encryption Option</title>
        <author>
            <name>T. Ts'o</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16527</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>stream</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This document describes a the telnet encryption option as a generic method of providing data confidentiality services for the telnet data stream. [STANDARDS TRACK] </abstract>
        <draft>tso-telnet-encryption-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2947</doc-id>
        <title>Telnet Encryption: DES3 64 bit Cipher Feedback</title>
        <author>
            <name>J. Altman</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11064</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>data</kw>
            <kw>encryption</kw>
            <kw>standard</kw>
        </keywords>
        <abstract>This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in cipher feedback mode with the telnet encryption option. [STANDARDS TRACK] </abstract>
        <draft>altman-telnet-enc-des3-cfb-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2948</doc-id>
        <title>Telnet Encryption: DES3 64 bit Output Feedback</title>
        <author>
            <name>J. Altman</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11064</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>data</kw>
            <kw>encryption</kw>
            <kw>standard</kw>
        </keywords>
        <abstract>This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in output feedback mode with the telnet encryption option. [STANDARDS TRACK] </abstract>
        <draft>altman-telnet-enc-des3-ofb-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2949</doc-id>
        <title>Telnet Encryption: CAST-128 64 bit Output Feedback</title>
        <author>
            <name>J. Altman</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9240</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>algorithm</kw>
            <kw>option</kw>
        </keywords>
        <abstract>This document specifies how to use the CAST-128 encryption algorithm in output feedback mode with the telnet encryption option. Two key sizes are defined: 40 bit and 128 bit. [STANDARDS TRACK] </abstract>
        <draft>altman-telnet-enc-cast128-ofb-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2950</doc-id>
        <title>Telnet Encryption: CAST-128 64 bit Cipher Feedback</title>
        <author>
            <name>J. Altman</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9267</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>algorithm</kw>
            <kw>option</kw>
        </keywords>
        <abstract>This document specifies how to use the CAST-128 encryption algorithm in cipher feedback mode with the telnet encryption option. Two key sizes are defined: 40 bit and 128 bit. [STANDARDS TRACK] </abstract>
        <draft>altman-telnet-enc-cast128-cfb-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2951</doc-id>
        <title>TELNET Authentication Using KEA and SKIPJACK</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>T. Horting</name>
        </author>
        <author>
            <name>P. Yee</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20757</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>key exchange</kw>
            <kw>algorithm</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract>This document defines a method to authenticate TELNET using the Key Exchange Algorithm (KEA), and encryption of the TELNET stream using SKIPJACK. This memo provides information for the Internet community. </abstract>
        <draft>housely-telnet-auth-keasj-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2952</doc-id>
        <title>Telnet Encryption: DES 64 bit Cipher Feedback</title>
        <author>
            <name>T. Ts'o</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9064</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>data</kw>
            <kw>encryption</kw>
            <kw>standard</kw>
        </keywords>
        <abstract>This document specifies how to use the DES encryption algorithm in cipher feedback mode with the telnet encryption option. This memo provides information for the Internet community. </abstract>
        <draft>tso-telnet-enc-des-cfb-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2953</doc-id>
        <title>Telnet Encryption: DES 64 bit Output Feedback</title>
        <author>
            <name>T. Ts'o</name>
        </author>
        <date>
            <month>September</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8995</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>data</kw>
            <kw>encryption</kw>
            <kw>standard</kw>
        </keywords>
        <abstract>This document specifies how to use the data encryption standard (DES) encryption algorithm in output feedback mode with the telnet encryption option. This memo provides information for the Internet community. </abstract>
        <draft>tso-telnet-enc-des-ofb-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2954</doc-id>
        <title>Definitions of Managed Objects for Frame Relay Service</title>
        <author>
            <name>K. Rehbehn</name>
        </author>
        <author>
            <name>D. Fowler</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>164217</char-count>
            <page-count>76</page-count>
        </format>
        <keywords>
            <kw>FR-MIB</kw>
            <kw>mib</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in Transmission Control Protocol/Internet Protocol-based (TCP/IP) internets. In particular, it defines objects for managing the frame relay service. [STANDARDS TRACK] </abstract>
        <draft>ietf-frnetmib-frs-mib-12</draft>
        <obsoletes>
            <doc-id>RFC1604</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2955</doc-id>
        <title>Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function</title>
        <author>
            <name>K. Rehbehn</name>
        </author>
        <author>
            <name>O. Nicklass</name>
        </author>
        <author>
            <name>G. Mouradian</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>83281</char-count>
            <page-count>39</page-count>
        </format>
        <keywords>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>permanent</kw>
            <kw>virtual</kw>
            <kw>connections</kw>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a Management Information Base (MIB) to configure, monitor, and control a service interworking function (IWF) for Permanent Virtual Connections (PVC) between Frame Relay and Asynchronous Transfer Mode (ATM) technologies. [STANDARDS TRACK] </abstract>
        <draft>ietf-frnetmib-atmiwf-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2956</doc-id>
        <title>Overview of 1999 IAB Network Layer Workshop</title>
        <author>
            <name>M. Kaat</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36830</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>intenret</kw>
            <kw>architecture</kw>
            <kw>board</kw>
        </keywords>
        <abstract>This document is an overview of a workshop held by the Internet Architecture Board (IAB) on the Internet Network Layer architecture hosted by SURFnet in Utrecht, the Netherlands on 7-9 July 1999. The goal of the workshop was to understand the state of the network layer and its impact on continued growth and usage of the Internet. This memo provides information for the Internet community. </abstract>
        <draft>iab-ntwlyrws-over-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2957</doc-id>
        <title>The application/whoispp-query Content-Type</title>
        <author>
            <name>L. Daigle</name>
        </author>
        <author>
            <name>P. Faltstrom</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10262</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>mime</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>media-types</kw>
        </keywords>
        <abstract>The intention of this document, in conjunction with RFC 2958, is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions. This memo provides information for the Internet community. </abstract>
        <draft>daigle-wppresp-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2958</doc-id>
        <title>The application/whoispp-response Content-type</title>
        <author>
            <name>L. Daigle</name>
        </author>
        <author>
            <name>P. Faltstrom</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9995</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>mime</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>media-types</kw>
        </keywords>
        <abstract>The intention of this document, in conjunction with RFC 2957, is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions. This memo provides information for the Internet community. </abstract>
        <draft>daigle-wppquery-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2959</doc-id>
        <title>Real-Time Transport Protocol Management Information Base</title>
        <author>
            <name>M. Baugher</name>
        </author>
        <author>
            <name>B. Strahm</name>
        </author>
        <author>
            <name>I. Suconick</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>62063</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>RTP</kw>
            <kw>MIB</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS TRACK] </abstract>
        <draft>ietf-avt-rtp-mib-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2960</doc-id>
        <title>Stream Control Transmission Protocol</title>
        <author>
            <name>R. Stewart</name>
        </author>
        <author>
            <name>Q. Xie</name>
        </author>
        <author>
            <name>K. Morneault</name>
        </author>
        <author>
            <name>C. Sharp</name>
        </author>
        <author>
            <name>H. Schwarzbauer</name>
        </author>
        <author>
            <name>T. Taylor</name>
        </author>
        <author>
            <name>I. Rytina</name>
        </author>
        <author>
            <name>M. Kalla</name>
        </author>
        <author>
            <name>L. Zhang</name>
        </author>
        <author>
            <name>V. Paxson</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>297757</char-count>
            <page-count>134</page-count>
        </format>
        <keywords>
            <kw>SCTP</kw>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>transport</kw>
            <kw>packet</kw>
            <kw>network</kw>
        </keywords>
        <abstract>This document describes the Stream Control Transmission Protocol (SCTP). [STANDARDS TRACK] </abstract>
        <draft>ietf-sigtran-sctp-13</draft>
        <updated-by>
            <doc-id>RFC3309</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2961</doc-id>
        <title>RSVP Refresh Overhead Reduction Extensions</title>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>D. Gan</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>P. Pan</name>
        </author>
        <author>
            <name>F. Tommasi</name>
        </author>
        <author>
            <name>S. Molendini</name>
        </author>
        <date>
            <month>April</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>81675</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
            <kw>messages</kw>
        </keywords>
        <abstract>This document describes a number of mechanisms that can be used to reduce processing overhead requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP (Resource ReserVation Protocol) message is lost and, when desired, refreshing state without the transmission of whole refresh messages. [STANDARDS TRACK] </abstract>
        <draft>ietf-rsvp-refresh-reduct-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2962</doc-id>
        <title>An SNMP Application Level Gateway for Payload Address Translation</title>
        <author>
            <name>D. Raz</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <author>
            <name>B. Sugla</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46803</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>simple</kw>
            <kw>network</kw>
            <kw>management</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document describes the ALG (Application Level Gateway) for the SNMP (Simple Network Management Protocol) by which IP (Internet Protocol) addresses in the payload of SNMP packets are statically mapped from one group to another. This memo provides information for the Internet community. </abstract>
        <draft>ietf-nat-snmp-alg-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2963</doc-id>
        <title>A Rate Adaptive Shaper for Differentiated Services</title>
        <author>
            <name>O. Bonaventure</name>
        </author>
        <author>
            <name>S. De Cnodder</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39895</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>RAS</kw>
            <kw>TCP</kw>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
            <kw>diffserv</kw>
        </keywords>
        <abstract>This memo describes several Rate Adaptive Shapers (RAS) that can be used in combination with the single rate Three Color Markers (srTCM) and the two rate Three Color Marker (trTCM) described in RFC2697 and RFC2698, respectively. This memo provides information for the Internet community. </abstract>
        <draft>bonaventure-diffserv-rashaper-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2964</doc-id>
        <title>Use of HTTP State Management</title>
        <author>
            <name>K. Moore</name>
        </author>
        <author>
            <name>N. Freed</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18899</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>hypertext</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo identifies specific uses of Hypertext Transfer Protocol (HTTP) State Management protocol which are either (a) not recommended by the IETF, or (b) believed to be harmful, and discouraged. This memo also details additional privacy considerations which are not covered by the HTTP State Management protocol specification. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>iesg-http-cookies-03</draft>
        <is-also>
            <doc-id>BCP0044</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2965</doc-id>
        <title>HTTP State Management Mechanism</title>
        <author>
            <name>D. Kristol</name>
        </author>
        <author>
            <name>L. Montulli</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>56176</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>hypertext</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document specifies a way to create a stateful session with Hypertext Transfer Protocol (HTTP) requests and responses. [STANDARDS TRACK] </abstract>
        <draft>ietf-http-state-man-mec-12</draft>
        <obsoletes>
            <doc-id>RFC2109</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2966</doc-id>
        <title>Domain-wide Prefix Distribution with Two-Level IS-IS</title>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>T. Przygienda</name>
        </author>
        <author>
            <name>H. Smit</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32465</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>intermediate</kw>
            <kw>system</kw>
            <kw>routers</kw>
            <kw>loops</kw>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. This memo provides information for the Internet community. </abstract>
        <draft>ietf-isis-domain-wide-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2967</doc-id>
        <title>TISDAG - Technical Infrastructure for Swedish Directory Access Gateways</title>
        <author>
            <name>L. Daigle</name>
        </author>
        <author>
            <name>R. Hedberg</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>209845</char-count>
            <page-count>105</page-count>
        </format>
        <keywords>
            <kw>single</kw>
            <kw>point</kw>
            <kw>service</kw>
        </keywords>
        <abstract>The overarching goal of this project is to develop the necessary technical infrastructure to provide a single-access-point service for searching for whitepages information on Swedish Internet users. This memo provides information for the Internet community. </abstract>
        <draft>daigle-tisdag-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2968</doc-id>
        <title>Mesh of Multiple DAG servers - Results from TISDAG</title>
        <author>
            <name>L. Daigle</name>
        </author>
        <author>
            <name>T. Eklof</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19306</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>technical</kw>
            <kw>infrastructure</kw>
            <kw>swedish</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>gateways</kw>
            <kw>mesh</kw>
            <kw>index</kw>
        </keywords>
        <abstract>This document defines the basic principle for establishing a mesh, that interoperating services should exchange index objects, according to the architecture of the mesh (e.g., hierarchical, or graph-like, preferably without loops!). The Common Indexing Protocol (CIP) is designed to facilitate the creation not only of query referral indexes, but also of meshes of (loosely) affiliated referral indexes. The purpose of such a mesh of servers is to implement some kind of distributed sharing of indexing and/or searching tasks across different servers. So far, the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways) project has focused on creating a single referral index; the obvious next step is to integrate that into a larger set of interoperating services. This memo provides information for the Internet community. </abstract>
        <draft>daigle-dag-mesh-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2969</doc-id>
        <title>Wide Area Directory Deployment - Experiences from TISDAG</title>
        <author>
            <name>T. Eklof</name>
        </author>
        <author>
            <name>L. Daigle</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43002</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>technical</kw>
            <kw>infrastructure</kw>
            <kw>swedish</kw>
            <kw>access</kw>
            <kw>gateways</kw>
        </keywords>
        <abstract>This document catalogues some of the experiences gained in developing the necessary infrastructure for a national (i.e., multi-organizational) directory service and pilot deployment of the service in an environment with off-the-shelf directory service products. This memo provides information for the Internet community. </abstract>
        <draft>eklof-dag-experiences-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2970</doc-id>
        <title>Architecture for Integrated Directory Services - Result from TISDAG</title>
        <author>
            <name>L. Daigle</name>
        </author>
        <author>
            <name>T. Eklof</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40448</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>ids</kw>
            <kw>whitepages</kw>
            <kw>technical</kw>
            <kw>infrastructure</kw>
            <kw>swedish</kw>
            <kw>access</kw>
            <kw>gateways</kw>
        </keywords>
        <abstract>Drawing from experiences with the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways) project, this document outlines an approach to providing the necessary infrastructure for integrating such widely-scattered servers into a single service, rather than attempting to mandate a single protocol and schema set for all participating servers to use. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2971</doc-id>
        <title>IMAP4 ID extension</title>
        <author>
            <name>T. Showalter</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14670</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>message</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>client</kw>
            <kw>server</kw>
        </keywords>
        <abstract>This document describes an ID extension which will enable Internet Message Access Protocol - Version 4rev1 (IMAP4rev1) to advertise what program a client or server uses to provide service. The ID extension allows the server and client to exchange identification information on their implementation in order to make bug reports and usage statistics more complete. [STANDARDS TRACK] </abstract>
        <draft>ietf-isis-wg-mesh-group-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2972</doc-id>
        <title>Context and Goals for Common Name Resolution</title>
        <author>
            <name>N. Popp</name>
        </author>
        <author>
            <name>M. Mealling</name>
        </author>
        <author>
            <name>L. Masinter</name>
        </author>
        <author>
            <name>K. Sollins</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26252</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>CNRP</kw>
        </keywords>
        <abstract>This document establishes the context and goals for a Common Name Resolution Protocol. This memo provides information for the Internet community. </abstract>
        <draft>ietf-cnrp-goals-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2973</doc-id>
        <title>IS-IS Mesh Groups</title>
        <author>
            <name>R. Balay</name>
        </author>
        <author>
            <name>D. Katz</name>
        </author>
        <author>
            <name>J. Parker</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14846</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>intermediate</kw>
            <kw>system</kw>
            <kw>PDU</kw>
            <kw>protocol data</kw>
            <kw>unit</kw>
        </keywords>
        <abstract>This document describes a mechanism to reduce redundant packet transmissions for the Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2974</doc-id>
        <title>Session Announcement Protocol</title>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>E. Whelan</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40129</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>SAP</kw>
        </keywords>
        <abstract>This document describes version 2 of the multicast session directory announcement protocol, Session Announcement Protocol (SAP), and the related issues affecting security and scalability that should be taken into account by implementors. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-mmusic-sap-v2-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2975</doc-id>
        <title>Introduction to Accounting Management</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>D. Harrington</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>129771</char-count>
            <page-count>54</page-count>
        </format>
        <keywords>
            <kw>resource</kw>
            <kw>consumption data</kw>
            <kw>cost allocation </kw>
        </keywords>
        <abstract>This document describes and discusses the issues involved in the design of the modern accounting systems. The field of Accounting Management is concerned with the collection the collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing. This memo provides information for the Internet community. </abstract>
        <draft>ietf-aaa-acct-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2976</doc-id>
        <title>The SIP INFO Method</title>
        <author>
            <name>S. Donovan</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17736</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>session</kw>
            <kw>initiation</kw>
            <kw>protocol</kw>
            <kw>information</kw>
            <kw>extension</kw>
        </keywords>
        <abstract>This document proposes an extension to the Session Initiation Protocol (SIP). This extension adds the INFO method to the SIP protocol. The intent of the INFO method is to allow for the carrying of session related control information that is generated during a session. [STANDARDS TRACK] </abstract>
        <draft>ietf-sip-info-method-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2977</doc-id>
        <title>Mobile IP Authentication, Authorization, and Accounting Requirements</title>
        <author>
            <name>S. Glass</name>
        </author>
        <author>
            <name>T. Hiller</name>
        </author>
        <author>
            <name>S. Jacobs</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63520</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>AAA</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document contains the requirements which would have to be supported by a AAA service to aid in providing Mobile IP services. This memo provides information for the Internet community. </abstract>
        <draft>ietf-mobileip-aaa-reqs-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2978</doc-id>
        <title>IANA Charset Registration Procedures</title>
        <author>
            <name>N. Freed</name>
        </author>
        <author>
            <name>J. Postel</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21615</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>character</kw>
            <kw>set</kw>
            <kw>mime</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>Multipurpose Internet Mail Extensions (MIME) and various other Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>freed-charset-regist-03</draft>
        <obsoletes>
            <doc-id>RFC2278</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0019</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2979</doc-id>
        <title>Behavior of and Requirements for Internet Firewalls</title>
        <author>
            <name>N. Freed</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14350</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>intranet</kw>
            <kw>network</kw>
        </keywords>
        <abstract>This memo defines behavioral characteristics of and interoperability requirements for Internet firewalls. This memo provides information for the Internet community. </abstract>
        <draft>iab-firewall-req-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2980</doc-id>
        <title>Common NNTP Extensions</title>
        <author>
            <name>S. Barber</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>57165</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>network</kw>
            <kw>news</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>In this document, a number of popular extensions to the Network News Transfer Protocol (NNTP) protocol defined in RFC 977 are documented and discussed. While this document is not intended to serve as a standard of any kind, it will hopefully serve as a reference document for future implementers of the NNTP protocol. This memo provides information for the Internet community. </abstract>
        <draft>ietf-nntpext-imp-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2981</doc-id>
        <title>Event MIB</title>
        <author>
            <name>R. Kavasseri (Ed. of this version)</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>98248</char-count>
            <page-count>50</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects that can be used to manage and monitor MIB objects and take action through events. [STANDARDS TRACK] </abstract>
        <draft>ietf-disman-event-mib-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2982</doc-id>
        <title>Distributed Management Expression MIB</title>
        <author>
            <name>R. Kavasseri (Ed. of this version)</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>81371</char-count>
            <page-count>41</page-count>
        </format>
        <keywords>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing expressions of MIB objects. [STANDARDS TRACK] </abstract>
        <draft>ietf-disman-express-mib-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2983</doc-id>
        <title>Differentiated Services and Tunnels</title>
        <author>
            <name>D. Black</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35644</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>encapsulation</kw>
        </keywords>
        <abstract>This document considers the interaction of Differentiated Services (diffserv) with IP tunnels of various forms. This memo provides information for the Internet community. </abstract>
        <draft>ietf-diffserv-tunnels-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2984</doc-id>
        <title>Use of the CAST-128 Encryption Algorithm in CMS</title>
        <author>
            <name>C. Adams</name>
        </author>
        <date>
            <month>October</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11591</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>cryptographic</kw>
            <kw>message</kw>
            <kw>syntax</kw>
            <kw>security</kw>
            <kw>cipher</kw>
        </keywords>
        <abstract>This document specifies how to incorporate CAST-128 into the S/MIME Cryptographic Message Syntax (CMS) as an additional algorithm for symmetric encryption. [STANDARDS TRACK] </abstract>
        <draft>ietf-smime-cast-128-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2985</doc-id>
        <title>PKCS #9: Selected Object Classes and Attribute Types Version 2.0</title>
        <author>
            <name>M. Nystrom</name>
        </author>
        <author>
            <name>B. Kaliski</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>70703</char-count>
            <page-count>42</page-count>
        </format>
        <keywords>
            <kw>public-key</kw>
            <kw>cryptography</kw>
            <kw>standards</kw>
            <kw>LDAP</kw>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo represents a republication of PKCS #9 v2.0 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from that specification. This memo provides information for the Internet community. </abstract>
        <draft>nystrom-pkcs9-v2-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2986</doc-id>
        <title>PKCS #10: Certification Request Syntax Specification Version 1.7</title>
        <author>
            <name>M. Nystrom</name>
        </author>
        <author>
            <name>B. Kaliski</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27794</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>public-key</kw>
            <kw>cryptography</kw>
            <kw>standards</kw>
            <kw>PKCS-10</kw>
            <kw>public</kw>
            <kw>key</kw>
            <kw>distinguished</kw>
            <kw>name</kw>
            <kw>encryption</kw>
            <kw>data</kw>
        </keywords>
        <abstract>This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community. </abstract>
        <draft>nystrom-pkcs10-v1-7-00</draft>
        <obsoletes>
            <doc-id>RFC2314</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2987</doc-id>
        <title>Registration of Charset and Languages Media Features Tags</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8799</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>character</kw>
            <kw>sets</kw>
            <kw>human</kw>
            <kw>languages</kw>
            <kw>devices</kw>
        </keywords>
        <abstract>This document contains the registration for two media feature tags: "charset" and "language". [STANDARDS TRACK] </abstract>
        <draft>hoffman-char-lang-media-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2988</doc-id>
        <title>Computing TCP's Retransmission Timer</title>
        <author>
            <name>V. Paxson</name>
        </author>
        <author>
            <name>M. Allman</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15280</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
            <kw>algorithm</kw>
        </keywords>
        <abstract>This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. [STANDARDS TRACK] </abstract>
        <draft>paxson-tcp-rto-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2989</doc-id>
        <title>Criteria for Evaluating AAA Protocols for Network Access </title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>P. Calhoun</name>
        </author>
        <author>
            <name>S. Glass</name>
        </author>
        <author>
            <name>T. Hiller</name>
        </author>
        <author>
            <name>P. McCann</name>
        </author>
        <author>
            <name>H. Shiino</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>G. Dommety</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>B. Patil</name>
        </author>
        <author>
            <name>D. Mitton</name>
        </author>
        <author>
            <name>S. Manning</name>
        </author>
        <author>
            <name>M. Beadles</name>
        </author>
        <author>
            <name>P. Walsh</name>
        </author>
        <author>
            <name>X. Chen</name>
        </author>
        <author>
            <name>S. Sivalingham</name>
        </author>
        <author>
            <name>A. Hameed</name>
        </author>
        <author>
            <name>M. Munson</name>
        </author>
        <author>
            <name>S. Jacobs</name>
        </author>
        <author>
            <name>B. Lim</name>
        </author>
        <author>
            <name>B. Hirschman</name>
        </author>
        <author>
            <name>R. Hsu</name>
        </author>
        <author>
            <name>Y. Xu</name>
        </author>
        <author>
            <name>E. Campbell</name>
        </author>
        <author>
            <name>S. Baba</name>
        </author>
        <author>
            <name>E. Jaques</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53197</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>authentication</kw>
            <kw>authorization</kw>
            <kw>accounting</kw>
        </keywords>
        <abstract>This document represents a summary of Authentication, Authorization, Accounting (AAA) protocol requirements for network access. This memo provides information for the Internet community. </abstract>
        <draft>ietf-aaa-na-reqts-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2990</doc-id>
        <title>Next Steps for the IP QoS Architecture</title>
        <author>
            <name>G. Huston</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>65450</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>quality of service</kw>
            <kw>end-to-end</kw>
        </keywords>
        <abstract>This document highlights the outstanding architectural issues relating to the deployment and use of QoS mechanisms within internet networks, noting those areas where further standards work may assist with the deployment of QoS internets. This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board. This memo provides information for the Internet community. </abstract>
        <draft>iab-qos-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2991</doc-id>
        <title>Multipath Issues in Unicast and Multicast Next-Hop Selection</title>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>C. Hopps</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17796</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>routing</kw>
            <kw>forwarding</kw>
            <kw>packets</kw>
            <kw>ECMP</kw>
        </keywords>
        <abstract>The effect of multipath routing on a forwarder is that the forwarder potentially has several next-hops for any given destination and must use some method to choose which next-hop should be used for a given data packet. This memo summarizes current practices, problems, and solutions. This memo provides information for the Internet community. </abstract>
        <draft>thaler-multipath-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2992</doc-id>
        <title>Analysis of an Equal-Cost Multi-Path Algorithm</title>
        <author>
            <name>C. Hopps</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17524</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>ECMP</kw>
            <kw>routing</kw>
            <kw>packets</kw>
            <kw>forwarding</kw>
        </keywords>
        <abstract>Equal-cost multi-path (ECMP) is a routing technique for routing packets along multiple paths of equal cost. The forwarding engine identifies paths by next-hop. When forwarding a packet the router must decide which next-hop (path) to use. This document gives an analysis of one method for making that decision. The analysis includes the performance of the algorithm and the disruption caused by changes to the set of next-hops. This memo provides information for the Internet community. </abstract>
        <draft>hopps-ecmp-algo-analysis-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2993</doc-id>
        <title>Architectural Implications of NAT</title>
        <author>
            <name>T. Hain</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>74136</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>network</kw>
            <kw>address</kw>
            <kw>translation</kw>
        </keywords>
        <abstract>This document discusses some of the architectural implications and guidelines for implementations of Network Address Translation (NAT). This memo provides information for the Internet community. </abstract>
        <draft>iab-nat-implications-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2994</doc-id>
        <title>A Description of the MISTY1 Encryption Algorithm</title>
        <author>
            <name>H. Ohta</name>
        </author>
        <author>
            <name>M. Matsui</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17803</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>cryptosystem</kw>
            <kw>security</kw>
            <kw>data</kw>
            <kw>stream</kw>
        </keywords>
        <abstract>This document describes a secret-key cryptosystem MISTY1, which is block cipher with a 128-bit key, a 64-bit block and a variable number of rounds. It documents the algorithm description including key scheduling part and data randomizing part. This memo provides information for the Internet community. </abstract>
        <draft>ohta-misty1desc-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2995</doc-id>
        <title>Pre-Spirits Implementations of PSTN-initiated Services</title>
        <author>
            <name>H. Lu</name>
            <title>Editor</title>
        </author>
        <author>
            <name>I. Faynberg</name>
        </author>
        <author>
            <name>J. Voelker</name>
        </author>
        <author>
            <name>M. Weissman</name>
        </author>
        <author>
            <name>W. Zhang</name>
        </author>
        <author>
            <name>S. Rhim</name>
        </author>
        <author>
            <name>J. Hwang</name>
        </author>
        <author>
            <name>S. Ago</name>
        </author>
        <author>
            <name>S. Moeenuddin</name>
        </author>
        <author>
            <name>S. Hadvani</name>
        </author>
        <author>
            <name>S. Nyckelgard</name>
        </author>
        <author>
            <name>J. Yoakum</name>
        </author>
        <author>
            <name>L. Robart</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>96427</char-count>
            <page-count>44</page-count>
        </format>
        <keywords>
            <kw>public</kw>
            <kw>switched</kw>
            <kw>telephone</kw>
            <kw>network</kw>
        </keywords>
        <abstract>This document describes four existing implementations of SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, and Telia in cooperation with Nortel Networks. SPIRITS-like services are those originating in the Public Switched Telephone Network (PSTN) and necessitating the interactions of the Internet and PSTN. This memo provides information for the Internet community. </abstract>
        <draft>ietf-spirits-implementations-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2996</doc-id>
        <title>Format of the RSVP DCLASS Object</title>
        <author>
            <name>Y. Bernet</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18929</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
            <kw>QoS</kw>
            <kw>Quality of Service</kw>
        </keywords>
        <abstract>This document specifies the format of the DCLASS object and briefly discusses its use. [STANDARDS TRACK] </abstract>
        <draft>ietf-issll-dclass-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2997</doc-id>
        <title>Specification of the Null Service Type</title>
        <author>
            <name>Y. Bernet</name>
        </author>
        <author>
            <name>A. Smith</name>
        </author>
        <author>
            <name>B. Davie</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25071</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
            <kw>QoS</kw>
            <kw>Quality of Service</kw>
        </keywords>
        <abstract>The Null Service allows applications to identify themselves to network Quality of Service (QoS) policy agents, using RSVP signaling. However, it does not require them to specify resource requirements. QoS policy agents in the network respond by applying QoS policies appropriate for the application (as determined by the network administrator). This mode of RSVP usage is particularly applicable to networks that combine differentiated service (diffserv) QoS mechanisms with RSVP signaling. In this environment, QoS policy agents may direct the signaled application's traffic to a particular diffserv class of service. [STANDARDS TRACK] </abstract>
        <draft>ietf-issll-nullservice-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2998</doc-id>
        <title>A Framework for Integrated Services Operation over Diffserv Networks</title>
        <author>
            <name>Y. Bernet</name>
        </author>
        <author>
            <name>P. Ford</name>
        </author>
        <author>
            <name>R. Yavatkar</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>L. Zhang</name>
        </author>
        <author>
            <name>M. Speer</name>
        </author>
        <author>
            <name>R. Braden</name>
        </author>
        <author>
            <name>B. Davie</name>
        </author>
        <author>
            <name>J. Wroclawski</name>
        </author>
        <author>
            <name>E. Felstaine</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>76378</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>intserv</kw>
            <kw>QoS</kw>
            <kw>Quality of Service</kw>
            <kw>end-to-end</kw>
        </keywords>
        <abstract>This document describes a framework by which Integrated Services may be supported over Diffserv networks. This memo provides information for the Internet community. </abstract>
        <draft>ietf-issll-diffserv-rsvp-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC2999</doc-id>
        <title>Request for Comments Summary RFC Numbers 2900-2999</title>
        <author>
            <name>S. Ginoza</name>
        </author>
        <date>
            <month>August</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45307</char-count>
            <page-count>23</page-count>
        </format>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3000</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Reynolds</name>
        </author>
        <author>
            <name>R. Braden</name>
        </author>
        <author>
            <name>S. Ginoza</name>
        </author>
        <author>
            <name>L. Shiota</name>
        </author>
        <date>
            <month>November</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>115207</char-count>
            <page-count>43</page-count>
        </format>
        <abstract>This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 25, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. [STANDARDS TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC2900</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3300</doc-id>
        </obsoleted-by>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3001</doc-id>
        <title>A URN Namespace of Object Identifiers</title>
        <author>
            <name>M. Mealling</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7459</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>names</kw>
            <kw>OIDs</kw>
        </keywords>
        <abstract>This document describes a Uniform Resource Names (URN) namespace that contains Object Identifiers (OIDs). This memo provides information for the Internet community. </abstract>
        <draft>mealling-oid-urn-01</draft>
        <obsoleted-by>
            <doc-id>RFC3061</doc-id>
        </obsoleted-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3002</doc-id>
        <title>Overview of 2000 IAB Wireless Internetworking Workshop</title>
        <author>
            <name>D. Mitzel</name>
        </author>
        <date>
            <month>December</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>101466</char-count>
            <page-count>42</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>architecture</kw>
            <kw>board</kw>
        </keywords>
        <abstract>This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on wireless internetworking. This memo provides information for the Internet community. </abstract>
        <draft>iab-wirelessws-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3003</doc-id>
        <title>The audio/mpeg Media Type</title>
        <author>
            <name>M. Nilsson</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8381</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>MIME</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>The audio layers of the MPEG-1 and MPEG-2 standards are in frequent use on the internet, but there is no uniform Multipurpose Internet Mail Extension (MIME) type for these files. The intention of this document is to define the media type audio/mpeg to refer to this kind of contents. [STANDARDS TRACK] </abstract>
        <draft>nilsson-audio-mpeg-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3004</doc-id>
        <title>The User Class Option for DHCP</title>
        <author>
            <name>G. Stump</name>
        </author>
        <author>
            <name>R. Droms</name>
        </author>
        <author>
            <name>Y. Gu</name>
        </author>
        <author>
            <name>R. Vyaghrapuri</name>
        </author>
        <author>
            <name>A. Demirtjis</name>
        </author>
        <author>
            <name>B. Beser</name>
        </author>
        <author>
            <name>J. Privat</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10423</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>dynamic</kw>
            <kw>host</kw>
            <kw>configuration</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This option is used by a Dynamic Host Configuration Protocol (DHCP) client to optionally identify the type or category of user or applications it represents. The information contained in this option is an opaque field that represents the user class of which the client is a member. Based on this class, a DHCP server selects the appropriate address pool to assign an address to the client and the appropriate configuration parameters. This option should be configurable by a user. [STANDARDS TRACK] </abstract>
        <draft>ietf-dhc-userclass-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3005</doc-id>
        <title>IETF Discussion List Charter</title>
        <author>
            <name>S. Harris</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5682</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>engineering</kw>
            <kw>task</kw>
            <kw>force</kw>
        </keywords>
        <abstract>The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through discussion of technical issues, and hosts discussions of IETF direction, policy, meetings, and procedures. As this is the most general IETF mailing list, considerable latitude is allowed. Advertising, whether to solicit business or promote employment opportunities, falls well outside the range of acceptable topics, as do discussions of a personal nature. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-poisson-listaup-02</draft>
        <is-also>
            <doc-id>BCP0045</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3006</doc-id>
        <title>Integrated Services in the Presence of Compressible Flows</title>
        <author>
            <name>B. Davie</name>
        </author>
        <author>
            <name>C. Iturralde</name>
        </author>
        <author>
            <name>D. Oran</name>
        </author>
        <author>
            <name>S. Casner</name>
        </author>
        <author>
            <name>J. Wroclawski</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31588</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>routing</kw>
            <kw>resource</kw>
            <kw>allocation</kw>
            <kw>int-serv</kw>
        </keywords>
        <abstract>This specification describes an extension to the TSpec which enables a sender of potentially compressible data to provide hints to int-serv routers about the compressibility they may obtain. [STANDARDS TRACK] </abstract>
        <draft>ietf-intserv-compress-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3007</doc-id>
        <title>Secure Domain Name System (DNS) Dynamic Update</title>
        <author>
            <name>B. Wellington</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18056</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>authentication</kw>
            <kw>validation</kw>
            <kw>DNSSEC</kw>
        </keywords>
        <abstract>This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. [STANDARDS TRACK] </abstract>
        <draft>ietf-dnsext-simple-secure-update-02</draft>
        <obsoletes>
            <doc-id>RFC2137</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2535</doc-id>
            <doc-id>RFC2136</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4035</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3008</doc-id>
        <title>Domain Name System Security (DNSSEC) Signing Authority</title>
        <author>
            <name>B. Wellington</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13484</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>DNSSEC</kw>
            <kw>authentication</kw>
            <kw>validation</kw>
            <kw>SIG</kw>
            <kw>signature</kw>
        </keywords>
        <abstract>This document proposes a revised model of Domain Name System Security (DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records. [STANDARDS TRACK] </abstract>
        <draft>ietf-dnsext-signing-auth-02</draft>
        <obsoleted-by>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4035</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2535</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC3658</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3009</doc-id>
        <title>Registration of parityfec MIME types</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16022</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>media-type</kw>
            <kw>multimedia</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>The RTP (Real-time Transport Protocol) payload format for generic forward error correction allows RTP participants to improve loss resiliency through the use of traditional parity-based channel codes. This payload format requires four new MIME types, audio/parityfec, video/parityfec, text/parityfec and application/parityfec. This document serves as the MIME type registration for those formats. [STANDARDS TRACK] </abstract>
        <draft>ietf-avt-fecmime-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3010</doc-id>
        <title>NFS version 4 Protocol</title>
        <author>
            <name>S. Shepler</name>
        </author>
        <author>
            <name>B. Callaghan</name>
        </author>
        <author>
            <name>D. Robinson</name>
        </author>
        <author>
            <name>R. Thurlow</name>
        </author>
        <author>
            <name>C. Beame</name>
        </author>
        <author>
            <name>M. Eisler</name>
        </author>
        <author>
            <name>D. Noveck</name>
        </author>
        <date>
            <month>December</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>450434</char-count>
            <page-count>212</page-count>
        </format>
        <keywords>
            <kw>NFSv4</kw>
            <kw>network</kw>
            <kw>file</kw>
            <kw>system</kw>
        </keywords>
        <abstract>NFS (Network File System) version 4 is a distributed file system protocol which owes heritage to NFS protocol versions 2 [RFC1094] and 3 [RFC1813]. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. [STANDARDS TRACK] </abstract>
        <draft>ietf-nfsv4-07</draft>
        <notes>10/29/03 - back in June 2002, Matthew Wilcox sent an email stating that RFC 3010 is listed as erronously obsoleting RFCs 1813 and 1094.  This was confirmed by Scott Bradner in October 2003.  I have removed the Obsoletes tag for for this entry.</notes>
        <obsoleted-by>
            <doc-id>RFC3530</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3011</doc-id>
        <title>The IPv4 Subnet Selection Option for DHCP</title>
        <author>
            <name>G. Waters</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13967</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>dynamic</kw>
            <kw>host</kw>
            <kw>configuration</kw>
        </keywords>
        <abstract>This memo defines a new Dynamic Host Configuration Protocol (DHCP) option for selecting the subnet on which to allocate an address. [STANDARDS TRACK] </abstract>
        <draft>ietf-dhc-subnet-option-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3012</doc-id>
        <title>Mobile IPv4 Challenge/Response Extensions</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>P. Calhoun</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37005</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>authentication</kw>
            <kw>foreign</kw>
            <kw>agent</kw>
        </keywords>
        <abstract>In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. [STANDARDS TRACK] </abstract>
        <draft>ietf-mobileip-challenge-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3013</doc-id>
        <title>Recommended Internet Service Provider Security Services and Procedures</title>
        <author>
            <name>T. Killalea</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27905</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>ISPs</kw>
        </keywords>
        <abstract>The purpose of this document is to express what the engineering community as represented by the IETF expects of Internet Service Providers (ISPs) with respect to security. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-grip-isp-expectations-06</draft>
        <is-also>
            <doc-id>BCP0046</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3014</doc-id>
        <title>Notification Log MIB</title>
        <author>
            <name>R. Kavasseri</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48287</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for logging Simple Network Management Protocol (SNMP) Notifications. [STANDARDS TRACK] </abstract>
        <draft>ietf-disman-notif-log-mib-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3015</doc-id>
        <title>Megaco Protocol Version 1.0</title>
        <author>
            <name>F. Cuervo</name>
        </author>
        <author>
            <name>N. Greene</name>
        </author>
        <author>
            <name>A. Rayhan</name>
        </author>
        <author>
            <name>C. Huitema</name>
        </author>
        <author>
            <name>B. Rosen</name>
        </author>
        <author>
            <name>J. Segers</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>385432</char-count>
            <page-count>179</page-count>
        </format>
        <keywords>
            <kw>MEGACO</kw>
            <kw>H.248</kw>
            <kw>media</kw>
            <kw>gateway</kw>
            <kw>control</kw>
        </keywords>
        <abstract>This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e. a Media Gateway and a Media Gateway Controller. [STANDARDS TRACK] </abstract>
        <draft>ietf-megaco-merged-01</draft>
        <obsoletes>
            <doc-id>RFC2885</doc-id>
            <doc-id>RFC2886</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3525</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3016</doc-id>
        <title>RTP Payload Format for MPEG-4 Audio/Visual Streams</title>
        <author>
            <name>Y. Kikuchi</name>
        </author>
        <author>
            <name>T. Nomura</name>
        </author>
        <author>
            <name>S. Fukunaga</name>
        </author>
        <author>
            <name>Y. Matsui</name>
        </author>
        <author>
            <name>H. Kimata</name>
        </author>
        <date>
            <month>November</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47070</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>real-time transport</kw>
            <kw>protocol</kw>
            <kw>media-type</kw>
        </keywords>
        <abstract>This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. [STANDARDS TRACK] </abstract>
        <draft>ietf-avt-rtp-mpeg4-es-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3017</doc-id>
        <title>XML DTD for Roaming Access Phone Book</title>
        <author>
            <name>M. Riegel</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <date>
            <month>December</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59762</char-count>
            <page-count>33</page-count>
        </format>
        <keywords>
            <kw>extensible</kw>
            <kw>markup</kw>
            <kw>language</kw>
            <kw>document</kw>
            <kw>type</kw>
            <kw>declaration</kw>
        </keywords>
        <abstract>This document defines the syntax as well as the semantics of the information to be included in the phone book for roaming applications. [STANDARDS TRACK] </abstract>
        <draft>ietf-roamops-phonebook-xml-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3018</doc-id>
        <title>Unified Memory Space Protocol Specification</title>
        <author>
            <name>A. Bogdanov</name>
        </author>
        <date>
            <month>December</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>177783</char-count>
            <page-count>81</page-count>
        </format>
        <keywords>
            <kw>UMSP</kw>
            <kw>network</kw>
            <kw>connection-oriented</kw>
        </keywords>
        <abstract>This document specifies Unified Memory Space Protocol (UMSP), which gives a capability of immediate access to memory of the remote nodes. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>bogdanov-usmp-00</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3019</doc-id>
        <title>IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol</title>
        <author>
            <name>B. Haberman</name>
        </author>
        <author>
            <name>R. Worzella</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28293</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>IPv6</kw>
            <kw>MIB</kw>
            <kw>MLD</kw>
        </keywords>
        <abstract>This document defines a portion of the Management Information Base (MIB) for use with network management protocols in Internet Protocol Version 6 internets. Specifically, this document is the MIB module that defines managed objects for implementations of the Multicast Listener Discovery Protocol [RFC2710]. [STANDARDS TRACK] </abstract>
        <draft>ietf-ipngwg-mld-mib-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3020</doc-id>
        <title>Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function</title>
        <author>
            <name>P. Pate</name>
        </author>
        <author>
            <name>B. Lynch</name>
        </author>
        <author>
            <name>K. Rehbehn</name>
        </author>
        <date>
            <month>December</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>67736</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a Management Information Base (MIB) for monitoring and controlling a UNI/NNI Multilink Frame Relay Function as defined in Frame Relay Forum FRF.16. [STANDARDS TRACK] </abstract>
        <draft>ietf-frnetmib-mfrmib-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3021</doc-id>
        <title>Using 31-Bit Prefixes on IPv4 Point-to-Point Links</title>
        <author>
            <name>A. Retana</name>
        </author>
        <author>
            <name>R. White</name>
        </author>
        <author>
            <name>V. Fuller</name>
        </author>
        <author>
            <name>D. McPherson</name>
        </author>
        <date>
            <month>December</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19771</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>addresses</kw>
            <kw>subnet masks</kw>
        </keywords>
        <abstract>With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to halve the amount of address space assigned to point-to-point links (common throughout the Internet infrastructure) by allowing the use of 31-bit subnet masks in a very limited way. [STANDARDS TRACK] </abstract>
        <draft>retana-31bits-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3022</doc-id>
        <title>Traditional IP Network Address Translator (Traditional NAT)</title>
        <author>
            <name>P. Srisuresh</name>
        </author>
        <author>
            <name>K. Egevang</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37675</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>ports</kw>
            <kw>private</kw>
        </keywords>
        <abstract>The NAT operation described in this document extends address translation introduced in RFC 1631 and includes a new type of network address and TCP/UDP port translation. In addition, this document corrects the Checksum adjustment algorithm published in RFC 1631 and attempts to discuss NAT operation and limitations in detail. This memo provides information for the Internet community. </abstract>
        <draft>ietf-nat-traditional-05</draft>
        <obsoletes>
            <doc-id>RFC1631</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3023</doc-id>
        <title>XML Media Types</title>
        <author>
            <name>M. Murata</name>
        </author>
        <author>
            <name>S. St. Laurent</name>
        </author>
        <author>
            <name>D. Kohn</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>86011</char-count>
            <page-count>39</page-count>
        </format>
        <keywords>
            <kw>extensible</kw>
            <kw>markup</kw>
            <kw>language</kw>
            <kw>web</kw>
            <kw>authority</kw>
            <kw>hypertext</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document standardizes five new media types -- text/xml, application/xml, text/xml-external-parsed-entity, application/xml- external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML). This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME (Multipurpose Internet Mail Extensions) entities. [STANDARDS TRACK] </abstract>
        <draft>murata-xml-09</draft>
        <obsoletes>
            <doc-id>RFC2376</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2048</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3024</doc-id>
        <title>Reverse Tunneling for Mobile IP, revised</title>
        <author>
            <name>G. Montenegro</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63929</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>node</kw>
            <kw>care-of-address</kw>
        </keywords>
        <abstract>This document proposes backwards-compatible extensions to Mobile IP to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address. [STANDARDS TRACK] </abstract>
        <draft>ietf-mobileip-rfc2344-bis-02</draft>
        <obsoletes>
            <doc-id>RFC2344</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3025</doc-id>
        <title>Mobile IP Vendor/Organization-Specific Extensions</title>
        <author>
            <name>G. Dommety</name>
        </author>
        <author>
            <name>K. Leung</name>
        </author>
        <date>
            <month>February</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15611</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. [STANDARDS TRACK] </abstract>
        <draft>ietf-mobileip-vendor-ext-11</draft>
        <obsoleted-by>
            <doc-id>RFC3115</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3026</doc-id>
        <title>Liaison to IETF/ISOC on ENUM</title>
        <author>
            <name>R. Blane</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11460</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>dns</kw>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>internet</kw>
            <kw>security</kw>
            <kw>engineering</kw>
            <kw>task force</kw>
            <kw>E.164</kw>
            <kw>number</kw>
        </keywords>
        <abstract>Working Party 1/2, of the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) held a meeting of its collaborators in Berlin Germany 19-26 October 2000. This liaison from WP1/2 to the IETF/ISOC conveys the understandings of the WP1/2 collaborators resulting from the discussions. This memo provides information for the Internet community. </abstract>
        <draft>itu-sg2-liason-enum-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3027</doc-id>
        <title>Protocol Complications with the IP Network Address Translator</title>
        <author>
            <name>M. Holdrege</name>
        </author>
        <author>
            <name>P. Srisuresh</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48662</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>network</kw>
            <kw>address</kw>
            <kw>translator</kw>
        </keywords>
        <abstract>The purpose of this document is to identify the protocols and applications that break with NAT enroute. The document also attempts to identify any known workarounds. This document attempts to capture as much information as possible, but is by no means a comprehensive coverage. This memo provides information for the Internet community. </abstract>
        <draft>ietf-nat-protocol-complications-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3028</doc-id>
        <title>Sieve: A Mail Filtering Language</title>
        <author>
            <name>T. Showalter</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>73582</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>client</kw>
            <kw>server</kw>
        </keywords>
        <abstract>This document describes a language for filtering e-mail messages at time of final delivery. [STANDARDS TRACK] </abstract>
        <draft>showalter-sieve-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3029</doc-id>
        <title>Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols</title>
        <author>
            <name>C. Adams</name>
        </author>
        <author>
            <name>P. Sylvester</name>
        </author>
        <author>
            <name>M. Zolotarev</name>
        </author>
        <author>
            <name>R. Zuccherato</name>
        </author>
        <date>
            <month>February</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>107347</char-count>
            <page-count>51</page-count>
        </format>
        <keywords>
            <kw>DVCS</kw>
            <kw>TTP</kw>
            <kw>trusted third party </kw>
        </keywords>
        <abstract>This document describes a general Data Validation and Certification Server (DVCS) and the protocols to be used when communicating with it. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-pkix-dcs-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3030</doc-id>
        <title>SMTP Service Extensions for Transmission of Large and Binary MIME Messages</title>
        <author>
            <name>G. Vaudreuil</name>
        </author>
        <date>
            <month>December</month>
            <year>2000</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23405</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>simple</kw>
            <kw>mail</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>multipurpose</kw>
            <kw>interent</kw>
        </keywords>
        <abstract>This memo defines two extensions to the SMTP (Simple Mail Transfer Protocol) service. [STANDARDS TRACK] </abstract>
        <draft>vaudreuil-esmtp-binary2-03</draft>
        <obsoletes>
            <doc-id>RFC1830</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3031</doc-id>
        <title>Multiprotocol Label Switching Architecture</title>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>A. Viswanathan</name>
        </author>
        <author>
            <name>R. Callon</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>147175</char-count>
            <page-count>61</page-count>
        </format>
        <keywords>
            <kw>MPLS</kw>
        </keywords>
        <abstract>This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS TRACK] </abstract>
        <draft>ietf-mpls-arch-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3032</doc-id>
        <title>MPLS Label Stack Encoding</title>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>D. Tappan</name>
        </author>
        <author>
            <name>G. Fedorkow</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>A. Conta</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48314</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>multi-protocol</kw>
            <kw>label</kw>
            <kw>switching</kw>
        </keywords>
        <abstract>This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. This document also specifies rules and procedures for processing the various fields of the label stack encoding. [STANDARDS TRACK] </abstract>
        <draft>ietf-mpls-label-encaps-07</draft>
        <updated-by>
            <doc-id>RFC3443</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3033</doc-id>
        <title>The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol</title>
        <author>
            <name>M. Suzuki</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52188</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>IP</kw>
        </keywords>
        <abstract>The purpose of this document is to specify the assignment of the information field and protocol identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet protocol. [STANDARDS TRACK] </abstract>
        <draft>ietf-mpls-git-uus-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3034</doc-id>
        <title>Use of Label Switching on Frame Relay Networks Specification</title>
        <author>
            <name>A. Conta</name>
        </author>
        <author>
            <name>P. Doolan</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53176</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>MPLS</kw>
            <kw>multi-protocol</kw>
        </keywords>
        <abstract>This document defines the model and generic mechanisms for Multiprotocol Label Switching on Frame Relay networks. [STANDARDS TRACK] </abstract>
        <draft>ietf-mpls-fr-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3035</doc-id>
        <title>MPLS using LDP and ATM VC Switching</title>
        <author>
            <name>B. Davie</name>
        </author>
        <author>
            <name>J. Lawrence</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>P. Doolan</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46463</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>multi-protocol</kw>
            <kw>label</kw>
            <kw>switching</kw>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>distribution</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document extends and clarifies the relevant portions of RFC 3031 and RFC 3036 by specifying in more detail the procedures which to be used when distributing labels to or from ATM-LSRs, when those labels represent Forwarding Equivalence Classes (FECs, see RFC 3031) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms. [STANDARDS TRACK] </abstract>
        <draft>ietf-mpls-atm-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3036</doc-id>
        <title>LDP Specification</title>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>P. Doolan</name>
        </author>
        <author>
            <name>N. Feldman</name>
        </author>
        <author>
            <name>A. Fredette</name>
        </author>
        <author>
            <name>B. Thomas</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>274855</char-count>
            <page-count>132</page-count>
        </format>
        <keywords>
            <kw>label</kw>
            <kw>distribution</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS TRACK] </abstract>
        <draft>ietf-mpls-ldp-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3037</doc-id>
        <title>LDP Applicability</title>
        <author>
            <name>B. Thomas</name>
        </author>
        <author>
            <name>E. Gray</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13601</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>label</kw>
            <kw>distribution</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document describes the applicability of a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. This memo provides information for the Internet community. </abstract>
        <draft>ietf-mpls-ldp-applic-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3038</doc-id>
        <title>VCID Notification over ATM link for LDP</title>
        <author>
            <name>K. Nagami</name>
        </author>
        <author>
            <name>Y. Katsube</name>
        </author>
        <author>
            <name>N. Demizu</name>
        </author>
        <author>
            <name>H. Esaki</name>
        </author>
        <author>
            <name>P. Doolan</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39134</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>label</kw>
            <kw>distribution</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property. [STANDARDS TRACK] </abstract>
        <draft>ietf-mpls-vcid-atm-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3039</doc-id>
        <title>Internet X.509 Public Key Infrastructure Qualified Certificates Profile</title>
        <author>
            <name>S. Santesson</name>
        </author>
        <author>
            <name>W. Polk</name>
        </author>
        <author>
            <name>P. Barzin</name>
        </author>
        <author>
            <name>M. Nystrom</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>67619</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
            <kw>syntax</kw>
        </keywords>
        <abstract>This document forms a certificate profile for Qualified Certificates, based on RFC 2459, for use in the Internet. The goal of this document is to define a general syntax independent of local legal requirements. [STANDARDS TRACK] </abstract>
        <draft>ietf-pkix-qc-06</draft>
        <obsoleted-by>
            <doc-id>RFC3739</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3040</doc-id>
        <title>Internet Web Replication and Caching Taxonomy</title>
        <author>
            <name>I. Cooper</name>
        </author>
        <author>
            <name>I. Melve</name>
        </author>
        <author>
            <name>G. Tomlinson</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63257</char-count>
            <page-count>32</page-count>
        </format>
        <keywords>
            <kw>infrastructure</kw>
            <kw>www</kw>
            <kw>world</kw>
            <kw>wide</kw>
        </keywords>
        <abstract>This memo specifies standard terminology and the taxonomy of web replication and caching infrastructure as deployed today. It introduces standard concepts, and protocols used today within this application domain. This memo provides information for the Internet community. </abstract>
        <draft>ietf-wrec-taxonomy-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3041</doc-id>
        <title>Privacy Extensions for Stateless Address Autoconfiguration in IPv6</title>
        <author>
            <name>T. Narten</name>
        </author>
        <author>
            <name>R. Draves</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44446</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>interface</kw>
            <kw>identifier</kw>
        </keywords>
        <abstract>This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. [STANDARDS TRACK] </abstract>
        <draft>ietf-ipngwg-addrconf-privacy-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3042</doc-id>
        <title>Enhancing TCP's Loss Recovery Using Limited Transmit</title>
        <author>
            <name>M. Allman</name>
        </author>
        <author>
            <name>H. Balakrishnan</name>
        </author>
        <author>
            <name>S. Floyd</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19885</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document proposes a new Transmission Control Protocol (TCP) mechanism that can be used to more effectively recover lost segments when a connection's congestion window is small, or when a large number of segments are lost in a single transmission window. [STANDARDS TRACK] </abstract>
        <draft>ietf-tsvwg-limited-xmit-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3043</doc-id>
        <title>The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations</title>
        <author>
            <name>M. Mealling</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8136</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>name</kw>
        </keywords>
        <abstract>This document describes a Uniform Resource Name (URN) namespace that is engineered by Network Solutions, Inc. for naming people and organizations. This memo provides information for the Internet community. </abstract>
        <draft>mealling-pin-urn-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3044</doc-id>
        <title>Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace</title>
        <author>
            <name>S. Rozenfeld</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28094</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>serials</kw>
            <kw>identifier</kw>
        </keywords>
        <abstract>This document presents how the ISSN - International Standard Serial Number - which is a persistent number for unique identification of serials widely recognised and used in the bibliographic world, can be supported within the Uniform Resource Name (URN) framework as a specific URN namespace identifier. This memo provides information for the Internet community. </abstract>
        <draft>rozenfeld-urn-lssn-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3045</doc-id>
        <title>Storing Vendor Information in the LDAP root DSE</title>
        <author>
            <name>M. Meredith</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10518</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>DSA-specific</kw>
            <kw>entry</kw>
        </keywords>
        <abstract>This document specifies two Lightweight Directory Access Protocol (LDAP) attributes, vendorName and vendorVersion that MAY be included in the root DSA-specific Entry (DSE) to advertise vendor-specific information. This memo provides information for the Internet community. </abstract>
        <draft>mmeredith-rootdse-vendor-info-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3046</doc-id>
        <title>DHCP Relay Agent Information Option</title>
        <author>
            <name>M. Patrick</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30633</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>dynamic</kw>
            <kw>host</kw>
            <kw>configuration</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>Newer high-speed public Internet access technologies call for a high- speed modem to have a local area network (LAN) attachment to one or more customer premise hosts. It is advantageous to use the Dynamic Host Configuration Protocol (DHCP) as defined in RFC 2131 to assign customer premise host IP addresses in this environment. However, a number of security and scaling problems arise with such "public" DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132. [STANDARDS TRACK] </abstract>
        <draft>ietf-dhc-agent-options-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3047</doc-id>
        <title>RTP Payload Format for ITU-T Recommendation G.722.1</title>
        <author>
            <name>P. Luthi</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16292</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>international</kw>
            <kw>telecommunication</kw>
            <kw>union</kw>
            <kw>real-time</kw>
            <kw>transport</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document describes the payload format for including G.722.1 generated bit streams within an RTP packet. Also included here are the necessary details for the use of G.722.1 with MIME and SDP. [STANDARDS TRACK] </abstract>
        <draft>ietf-avt-rtp-g7221-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3048</doc-id>
        <title>Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer</title>
        <author>
            <name>B. Whetten</name>
        </author>
        <author>
            <name>L. Vicisano</name>
        </author>
        <author>
            <name>R. Kermode</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>M. Luby</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48965</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>RMT</kw>
            <kw>protocol</kw>
            <kw>core</kw>
        </keywords>
        <abstract>This document describes a framework for the standardization of bulk-data reliable multicast transport. This memo provides information for the Internet community. </abstract>
        <draft>ietf-rmt-buildingblocks-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3049</doc-id>
        <title>TN3270E Service Location and Session Balancing</title>
        <author>
            <name>J. Naugle</name>
        </author>
        <author>
            <name>K. Kasthurirangan</name>
        </author>
        <author>
            <name>G. Ledford</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40743</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>SLP</kw>
        </keywords>
        <abstract>This document discusses the implementation of Service Location Protocol (SLP) and session balancing with a TN3270E emulator in a client server implementation with a TN3270E server. [STANDARDS TRACK] </abstract>
        <draft>ietf-tn3270e-service-loc-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3050</doc-id>
        <title>Common Gateway Interface for SIP</title>
        <author>
            <name>J. Lennox</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>76652</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
            <kw>session</kw>
            <kw>initiation</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document defines a SIP CGI interface for providing SIP services on a SIP server. This memo provides information for the Internet community. </abstract>
        <draft>lennox-sip-cgi-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3051</doc-id>
        <title>IP Payload Compression Using ITU-T V.44 Packet Method</title>
        <author>
            <name>J. Heath</name>
        </author>
        <author>
            <name>J. Border</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15845</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>international</kw>
            <kw>telecommunication</kw>
            <kw>union</kw>
        </keywords>
        <abstract>This document describes a compression method based on the data compression algorithm described in International Telecommunication Union (ITU-T) Recommendation V.44. This document defines the application of V.44 Packet Method to the Internet Protocol (IP) Payload Compression Protocol (RFC 2393). This memo provides information for the Internet community. </abstract>
        <draft>heath-ipcomp-v44-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3052</doc-id>
        <title>Service Management Architectures Issues and Review</title>
        <author>
            <name>M. Eder</name>
        </author>
        <author>
            <name>S. Nag</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31859</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>framework</kw>
            <kw>packets</kw>
            <kw>network</kw>
        </keywords>
        <abstract>The purpose of this document is to explore the problems of defining a Service management framework and to examine some of the issues that still need to be resolved. This memo provides information for the Internet community. </abstract>
        <draft>irtf-nsmrg-sm-issues-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3053</doc-id>
        <title>IPv6 Tunnel Broker</title>
        <author>
            <name>A. Durand</name>
        </author>
        <author>
            <name>P. Fasano</name>
        </author>
        <author>
            <name>I. Guardini</name>
        </author>
        <author>
            <name>D. Lento</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27336</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>infrastructure</kw>
        </keywords>
        <abstract>The motivation for the development of the tunnel broker model is to help early IPv6 adopters to hook up to an existing IPv6 network (e.g., the 6bone) and to get stable, permanent IPv6 addresses and DNS names. The concept of the tunnel broker was first presented at Orlando's IETF in December 1998. Two implementations were demonstrated during the Grenoble IPng &amp; NGtrans interim meeting in February 1999. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ngtrans-broker-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3054</doc-id>
        <title>Megaco IP Phone Media Gateway Application Profile</title>
        <author>
            <name>P. Blatherwick</name>
        </author>
        <author>
            <name>R. Bell</name>
        </author>
        <author>
            <name>P. Holland</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31971</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>H.248</kw>
            <kw>telephone</kw>
            <kw>MG</kw>
        </keywords>
        <abstract>This document specifies a particular application of the Megaco/H.248 Protocol for control of Internet telephones and similar appliances: the Megaco IP Phone Media Gateway. This memo provides information for the Internet community. </abstract>
        <draft>ietf-megaco-ipphone-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3055</doc-id>
        <title>Management Information Base for the PINT Services Architecture</title>
        <author>
            <name>M. Krishnaswamy</name>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <date>
            <month>February</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39315</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>PSTN/Internet</kw>
            <kw>interworking</kw>
        </keywords>
        <abstract>This memo describes a proposed Management Information Base (MIB) for the PSTN/Internet Interworking (PINT) Services Architecture. [STANDARDS TRACK] </abstract>
        <draft>ietf-pint-mib-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3056</doc-id>
        <title>Connection of IPv6 Domains via IPv4 Clouds</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>K. Moore</name>
        </author>
        <date>
            <month>February</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54902</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>wide area</kw>
            <kw>network</kw>
            <kw>unicast</kw>
            <kw>point-to-point</kw>
        </keywords>
        <abstract>This memo specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. [STANDARDS TRACK] </abstract>
        <draft>ietf-ngtrans-6to4-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3057</doc-id>
        <title>ISDN Q.921-User Adaptation Layer</title>
        <author>
            <name>K. Morneault</name>
        </author>
        <author>
            <name>S. Rengasami</name>
        </author>
        <author>
            <name>M. Kalla</name>
        </author>
        <author>
            <name>G. Sidebottom</name>
        </author>
        <date>
            <month>February</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13601</char-count>
            <page-count>66</page-count>
        </format>
        <keywords>
            <kw>SCTP</kw>
            <kw>signaling</kw>
            <kw>media</kw>
            <kw>gateway</kw>
            <kw>interface</kw>
        </keywords>
        <abstract>This document defines a protocol for backhauling of ISDN Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). [STANDARDS TRACK] </abstract>
        <draft>ietf-sigtran-iua-10</draft>
        <updated-by>
            <doc-id>RFC3807</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3058</doc-id>
        <title>Use of the IDEA Encryption Algorithm in CMS</title>
        <author>
            <name>S. Teiwes</name>
        </author>
        <author>
            <name>P. Hartmann</name>
        </author>
        <author>
            <name>D. Kuenzi</name>
        </author>
        <date>
            <month>February</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17257</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>international</kw>
            <kw>data encryption</kw>
            <kw>algorithm</kw>
            <kw>cryptic message</kw>
            <kw>syntax</kw>
            <kw>s/mime</kw>
            <kw>multipurpose internet</kw>
            <kw>mail extensions</kw>
        </keywords>
        <abstract>This memo specifies how to incorporate International Data Encryption Algorithm (IDEA) into CMS or S/MIME as an additional strong algorithm for symmetric encryption. This memo provides information for the Internet community. </abstract>
        <draft>ietf-smime-idea-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3059</doc-id>
        <title>Attribute List Extension for the Service Location Protocol</title>
        <author>
            <name>E. Guttman</name>
        </author>
        <date>
            <month>February</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11208</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>SLPv2</kw>
            <kw>messages</kw>
            <kw>user agent</kw>
        </keywords>
        <abstract>This document specifies a SLPv2 extension which allows a User Agent (UA) to request a service's attributes be included as an extension to Service Reply messages. This will eliminate the need for multiple round trip messages for a UA to acquire all service information. [STANDARDS TRACK] </abstract>
        <draft>guttman-svrloc-attrust-ext-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3060</doc-id>
        <title>Policy Core Information Model -- Version 1 Specification</title>
        <author>
            <name>B. Moore</name>
        </author>
        <author>
            <name>E. Ellesson</name>
        </author>
        <author>
            <name>J. Strassner</name>
        </author>
        <author>
            <name>A. Westerinen</name>
        </author>
        <date>
            <month>February</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>240309</char-count>
            <page-count>100</page-count>
        </format>
        <keywords>
            <kw>CIM</kw>
            <kw>common</kw>
            <kw>schema</kw>
            <kw>object-oriented</kw>
        </keywords>
        <abstract>This document presents the object-oriented information model for representing policy information developed jointly in the IETF Policy Framework WG and as extensions to the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF). [STANDARDS TRACK] </abstract>
        <draft>ietf-policy-core-info-model-08</draft>
        <updated-by>
            <doc-id>RFC3460</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3061</doc-id>
        <title>A URN Namespace of Object Identifiers</title>
        <author>
            <name>M. Mealling</name>
        </author>
        <date>
            <month>February</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8387</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>names</kw>
            <kw>OIDs</kw>
        </keywords>
        <abstract>This document describes a Uniform Resource Name (URN) namespace that contains Object Identifiers (OIDs). This memo provides information for the Internet community. </abstract>
        <draft>mealling-rfc3001bis-01</draft>
        <obsoletes>
            <doc-id>RFC3001</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3062</doc-id>
        <title>LDAP Password Modify Extended Operation</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>February</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11807</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document describes an LDAP extended operation to allow modification of user passwords which is not dependent upon the form of the authentication identity nor the password storage mechanism used. [STANDARDS TRACK] </abstract>
        <draft>zeilenga-ldap-passwd-exop-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3063</doc-id>
        <title>MPLS Loop Prevention Mechanism</title>
        <author>
            <name>Y. Ohba</name>
        </author>
        <author>
            <name>Y. Katsube</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <author>
            <name>P. Doolan</name>
        </author>
        <date>
            <month>February</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>93523</char-count>
            <page-count>44</page-count>
        </format>
        <keywords>
            <kw>multiprotocol</kw>
            <kw>label</kw>
            <kw>switching</kw>
            <kw>path</kw>
            <kw>LSPs</kw>
        </keywords>
        <abstract>This paper presents a simple mechanism, based on "threads", which can be used to prevent Multiprotocol Label Switching (MPLS) from setting up label switched path (LSPs) which have loops. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-mpls-loop-prevention-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3064</doc-id>
        <title>MGCP CAS Packages</title>
        <author>
            <name>B. Foster</name>
        </author>
        <date>
            <month>February</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>116818</char-count>
            <page-count>56</page-count>
        </format>
        <keywords>
            <kw>media</kw>
            <kw>gateway</kw>
            <kw>controllers</kw>
        </keywords>
        <abstract>This document contains a collection of media gateway Channel Associated Signaling (CAS) packages for R1 CAS, North American CAS, CAS PBX interconnect as well as basic FXO support. This memo provides information for the Internet community. </abstract>
        <draft>foster-mgcp-cas-packages-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3065</doc-id>
        <title>Autonomous System Confederations for BGP</title>
        <author>
            <name>P. Traina</name>
        </author>
        <author>
            <name>D. McPherson</name>
        </author>
        <author>
            <name>J. Scudder</name>
        </author>
        <date>
            <month>February</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20529</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>BGP-ASC</kw>
            <kw>AS</kw>
            <kw>border</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document describes an extension to BGP which may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. [STANDARDS TRACK] </abstract>
        <draft>ietf-idr-bgp-confed-rfc1965bis-01</draft>
        <obsoletes>
            <doc-id>RFC1965</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3066</doc-id>
        <title>Tags for the Identification of Languages</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>January</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26522</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>Lang-Tag</kw>
        </keywords>
        <abstract>This document describes a language tag for use in cases where it is desired to indicate the language used in an information object, how to register values for use in this language tag, and a construct for matching such language tags. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>alvestrand-lang-tag-v2-05</draft>
        <obsoletes>
            <doc-id>RFC1766</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0047</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3067</doc-id>
        <title>TERENA'S Incident Object Description and Exchange Format Requirements</title>
        <author>
            <name>J. Arvidsson</name>
        </author>
        <author>
            <name>A. Cormack</name>
        </author>
        <author>
            <name>Y. Demchenko</name>
        </author>
        <author>
            <name>J. Meijer</name>
        </author>
        <date>
            <month>February</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36836</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>IEDEF</kw>
            <kw>data</kw>
            <kw>archiving</kw>
        </keywords>
        <abstract>The purpose of the Incident Object Description and Exchange Format is to define a common data format for the description, archiving and exchange of information about incidents between CSIRTs (Computer Security Incident Response Teams) (including alert, incident in investigation, archiving, statistics, reporting, etc.). This document describes the high-level requirements for such a description and exchange format, including the reasons for those requirements. This memo provides information for the Internet community. </abstract>
        <draft>terena-itdwg-iodef-requirements-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3068</doc-id>
        <title>An Anycast Prefix for 6to4 Relay Routers</title>
        <author>
            <name>C. Huitema</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20120</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>exterior</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
            <kw>interior</kw>
            <kw>IGP</kw>
            <kw>EGP</kw>
        </keywords>
        <abstract>This memo introduces a "6to4 anycast address" in order to simplify the configuration of 6to4 routers. It also defines how this address will be used by 6to4 relay routers, how the corresponding "6to4 anycast prefix" will be advertised in the IGP and in the EGP. The memo documents the reservation by IANA (Internet Assigned Numbers Authority) of the "6to4 relay anycast prefix." [STANDARDS TRACK] </abstract>
        <draft>ietf-ngtrans-6to4anycast-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3069</doc-id>
        <title>VLAN Aggregation for Efficient IP Address Allocation</title>
        <author>
            <name>D. McPherson</name>
        </author>
        <author>
            <name>B. Dykes</name>
        </author>
        <date>
            <month>February</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14891</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>virtual</kw>
            <kw>local</kw>
            <kw>area</kw>
            <kw>network</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document introduces the concept of Virtual Local Area Network (VLAN) aggregation as it relates to IPv4 address allocation. This memo provides information for the Internet community. </abstract>
        <draft>mcpherson-vlan-ipagg-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3070</doc-id>
        <title>Layer Two Tunneling Protocol (L2TP) over Frame Relay</title>
        <author>
            <name>V. Rawat</name>
        </author>
        <author>
            <name>R. Tio</name>
        </author>
        <author>
            <name>S. Nanji</name>
        </author>
        <author>
            <name>R. Verma</name>
        </author>
        <date>
            <month>February</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12940</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>L2TP-FR</kw>
            <kw>point-to-point</kw>
            <kw>virtual</kw>
            <kw>switched</kw>
            <kw>circuits</kw>
            <kw>PVCs</kw>
            <kw>SVCs</kw>
        </keywords>
        <abstract>This document describes how L2TP is implemented over Frame Relay Permanent Virtual Circuits (PVCs) and Switched Virtual Circuits (SVCs). [STANDARDS TRACK] </abstract>
        <draft>ietf-l2tpext-fr-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3071</doc-id>
        <title>Reflections on the DNS, RFC 1591, and Categories of Domains</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>February</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24892</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>DNS</kw>
            <kw>Policy</kw>
            <kw>Top-Level</kw>
            <kw>TLD</kw>
        </keywords>
        <abstract>This document is being published primarily for historical context and comparative purposes, essentially to document some thoughts about how 1591 might have been interpreted and adjusted by the Internet Assigned Numbers Authority (IANA) and ICANN to better reflect today's world while retaining characteristics and policies that have proven to be effective in supporting Internet growth and stability. This memo provides information for the Internet community. </abstract>
        <draft>klensin-1591-reflections-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3072</doc-id>
        <title>Structured Data Exchange Format (SDXF)</title>
        <author>
            <name>M. Wildgrube</name>
        </author>
        <date>
            <month>March</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48481</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>chunks</kw>
            <kw>file</kw>
            <kw>datatype</kw>
        </keywords>
        <abstract>This specification describes an all-purpose interchange format for use as a file format or for net-working. This memo provides information for the Internet community. </abstract>
        <draft>wildgrube-sdxf-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3073</doc-id>
        <title>Portable Font Resource (PFR) - application/font-tdpfr MIME Sub-type Registration</title>
        <author>
            <name>J. Collins</name>
        </author>
        <date>
            <month>March</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9076</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document describes the registration of the Multipurpose Internet Mail Extensions (MIME) sub-type application/font-tdpfr. The encoding is defined by the PFR Specification. This memo provides information for the Internet community. </abstract>
        <draft>collins-pfr-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3074</doc-id>
        <title>DHC Load Balancing Algorithm</title>
        <author>
            <name>B. Volz</name>
        </author>
        <author>
            <name>S. Gonczi</name>
        </author>
        <author>
            <name>T. Lemon</name>
        </author>
        <author>
            <name>R. Stevens</name>
        </author>
        <date>
            <month>February</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19374</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>dynamic</kw>
            <kw>host</kw>
            <kw>configuration</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document proposes a method of algorithmic load balancing. [STANDARDS TRACK] </abstract>
        <draft>ietf-dhc-loadb-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3075</doc-id>
        <title>XML-Signature Syntax and Processing</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>J. Reagle</name>
        </author>
        <author>
            <name>D. Solo</name>
        </author>
        <date>
            <month>March</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>145520</char-count>
            <page-count>64</page-count>
        </format>
        <keywords>
            <kw>extensible</kw>
            <kw>markup</kw>
            <kw>language</kw>
        </keywords>
        <abstract>This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. [STANDARDS TRACK] </abstract>
        <draft>ietf-xmldsig-core-11</draft>
        <obsoleted-by>
            <doc-id>RFC3275</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3076</doc-id>
        <title>Canonical XML Version 1.0</title>
        <author>
            <name>J. Boyer</name>
        </author>
        <date>
            <month>March</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63955</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>extensible</kw>
            <kw>markup</kw>
            <kw>language</kw>
        </keywords>
        <abstract>This specification describes a method for generating a physical representation, the canonical form, of an XML document that accounts for the permissible changes. This memo provides information for the Internet community. </abstract>
        <draft>ietf-xmldsig-canonical-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3077</doc-id>
        <title>A Link-Layer Tunneling Mechanism for Unidirectional Links</title>
        <author>
            <name>E. Duros</name>
        </author>
        <author>
            <name>W. Dabbous</name>
        </author>
        <author>
            <name>H. Izumiyama</name>
        </author>
        <author>
            <name>N. Fujii</name>
        </author>
        <author>
            <name>Y. Zhang</name>
        </author>
        <date>
            <month>March</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52410</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>ll</kw>
            <kw>udl</kw>
            <kw>bidirectional</kw>
            <kw>connectivity</kw>
            <kw>ip</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document describes a mechanism to emulate full bidirectional connectivity between all nodes that are directly connected by a unidirectional link. [STANDARDS TRACK] </abstract>
        <draft>ietf-udlr-lltunnel-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3078</doc-id>
        <title>Microsoft Point-To-Point Encryption (MPPE) Protocol</title>
        <author>
            <name>G. Pall</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <date>
            <month>March</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22952</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>ppp</kw>
        </keywords>
        <abstract>This document describes the use of the Microsoft Point to Point Encryption (MPPE) to enhance the confidentiality of PPP-encapsulated packets. This memo provides information for the Internet community. </abstract>
        <draft>ietf-pppext-mppe-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3079</doc-id>
        <title>Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)</title>
        <author>
            <name>G. Zorn</name>
        </author>
        <date>
            <month>March</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38905</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>ppp</kw>
        </keywords>
        <abstract>This document describes the method used to derive initial MPPE session keys from a variety of credential types. It is expected that this memo will be updated whenever Microsoft defines a new key derivation method for MPPE, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products. This memo provides information for the Internet community. </abstract>
        <draft>ietf-pppext-mppe-keys-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3080</doc-id>
        <title>The Blocks Extensible Exchange Protocol Core</title>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>March</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>82089</char-count>
            <page-count>58</page-count>
        </format>
        <keywords>
            <kw>BEEP</kw>
            <kw>text</kw>
            <kw>binary</kw>
            <kw>messages</kw>
            <kw>kernal</kw>
        </keywords>
        <abstract>This memo describes a generic application protocol kernel for connection-oriented, asynchronous interactions called the BEEP (Blocks Extensible Exchange Protocol) core. [STANDARDS TRACK] </abstract>
        <draft>ietf-beep-framework-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3081</doc-id>
        <title>Mapping the BEEP Core onto TCP</title>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>March</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14008</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
            <kw>blocks</kw>
            <kw>extensible</kw>
            <kw>exchange</kw>
        </keywords>
        <abstract>This memo describes how a BEEP (Blocks Extensible Exchange Protocol) session is mapped onto a single TCP (Transmission Control Protocol) connection. [STANDARDS TRACK] </abstract>
        <draft>ietf-beep-tcpmapping-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3082</doc-id>
        <title>Notification and Subscription for SLP</title>
        <author>
            <name>J. Kempf</name>
        </author>
        <author>
            <name>J. Goldschmidt</name>
        </author>
        <date>
            <month>March</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33410</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>service</kw>
            <kw>location</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>The Service Location Protocol (SLP) provides mechanisms whereby service agent clients can advertise and user agent clients can query for services. The design is very much demand-driven, so that user agents only obtain service information when they specifically ask for it. There exists another class of user agent applications, however, that requires notification when a new service appears or disappears. In the RFC 2608 design, these applications are forced to poll the network to catch changes. In this document, we describe a protocol for allowing such clients to be notified when a change occurs, removing the need for polling. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>kempf-srvloc-notify-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3083</doc-id>
        <title>Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems</title>
        <author>
            <name>R. Woundy</name>
        </author>
        <date>
            <month>March</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>88318</char-count>
            <page-count>45</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>BPI</kw>
            <kw>data-over-cable</kw>
            <kw>service interface</kw>
            <kw>specifications</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based (Simple Network Management Protocol) management of the Baseline Privacy Interface (BPI), which provides data privacy for DOCSIS 1.0 (Data-Over- Cable Service Interface Specifications) compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Radio Frequency Interface MIB, RFC 2670. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ipcdn-mcns-bpi-mib-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3084</doc-id>
        <title>COPS Usage for Policy Provisioning (COPS-PR)</title>
        <author>
            <name>K. Chan</name>
        </author>
        <author>
            <name>J. Seligson</name>
        </author>
        <author>
            <name>D. Durham</name>
        </author>
        <author>
            <name>S. Gai</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>S. Herzog</name>
        </author>
        <author>
            <name>F. Reichmeyer</name>
        </author>
        <author>
            <name>R. Yavatkar</name>
        </author>
        <author>
            <name>A. Smith</name>
        </author>
        <date>
            <month>March</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>79341</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>COPS-PR</kw>
            <kw>common</kw>
            <kw>open</kw>
            <kw>service</kw>
            <kw>security</kw>
            <kw>quality</kw>
        </keywords>
        <abstract>This document describes the use of the Common Open Policy Service (COPS) protocol for support of policy provisioning (COPS-PR). [STANDARDS TRACK] </abstract>
        <draft>ietf-rap-pr-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3085</doc-id>
        <title>URN Namespace for NewsML Resources</title>
        <author>
            <name>A. Coates</name>
        </author>
        <author>
            <name>D. Allen</name>
        </author>
        <author>
            <name>D. Rivers-Moore</name>
        </author>
        <date>
            <month>March</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10016</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>name</kw>
            <kw>newsitems</kw>
            <kw>iptc</kw>
        </keywords>
        <abstract>This document describes a URN (Uniform Resource Name) namespace for identifying NewsML NewsItems. This memo provides information for the Internet community. </abstract>
        <draft>iptc-newsml-urn-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3086</doc-id>
        <title>Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification</title>
        <author>
            <name>K. Nichols</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <date>
            <month>April</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63122</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>diffserv</kw>
            <kw>QoS</kw>
            <kw>quality of service</kw>
        </keywords>
        <abstract>This document defines and discusses Per-Domain Behaviors in detail and lays out the format and required content for contributions to the Diffserv WG on PDBs and the procedure that will be applied for individual PDB specifications to advance as WG products. This format is specified to expedite working group review of PDB submissions. This memo provides information for the Internet community. </abstract>
        <draft>ietf-diffserv-pdb-def-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3087</doc-id>
        <title>Control of Service Context using SIP Request-URI</title>
        <author>
            <name>B. Campbell</name>
        </author>
        <author>
            <name>R. Sparks</name>
        </author>
        <date>
            <month>April</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>83612</char-count>
            <page-count>39</page-count>
        </format>
        <keywords>
            <kw>session</kw>
            <kw>initiation</kw>
            <kw>protocol</kw>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>identifier</kw>
        </keywords>
        <abstract>This memo describes a useful way to conceptualize the use of the standard SIP (Session Initiation Protocol) Request-URI (Uniform Resource Identifier) that the authors and many members of the SIP community think is suitable as a convention. It does not define any new protocol with respect to RFC 2543. This memo provides information for the Internet community. </abstract>
        <draft>campbell-sip-service-control-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3088</doc-id>
        <title>OpenLDAP Root Service An experimental LDAP referral service</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>April</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19471</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>dns</kw>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
        </keywords>
        <abstract>The OpenLDAP Project is operating an experimental LDAP (Lightweight Directory Access Protocol) referral service known as the "OpenLDAP Root Service". The automated system generates referrals based upon service location information published in DNS SRV RRs (Domain Name System location of services resource records). This document describes this service. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>zeilenga-ldap-root-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3089</doc-id>
        <title>A SOCKS-based IPv6/IPv4 Gateway Mechanism</title>
        <author>
            <name>H. Kitamura</name>
        </author>
        <date>
            <month>April</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25193</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>application</kw>
            <kw>layer</kw>
        </keywords>
        <abstract>This document describes a SOCKS-based IPv6/IPv4 gateway mechanism that enables smooth heterogeneous communications between the IPv6 nodes and IPv4 nodes. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ngtrans-socks-gateway-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3090</doc-id>
        <title>DNS Security Extension Clarification on Zone Status</title>
        <author>
            <name>E. Lewis</name>
        </author>
        <date>
            <month>March</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24166</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>rsa</kw>
            <kw>dsa</kw>
        </keywords>
        <abstract>The definition of a secured zone is presented, clarifying and updating sections of RFC 2535. RFC 2535 defines a zone to be secured based on a per algorithm basis, e.g., a zone can be secured with RSA keys, and not secured with DSA keys. This document changes this to define a zone to be secured or not secured regardless of the key algorithm used (or not used). To further simplify the determination of a zone's status, "experimentally secure" status is deprecated. [STANDARDS TRACK] </abstract>
        <draft>ietf-dnsext-zone-status-05</draft>
        <obsoleted-by>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4035</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2535</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC3658</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3091</doc-id>
        <title>Pi Digit Generation Protocol</title>
        <author>
            <name>H. Kennedy</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10375</char-count>
            <page-count>6</page-count>
        </format>
        <abstract>This memo defines a protocol to provide the Pi digit generation service (PIgen) used between clients and servers on host computers. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3092</doc-id>
        <title>Etymology of "Foo"</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>C. Manros</name>
        </author>
        <author>
            <name>E. Raymond</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29235</char-count>
            <page-count>14</page-count>
        </format>
        <abstract>Approximately 212 RFCs so far, starting with RFC 269, contain the terms `foo', `bar', or `foobar' as metasyntactic variables without any proper explanation or definition. This document rectifies that deficiency. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3093</doc-id>
        <title>Firewall Enhancement Protocol (FEP)</title>
        <author>
            <name>M. Gaynor</name>
        </author>
        <author>
            <name>S. Bradner</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22405</char-count>
            <page-count>11</page-count>
        </format>
        <abstract>Internet Transparency via the end-to-end architecture of the Internet has allowed vast innovation of new technologies and services [1]. However, recent developments in Firewall technology have altered this model and have been shown to inhibit innovation. We propose the Firewall Enhancement Protocol (FEP) to allow innovation, without violating the security model of a Firewall. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3094</doc-id>
        <title>Tekelec's Transport Adapter Layer Interface</title>
        <author>
            <name>D. Sprague</name>
        </author>
        <author>
            <name>R. Benedyk</name>
        </author>
        <author>
            <name>D. Brendes</name>
        </author>
        <author>
            <name>J. Keller</name>
        </author>
        <date>
            <month>April</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>265099</char-count>
            <page-count>106</page-count>
        </format>
        <keywords>
            <kw>signaling</kw>
            <kw>gatewa</kw>
            <kw>circuit</kw>
            <kw>network</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document proposes the interfaces of a Signaling Gateway, which provides interworking between the Switched Circuit Network (SCN) and an IP network. This memo provides information for the Internet community. </abstract>
        <draft>benedyk-sigtran-tali-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3095</doc-id>
        <title>RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed </title>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>C. Burmeister</name>
        </author>
        <author>
            <name>M. Degermark</name>
        </author>
        <author>
            <name>H. Fukushima</name>
        </author>
        <author>
            <name>H. Hannu</name>
        </author>
        <author>
            <name>L-E. Jonsson</name>
        </author>
        <author>
            <name>R. Hakenberg</name>
        </author>
        <author>
            <name>T. Koren</name>
        </author>
        <author>
            <name>K. Le</name>
        </author>
        <author>
            <name>Z. Liu</name>
        </author>
        <author>
            <name>A. Martensson</name>
        </author>
        <author>
            <name>A. Miyazaki</name>
        </author>
        <author>
            <name>K. Svanbro</name>
        </author>
        <author>
            <name>T. Wiebke</name>
        </author>
        <author>
            <name>T. Yoshimura</name>
        </author>
        <author>
            <name>H. Zheng</name>
        </author>
        <date>
            <month>July</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>368746</char-count>
            <page-count>168</page-count>
        </format>
        <keywords>
            <kw>encapsulating</kw>
            <kw>security</kw>
            <kw>payload</kw>
            <kw>real-time</kw>
            <kw>transport</kw>
            <kw>protocol</kw>
            <kw>user</kw>
            <kw>datagram</kw>
        </keywords>
        <abstract>This document specifies a highly robust and efficient header compression scheme for RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), UDP/IP, and ESP/IP (Encapsulating Security Payload) headers. [STANDARDS TRACK] </abstract>
        <draft>ietf-rohc-rtp-09</draft>
        <updated-by>
            <doc-id>RFC3759</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3096</doc-id>
        <title>Requirements for robust IP/UDP/RTP header compression</title>
        <author>
            <name>M. Degermark</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15018</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>real-time</kw>
            <kw>transport</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>user</kw>
            <kw>datagram</kw>
        </keywords>
        <abstract>This document contains requirements for robust IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression to be developed by the ROHC (Robust Header Compression) WG. It is based on the ROHC charter, discussions in the WG, the 3GPP document "3GPP TR 23.922", version 1.0.0 of October 1999, as well as contributions from 3G.IP. This memo provides information for the Internet community. </abstract>
        <draft>ietf-rohc-rtp-requirements-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3097</doc-id>
        <title>RSVP Cryptographic Authentication -- Updated Message Type Value</title>
        <author>
            <name>R. Braden</name>
        </author>
        <author>
            <name>L. Zhang</name>
        </author>
        <date>
            <month>April</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6320</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>RSVP</kw>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
            <kw>security </kw>
        </keywords>
        <abstract>This memo resolves a duplication in the assignment of RSVP Message Types, by changing the Message Types assigned by RFC 2747 to Challenge and Integrity Response messages. [STANDARDS TRACK] </abstract>
        <draft>ietf-rsvp-fix-iana-00</draft>
        <updates>
            <doc-id>RFC2747</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3098</doc-id>
        <title>How to Advertise Responsibly Using E-Mail and Newsgroups or - how NOT to $$$$$  MAKE ENEMIES FAST!  $$$$$</title>
        <author>
            <name>T. Gavin</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>S. Hambridge</name>
        </author>
        <date>
            <month>April</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>64687</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>marketing</kw>
            <kw>users</kw>
            <kw>service</kw>
            <kw>providers</kw>
            <kw>isps</kw>
        </keywords>
        <abstract>This memo offers useful suggestions for responsible advertising techniques that can be used via the internet in an environment where the advertiser, recipients, and the Internet Community can coexist in a productive and mutually respectful fashion. This memo provides information for the Internet community. </abstract>
        <draft>ietf-run-adverts-02</draft>
        <is-also>
            <doc-id>FYI0038</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3099</doc-id>
        <title>Request for Comments Summary RFC Numbers 3000-3099</title>
        <author>
            <name>S. Ginoza</name>
        </author>
        <date>
            <month>November</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48990</char-count>
            <page-count>25</page-count>
        </format>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC3100</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC3101</doc-id>
        <title>The OSPF Not-So-Stubby Area (NSSA) Option</title>
        <author>
            <name>P. Murphy</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>76243</char-count>
            <page-count>33</page-count>
        </format>
        <keywords>
            <kw>OSPF-NSSA</kw>
            <kw>stub</kw>
            <kw>external routes</kw>
            <kw>backward compatible</kw>
        </keywords>
        <abstract>This memo documents an optional type of Open Shortest Path First (OSPF) area that is somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. The OSPF NSSA Option was originally defined in RFC 1587. The functional differences between this memo and RFC 1587 are explained in Appendix F. All differences, while expanding capability, are backward-compatible in nature. Implementations of this memo and of RFC 1587 will interoperate. [STANDARDS TRACK] </abstract>
        <draft>ietf-ospf-nssa-update-11</draft>
        <obsoletes>
            <doc-id>RFC1587</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3102</doc-id>
        <title>Realm Specific IP: Framework</title>
        <author>
            <name>M. Borella</name>
        </author>
        <author>
            <name>J. Lo</name>
        </author>
        <author>
            <name>D. Grabelsky</name>
        </author>
        <author>
            <name>G. Montenegro</name>
        </author>
        <date>
            <month>October</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>73856</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>RSIP</kw>
            <kw>end-to-end</kw>
            <kw>NAT</kw>
            <kw>addressing</kw>
            <kw>requirements</kw>
        </keywords>
        <abstract>This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end-to- end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-nat-rsip-framework-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3103</doc-id>
        <title>Realm Specific IP: Protocol Specification</title>
        <author>
            <name>M. Borella</name>
        </author>
        <author>
            <name>D. Grabelsky</name>
        </author>
        <author>
            <name>J. Lo</name>
        </author>
        <author>
            <name>K. Taniguchi</name>
        </author>
        <date>
            <month>October</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>115855</char-count>
            <page-count>54</page-count>
        </format>
        <keywords>
            <kw>RSIP</kw>
            <kw>host</kw>
            <kw>gateway</kw>
            <kw>NAT</kw>
            <kw>requirements</kw>
        </keywords>
        <abstract>This document presents a protocol with which to implement Realm Specific IP (RSIP). The protocol defined herein allows negotiation of resources between an RSIP host and gateway, so that the host can lease some of the gateway's addressing parameters in order to establish a global network presence. This protocol is designed to operate on the application layer and to use its own TCP or UDP port. In particular, the protocol allows a gateway to allocate addressing and control parameters to a host such that a flow policy can be enforced at the gateway. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-nat-rsip-protocol-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3104</doc-id>
        <title>RSIP Support for End-to-end IPsec</title>
        <author>
            <name>G. Montenegro</name>
        </author>
        <author>
            <name>M. Borella</name>
        </author>
        <date>
            <month>October</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38719</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>realm</kw>
            <kw>specific</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>NAT</kw>
            <kw>addressing</kw>
            <kw>requirements</kw>
        </keywords>
        <abstract>This document proposes mechanisms that enable Realm Specific IP (RSIP) to handle end-to-end IPsec (IP Security). This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-nat-rsip-ipsec-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3105</doc-id>
        <title>Finding an RSIP Server with SLP</title>
        <author>
            <name>J. Kempf</name>
        </author>
        <author>
            <name>G. Montenegro</name>
        </author>
        <date>
            <month>October</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21427</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>realm</kw>
            <kw>specific</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>service</kw>
            <kw>location</kw>
            <kw>NAT</kw>
            <kw>addressing</kw>
            <kw>requirements</kw>
        </keywords>
        <abstract>This document contains an SLP service type template that describes the advertisements made by RSIP servers for their services. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-nat-rsip-slp-00</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3106</doc-id>
        <title>ECML v1.1: Field Specifications for E-Commerce</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>T. Goldstein</name>
        </author>
        <date>
            <month>April</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40715</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>electronic</kw>
            <kw>modeling</kw>
            <kw>language</kw>
        </keywords>
        <abstract>Customers are frequently required to enter substantial amounts of information at an Internet merchant site in order to complete a purchase or other transaction, especially the first time they go there. A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. Even for the manual data entry case, customers will be less confused by varying merchant sites if a substantial number adopt these standard fields. In addition, some fields are defined for merchant to consumer communication. This memo provides information for the Internet community. </abstract>
        <draft>eastlake-ecom-fields2-05</draft>
        <obsoletes>
            <doc-id>RFC2706</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3107</doc-id>
        <title>Carrying Label Information in BGP-4</title>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>E. Rosen</name>
        </author>
        <date>
            <month>May</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16442</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>SDP</kw>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>AAL</kw>
            <kw>syntax</kw>
            <kw>adaption</kw>
            <kw>layer</kw>
        </keywords>
        <abstract>This document specifies the way in which the label mapping information for a particular route is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the route itself. [STANDARDS TRACK] </abstract>
        <draft>ietf-mpls-bgp4-mpls-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3108</doc-id>
        <title>Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections</title>
        <author>
            <name>R. Kumar</name>
        </author>
        <author>
            <name>M. Mostafa</name>
        </author>
        <date>
            <month>May</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>248037</char-count>
            <page-count>110</page-count>
        </format>
        <keywords>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>AAL</kw>
            <kw>syntax</kw>
            <kw>adaption</kw>
            <kw>layer</kw>
        </keywords>
        <abstract>This document describes conventions for using the Session Description Protocol (SDP) described in RFC 2327 for controlling ATM Bearer Connections, and any associated ATM Adaptation Layer (AAL). The AALs addressed are Type 1, Type 2 and Type 5. [STANDARDS TRACK] </abstract>
        <draft>ietf-mmusic-sdp-atm-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3109</doc-id>
        <title>Request to Move STD 39 to Historic Status</title>
        <author>
            <name>R. Braden</name>
        </author>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>May</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5841</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>BBN 1822</kw>
            <kw>host</kw>
            <kw>imp</kw>
            <kw>arpanet</kw>
        </keywords>
        <abstract>This memo changes the status of STD 39, BBN Report 1822, "Specification of the Interconnection of a Host and an IMP", from Standard to Historic. This memo provides information for the Internet community. </abstract>
        <draft>ymbk-std39-historic-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3110</doc-id>
        <title>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>May</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14587</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>RRs</kw>
            <kw>resource</kw>
            <kw>records</kw>
            <kw>security</kw>
        </keywords>
        <abstract>This document describes how to produce RSA/SHA1 SIG resource records (RRs) in Section 3 and, so as to completely replace RFC 2537, describes how to produce RSA KEY RRs in Section 2. [STANDARDS TRACK] </abstract>
        <draft>ietf-dnsext-rsa-03</draft>
        <obsoletes>
            <doc-id>RFC2537</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3111</doc-id>
        <title>Service Location Protocol Modifications for IPv6</title>
        <author>
            <name>E. Guttman</name>
        </author>
        <date>
            <month>May</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25543</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>SLP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document defines the Service Location Protocol Version 2's (SLPv2) use over IPv6 networks. Since this protocol relies on UDP and TCP, the changes to support its use over IPv6 are minor. [STANDARDS TRACK] </abstract>
        <draft>ietf-svrloc-ipv6-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3112</doc-id>
        <title>LDAP Authentication Password Schema</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>May</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17116</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document describes schema in support of user/password authentication in a LDAP (Lightweight Directory Access Protocol) directory including the authPassword attribute type. This memo provides information for the Internet community. </abstract>
        <draft>zeilenga-ldap-authpsswd-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3113</doc-id>
        <title>3GPP-IETF Standardization Collaboration</title>
        <author>
            <name>K. Rosenbrock</name>
        </author>
        <author>
            <name>R. Sanmugam</name>
        </author>
        <author>
            <name>S. Bradner</name>
        </author>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11405</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>engineering</kw>
            <kw>task</kw>
            <kw>force</kw>
            <kw>third generation</kw>
            <kw>partnership project</kw>
        </keywords>
        <abstract>This document describes the standardization collaboration between 3GPP and IETF. This memo provides information for the Internet community. </abstract>
        <draft>3gpp-collaboration-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3114</doc-id>
        <title>Implementing Company Classification Policy with the S/MIME Security Label</title>
        <author>
            <name>W. Nicolls</name>
        </author>
        <date>
            <month>May</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27764</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>data</kw>
            <kw>multipurpose</kw>
            <kw>internet mail extensions</kw>
            <kw>access control</kw>
            <kw>information classification</kw>
            <kw>security category</kw>
        </keywords>
        <abstract>This document discusses how company security policy for data classification can be mapped to the S/MIME security label. Actual policies from three companies provide worked examples. This memo provides information for the Internet community. </abstract>
        <draft>ietf-smime-seclabel-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3115</doc-id>
        <title>Mobile IP Vendor/Organization-Specific Extensions</title>
        <author>
            <name>G. Dommety</name>
        </author>
        <author>
            <name>K. Leung</name>
        </author>
        <date>
            <month>April</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16363</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. [STANDARDS TRACK] </abstract>
        <obsoletes>
            <doc-id>RFC3025</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3116</doc-id>
        <title>Methodology for ATM Benchmarking</title>
        <author>
            <name>J. Dunn</name>
        </author>
        <author>
            <name>C. Martin</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>295052</char-count>
            <page-count>127</page-count>
        </format>
        <keywords>
            <kw>asynchronous</kw>
            <kw>transfer mode</kw>
            <kw>formats</kw>
            <kw>switching</kw>
        </keywords>
        <abstract>This document discusses and defines a number of tests that may be used to describe the performance characteristics of ATM (Asynchronous Transfer Mode) based switching devices. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. This memo provides information for the Internet community. </abstract>
        <draft>ietf-bmwg-atm-method-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3117</doc-id>
        <title>On the Design of Application Protocols</title>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>November</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>57279</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>beep</kw>
            <kw>bxxp</kw>
            <kw>blocks</kw>
            <kw>extensible</kw>
            <kw>exchange</kw>
            <kw>text</kw>
            <kw>binary</kw>
        </keywords>
        <abstract>This memo describes the design principles for the Blocks eXtensible eXchange Protocol (BXXP). This memo provides information for the Internet community. </abstract>
        <draft>mrose-beep-design-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3118</doc-id>
        <title>Authentication for DHCP Messages</title>
        <author>
            <name>R. Droms</name>
        </author>
        <author>
            <name>W. Arbaugh</name>
            <title>Editors</title>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35536</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>dynamic</kw>
            <kw>host</kw>
            <kw>configuration</kw>
            <kw>protocol</kw>
            <kw>verification</kw>
        </keywords>
        <abstract>This document defines a new Dynamic Host Configuration Protocol (DHCP) option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. [STANDARDS TRACK] </abstract>
        <draft>ietf-dhc-authentication-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3119</doc-id>
        <title>A More Loss-Tolerant RTP Payload Format for MP3 Audio</title>
        <author>
            <name>R. Finlayson</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37796</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>real-time</kw>
            <kw>protocol</kw>
            <kw>moving</kw>
            <kw>picture</kw>
            <kw>experts</kw>
            <kw>group</kw>
        </keywords>
        <abstract>This document describes a RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as "MP3"). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. [STANDARDS TRACK] </abstract>
        <draft>ietf-avt-rtp-mp3-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3120</doc-id>
        <title>A URN Namespace for XML.org</title>
        <author>
            <name>K. Best</name>
        </author>
        <author>
            <name>N. Walsh</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8068</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>name</kw>
            <kw>extensible</kw>
            <kw>markup</kw>
            <kw>language</kw>
        </keywords>
        <abstract>This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of Structured Information Standards (OASIS) for naming persistent resources stored in the XML.org repository (such as XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, Stylesheets, and other documents). This memo provides information for the Internet community. </abstract>
        <draft>best-xmlorg-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3121</doc-id>
        <title>A URN Namespace for OASIS</title>
        <author>
            <name>K. Best</name>
        </author>
        <author>
            <name>N. Walsh</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11074</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>name</kw>
            <kw>organization for the advancement of structured information standards</kw>
        </keywords>
        <abstract>This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of Structured Information Standards (OASIS) for naming persistent resources published by OASIS (such as OASIS Standards, XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, Stylesheets, and other documents). This memo provides information for the Internet community. </abstract>
        <draft>best-urn-oasis-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3122</doc-id>
        <title>Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification</title>
        <author>
            <name>A. Conta</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40416</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>IND</kw>
            <kw>link-layer</kw>
        </keywords>
        <abstract>This memo describes extensions to the IPv6 Neighbor Discovery that allow a node to determine and advertise an IPv6 address corresponding to a given link-layer address. [STANDARDS TRACK] </abstract>
        <draft>ietf-ion-ipv6-ind-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3123</doc-id>
        <title>A DNS RR Type for Lists of Address Prefixes (APL RR)</title>
        <author>
            <name>P. Koch</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14648</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>resource</kw>
            <kw>record</kw>
        </keywords>
        <abstract>The Domain Name System (DNS) is primarily used to translate domain names into IPv4 addresses using A RRs (Resource Records). Several approaches exist to describe networks or address ranges. This document specifies a new DNS RR type "APL" for address prefix lists. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-dnsext-apl-rr-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3124</doc-id>
        <title>The Congestion Manager</title>
        <author>
            <name>H. Balakrishnan</name>
        </author>
        <author>
            <name>S. Seshan</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53591</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>network</kw>
            <kw>stream</kw>
            <kw>end-system module</kw>
        </keywords>
        <abstract>This document describes the Congestion Manager (CM), an end-system module that enables an ensemble of multiple concurrent streams from a sender destined to the same receiver and sharing the same congestion properties to perform proper congestion avoidance and control, and allows applications to easily adapt to network congestion. [STANDARDS TRACK] </abstract>
        <draft>ietf-ecm-cm-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3125</doc-id>
        <title>Electronic Signature Policies</title>
        <author>
            <name>J. Ross</name>
        </author>
        <author>
            <name>D. Pinkas</name>
        </author>
        <author>
            <name>N. Pope</name>
        </author>
        <date>
            <month>September</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>95505</char-count>
            <page-count>44</page-count>
        </format>
        <keywords>
            <kw>signer</kw>
            <kw>purchase</kw>
            <kw>contract</kw>
            <kw>invoice</kw>
            <kw>transactions</kw>
            <kw>applications</kw>
        </keywords>
        <abstract>This document defines signature policies for electronic signatures. A signature policy is a set of rules for the creation and validation of an electronic signature, under which the validity of signature can be determined. A given legal/contractual context may recognize a particular signature policy as meeting its requirements. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-smime-espolicies-00</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3126</doc-id>
        <title>Electronic Signature Formats for long term electronic signatures</title>
        <author>
            <name>D. Pinkas</name>
        </author>
        <author>
            <name>J. Ross</name>
        </author>
        <author>
            <name>N. Pope</name>
        </author>
        <date>
            <month>September</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>175886</char-count>
            <page-count>84</page-count>
        </format>
        <keywords>
            <kw>purchase</kw>
            <kw>contract</kw>
            <kw>invoice</kw>
            <kw>application</kw>
            <kw>smart cards</kw>
            <kw>data</kw>
        </keywords>
        <abstract>This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates the validity of the signature). This memo provides information for the Internet community. </abstract>
        <draft>ietf-smime-esformats-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3127</doc-id>
        <title>Authentication, Authorization, and Accounting: Protocol Evaluation</title>
        <author>
            <name>D. Mitton</name>
        </author>
        <author>
            <name>M. St.Johns</name>
        </author>
        <author>
            <name>S. Barkley</name>
        </author>
        <author>
            <name>D. Nelson</name>
        </author>
        <author>
            <name>B. Patil</name>
        </author>
        <author>
            <name>M. Stevens</name>
        </author>
        <author>
            <name>B. Wolff</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>170579</char-count>
            <page-count>84</page-count>
        </format>
        <keywords>
            <kw>AAA</kw>
            <kw>network</kw>
            <kw>access</kw>
            <kw>requirements</kw>
        </keywords>
        <abstract>This memo represents the process and findings of the Authentication, Authorization, and Accounting Working Group (AAA WG) panel evaluating protocols proposed against the AAA Network Access Requirements, RFC 2989. This memo provides information for the Internet community. </abstract>
        <draft>ietf-aaa-proto-eval-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3128</doc-id>
        <title>Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)</title>
        <author>
            <name>I. Miller</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8242</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>firewalls</kw>
            <kw>internet</kw>
        </keywords>
        <abstract>This document discusses how RFC 1858 compliant filters can be vulnerable to a variant of the "Tiny Fragment Attack" described in section 3.1 of the RFC. This document describes the attack and recommends corrective action. This memo provides information for the Internet community. </abstract>
        <draft>miller-rfc1858-cmts-00</draft>
        <updates>
            <doc-id>RFC1858</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3129</doc-id>
        <title>Requirements for Kerberized Internet Negotiation of Keys</title>
        <author>
            <name>M. Thomas</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11401</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>KINK</kw>
            <kw>cryptographic</kw>
            <kw>security</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>The goal of this document is to produce a streamlined, fast, easily managed, and cryptographically sound protocol without requiring public key. This memo provides information for the Internet community. </abstract>
        <draft>ietf-kink-reqmt-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3130</doc-id>
        <title>Notes from the State-Of-The-Technology: DNSSEC</title>
        <author>
            <name>E. Lewis</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22291</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>security</kw>
            <kw>extensions</kw>
            <kw>report</kw>
        </keywords>
        <abstract>This is a memo of a DNSSEC (Domain Name System Security Extensions) status meeting. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3131</doc-id>
        <title>3GPP2-IETF Standardization Collaboration</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <author>
            <name>P. Calhoun</name>
        </author>
        <author>
            <name>H. Cuschieri</name>
        </author>
        <author>
            <name>S. Dennett</name>
        </author>
        <author>
            <name>G. Flynn</name>
        </author>
        <author>
            <name>M. Lipford</name>
        </author>
        <author>
            <name>M. McPheters</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13643</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>engineering</kw>
            <kw>task</kw>
            <kw>force</kw>
            <kw>third generation</kw>
            <kw>partnership project</kw>
        </keywords>
        <abstract>This document describes the standardization collaboration between 3GPP2 and IETF. This memo provides information for the Internet community. </abstract>
        <draft>bradner-3gpp2-collaboration-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3132</doc-id>
        <title>Dormant Mode Host Alerting ("IP Paging") Problem Statement</title>
        <author>
            <name>J. Kempf</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34985</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>molulity</kw>
            <kw>radio</kw>
            <kw>link</kw>
            <kw>internet</kw>
            <kw>protocl</kw>
        </keywords>
        <abstract>This memo describes paging, assesses the need for IP paging, and presents a list of recommendations for Seamoby charter items regarding work on paging. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3133</doc-id>
        <title>Terminology for Frame Relay Benchmarking</title>
        <author>
            <name>J. Dunn</name>
        </author>
        <author>
            <name>C. Martin</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44182</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>switching</kw>
            <kw>devices</kw>
            <kw>signaling</kw>
        </keywords>
        <abstract>This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of frame relay switching devices. This memo provides information for the Internet community. </abstract>
        <draft>ietf-bmwg-atm-term-abr-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3134</doc-id>
        <title>Terminology for ATM ABR Benchmarking</title>
        <author>
            <name>J. Dunn</name>
        </author>
        <author>
            <name>C. Martin</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29542</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
            <kw>available</kw>
            <kw>bit rate</kw>
        </keywords>
        <abstract>This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of Asynchronous Transfer Mode (ATM) based switching devices supporting ABR (Available Bit Rate). This memo provides information for the Internet community. </abstract>
        <draft>ietf-bmwg-atm-term-abr-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3135</doc-id>
        <title>Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations</title>
        <author>
            <name>J. Border</name>
        </author>
        <author>
            <name>M. Kojo</name>
        </author>
        <author>
            <name>J. Griner</name>
        </author>
        <author>
            <name>G. Montenegro</name>
        </author>
        <author>
            <name>Z. Shelby</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>114825</char-count>
            <page-count>45</page-count>
        </format>
        <keywords>
            <kw>PEP</kw>
            <kw>PILC</kw>
            <kw>TCP</kw>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document is a survey of Performance Enhancing Proxies (PEPs) often employed to improve degraded TCP performance caused by characteristics of specific link environments, for example, in satellite, wireless WAN, and wireless LAN environments. This memo provides information for the Internet community. </abstract>
        <draft>ietf-pilc-pep-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3136</doc-id>
        <title>The SPIRITS Architecture</title>
        <author>
            <name>L. Slutsman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>I. Faynberg</name>
        </author>
        <author>
            <name>H. Lu</name>
        </author>
        <author>
            <name>M. Weissman</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19241</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>PSTN</kw>
            <kw>public</kw>
            <kw>switched</kw>
            <kw>telephone</kw>
            <kw>network</kw>
        </keywords>
        <abstract>This document describes the architecture for supporting SPIRITS services, which are those originating in the PSTN (Public Switched Telephone Network)and necessitating the interactions between the PSTN and the Internet. This memo provides information for the Internet community. </abstract>
        <draft>ietf-spirits-architecture-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3137</doc-id>
        <title>OSPF Stub Router Advertisement</title>
        <author>
            <name>A. Retana</name>
        </author>
        <author>
            <name>L. Nguyen</name>
        </author>
        <author>
            <name>R. White</name>
        </author>
        <author>
            <name>A. Zinin</name>
        </author>
        <author>
            <name>D. McPherson</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8140</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>open</kw>
            <kw>shortest</kw>
            <kw>path</kw>
            <kw>first</kw>
        </keywords>
        <abstract>This memo describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise unavailability to forward transit traffic or to lower the preference level for the paths through such a router. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ospf-stub-adv-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3138</doc-id>
        <title>Extended Assignments in 233/8</title>
        <author>
            <name>D. Meyer</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6776</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>address</kw>
            <kw>AS</kw>
            <kw>autonomous</kw>
            <kw>system</kw>
            <kw>number</kw>
        </keywords>
        <abstract>This memo provides describes the mapping of the GLOP addresses corresponding to the private AS space. This memo provides information for the Internet community. </abstract>
        <draft>ietf-mboned-glop-extensions-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3139</doc-id>
        <title>Requirements for Configuration Management of IP-based Networks</title>
        <author>
            <name>L. Sanchez</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>J. Saperia</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23624</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol </kw>
        </keywords>
        <abstract>This memo discusses different approaches to configure networks and identifies a set of configuration management requirements for IP-based networks. This memo provides information for the Internet community. </abstract>
        <draft>ops-ip-config-management-reqmnts-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3140</doc-id>
        <title>Per Hop Behavior Identification Codes</title>
        <author>
            <name>D. Black</name>
        </author>
        <author>
            <name>S. Brim</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>F. Le Faucheur</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16586</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>PHB</kw>
            <kw>differentiated</kw>
            <kw>services</kw>
            <kw>codepoint</kw>
            <kw>DSCP</kw>
        </keywords>
        <abstract>This document defines a 16 bit encoding mechanism for the identification of differentiated services Per Hop Behaviors in protocol messages. It replaces RFC 2836. [STANDARDS TRACK] </abstract>
        <draft>ietf-diffserv-2836bis-02</draft>
        <obsoletes>
            <doc-id>RFC2836</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3141</doc-id>
        <title>CDMA2000 Wireless Data Requirements for AAA</title>
        <author>
            <name>T. Hiller</name>
        </author>
        <author>
            <name>P. Walsh</name>
        </author>
        <author>
            <name>X. Chen</name>
        </author>
        <author>
            <name>M. Munson</name>
        </author>
        <author>
            <name>G. Dommety</name>
        </author>
        <author>
            <name>S. Sivalingham</name>
        </author>
        <author>
            <name>B. Lim</name>
        </author>
        <author>
            <name>P. McCann</name>
        </author>
        <author>
            <name>H. Shiino</name>
        </author>
        <author>
            <name>B. Hirschman</name>
        </author>
        <author>
            <name>S. Manning</name>
        </author>
        <author>
            <name>R. Hsu</name>
        </author>
        <author>
            <name>H. Koo</name>
        </author>
        <author>
            <name>M. Lipford</name>
        </author>
        <author>
            <name>P. Calhoun</name>
        </author>
        <author>
            <name>C. Lo</name>
        </author>
        <author>
            <name>E. Jaques</name>
        </author>
        <author>
            <name>E. Campbell</name>
        </author>
        <author>
            <name>Y. Xu</name>
        </author>
        <author>
            <name>S. Baba</name>
        </author>
        <author>
            <name>T. Ayaki</name>
        </author>
        <author>
            <name>T. Seki</name>
        </author>
        <author>
            <name>A. Hameed</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27998</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>authentication</kw>
            <kw>authorization</kw>
            <kw>accounting</kw>
        </keywords>
        <abstract>This memo specifies cdma2000 wireless data AAA (Authentication, Authorization, Accounting) requirements associated with third generation wireless architecture that supports roaming among service providers for traditional PPP and Mobile IP services. This memo provides information for the Internet community. </abstract>
        <draft>hiller-cdma2000-aaa-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3142</doc-id>
        <title>An IPv6-to-IPv4 Transport Relay Translator</title>
        <author>
            <name>J. Hagino</name>
        </author>
        <author>
            <name>K. Yamamoto</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20864</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>TRT</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>The document describes an IPv6-to-IPv4 transport relay translator (TRT). This memo provides information for the Internet community. </abstract>
        <draft>ietf-ngtrans-tcpudp-relay-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3143</doc-id>
        <title>Known HTTP Proxy/Caching Problems</title>
        <author>
            <name>I. Cooper</name>
        </author>
        <author>
            <name>J. Dilley</name>
        </author>
        <date>
            <month>June</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>57117</char-count>
            <page-count>32</page-count>
        </format>
        <keywords>
            <kw>www</kw>
            <kw>world wide web</kw>
            <kw>hypertext transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document catalogs a number of known problems with World Wide Web (WWW) (caching) proxies and cache servers. The goal of the document is to provide a discussion of the problems and proposed workarounds, and ultimately to improve conditions by illustrating problems. This memo provides information for the Internet community. </abstract>
        <draft>cooper-wrec-known-prob-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3144</doc-id>
        <title>Remote Monitoring MIB Extensions for Interface Parameters Monitoring</title>
        <author>
            <name>D. Romascanu</name>
        </author>
        <date>
            <month>August</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>62491</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Remote Monitoring MIB with a method of sorting the interfaces of a monitored device according to values of parameters specific to this interface. [STANDARDS TRACK] </abstract>
        <draft>ietf-rmonmib-iftopn-mib-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3145</doc-id>
        <title>L2TP Disconnect Cause Information</title>
        <author>
            <name>R. Verma</name>
        </author>
        <author>
            <name>M. Verma</name>
        </author>
        <author>
            <name>J. Carlson</name>
        </author>
        <date>
            <month>July</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17421</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>layer2</kw>
            <kw>tunneling</kw>
            <kw>PPP</kw>
            <kw>point-to-point</kw>
            <kw>accounting</kw>
            <kw>debugging</kw>
        </keywords>
        <abstract>This document provides an extension to the Layer 2 Tunneling Protocol ("L2TP"), a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. [STANDARDS TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3146</doc-id>
        <title>Transmission of IPv6 Packets over IEEE 1394 Networks</title>
        <author>
            <name>K. Fujisawa</name>
        </author>
        <author>
            <name>A. Onoe</name>
        </author>
        <date>
            <month>October</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16569</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>link-local</kw>
            <kw>addresses</kw>
            <kw>statelessly</kw>
            <kw>autoconfigured</kw>
        </keywords>
        <abstract>This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. [STANDARDS TRACK] </abstract>
        <draft>ietf-ipngwg-1394-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3147</doc-id>
        <title>Generic Routing Encapsulation over CLNS Networks</title>
        <author>
            <name>P. Christian</name>
        </author>
        <date>
            <month>July</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14125</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>connectionless</kw>
            <kw>network</kw>
            <kw>service</kw>
            <kw>GRE</kw>
            <kw>layer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document proposes a method for transporting an arbitrary protocol over a CLNS (Connectionless Network Service) network using GRE (Generic Routing Encapsulation). This may then be used as a method to tunnel IPv4 or IPv6 over CLNS. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3148</doc-id>
        <title>A Framework for Defining Empirical Bulk Transfer Capacity Metrics</title>
        <author>
            <name>M. Mathis</name>
        </author>
        <author>
            <name>M. Allman</name>
        </author>
        <date>
            <month>July</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36041</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>BTC</kw>
            <kw>transport</kw>
            <kw>data</kw>
        </keywords>
        <abstract>This document defines a framework for standardizing multiple BTC (Bulk Transport Capacity) metrics that parallel the permitted transport diversity. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ippm-btc-framework-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3149</doc-id>
        <title>MGCP Business Phone Packages</title>
        <author>
            <name>A. Srinath</name>
        </author>
        <author>
            <name>G. Levendel</name>
        </author>
        <author>
            <name>K. Fritz</name>
        </author>
        <author>
            <name>R. Kalyanaram</name>
        </author>
        <date>
            <month>September</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>77304</char-count>
            <page-count>41</page-count>
        </format>
        <keywords>
            <kw>media</kw>
            <kw>gateway</kw>
            <kw>control</kw>
            <kw>packages</kw>
        </keywords>
        <abstract>This document describes a collection of MGCP (Media Gateway Control Protocol) packages that can be used to take advantage of the feature keys and displays on digital business phones and IP-Phones. This memo provides information for the Internet community. </abstract>
        <draft>srinath-mgcp-bus-packages-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3150</doc-id>
        <title>End-to-end Performance Implications of Slow Links</title>
        <author>
            <name>S. Dawkins</name>
        </author>
        <author>
            <name>G. Montenegro</name>
        </author>
        <author>
            <name>M. Kojo</name>
        </author>
        <author>
            <name>V. Magret</name>
        </author>
        <date>
            <month>July</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39942</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>PILC</kw>
            <kw>data</kw>
            <kw>applications</kw>
            <kw>header</kw>
            <kw>compression</kw>
        </keywords>
        <abstract>This document makes performance-related recommendations for users of network paths that traverse "very low bit-rate" links. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-pilc-slow-06</draft>
        <is-also>
            <doc-id>BCP0048</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3151</doc-id>
        <title>A URN Namespace for Public Identifiers</title>
        <author>
            <name>N. Walsh</name>
        </author>
        <author>
            <name>J. Cowan</name>
        </author>
        <author>
            <name>P. Grosso</name>
        </author>
        <date>
            <month>August</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15595</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>name</kw>
            <kw>publicid</kw>
        </keywords>
        <abstract>This document describes a URN (Uniform Resource Name) namespace that is designed to allow Public Identifiers to be expressed in URI (Uniform Resource Identifiers) syntax. This memo provides information for the Internet community. </abstract>
        <draft>walsh-urn-publicid-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3152</doc-id>
        <title>Delegation of IP6.ARPA</title>
        <author>
            <name>R. Bush</name>
        </author>
        <date>
            <month>August</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>5727</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>DNS</kw>
            <kw>zone</kw>
        </keywords>
        <abstract>This document discusses the need for delegation of the IP6.ARPA DNS zone, and specifies a plan for the technical operation thereof. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ymbk-ip6-arpa-delegation-02</draft>
        <obsoleted-by>
            <doc-id>RFC3596</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2874</doc-id>
            <doc-id>RFC2772</doc-id>
            <doc-id>RFC2766</doc-id>
            <doc-id>RFC2553</doc-id>
            <doc-id>RFC1886</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0049</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3153</doc-id>
        <title>PPP Multiplexing</title>
        <author>
            <name>R. Pazhyannur</name>
        </author>
        <author>
            <name>I. Ali</name>
        </author>
        <author>
            <name>C. Fox</name>
        </author>
        <date>
            <month>August</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19244</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>point-to-point</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document describes a method to reduce the PPP (Point-to-Point Protocol) framing overhead used to transport small packets over slow links. [STANDARDS TRACK] </abstract>
        <draft>ietf-pppext-pppmux-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3154</doc-id>
        <title>Requirements and Functional Architecture for an IP Host Alerting Protocol</title>
        <author>
            <name>J. Kempf</name>
        </author>
        <author>
            <name>C. Castelluccia</name>
        </author>
        <author>
            <name>P. Mutaf</name>
        </author>
        <author>
            <name>N. Nakajima</name>
        </author>
        <author>
            <name>Y. Ohba</name>
        </author>
        <author>
            <name>R. Ramjee</name>
        </author>
        <author>
            <name>Y. Saifullah</name>
        </author>
        <author>
            <name>B. Sarikaya</name>
        </author>
        <author>
            <name>X. Xu</name>
        </author>
        <date>
            <month>August</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31534</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>paging</kw>
            <kw>mobile</kw>
            <kw>hosts</kw>
        </keywords>
        <abstract>This document develops an architecture and a set of requirements needed to support alerting of hosts that are in dormant mode. The architecture and requirements are designed to guide development of an IP protocol for alerting dormant IP mobile hosts, commonly called paging. This memo provides information for the Internet community. </abstract>
        <draft>ietf-seamoby-paging-requirements-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3155</doc-id>
        <title>End-to-end Performance Implications of Links with Errors</title>
        <author>
            <name>S. Dawkins</name>
        </author>
        <author>
            <name>G. Montenegro</name>
        </author>
        <author>
            <name>M. Kojo</name>
        </author>
        <author>
            <name>V. Magret</name>
        </author>
        <author>
            <name>N. Vaidya</name>
        </author>
        <date>
            <month>August</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36388</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>TCP</kw>
            <kw>transmission</kw>
            <kw>control</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document discusses the specific TCP mechanisms that are problematic in environments with high uncorrected error rates, and discusses what can be done to mitigate the problems without introducing intermediate devices into the connection. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-pilc-error-08</draft>
        <is-also>
            <doc-id>BCP0050</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3156</doc-id>
        <title>MIME Security with OpenPGP</title>
        <author>
            <name>M. Elkins</name>
        </author>
        <author>
            <name>D. Del Torto</name>
        </author>
        <author>
            <name>R. Levien</name>
        </author>
        <author>
            <name>T. Roessler</name>
        </author>
        <date>
            <month>August</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26809</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>MIME-PGP</kw>
            <kw>Authentication</kw>
            <kw>Encryption</kw>
        </keywords>
        <abstract>This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC 1847. [STANDARDS TRACK] </abstract>
        <draft>ietf-openpgp-mime-07</draft>
        <updates>
            <doc-id>RFC2015</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3157</doc-id>
        <title>Securely Available Credentials - Requirements</title>
        <author>
            <name>A. Arsenault</name>
        </author>
        <author>
            <name>S. Farrell</name>
        </author>
        <date>
            <month>August</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46169</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>SACRED</kw>
            <kw>trusted roots</kw>
            <kw>private keys</kw>
            <kw>PSE</kw>
            <kw>personal security environment</kw>
        </keywords>
        <abstract>This document describes requirements to be placed on Securely Available Credentials (SACRED) protocols. This memo provides information for the Internet community. </abstract>
        <draft>ietf-sacred-reqs-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3158</doc-id>
        <title>RTP Testing Strategies</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>August</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48208</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>real-time</kw>
            <kw>transport protocol</kw>
        </keywords>
        <abstract>This memo describes a possible testing strategy for RTP (real-time transport protocol) implementations. This memo provides information for the Internet community. </abstract>
        <draft>ietf-avt-rtptest-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3159</doc-id>
        <title>Structure of Policy Provisioning Information (SPPI)</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <author>
            <name>M. Fine</name>
        </author>
        <author>
            <name>J. Seligson</name>
        </author>
        <author>
            <name>K. Chan</name>
        </author>
        <author>
            <name>S. Hahn</name>
        </author>
        <author>
            <name>R. Sahita</name>
        </author>
        <author>
            <name>A. Smith</name>
        </author>
        <author>
            <name>F. Reichmeyer</name>
        </author>
        <date>
            <month>August</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>78621</char-count>
            <page-count>40</page-count>
        </format>
        <keywords>
            <kw>PIB</kw>
            <kw>base</kw>
            <kw>SNMP</kw>
            <kw>simple</kw>
            <kw>network</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>SMI</kw>
        </keywords>
        <abstract>This document, the Structure of Policy Provisioning Information (SPPI), defines the adapted subset of SNMP's Structure of Management Information (SMI) used to write Policy Information Base (PIB) modules. [STANDARDS TRACK] </abstract>
        <draft>ietf-rap-sppi-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3160</doc-id>
        <title>The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force</title>
        <author>
            <name>S. Harris</name>
        </author>
        <date>
            <month>August</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>98411</char-count>
            <page-count>38</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Engineering</kw>
            <kw>Task</kw>
            <kw>Force</kw>
            <kw>Meeting</kw>
        </keywords>
        <abstract>This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. This memo provides information for the Internet community. </abstract>
        <draft>ietf-uswg-tao-06</draft>
        <obsoletes>
            <doc-id>RFC1718</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>FYI0017</doc-id>
        </is-also>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3161</doc-id>
        <title>Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)</title>
        <author>
            <name>C. Adams</name>
        </author>
        <author>
            <name>P. Cain</name>
        </author>
        <author>
            <name>D. Pinkas</name>
        </author>
        <author>
            <name>R. Zuccherato</name>
        </author>
        <date>
            <month>August</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54585</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>TSA</kw>
            <kw>authority</kw>
            <kw>security</kw>
            <kw>request</kw>
            <kw>response</kw>
        </keywords>
        <abstract>This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS TRACK] </abstract>
        <draft>ietf-pkix-time-stamp-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3162</doc-id>
        <title>RADIUS and IPv6</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>D. Mitton</name>
        </author>
        <date>
            <month>August</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20492</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>remote</kw>
            <kw>authentication</kw>
            <kw>dial in user</kw>
            <kw>service</kw>
            <kw>attributes</kw>
        </keywords>
        <abstract>This document specifies the operation of RADIUS (Remote Authentication Dial In User Service) when run over IPv6 as well as the RADIUS attributes used to support IPv6 network access. [STANDARDS TRACK] </abstract>
        <draft>aboba-radius-ipv6-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3163</doc-id>
        <title>ISO/IEC 9798-3 Authentication SASL Mechanism</title>
        <author>
            <name>R. Zuccherato</name>
        </author>
        <author>
            <name>M. Nystrom</name>
        </author>
        <date>
            <month>August</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32498</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>simple</kw>
            <kw>authentication</kw>
            <kw>security</kw>
            <kw>layer</kw>
        </keywords>
        <abstract>This document defines a SASL (Simple Authentication and Security Layer) authentication mechanism based on ISO/IEC 9798-3 and FIPS PUB 196 entity authentication. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>zuccherato-9798-3-sasl-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3164</doc-id>
        <title>The BSD Syslog Protocol</title>
        <author>
            <name>C. Lonvick</name>
        </author>
        <date>
            <month>August</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>72951</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>berkeley</kw>
            <kw>software</kw>
            <kw>distribution</kw>
            <kw>transmission</kw>
            <kw>messages</kw>
        </keywords>
        <abstract>This document describes the observed behavior of the syslog protocol. This memo provides information for the Internet community. </abstract>
        <draft>ietf-syslog-syslog-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3165</doc-id>
        <title>Definitions of Managed Objects for the Delegation of Management Scripts</title>
        <author>
            <name>D. Levi</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>August</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>134479</char-count>
            <page-count>64</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow the delegation of management scripts to distributed managers. [STANDARDS TRACK] </abstract>
        <draft>ietf-disman-script-mib-v2-04</draft>
        <obsoletes>
            <doc-id>RFC2592</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3166</doc-id>
        <title>Request to Move RFC 1403 to Historic Status</title>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>J. Scudder</name>
        </author>
        <date>
            <month>August</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3740</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>BGP-OSPF</kw>
            <kw>Border gateway protocol</kw>
            <kw>Open shortest path first routing</kw>
        </keywords>
        <abstract>RFC 1403, "BGP OSPF Interaction", describes technology which is no longer used. This document requests that RFC 1403 be moved to Historic status. This memo provides information for the Internet community. </abstract>
        <draft>meyer-rfc1403-historic-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3167</doc-id>
        <title>Request to Move RFC 1745 to Historic Status</title>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>J. Scudder</name>
        </author>
        <date>
            <month>August</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3825</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>BGP4/IDRP</kw>
            <kw>Internet</kw>
            <kw>Inter-Domain</kw>
            <kw>Routing</kw>
            <kw>Protocol</kw>
            <kw>Border</kw>
            <kw>Gateway</kw>
            <kw>Open</kw>
            <kw>Shortest</kw>
            <kw>Path</kw>
            <kw>First</kw>
        </keywords>
        <abstract>RFC 1745, "BGP4/IDRP for IP---OSPF Interaction", describes technology which was never deployed in the public internet. This document requests that RFC 1745 be moved to Historic status. This memo provides information for the Internet community. </abstract>
        <draft>meyer-rfc1745-historic-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3168</doc-id>
        <title>The Addition of Explicit Congestion Notification (ECN) to IP</title>
        <author>
            <name>K. Ramakrishnan</name>
        </author>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>D. Black</name>
        </author>
        <date>
            <month>September</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>170966</char-count>
            <page-count>63</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>header</kw>
        </keywords>
        <abstract>This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS TRACK] </abstract>
        <draft>ietf-tsvwg-ecn-04</draft>
        <obsoletes>
            <doc-id>RFC2481</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2474</doc-id>
            <doc-id>RFC2401</doc-id>
            <doc-id>RFC0793</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3169</doc-id>
        <title>Criteria for Evaluating Network Access Server Protocols</title>
        <author>
            <name>M. Beadles</name>
        </author>
        <author>
            <name>D. Mitton</name>
        </author>
        <date>
            <month>September</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35303</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>NAS</kw>
            <kw>network</kw>
            <kw>device</kw>
            <kw>AAA</kw>
            <kw>authentication</kw>
            <kw>authorization</kw>
            <kw>accounting</kw>
        </keywords>
        <abstract>This document defines requirements for protocols used by Network Access Servers (NAS). This memo provides information for the Internet community. </abstract>
        <draft>ietf-nasreq-criteria-06</draft>
        <notes>Network Access Server Requirements Working Group</notes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3170</doc-id>
        <title>IP Multicast Applications: Challenges and Solutions</title>
        <author>
            <name>B. Quinn</name>
        </author>
        <author>
            <name>K. Almeroth</name>
        </author>
        <date>
            <month>September</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>67207</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract>This document describes the challenges involved with designing and implementing multicast applications. It is an introductory guide for application developers that highlights the unique considerations of multicast applications as compared to unicast applications. This memo provides information for the Internet community. </abstract>
        <draft>ietf-mboned-mcast-apps-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3171</doc-id>
        <title>IANA Guidelines for IPv4 Multicast Address Assignments</title>
        <author>
            <name>Z. Albanna</name>
        </author>
        <author>
            <name>K. Almeroth</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>M. Schipper</name>
        </author>
        <date>
            <month>August</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15389</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>assigned</kw>
            <kw>numbers</kw>
            <kw>authority</kw>
            <kw>protocol</kw>
            <kw>parameters</kw>
        </keywords>
        <abstract>This memo provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-mboned-iana-ipv4-mcast-guidelines-04</draft>
        <is-also>
            <doc-id>BCP0051</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3172</doc-id>
        <title>Management Guidelines &amp; Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")</title>
        <author>
            <name>G. Huston</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18097</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>database</kw>
            <kw>DNS</kw>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
        </keywords>
        <abstract>This memo describes the management and operational requirements for the address and routing parameter area ("arpa") domain. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>iab-arpa-03</draft>
        <is-also>
            <doc-id>BCP0052</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3173</doc-id>
        <title>IP Payload Compression Protocol (IPComp)</title>
        <author>
            <name>A. Shacham</name>
        </author>
        <author>
            <name>B. Monsour</name>
        </author>
        <author>
            <name>R. Pereira</name>
        </author>
        <author>
            <name>M. Thomas</name>
        </author>
        <date>
            <month>September</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15389</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>IPCOMP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>datagram</kw>
            <kw>lossless</kw>
        </keywords>
        <abstract>This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. [STANDARDS TRACK] </abstract>
        <draft>shacham-ippcp-rfc2392bis-08</draft>
        <obsoletes>
            <doc-id>RFC2393</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3174</doc-id>
        <title>US Secure Hash Algorithm 1 (SHA1)</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>P. Jones</name>
        </author>
        <date>
            <month>September</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35525</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>FIPS</kw>
            <kw>federal</kw>
            <kw>information</kw>
            <kw>processing</kw>
            <kw>standard</kw>
        </keywords>
        <abstract>The purpose of this document is to make the SHA-1 (Secure Hash Algorithm 1) hash algorithm conveniently available to the Internet community. This memo provides information for the Internet community. </abstract>
        <draft>eastlake-sha1-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3175</doc-id>
        <title>Aggregation of RSVP for IPv4 and IPv6 Reservations</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>C. Iturralde</name>
        </author>
        <author>
            <name>F. Le Faucheur</name>
        </author>
        <author>
            <name>B. Davie</name>
        </author>
        <date>
            <month>September</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>88681</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
            <kw>internet</kw>
            <kw>ATM</kw>
            <kw>asynchronous</kw>
            <kw>transfer</kw>
            <kw>mode</kw>
        </keywords>
        <abstract>This document describes the use of a single RSVP (Resource ReSerVation Protocol) reservation to aggregate other RSVP reservations across a transit routing region, in a manner conceptually similar to the use of Virtual Paths in an ATM (Asynchronous Transfer Mode) network. It proposes a way to dynamically create the aggregate reservation, classify the traffic for which the aggregate reservation applies, determine how much bandwidth is needed to achieve the requirement, and recover the bandwidth when the sub-reservations are no longer required. It also contains recommendations concerning algorithms and policies for predictive reservations. [STANDARDS TRACK] </abstract>
        <draft>ietf-issll-rsvp-aggr-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3176</doc-id>
        <title>InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks</title>
        <author>
            <name>P. Phaal</name>
        </author>
        <author>
            <name>S. Panchen</name>
        </author>
        <author>
            <name>N. McKee</name>
        </author>
        <date>
            <month>September</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>60171</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>agent</kw>
            <kw>data</kw>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines InMon Corporation's sFlow system. sFlow is a technology for monitoring traffic in data networks containing switches and routers. In particular, it defines the sampling mechanisms implemented in an sFlow Agent for monitoring traffic, the sFlow MIB for controlling the sFlow Agent, and the format of sample data used by the sFlow Agent when forwarding data to a central data collector. This memo provides information for the Internet community. </abstract>
        <draft>phaal-sflow-montraffic-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3177</doc-id>
        <title>IAB/IESG Recommendations on IPv6 Address Allocations to Sites</title>
        <author>
            <name>IAB</name>
        </author>
        <author>
            <name>IESG</name>
        </author>
        <date>
            <month>September</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23178</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>architecture</kw>
            <kw>board</kw>
            <kw>engineering</kw>
            <kw>steering</kw>
            <kw>group</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document provides recommendations to the addressing registries (APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address blocks to end sites. In particular, it recommends the assignment of /48 in the general case, /64 when it is known that one and only one subnet is needed and /128 when it is absolutely known that one and only one device is connecting. </abstract>
        <draft>iesg-ipv6-addressing-recommendations-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3178</doc-id>
        <title>IPv6 Multihoming Support at Site Exit Routers</title>
        <author>
            <name>J. Hagino</name>
        </author>
        <author>
            <name>H. Snyder</name>
        </author>
        <date>
            <month>October</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24453</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>ISP</kw>
            <kw>Service</kw>
            <kw>Provider</kw>
            <kw>Routing</kw>
        </keywords>
        <abstract>The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ipngwg-ipv6-2260-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3179</doc-id>
        <title>Script MIB Extensibility Protocol Version 1.1</title>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <author>
            <name>J. Quittek</name>
        </author>
        <date>
            <month>October</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>56311</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>SMX</kw>
            <kw>language</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations. The IETF Script MIB defines an interface for the delegation of management functions based on the Internet management framework. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>schoenw-rfc-2593-update-04</draft>
        <obsoletes>
            <doc-id>RFC2593</doc-id>
        </obsoletes>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3180</doc-id>
        <title>GLOP Addressing in 233/8</title>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>P. Lothberg</name>
        </author>
        <date>
            <month>September</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8225</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>static</kw>
            <kw>multicast</kw>
        </keywords>
        <abstract>This document defines the policy for the use of 233/8 for statically e assigned multicast addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-mboned-glop-update-01</draft>
        <obsoletes>
            <doc-id>RFC2770</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0053</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3181</doc-id>
        <title>Signaled Preemption Priority Policy Element</title>
        <author>
            <name>S. Herzog</name>
        </author>
        <date>
            <month>October</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21990</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>rsvp</kw>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
            <kw>cops</kw>
            <kw>common</kw>
            <kw>open</kw>
            <kw>service</kw>
        </keywords>
        <abstract>This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as the Resource ReSerVation Protocol (RSVP) and Common Open Policy Service (COPS). [STANDARDS TRACK] </abstract>
        <draft>ietf-rap-signaled-priority-v2-00</draft>
        <obsoletes>
            <doc-id>RFC2751</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3182</doc-id>
        <title>Identity Representation for RSVP</title>
        <author>
            <name>S. Yadav</name>
        </author>
        <author>
            <name>R. Yavatkar</name>
        </author>
        <author>
            <name>R. Pabbati</name>
        </author>
        <author>
            <name>P. Ford</name>
        </author>
        <author>
            <name>T. Moore</name>
        </author>
        <author>
            <name>S. Herzog</name>
        </author>
        <author>
            <name>R. Hess</name>
        </author>
        <date>
            <month>October</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36544</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document describes the representation of identity information in POLICY_DATA object for supporting policy based admission control in the Resource ReSerVation Protocol (RSVP). The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g., user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner. We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. [STANDARDS TRACK] </abstract>
        <draft>ietf-rap-rsvp-newidentity-01</draft>
        <obsoletes>
            <doc-id>RFC2752</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3183</doc-id>
        <title>Domain Security Services using S/MIME</title>
        <author>
            <name>T. Dean</name>
        </author>
        <author>
            <name>W. Ottaway</name>
        </author>
        <date>
            <month>October</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>57129</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>secure/multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document describes how the S/MIME (Secure/Multipurpose Internet Mail Extensions) protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-smime-domsec-09</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3184</doc-id>
        <title>IETF Guidelines for Conduct</title>
        <author>
            <name>S. Harris</name>
        </author>
        <date>
            <month>October</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7413</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>interent</kw>
            <kw>engineering</kw>
            <kw>task</kw>
            <kw>force</kw>
        </keywords>
        <abstract>This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-poisson-code-04</draft>
        <is-also>
            <doc-id>BCP0054</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3185</doc-id>
        <title>Reuse of CMS Content Encryption Keys</title>
        <author>
            <name>S. Farrell</name>
        </author>
        <author>
            <name>S. Turner</name>
        </author>
        <date>
            <month>October</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20404</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>cryptographic</kw>
            <kw>message</kw>
            <kw>syntax</kw>
            <kw>data</kw>
            <kw>packets</kw>
        </keywords>
        <abstract>This document describes a way to include a key identifier in a CMS (Cryptographic Message Syntax) enveloped data structure, so that the content encryption key can be re-used for further enveloped data packets. [STANDARDS TRACK] </abstract>
        <draft>ietf-smime-rcek-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3186</doc-id>
        <title>MAPOS/PPP Tunneling mode</title>
        <author>
            <name>S. Shimizu</name>
        </author>
        <author>
            <name>T. Kawano</name>
        </author>
        <author>
            <name>K. Murakami</name>
        </author>
        <author>
            <name>E. Beier</name>
        </author>
        <date>
            <month>December</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27109</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>multiple</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>over</kw>
            <kw>SONET/SDH</kw>
            <kw>point-to-point</kw>
        </keywords>
        <abstract>This document specifies tunneling configuration over MAPOS (Multiple Access Protocol over SONET/SDH) networks. Using this mode, a MAPOS network can provide transparent point-to-point link for PPP over SONET/SDH (Packet over SONET/SDH, POS) without any additional overhead. This memo provides information for the Internet community. </abstract>
        <draft>shimizu-ppp-mapos-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3187</doc-id>
        <title>Using International Standard Book Numbers as Uniform Resource Names</title>
        <author>
            <name>J. Hakala</name>
        </author>
        <author>
            <name>H. Walravens</name>
        </author>
        <date>
            <month>October</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22620</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>isbn</kw>
            <kw>urn</kw>
            <kw>bibliographic</kw>
            <kw>identifiers</kw>
        </keywords>
        <abstract>This document discusses how International Standard Book Numbers (ISBN) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion below is based on the ideas expressed in RFC 2288. This memo provides information for the Internet community. </abstract>
        <draft>hakala-isbn-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3188</doc-id>
        <title>Using National Bibliography Numbers as Uniform Resource Names</title>
        <author>
            <name>J. Hakala</name>
        </author>
        <date>
            <month>October</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27923</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>urn</kw>
            <kw>nbn</kw>
            <kw>national</kw>
            <kw>libraries</kw>
        </keywords>
        <abstract>This document discusses how national bibliography numbers (persistent and unique identifiers assigned by the national libraries) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion is based on the ideas expressed in RFC 2288. This memo provides information for the Internet community. </abstract>
        <draft>hakala-nbn-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3189</doc-id>
        <title>RTP Payload Format for DV (IEC 61834) Video</title>
        <author>
            <name>K. Kobayashi</name>
        </author>
        <author>
            <name>A. Ogawa</name>
        </author>
        <author>
            <name>S. Casner</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>January</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25991</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>real-time</kw>
            <kw>transport</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). [STANDARDS TRACK] </abstract>
        <draft>ietf-avt-dv-video-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3190</doc-id>
        <title>RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio</title>
        <author>
            <name>K. Kobayashi</name>
        </author>
        <author>
            <name>A. Ogawa</name>
        </author>
        <author>
            <name>S. Casner</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>January</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34977</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>real-time</kw>
            <kw>transport</kw>
            <kw>protocol</kw>
            <kw>digital</kw>
            <kw>audio</kw>
            <kw>tape</kw>
        </keywords>
        <abstract>This document specifies a packetization scheme for encapsulating 12-bit nonlinear, 20-bit linear, and 24-bit linear audio data streams using the Real-time Transport Protocol (RTP). This document also specifies the format of a Session Description Protocol (SDP) parameter to indicate when audio data is preemphasized before sampling. The parameter may be used with other audio payload formats, in particular L16 (16-bit linear). [STANDARDS TRACK] </abstract>
        <draft>ietf-avt-dv-audio-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3191</doc-id>
        <title>Minimal GSTN address format in Internet Mail</title>
        <author>
            <name>C. Allocchio</name>
        </author>
        <date>
            <month>October</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24235</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>MIN-PSTN</kw>
            <kw>global</kw>
            <kw>switched</kw>
            <kw>telephone</kw>
            <kw>network</kw>
            <kw>email</kw>
        </keywords>
        <abstract>This memo describes a simple method of encoding Global Switched Telephone Network (GSTN) addresses (commonly called "telephone numbers") in the local-part of Internet email addresses, along with an extension mechanism to allow encoding of additional standard attributes needed for email gateways to GSTN-based services. [STANDARDS TRACK] </abstract>
        <draft>ietf-fax-minaddr-v2-04</draft>
        <obsoletes>
            <doc-id>RFC2303</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2846</doc-id>
        </updates>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3192</doc-id>
        <title>Minimal FAX address format in Internet Mail</title>
        <author>
            <name>C. Allocchio</name>
        </author>
        <date>
            <month>October</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18813</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>MINFAX-IM</kw>
            <kw>facsimile</kw>
            <kw>GSTN</kw>
            <kw>global</kw>
            <kw>switched</kw>
            <kw>telephone</kw>
            <kw>network</kw>
        </keywords>
        <abstract>This memo describes a simple method of encoding Global Switched Telephone Network (GSTN) addresses of facsimile devices in the local- part of Internet email addresses. [STANDARDS TRACK] </abstract>
        <draft>ietf-fax-faxaddr-v2-04</draft>
        <obsoletes>
            <doc-id>RFC2304</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2846</doc-id>
        </updates>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3193</doc-id>
        <title>Securing L2TP using IPsec</title>
        <author>
            <name>B. Patel</name>
        </author>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>W. Dixon</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>S. Booth</name>
        </author>
        <date>
            <month>November</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63804</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>layer</kw>
            <kw>two</kw>
            <kw>tunneling</kw>
            <kw>protocol</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This document discusses how L2TP (Layer Two Tunneling Protocol) may utilize IPsec to provide for tunnel authentication, privacy protection, integrity checking and replay protection. Both the voluntary and compulsory tunneling cases are discussed. [STANDARDS TRACK] </abstract>
        <draft>ietf-l2tpext-security-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3194</doc-id>
        <title>The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio</title>
        <author>
            <name>A. Durand</name>
        </author>
        <author>
            <name>C. Huitema</name>
        </author>
        <date>
            <month>November</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14539</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>IPng</kw>
            <kw>White</kw>
            <kw>Paper</kw>
        </keywords>
        <abstract>This document provides an update on the "H ratio" defined in RFC 1715. It defines a new ratio which the authors claim is easier to understand. This memo provides information for the Internet community. </abstract>
        <draft>durand-huitema-h-density-ratio-01</draft>
        <updates>
            <doc-id>RFC1715</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3195</doc-id>
        <title>Reliable Delivery for syslog</title>
        <author>
            <name>D. New</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>November</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>60960</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>mappings</kw>
            <kw>encryption</kw>
            <kw>authentication</kw>
            <kw>beep</kw>
            <kw>blocks</kw>
            <kw>extensible</kw>
            <kw>exchange</kw>
        </keywords>
        <abstract>The BSD Syslog Protocol describes a number of service options related to propagating event messages. This memo describes two mappings of the syslog protocol to TCP connections, both useful for reliable delivery of event messages. [STANDARDS TRACK] </abstract>
        <draft>ietf-syslog-reliable-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3196</doc-id>
        <title>Internet Printing Protocol/1.1: Implementor's Guide</title>
        <author>
            <name>T. Hastings</name>
        </author>
        <author>
            <name>C. Manros</name>
        </author>
        <author>
            <name>P. Zehler</name>
        </author>
        <author>
            <name>C. Kugler</name>
        </author>
        <author>
            <name>H. Holst</name>
        </author>
        <date>
            <month>November</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>200720</char-count>
            <page-count>96</page-count>
        </format>
        <keywords>
            <kw>IPP</kw>
            <kw>client</kw>
            <kw>object</kw>
        </keywords>
        <abstract>This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). This memo provides information for the Internet community. </abstract>
        <draft>ietf-ipp-implementers-guide-v11-03</draft>
        <obsoletes>
            <doc-id>RFC2639</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3197</doc-id>
        <title>Applicability Statement for DNS MIB Extensions</title>
        <author>
            <name>R. Austein</name>
        </author>
        <date>
            <month>November</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8610</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>DNS-R-MIB</kw>
            <kw>Domain</kw>
            <kw>Name</kw>
            <kw>System</kw>
            <kw>Management</kw>
            <kw>Information</kw>
            <kw>Base</kw>
        </keywords>
        <abstract>This document explains why, after more than six years as proposed standards, the DNS Server and Resolver MIB extensions were never deployed, and recommends retiring these MIB extensions by moving them to Historical status. This memo provides information for the Internet community. </abstract>
        <draft>ietf-dnsext-dnsmib-historical-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3198</doc-id>
        <title>Terminology for Policy-Based Management</title>
        <author>
            <name>A. Westerinen</name>
        </author>
        <author>
            <name>J. Schnizlein</name>
        </author>
        <author>
            <name>J. Strassner</name>
        </author>
        <author>
            <name>M. Scherling</name>
        </author>
        <author>
            <name>B. Quinn</name>
        </author>
        <author>
            <name>S. Herzog</name>
        </author>
        <author>
            <name>A. Huynh</name>
        </author>
        <author>
            <name>M. Carlson</name>
        </author>
        <author>
            <name>J. Perry</name>
        </author>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>November</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47806</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>glossary</kw>
            <kw>netowrk</kw>
            <kw>ISDs</kw>
            <kw>internet</kw>
            <kw>standard</kw>
            <kw>documents </kw>
        </keywords>
        <abstract>This document is a glossary of policy-related terms. It provides abbreviations, explanations, and recommendations for use of these terms. The intent is to improve the comprehensibility and consistency of writing that deals with network policy, particularly Internet Standards documents (ISDs). This memo provides information for the Internet community. </abstract>
        <draft>ietf-policy-terminology-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3199</doc-id>
        <title>Request for Comments Summary RFC Numbers 3100-3199</title>
        <author>
            <name>S. Ginoza</name>
        </author>
        <date>
            <month>February</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47287</char-count>
            <page-count>24</page-count>
        </format>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC3200</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC3201</doc-id>
        <title>Definitions of Managed Objects for Circuit to Interface Translation</title>
        <author>
            <name>R. Steinberger</name>
        </author>
        <author>
            <name>O. Nicklass</name>
        </author>
        <date>
            <month>January</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45583</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
        </keywords>
        <abstract>This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the insertion of interesting Circuit Interfaces into the ifTable. This is important for circuits that must be used within other MIB modules which require an ifEntry. It allows for integrated monitoring of circuits as well as routing to circuits using unaltered, pre-existing MIB modules. [STANDARDS TRACK] </abstract>
        <draft>ietf-frnetmib-frsi-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3202</doc-id>
        <title>Definitions of Managed Objects for Frame Relay Service Level Definitions</title>
        <author>
            <name>R. Steinberger</name>
        </author>
        <author>
            <name>O. Nicklass</name>
        </author>
        <date>
            <month>January</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>130816</char-count>
            <page-count>64</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
        </keywords>
        <abstract>This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service Level Definitions. [STANDARDS TRACK] </abstract>
        <draft>ietf-frnetmib-frmrelay-service-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3203</doc-id>
        <title>DHCP reconfigure extension</title>
        <author>
            <name>Y. T'Joens</name>
        </author>
        <author>
            <name>C. Hublet</name>
        </author>
        <author>
            <name>P. De Schrijver</name>
        </author>
        <date>
            <month>December</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11857</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>dynamic</kw>
            <kw>host</kw>
            <kw>configuration</kw>
            <kw>protocol</kw>
            <kw>forcerenew</kw>
        </keywords>
        <abstract>This document defines extensions to DHCP (Dynamic Host Configuration Protocol) to allow dynamic reconfiguration of a single host triggered by the DHCP server (e.g., a new IP address and/or local configuration parameters). [STANDARDS TRACK] </abstract>
        <draft>ietf-dhc-pv4-reconfigure-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3204</doc-id>
        <title>MIME media types for ISUP and QSIG Objects</title>
        <author>
            <name>E. Zimmerer</name>
        </author>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>A. Vemuri</name>
        </author>
        <author>
            <name>L. Ong</name>
        </author>
        <author>
            <name>F. Audet</name>
        </author>
        <author>
            <name>M. Watson</name>
        </author>
        <author>
            <name>M. Zonoun</name>
        </author>
        <date>
            <month>December</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19712</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>multipart</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document describes MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC 2048. These types can be used to identify ISUP and QSIG objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the call involves interworking to the PSTN. [STANDARDS TRACK] </abstract>
        <draft>ietf-sip-isup-mime-10</draft>
        <updated-by>
            <doc-id>RFC3459</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3205</doc-id>
        <title>On the use of HTTP as a Substrate</title>
        <author>
            <name>K. Moore</name>
        </author>
        <date>
            <month>February</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34785</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>hypertext</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>layering</kw>
        </keywords>
        <abstract>Recently there has been widespread interest in using Hypertext Transfer Protocol (HTTP) as a substrate for other applications-level protocols. This document recommends technical particulars of such use, including use of default ports, URL schemes, and HTTP security mechanisms. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>moore-using-http-01</draft>
        <is-also>
            <doc-id>BCP0056</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3206</doc-id>
        <title>The SYS and AUTH POP Response Codes</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <date>
            <month>February</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9917</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This memo proposes two response codes: SYS and AUTH, which enable clients to unambiguously determine an optimal response to an authentication failure. In addition, a new capability (AUTH-RESP-CODE) is defined. [STANDARDS TRACK] </abstract>
        <draft>gellens-pop-err-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3207</doc-id>
        <title>SMTP Service Extension for Secure SMTP over Transport Layer Security</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>February</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18679</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>simple</kw>
            <kw>mail</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>ssl</kw>
            <kw>tls</kw>
        </keywords>
        <abstract>This document describes an extension to the SMTP (Simple Mail Transfer Protocol) service that allows an SMTP server and client to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS TRACK] </abstract>
        <draft>hoffman-rfc2487bis-06</draft>
        <obsoletes>
            <doc-id>RFC2487</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3208</doc-id>
        <title>PGM Reliable Transport Protocol Specification</title>
        <author>
            <name>T. Speakman</name>
        </author>
        <author>
            <name>J. Crowcroft</name>
        </author>
        <author>
            <name>J. Gemmell</name>
        </author>
        <author>
            <name>D. Farinacci</name>
        </author>
        <author>
            <name>S. Lin</name>
        </author>
        <author>
            <name>D. Leshchiner</name>
        </author>
        <author>
            <name>M. Luby</name>
        </author>
        <author>
            <name>T. Montgomery</name>
        </author>
        <author>
            <name>L. Rizzo</name>
        </author>
        <author>
            <name>A. Tweedly</name>
        </author>
        <author>
            <name>N. Bhaskar</name>
        </author>
        <author>
            <name>R. Edmonstone</name>
        </author>
        <author>
            <name>R. Sumanasekera</name>
        </author>
        <author>
            <name>L. Vicisano</name>
        </author>
        <date>
            <month>December</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>244637</char-count>
            <page-count>111</page-count>
        </format>
        <keywords>
            <kw>pragmatic</kw>
            <kw>general</kw>
            <kw>multicast</kw>
        </keywords>
        <abstract>Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered or unordered, duplicate- free, multicast data delivery from multiple sources to multiple receivers. PGM guarantees that a receiver in the group either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss. PGM is specifically intended as a workable solution for multicast applications with basic reliability requirements. Its central design goal is simplicity of operation with due regard for scalability and network efficiency. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>speakman-pgm-spec-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3209</doc-id>
        <title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
        <author>
            <name>D. Awduche</name>
        </author>
        <author>
            <name>L. Berger</name>
        </author>
        <author>
            <name>D. Gan</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>V. Srinivasan</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <date>
            <month>December</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>132264</char-count>
            <page-count>61</page-count>
        </format>
        <keywords>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
            <kw>label</kw>
            <kw>switched</kw>
            <kw>paths</kw>
        </keywords>
        <abstract>This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS TRACK] </abstract>
        <draft>ietf-mpls-rsvp-lsp-tunnel-09</draft>
        <updated-by>
            <doc-id>RFC3936</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3210</doc-id>
        <title>Applicability Statement for Extensions to RSVP for LSP-Tunnels</title>
        <author>
            <name>D. Awduche</name>
        </author>
        <author>
            <name>A.  Hannan</name>
        </author>
        <author>
            <name>X. Xiao</name>
        </author>
        <date>
            <month>December</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17691</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
            <kw>label</kw>
            <kw>switched</kw>
            <kw>paths</kw>
        </keywords>
        <abstract>This memo discusses the applicability of "Extensions to RSVP (Resource ReSerVation Protocol) for LSP Tunnels". It highlights the protocol's principles of operation and describes the network context for which it was designed. Guidelines for deployment are offered and known protocol limitations are indicated. This document is intended to accompany the submission of "Extensions to RSVP for LSP Tunnels" onto the Internet standards track. This memo provides information for the Internet community. </abstract>
        <draft>ietf-mpls-rsvp-tunnel-applicability-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3211</doc-id>
        <title>Password-based Encryption for CMS</title>
        <author>
            <name>P. Gutmann</name>
        </author>
        <date>
            <month>December</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30527</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>cryptographic</kw>
            <kw>message</kw>
            <kw>syntax</kw>
            <kw>S/MIME</kw>
            <kw>key wrap</kw>
            <kw>derivation</kw>
            <kw>passwordrecipientinfo</kw>
            <kw>PWRI</kw>
        </keywords>
        <abstract>This document provides a method of encrypting data using user-supplied passwords and, by extension, any form of variable-length keying material which is not necessarily an algorithm-specific fixed-format key. The Cryptographic Message Syntax data format does not currently contain any provisions for password-based data encryption. [STANDARDS TRACK] </abstract>
        <draft>ietf-smime-password-06</draft>
        <obsoleted-by>
            <doc-id>RFC3369</doc-id>
            <doc-id>RFC3370</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3212</doc-id>
        <title>Constraint-Based LSP Setup using LDP</title>
        <author>
            <name>B. Jamoussi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>R. Callon</name>
        </author>
        <author>
            <name>R. Dantu</name>
        </author>
        <author>
            <name>L. Wu</name>
        </author>
        <author>
            <name>P. Doolan</name>
        </author>
        <author>
            <name>T. Worster</name>
        </author>
        <author>
            <name>N. Feldman</name>
        </author>
        <author>
            <name>A. Fredette</name>
        </author>
        <author>
            <name>M. Girish</name>
        </author>
        <author>
            <name>E. Gray</name>
        </author>
        <author>
            <name>J. Heinanen</name>
        </author>
        <author>
            <name>T. Kilty</name>
        </author>
        <author>
            <name>A. Malis</name>
        </author>
        <date>
            <month>January</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>87591</char-count>
            <page-count>42</page-count>
        </format>
        <keywords>
            <kw>label</kw>
            <kw>switching</kw>
            <kw>protocol</kw>
            <kw>distribution</kw>
            <kw>CR ORGANIZATION: Nortel Networks</kw>
            <kw>Utfors AB</kw>
            <kw>Juniper Networks</kw>
            <kw>Netrake Corporation</kw>
            <kw>Cisco Systems</kw>
            <kw>OTB Consulting Corp.</kw>
            <kw>Unspec.</kw>
            <kw>IBM Corp.</kw>
            <kw>ANF Consulting</kw>
            <kw>Atoga Systems</kw>
            <kw>Sandburst</kw>
            <kw>Song Networks</kw>
            <kw>Inc.</kw>
            <kw>Newbridge Networks</kw>
            <kw>Inc.</kw>
            <kw>Vivace Networks</kw>
        </keywords>
        <abstract>This document specifies mechanisms and TLVs (Type/Length/Value) for support of CR-LSPs (constraint-based routed Label Switched Path) using LDP (Label Distribution Protocol). [STANDARDS TRACK] </abstract>
        <draft>ietf-mpls-cr-ldp-06</draft>
        <updated-by>
            <doc-id>RFC3468</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3213</doc-id>
        <title>Applicability Statement for CR-LDP</title>
        <author>
            <name>J. Ash</name>
        </author>
        <author>
            <name>M. Girish</name>
        </author>
        <author>
            <name>E. Gray</name>
        </author>
        <author>
            <name>B. Jamoussi</name>
        </author>
        <author>
            <name>G. Wright</name>
        </author>
        <date>
            <month>January</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14489</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>constraint-based</kw>
            <kw>label</kw>
            <kw>distribution</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document discusses the applicability of Constraint-Based LSP Setup using LDP. It discusses possible network applications, extensions to Label Distribution Protocol (LDP) required to implement constraint-based routing, guidelines for deployment and known limitations of the protocol. This document is a prerequisite to advancing CR-LDP on the standards track. This memo provides information for the Internet community. </abstract>
        <draft>ietf-mpls-crldp-applic-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3214</doc-id>
        <title>LSP Modification Using CR-LDP</title>
        <author>
            <name>J. Ash</name>
        </author>
        <author>
            <name>Y. Lee</name>
        </author>
        <author>
            <name>P. Ashwood-Smith</name>
        </author>
        <author>
            <name>B. Jamoussi</name>
        </author>
        <author>
            <name>D. Fedyk</name>
        </author>
        <author>
            <name>D. Skalecki</name>
        </author>
        <author>
            <name>L. Li</name>
        </author>
        <date>
            <month>January</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25453</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>label</kw>
            <kw>switching</kw>
            <kw>protocol</kw>
            <kw>constraint-based</kw>
            <kw>distribution</kw>
        </keywords>
        <abstract>This document presents an approach to modify the bandwidth and possibly other parameters of an established CR-LSP (Constraint-based Routed Label Switched Paths) using CR-LDP (Constraint-based Routed Label Distribution Protocol) without service interruption. [STANDARDS TRACK] </abstract>
        <draft>ietf-mpls-crlsp-modify-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3215</doc-id>
        <title>LDP State Machine</title>
        <author>
            <name>C. Boscher</name>
        </author>
        <author>
            <name>P. Cheval</name>
        </author>
        <author>
            <name>L. Wu</name>
        </author>
        <author>
            <name>E. Gray</name>
        </author>
        <date>
            <month>January</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>117278</char-count>
            <page-count>78</page-count>
        </format>
        <keywords>
            <kw>label</kw>
            <kw>distribution</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document provides state machine tables for ATM (Asynchronous Transfer Mode) switch LSRs. In the current LDP specification, there is no state machine specified for processing LDP messages. We think that defining a common state machine is very important for interoperability between different LDP and CR-LDP implementations. This memo provides information for the Internet community. </abstract>
        <draft>ietf-mpls-ldp-state-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3216</doc-id>
        <title>SMIng Objectives</title>
        <author>
            <name>C. Elliott</name>
        </author>
        <author>
            <name>D. Harrington</name>
        </author>
        <author>
            <name>J. Jason</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <author>
            <name>F. Strauss</name>
        </author>
        <author>
            <name>W. Weiss</name>
        </author>
        <date>
            <month>December</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>58551</char-count>
            <page-count>33</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
            <kw>simple</kw>
            <kw>network</kw>
            <kw>management</kw>
            <kw>protocol</kw>
            <kw>COPS-PR</kw>
            <kw>common</kw>
            <kw>open</kw>
            <kw>policy</kw>
            <kw>service</kw>
            <kw>provisioning</kw>
        </keywords>
        <abstract>This document describes the objectives for a new data definition language, suitable for the modeling of network management constructs, that can be directly mapped into SNMP and COPS-PR protocol operations. This memo provides information for the Internet community. </abstract>
        <draft>ietf-sming-reqs-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3217</doc-id>
        <title>Triple-DES and RC2 Key Wrapping</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>December</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19855</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>algorithm</kw>
            <kw>data encryption standard</kw>
        </keywords>
        <abstract>This document specifies the algorithm for wrapping one Triple-DES key with another Triple-DES key and the algorithm for wrapping one RC2 key with another RC2 key. This memo provides information for the Internet community. </abstract>
        <draft>ietf-smime-key-wrap-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3218</doc-id>
        <title>Preventing the Million Message Attack on Cryptographic Message Syntax</title>
        <author>
            <name>E. Rescorla</name>
        </author>
        <date>
            <month>January</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16047</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>cryptographic</kw>
            <kw>syntax</kw>
        </keywords>
        <abstract>This memo describes a strategy for resisting the Million Message Attack. This memo provides information for the Internet community. </abstract>
        <draft>ietf-smime-pkcs1-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3219</doc-id>
        <title>Telephony Routing over IP (TRIP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>H. Salama</name>
        </author>
        <author>
            <name>M. Squire</name>
        </author>
        <date>
            <month>January</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>184618</char-count>
            <page-count>79</page-count>
        </format>
        <keywords>
            <kw>inter-administrative</kw>
            <kw>BGP</kw>
            <kw>border</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. [STANDARDS TRACK] </abstract>
        <draft>ietf-iptel-trip-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3220</doc-id>
        <title>IP Mobility Support for IPv4</title>
        <author>
            <name>C. Perkins</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>238343</char-count>
            <page-count>98</page-count>
        </format>
        <keywords>
            <kw>MOBILEIPSUPIP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. [STANDARDS TRACK] </abstract>
        <draft>ietf-mobileip-rfc2002-bis-08</draft>
        <obsoletes>
            <doc-id>RFC2002</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3344</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3221</doc-id>
        <title>Commentary on Inter-Domain Routing in the Internet</title>
        <author>
            <name>G. Huston</name>
        </author>
        <date>
            <month>December</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>66580</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>BGP</kw>
            <kw>border</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document examines the various longer term trends visible within the characteristics of the Internet's BGP table and identifies a number of operational practices and protocol factors that contribute to these trends. The potential impacts of these practices and protocol properties on the scaling properties of the inter-domain routing space are examined. This memo provides information for the Internet community. </abstract>
        <draft>iab-bgparch-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3222</doc-id>
        <title>Terminology for Forwarding Information Base (FIB) based Router Performance</title>
        <author>
            <name>G. Trotter</name>
        </author>
        <date>
            <month>December</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25483</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>routing table</kw>
            <kw>benchmark</kw>
        </keywords>
        <abstract>This document describes the terms to be used in a methodology that determines the IP packet forwarding performance of IP routers as a function of the forwarding information base installed within a router. The forwarding performance of an IP router may be dependent upon or may be linked to the composition and size of the forwarding information base installed within a router. This memo provides information for the Internet community. </abstract>
        <draft>ietf-bmwg-fib-term-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC3223</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC3224</doc-id>
        <title>Vendor Extensions for Service Location Protocol, Version 2</title>
        <author>
            <name>E. Guttman</name>
        </author>
        <date>
            <month>January</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19618</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>SLP</kw>
            <kw>SVRLOC</kw>
            <kw>opaque</kw>
        </keywords>
        <abstract>This document specifies how the features of the Service Location Protocol, Version 2 allow for vendor extensibility safely, with no possibility of collisions. The specification introduces a new SLPv2 extension: The Vendor Opaque Extension. While proprietary protocol extensions are not encouraged by IETF standards, it is important that they not hinder interoperability of compliant implementations when they are undertaken. This document udpates RFC 2608, "The Service Location Protocol." [STANDARDS TRACK] </abstract>
        <updates>
            <doc-id>RFC2608</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3225</doc-id>
        <title>Indicating Resolver Support of DNSSEC</title>
        <author>
            <name>D. Conrad</name>
        </author>
        <date>
            <month>December</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11548</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>security</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification. [STANDARDS TRACK] </abstract>
        <draft>ietf-dnsext-dnssec-okbit-02</draft>
        <updated-by>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4035</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3226</doc-id>
        <title>DNSSEC and IPv6 A6 aware server/resolver message size requirements</title>
        <author>
            <name>O. Gudmundsson</name>
        </author>
        <date>
            <month>December</month>
            <year>2001</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12078</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>space</kw>
            <kw>security</kw>
            <kw>extensions</kw>
            <kw>dns</kw>
            <kw>endso</kw>
        </keywords>
        <abstract>This document mandates support for EDNS0 (Extension Mechanisms for DNS) in DNS entities claiming to support either DNS Security Extensions or A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load. This document updates RFC 2535 and RFC 2874, by adding new requirements. [STANDARDS TRACK] </abstract>
        <draft>ietf-dnsext-message-size-04</draft>
        <updates>
            <doc-id>RFC2535</doc-id>
            <doc-id>RFC2874</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4035</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3227</doc-id>
        <title>Guidelines for Evidence Collection and Archiving</title>
        <author>
            <name>D. Brezinski</name>
        </author>
        <author>
            <name>T. Killalea</name>
        </author>
        <date>
            <month>February</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18468</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>incident</kw>
        </keywords>
        <abstract>A "security incident" as defined in the "Internet Security Glossary", RFC 2828, is a security-relevant system event in which the system's security policy is disobeyed or otherwise breached. The purpose of this document is to provide System Administrators with guidelines on the collection and archiving of evidence relevant to such a security incident. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <is-also>
            <doc-id>BCP0055</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3228</doc-id>
        <title>IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)</title>
        <author>
            <name>B. Fenner</name>
        </author>
        <date>
            <month>February</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6473</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>assigned</kw>
            <kw>numbers</kw>
            <kw>authority</kw>
        </keywords>
        <abstract>This memo requests that the IANA create a registry for fields in the IGMP (Internet Group Management Protocol) protocol header, and provides guidance for the IANA to use in assigning parameters for those fields. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-magma-igmp-iana-01</draft>
        <is-also>
            <doc-id>BCP0057</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3229</doc-id>
        <title>Delta encoding in HTTP</title>
        <author>
            <name>J. Mogul</name>
        </author>
        <author>
            <name>B. Krishnamurthy</name>
        </author>
        <author>
            <name>F. Douglis</name>
        </author>
        <author>
            <name>A. Feldmann</name>
        </author>
        <author>
            <name>Y. Goland</name>
        </author>
        <author>
            <name>A. van Hoff</name>
        </author>
        <author>
            <name>D. Hellerstein</name>
        </author>
        <date>
            <month>January</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>111953</char-count>
            <page-count>49</page-count>
        </format>
        <keywords>
            <kw>hyper</kw>
            <kw>text</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. [STANDARDS TRACK] </abstract>
        <draft>mogul-http-delta-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3230</doc-id>
        <title>Instance Digests in HTTP</title>
        <author>
            <name>J. Mogul</name>
        </author>
        <author>
            <name>A. Van Hoff</name>
        </author>
        <date>
            <month>January</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26846</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>hyper</kw>
            <kw>text</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1 (Secure Hash Standard), may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems. [STANDARDS TRACK] </abstract>
        <draft>mogul-http-digest-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3231</doc-id>
        <title>Definitions of Managed Objects for Scheduling Management Operations</title>
        <author>
            <name>D. Levi</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>January</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>61308</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to schedule management operations periodically or at specified dates and times. [STANDARDS TRACK] </abstract>
        <draft>ietf-disman-schedule-mib-v2-04</draft>
        <obsoletes>
            <doc-id>RFC2591</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3232</doc-id>
        <title>Assigned Numbers: RFC 1700 is Replaced by an On-line Database</title>
        <author>
            <name>J. Reynolds</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>3849</char-count>
            <page-count>3</page-count>
        </format>
        <keywords>
            <kw>IANA</kw>
            <kw>internet</kw>
            <kw>assigned</kw>
            <kw>numbers</kw>
            <kw>authority</kw>
            <kw>parameters</kw>
        </keywords>
        <abstract>This memo obsoletes RFC 1700 (STD 2) "Assigned Numbers", which contained an October 1994 snapshot of assigned Internet protocol parameters. This memo provides information for the Internet community. </abstract>
        <obsoletes>
            <doc-id>RFC1700</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3233</doc-id>
        <title>Defining the IETF</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>S. Bradner</name>
        </author>
        <date>
            <month>February</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6401</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>engineering</kw>
            <kw>task</kw>
            <kw>force</kw>
        </keywords>
        <abstract>This document gives a more concrete definition of "the IETF" as it understood today. Many RFCs refer to "the IETF". Many important IETF documents speak of the IETF as if it were an already-defined entity. However, no IETF document correctly defines what the IETF is. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>hoffman-what-is-ietf-05</draft>
        <is-also>
            <doc-id>BCP0058</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3234</doc-id>
        <title>Middleboxes: Taxonomy and Issues</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>S. Brim</name>
        </author>
        <date>
            <month>February</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>62329</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>router</kw>
            <kw>data</kw>
            <kw>path</kw>
            <kw>host</kw>
        </keywords>
        <abstract>This document is intended as part of an IETF discussion about "middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive. This memo provides information for the Internet community. </abstract>
        <draft>carpenter-midtax-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3235</doc-id>
        <title>Network Address Translator (NAT)-Friendly Application Design Guidelines</title>
        <author>
            <name>D. Senie</name>
        </author>
        <date>
            <month>January</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29588</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>NAPT</kw>
            <kw>ALG</kw>
            <kw>firewall</kw>
        </keywords>
        <abstract>This document discusses those things that application designers might wish to consider when designing new protocols. While many common Internet applications will operate cleanly in the presence of Network Address Translators, others suffer from a variety of problems when crossing these devices. Guidelines are presented herein to help ensure new protocols and applications will, to the extent possible, be compatible with NAT (Network Address Translation). This memo provides information for the Internet community. </abstract>
        <draft>ietf-nat-app-guide-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3236</doc-id>
        <title>The 'application/xhtml+xml' Media Type</title>
        <author>
            <name>M. Baker</name>
        </author>
        <author>
            <name>P. Stark</name>
        </author>
        <date>
            <month>January</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16750</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>mime</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document defines the 'application/xhtml+xml' MIME media type for XHTML based markup languages; it is not intended to obsolete any previous IETF documents, in particular RFC 2854 which registers 'text/html'. This memo provides information for the Internet community. </abstract>
        <draft>baker-xhtml-media-reg-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3237</doc-id>
        <title>Requirements for Reliable Server Pooling</title>
        <author>
            <name>M. Tuexen</name>
        </author>
        <author>
            <name>Q. Xie</name>
        </author>
        <author>
            <name>R. Stewart</name>
        </author>
        <author>
            <name>M. Shore</name>
        </author>
        <author>
            <name>L. Ong</name>
        </author>
        <author>
            <name>J. Loughney</name>
        </author>
        <author>
            <name>M. Stillman</name>
        </author>
        <date>
            <month>January</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16986</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>rserpool</kw>
            <kw>application</kw>
        </keywords>
        <abstract>This document defines a basic set of requirements for reliable server pooling. This memo provides information for the Internet community. </abstract>
        <draft>ietf-rserpool-reqts-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3238</doc-id>
        <title>IAB Architectural and Policy Considerations for Open Pluggable Edge Services</title>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>L. Daigle</name>
        </author>
        <date>
            <month>January</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42336</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>OPES</kw>
            <kw>internet</kw>
            <kw>architecture</kw>
            <kw>board</kw>
        </keywords>
        <abstract>This document includes comments and recommendations by the IAB on some architectural and policy issues related to the chartering of Open Pluggable Edge Services (OPES) in the IETF. OPES are services that would be deployed at application-level intermediaries in the network, for example, at a web proxy cache between the origin server and the client. These intermediaries would transform or filter content, with the explicit consent of either the content provider or the end user. This memo provides information for the Internet community. </abstract>
        <draft>iab-opes-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3239</doc-id>
        <title>Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations</title>
        <author>
            <name>C. Kugler</name>
        </author>
        <author>
            <name>H. Lewis</name>
        </author>
        <author>
            <name>T. Hastings</name>
        </author>
        <date>
            <month>February</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29532</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>object</kw>
            <kw>device</kw>
        </keywords>
        <abstract>This document specifies the requirements and uses cases for some optional administrative operations for use with the Internet Printing Protocol (IPP) version 1.0 and version 1.1. Some of these administrative operations operate on the IPP Job and Printer objects. The remaining operations operate on a new Device object that more closely models a single output device. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ipp-ops-admin-req-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3240</doc-id>
        <title>Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration</title>
        <author>
            <name>D. Clunie</name>
        </author>
        <author>
            <name>E. Cordonnier</name>
        </author>
        <date>
            <month>February</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9102</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document describes the registration of the MIME sub-type application/dicom (Digital Imaging and Communications in Medicine). The baseline encoding is defined by the DICOM Standards Committee in "Digital Imaging and Communications in Medicine". This memo provides information for the Internet community. </abstract>
        <draft>dicom-media-type-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3241</doc-id>
        <title>Robust Header Compression (ROHC) over PPP</title>
        <author>
            <name>C. Bormann</name>
        </author>
        <date>
            <month>April</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24424</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>point-to-point protocol</kw>
            <kw>datagram</kw>
            <kw>packets</kw>
        </keywords>
        <abstract>This document describes an option for negotiating the use of robust header compression (ROHC) on IP datagrams transmitted over the Point- to-Point Protocol (PPP). It defines extensions to the PPP Control Protocols for IPv4 and IPv6. [STANDARDS TRACK] </abstract>
        <draft>ietf-rohc-over-ppp-04</draft>
        <updates>
            <doc-id>RFC1332</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3242</doc-id>
        <title>RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP</title>
        <author>
            <name>L-E. Jonsson</name>
        </author>
        <author>
            <name>G. Pelletier</name>
        </author>
        <date>
            <month>April</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49007</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>user</kw>
            <kw>datagram</kw>
            <kw>real-time application</kw>
            <kw>transport</kw>
        </keywords>
        <abstract>This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed in ROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression making use of this header-free packet. [STANDARDS TRACK] </abstract>
        <draft>ietf-rohc-rtp-lla-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3243</doc-id>
        <title>RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP Compression</title>
        <author>
            <name>L-E. Jonsson</name>
        </author>
        <date>
            <month>April</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12451</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>user</kw>
            <kw>datagram</kw>
            <kw>real-time application</kw>
            <kw>transport</kw>
            <kw>applications</kw>
            <kw>LLA</kw>
            <kw>link-layer assisted</kw>
        </keywords>
        <abstract>This document contains requirements for the 0-byte IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression scheme to be developed by the Robust Header Compression (ROHC) Working Group. It also includes the basic assumptions for the typical link layers over which 0-byte compression may be implemented, and assumptions about its usage in general. </abstract>
        <draft>ietf-rohc-rtp-0-byte-requirements-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3244</doc-id>
        <title>Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols</title>
        <author>
            <name>M. Swift</name>
        </author>
        <author>
            <name>J. Trostle</name>
        </author>
        <author>
            <name>J. Brezak</name>
        </author>
        <date>
            <month>February</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13334</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>message</kw>
            <kw>codes</kw>
        </keywords>
        <abstract>This memo specifies Microsoft's Windows 2000 Kerberos change password and set password protocols. The Windows 2000 Kerberos change password protocol interoperates with the original Kerberos change password protocol. Change password is a request reply protocol that includes a KRB_PRIV message that contains the new password for the user. This memo provides information for the Internet community. </abstract>
        <draft>trostle-win2k-cat-kerberos-set-passwd-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3245</doc-id>
        <title>The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)</title>
        <author>
            <name>J. Klensin</name>
            <title>Editor</title>
        </author>
        <author>
            <name>IAB</name>
        </author>
        <date>
            <month>March</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23758</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>IAB</kw>
            <kw>ARPA</kw>
        </keywords>
        <abstract>RFC 2916 assigned responsibility for a number of administrative and operational details of Telephone Number Mapping (ENUM) to the IAB. It also anticipated that ITU would take responsibility for determining the legitimacy and appropriateness of applicants for delegation of "country code"-level subdomains of the top-level ENUM domain. Recently, three memos have been prepared for the ITU-T Study Group 2 (SG2) to explain the background of, and reasoning for, the relevant decisions. The IAB has also supplied a set of procedural instructions to the RIPE NCC for implementation of their part of the model. The content of the three memos is provided in this document for the information of the IETF community. </abstract>
        <draft>iab-itu-enum-notes-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3246</doc-id>
        <title>An Expedited Forwarding PHB (Per-Hop Behavior)</title>
        <author>
            <name>B. Davie</name>
        </author>
        <author>
            <name>A. Charny</name>
        </author>
        <author>
            <name>J.C.R. Bennet</name>
        </author>
        <author>
            <name>K. Benson</name>
        </author>
        <author>
            <name>J.Y. Le Boudec</name>
        </author>
        <author>
            <name>W. Courtney</name>
        </author>
        <author>
            <name>S. Davari</name>
        </author>
        <author>
            <name>V. Firoiu</name>
        </author>
        <author>
            <name>D. Stiliadis</name>
        </author>
        <date>
            <month>March</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33896</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>per-hop behavior</kw>
            <kw>expedited forwarding</kw>
            <kw>differentiated services</kw>
            <kw>delay</kw>
            <kw>jitter</kw>
        </keywords>
        <abstract>This document defines a PHB (per-hop behavior) called Expedited Forwarding (EF). The PHB is a basic building block in the Differentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598. [STANDARDS TRACK] </abstract>
        <draft>ietf-diffserv-rfc2598bis-02</draft>
        <obsoletes>
            <doc-id>RFC2598</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3247</doc-id>
        <title>Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)</title>
        <author>
            <name>A. Charny</name>
        </author>
        <author>
            <name>J. Bennet</name>
        </author>
        <author>
            <name>K. Benson</name>
        </author>
        <author>
            <name>J. Boudec</name>
        </author>
        <author>
            <name>A. Chiu</name>
        </author>
        <author>
            <name>W. Courtney</name>
        </author>
        <author>
            <name>S. Davari</name>
        </author>
        <author>
            <name>V. Firoiu</name>
        </author>
        <author>
            <name>C. Kalmanek</name>
        </author>
        <author>
            <name>K. Ramakrishnan</name>
        </author>
        <date>
            <month>March</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53786</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>differentiated services</kw>
            <kw>fifo</kw>
            <kw>fair queuing</kw>
            <kw>delay</kw>
            <kw>jitter </kw>
        </keywords>
        <abstract>This document was written during the process of clarification of RFC2598 "An Expedited Forwarding PHB" that led to the publication of revised specification of EF "An Expedited Forwarding PHB". Its primary motivation is providing additional explanation to the revised EF definition and its properties. The document also provides additional implementation examples and gives some guidance for computation of the numerical parameters of the new definition for several well known schedulers and router architectures. This memo provides information for the Internet community. </abstract>
        <draft>ietf-diffserv-ef-supplemental-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3248</doc-id>
        <title>A Delay Bound alternative revision of RFC 2598</title>
        <author>
            <name>G. Armitage</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>A. Casati</name>
        </author>
        <author>
            <name>J. Crowcroft</name>
        </author>
        <author>
            <name>J. Halpern</name>
        </author>
        <author>
            <name>B. Kumar</name>
        </author>
        <author>
            <name>J. Schnizlein</name>
        </author>
        <date>
            <month>March</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21597</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>per hop behavior</kw>
            <kw>phb</kw>
            <kw>expedited forwarding</kw>
            <kw>ef</kw>
            <kw>db</kw>
        </keywords>
        <abstract>For historical interest, this document captures the EF Design Team's proposed solution, preferred by the original authors of RFC 2598 but not adopted by the working group in December 2000. The original definition of EF was based on comparison of forwarding on an unloaded network. This experimental Delay Bound (DB) PHB requires a bound on the delay of packets due to other traffic in the network. At the Pittsburgh IETF meeting in August 2000, the Differentiated Services working group faced serious questions regarding RFC 2598 - the group's standards track definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB). An 'EF Design Team' volunteered to develop a re-expression of RFC 2598, bearing in mind the issues raised in the DiffServ group. At the San Diego IETF meeting in December 2000 the DiffServ working group decided to pursue an alternative re-expression of the EF PHB. This memo provides information for the Internet community. </abstract>
        <draft>ietf-diffserv-efresolve-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3249</doc-id>
        <title>Implementers Guide for Facsimile Using Internet Mail</title>
        <author>
            <name>V. Cancio</name>
        </author>
        <author>
            <name>M. Moldovan</name>
        </author>
        <author>
            <name>H. Tamura</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40413</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>fax</kw>
            <kw>tiff</kw>
            <kw>tiff-fx</kw>
            <kw>ifax</kw>
            <kw>e-mail</kw>
            <kw>email</kw>
            <kw>esmtp</kw>
            <kw>dsn</kw>
            <kw>mdn</kw>
        </keywords>
        <abstract>This document is intended for the implementers of software that use email to send to facsimiles using RFC 2305 and 2532. This is an informational document and its guidelines do not supersede the referenced documents. This memo provides information for the Internet community. </abstract>
        <draft>ietf-fax-implementers-guide-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3250</doc-id>
        <title>Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration</title>
        <author>
            <name>L. McIntyre</name>
        </author>
        <author>
            <name>G. Parsons</name>
        </author>
        <author>
            <name>J. Rafferty</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17876</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>FFIF</kw>
            <kw>TIFF</kw>
            <kw>Tag</kw>
            <kw>Image</kw>
            <kw>facsimile</kw>
            <kw>MIME</kw>
            <kw>multipurpose</kw>
            <kw>Internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for Internet Fax and its extensions. [STANDARDS TRACK] </abstract>
        <draft>ietf-fax-tiff-fx-reg-01</draft>
        <obsoleted-by>
            <doc-id>RFC3950</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3251</doc-id>
        <title>Electricity over IP</title>
        <author>
            <name>B. Rajagopalan</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18994</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>Internet Protocol</kw>
        </keywords>
        <abstract>Mostly Pointless Lamp Switching (MPLampS) is an architecture for carrying electricity over IP (with an MPLS control plane). According to our marketing department, MPLampS has the potential to dramatically lower the price, ease the distribution and usage, and improve the manageability of delivering electricity. This document is motivated by such work as SONET/SDH over IP/MPLS (with apologies to the authors). Readers of the previous work have been observed scratching their heads and muttering, "What next?". This document answers that question. This memo provides information for the Internet community. </abstract>
        <draft>bala-mplamps-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3252</doc-id>
        <title>Binary Lexical Octet Ad-hoc Transport</title>
        <author>
            <name>H. Kennedy</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25962</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>bloat</kw>
        </keywords>
        <abstract>This document defines a reformulation of IP and two transport layer protocols (TCP and UDP) as XML applications. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3253</doc-id>
        <title>Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)</title>
        <author>
            <name>G. Clemm</name>
        </author>
        <author>
            <name>J. Amsden</name>
        </author>
        <author>
            <name>T. Ellison</name>
        </author>
        <author>
            <name>C. Kaler</name>
        </author>
        <author>
            <name>J. Whitehead</name>
        </author>
        <date>
            <month>March</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>245514</char-count>
            <page-count>118</page-count>
        </format>
        <keywords>
            <kw>hypertext</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>clients</kw>
            <kw>label</kw>
            <kw>configuration</kw>
            <kw>management</kw>
        </keywords>
        <abstract>This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. [STANDARDS TRACK] </abstract>
        <draft>ietf-deltav-versioning-20</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3254</doc-id>
        <title>Definitions for talking about directories</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>April</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21541</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>lightweight</kw>
            <kw>access</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>When discussing systems for making information accessible through the Internet in standardized ways, it may be useful if the people who are discussing it have a common understanding of the terms they use. For example, a reference to this document would give one the power to agree that the DNS (Domain Name System) is a global lookup repository with perimeter integrity and loose, converging consistency. On the other hand, a LDAP (Lightweight Directory Access Protocol) directory server is a local, centralized repository with both lookup and search capability. This document discusses one group of such systems which is known under the term, "directories". This memo provides information for the Internet community. </abstract>
        <draft>alvestrand-directory-defs-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3255</doc-id>
        <title>Extending Point-to-Point Protocol (PPP) over Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) with virtual concatenation, high order and low order payloads</title>
        <author>
            <name>N. Jones</name>
        </author>
        <author>
            <name>C. Murton</name>
        </author>
        <date>
            <month>April</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14192</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document describes an extension to the mapping of Point-to-Point Protocol (PPP) into Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) to include the use of SONET/SDH SPE/VC virtual concatenation and the use of both high order and low order payloads. [STANDARDS TRACK] </abstract>
        <draft>ietf-pppext-posvcholo-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3256</doc-id>
        <title>The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option</title>
        <author>
            <name>D. Jones</name>
        </author>
        <author>
            <name>R. Woundy</name>
        </author>
        <date>
            <month>April</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8551</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document proposes a new sub-option to the DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Option. [STANDARDS TRACK] </abstract>
        <draft>ietf-dhc-agentoptions-device-class-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3257</doc-id>
        <title>Stream Control Transmission Protocol Applicability Statement</title>
        <author>
            <name>L. Coene</name>
        </author>
        <date>
            <month>April</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24198</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>sctp</kw>
            <kw>udp</kw>
            <kw>tcp</kw>
            <kw>rtp</kw>
            <kw>transport security</kw>
            <kw>transport</kw>
            <kw>nat</kw>
            <kw>multihoming</kw>
        </keywords>
        <abstract>This document describes the applicability of the Stream Control Transmission Protocol (SCTP). It also contrasts SCTP with the two dominant transport protocols, User Datagram Protocol (UDP) &amp; Transmission Control Protocol (TCP), and gives some guidelines for when best to use SCTP and when not best to use SCTP. This memo provides information for the Internet community. </abstract>
        <draft>ietf-sigtran-sctp-applicability-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3258</doc-id>
        <title>Distributing Authoritative Name Servers via Shared Unicast Addresses</title>
        <author>
            <name>T. Hardie</name>
        </author>
        <date>
            <month>April</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22195</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>dns</kw>
            <kw>network</kw>
            <kw>topology</kw>
            <kw>latency</kw>
        </keywords>
        <abstract>This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations. The primary motivation for the development and deployment of these practices is to increase the distribution of Domain Name System (DNS) servers to previously under- served areas of the network topology and to reduce the latency for DNS query responses in those areas. This memo provides information for the Internet community. </abstract>
        <draft>ietf-dnsop-hardie-shared-root-server-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3259</doc-id>
        <title>A Message Bus for Local Coordination</title>
        <author>
            <name>J. Ott</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>D. Kutscher</name>
        </author>
        <date>
            <month>April</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>84125</char-count>
            <page-count>39</page-count>
        </format>
        <keywords>
            <kw>mbus</kw>
            <kw>message</kw>
            <kw>ip</kw>
            <kw>multicast</kw>
            <kw>addressing</kw>
            <kw>transport</kw>
            <kw>syntax</kw>
        </keywords>
        <abstract>The local Message Bus (Mbus) is a light-weight message-oriented coordination protocol for group communication between application components. The Mbus provides automatic location of communication peers, subject based addressing, reliable message transfer and different types of communication schemes. The protocol is layered on top of IP multicast and is specified for IPv4 and IPv6. The IP multicast scope is limited to link-local multicast. This document specifies the Mbus protocol, i.e., message syntax, addressing and transport mechanisms. This memo provides information for the Internet community. </abstract>
        <draft>ietf-mmusic-mbus-transport-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3260</doc-id>
        <title>New Terminology and Clarifications for Diffserv</title>
        <author>
            <name>D. Grossman</name>
        </author>
        <date>
            <month>April</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21900</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>DIFFSRV</kw>
            <kw>scalability</kw>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo captures Diffserv working group agreements concerning new and improved terminology, and provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC 2597. When RFCs 2474 and 2597 advance on the standards track, and RFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the new RFCs. This memo provides information for the Internet community. </abstract>
        <draft>ietf-diffserv-new-terms-08</draft>
        <updates>
            <doc-id>RFC2474</doc-id>
            <doc-id>RFC2475</doc-id>
            <doc-id>RFC2597</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3261</doc-id>
        <title>SIP: Session Initiation Protocol</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>A. Johnston</name>
        </author>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>R. Sparks</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>E. Schooler</name>
        </author>
        <date>
            <month>June</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>647976</char-count>
            <page-count>269</page-count>
        </format>
        <keywords>
            <kw>SIP</kw>
            <kw>application-layer</kw>
            <kw>application</kw>
            <kw>layer</kw>
            <kw>multimedia</kw>
            <kw>multicast</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract>This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS TRACK] </abstract>
        <draft>ietf-sip-rfc2543bis-09</draft>
        <obsoletes>
            <doc-id>RFC2543</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3265</doc-id>
            <doc-id>RFC3853</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3262</doc-id>
        <title>Reliability of Provisional Responses in Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>June</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29643</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>SIP</kw>
            <kw>application-layer</kw>
            <kw>application</kw>
            <kw>layer</kw>
            <kw>multimedia</kw>
            <kw>multicast</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract>This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method. [STANDARDS TRACK] </abstract>
        <draft>ietf-sip-100rel-06</draft>
        <obsoletes>
            <doc-id>RFC2543</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3263</doc-id>
        <title>Session Initiation Protocol (SIP): Locating SIP Servers</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>June</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42310</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>SIP</kw>
            <kw>application-layer</kw>
            <kw>application</kw>
            <kw>layer</kw>
            <kw>multimedia</kw>
            <kw>multicast</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract>The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail. [STANDARDS TRACK] </abstract>
        <draft>ietf-sip-srv-06</draft>
        <obsoletes>
            <doc-id>RFC2543</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3264</doc-id>
        <title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>June</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>60854</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>SIP</kw>
            <kw>application-layer</kw>
            <kw>application</kw>
            <kw>layer</kw>
            <kw>multimedia</kw>
            <kw>multicast</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract>This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS TRACK] </abstract>
        <draft>ietf-mmusic-sdp-offer-answer-02</draft>
        <obsoletes>
            <doc-id>RFC2543</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3265</doc-id>
        <title>Session Initiation Protocol (SIP)-Specific Event Notification</title>
        <author>
            <name>A. B. Roach</name>
        </author>
        <date>
            <month>June</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>89005</char-count>
            <page-count>38</page-count>
        </format>
        <keywords>
            <kw>SIP</kw>
            <kw>application-layer</kw>
            <kw>application</kw>
            <kw>layer</kw>
            <kw>multimedia</kw>
            <kw>multicast</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract>This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. [STANDARDS TRACK] </abstract>
        <draft>ietf-sip-events-05</draft>
        <obsoletes>
            <doc-id>RFC2543</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3261</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3266</doc-id>
        <title>Support for IPv6 in Session Description Protocol (SDP)</title>
        <author>
            <name>S. Olson</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>A. B. Roach</name>
        </author>
        <date>
            <month>June</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8693</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>internet addresses syntax</kw>
        </keywords>
        <abstract>This document describes the use of Internet Protocol Version 6 (IPv6) addresses in conjunction with the Session Description Protocol (SDP). Specifically, this document clarifies existing text in SDP with regards to the syntax of IPv6 addresses. [STANDARDS TRACK] </abstract>
        <draft>ietf-mmusic-sdp-ipv6-03</draft>
        <updates>
            <doc-id>RFC2327</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3267</doc-id>
        <title>Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs</title>
        <author>
            <name>J. Sjoberg</name>
        </author>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>A. Lakaniemi</name>
        </author>
        <author>
            <name>Q. Xie</name>
        </author>
        <date>
            <month>June</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>110652</char-count>
            <page-count>49</page-count>
        </format>
        <keywords>
            <kw>interoperate</kw>
            <kw>applications</kw>
        </keywords>
        <abstract>This document specifies a real-time transport protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate MIME type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. [STANDARDS TRACK] </abstract>
        <draft>ietf-avt-rtp-amr-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3268</doc-id>
        <title>Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)</title>
        <author>
            <name>P. Chown</name>
        </author>
        <date>
            <month>June</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13530</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>idea</kw>
            <kw>international data algorithm</kw>
            <kw>symmetric</kw>
        </keywords>
        <abstract>This document proposes several new ciphersuites. At present, the symmetric ciphers supported by Transport Layer Security (TLS) are RC2, RC4, International Data Encryption Algorithm (IDEA), Data Encryption Standard (DES), and triple DES. The protocol would be enhanced by the addition of Advanced Encryption Standard (AES) ciphersuites. [STANDARDS TRACK] </abstract>
        <draft>ietf-tls-ciphersuite-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3269</doc-id>
        <title>Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents</title>
        <author>
            <name>R. Kermode</name>
        </author>
        <author>
            <name>L. Vicisano</name>
        </author>
        <date>
            <month>April</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25258</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>definitions</kw>
            <kw>operation</kw>
        </keywords>
        <abstract>This document provides general guidelines to assist the authors of Reliable Multicast Transport (RMT) building block and protocol instantiation definitions. The purpose of these guidelines is to ensure that any building block and protocol instantiation definitions produced contain sufficient information to fully explain their operation and use. In addition these guidelines provide directions to specify modular and clearly defined RMT building blocks and protocol instantiations that can be refined and augmented to safely create new protocols for use in new scenarios for which any existing protocols were not designed. This memo provides information for the Internet community. </abstract>
        <draft>ietf-rmt-author-guidelines-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3270</doc-id>
        <title>Multi-Protocol Label Switching (MPLS) Support of Differentiated Services</title>
        <author>
            <name>F. Le Faucheur</name>
        </author>
        <author>
            <name>L. Wu</name>
        </author>
        <author>
            <name>B. Davie</name>
        </author>
        <author>
            <name>S. Davari</name>
        </author>
        <author>
            <name>P. Vaananen</name>
        </author>
        <author>
            <name>R. Krishnan</name>
        </author>
        <author>
            <name>P. Cheval</name>
        </author>
        <author>
            <name>J. Heinanen</name>
        </author>
        <date>
            <month>May</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>137960</char-count>
            <page-count>64</page-count>
        </format>
        <keywords>
            <kw>diff-serv</kw>
            <kw>ba</kw>
            <kw>behaviour aggregate</kw>
            <kw>lsp</kw>
            <kw>label switched paths</kw>
        </keywords>
        <abstract>This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks. [STANDARDS TRACK] </abstract>
        <draft>ietf-mpls-diff-ext-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3271</doc-id>
        <title>The Internet is for Everyone</title>
        <author>
            <name>V. Cerf</name>
        </author>
        <date>
            <month>April</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12345</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>isoc</kw>
            <kw>internet society</kw>
            <kw>policy issues</kw>
            <kw>social impact</kw>
            <kw>economic impact</kw>
            <kw>international policy</kw>
            <kw>use and abuse of the internet</kw>
        </keywords>
        <abstract>This document expresses the Internet Society's ideology that the Internet really is for everyone. However, it will only be such if we make it so. This memo provides information for the Internet community. </abstract>
        <draft>isoc-internet-for-everyone-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3272</doc-id>
        <title>Overview and Principles of Internet Traffic Engineering</title>
        <author>
            <name>D. Awduche</name>
        </author>
        <author>
            <name>A. Chiu</name>
        </author>
        <author>
            <name>A. Elwalid</name>
        </author>
        <author>
            <name>I. Widjaja</name>
        </author>
        <author>
            <name>X. Xiao</name>
        </author>
        <date>
            <month>May</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>190384</char-count>
            <page-count>71</page-count>
        </format>
        <keywords>
            <kw>te</kw>
            <kw>ip</kw>
            <kw>networks</kw>
        </keywords>
        <abstract>This memo describes the principles of Traffic Engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational IP networks are discussed throughout this document. This memo provides information for the Internet community. </abstract>
        <draft>ietf-tewg-principles-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3273</doc-id>
        <title>Remote Network Monitoring Management Information Base for High Capacity Networks</title>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>July</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>150924</char-count>
            <page-count>77</page-count>
        </format>
        <keywords>
            <kw>rmon</kw>
            <kw>mib</kw>
            <kw>high speed networks</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring (RMON) devices for use on high speed networks. This document contains a MIB Module that defines these new objects and also contains definitions of some updated objects from the RMON-MIB in RFC 2819 and the RMON2-MIB in RFC 2021. [PROPOSED STANDARD] </abstract>
        <draft>ietf-rmonmib-hcrmon-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3274</doc-id>
        <title>Compressed Data Content Type for Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>P. Gutmann</name>
        </author>
        <date>
            <month>June</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11276</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>content info type</kw>
        </keywords>
        <abstract>This document defines a format for using compressed data as a Cryptographic Message Syntax (CMS) content type. Compressing data before transmission provides a number of advantages, including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps (such as signing or encryption), and reducing overall message size. Although there have been proposals for adding compression at other levels (for example at the MIME or SSL level), these don't address the problem of compression of CMS content unless the compression is supplied by an external means (for example by intermixing MIME and CMS). [STANDARDS TRACK] </abstract>
        <draft>ietf-smime-compression-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3275</doc-id>
        <title>(Extensible Markup Language) XML-Signature Syntax and Processing</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>J. Reagle</name>
        </author>
        <author>
            <name>D. Solo</name>
        </author>
        <date>
            <month>March</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>164198</char-count>
            <page-count>73</page-count>
        </format>
        <keywords>
            <kw>extensible</kw>
            <kw>markup</kw>
            <kw>language</kw>
        </keywords>
        <abstract>This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. [STANDARDS TRACK] </abstract>
        <draft>ietf-xmldsig-core-2-03</draft>
        <obsoletes>
            <doc-id>RFC3075</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3276</doc-id>
        <title>Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines Processing</title>
        <author>
            <name>B. Ray</name>
        </author>
        <author>
            <name>R. Abbi</name>
        </author>
        <date>
            <month>May</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>122991</char-count>
            <page-count>66</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>interfaces</kw>
        </keywords>
        <abstract>This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces. [STANDARDS TRACK] </abstract>
        <draft>ietf-adslmib-hdsl2-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3277</doc-id>
        <title>Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance</title>
        <author>
            <name>D. McPherson</name>
        </author>
        <date>
            <month>April</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13077</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>router</kw>
        </keywords>
        <abstract>This document describes a simple, interoperable mechanism that can be employed in Intermediate System to Intermediate System (IS-IS) networks in order to decrease the data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. This memo provides information for the Internet community. </abstract>
        <draft>ietf-isis-transient-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3278</doc-id>
        <title>Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>S. Blake-Wilson</name>
        </author>
        <author>
            <name>D. Brown</name>
        </author>
        <author>
            <name>P. Lambert</name>
        </author>
        <date>
            <month>April</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33779</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>public key</kw>
            <kw>digital signatures</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the ANSI X9.62 standard, developed by the ANSI X9F1 working group, the IEEE 1363 standard, and the SEC 1 standard. This memo provides information for the Internet community. </abstract>
        <draft>ietf-smime-ecc-06 </draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3279</doc-id>
        <title>Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
        <author>
            <name>L. Bassham</name>
        </author>
        <author>
            <name>W. Polk</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>April</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53833</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>ASN.1</kw>
        </keywords>
        <abstract>This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject. [STANDARDS TRACK] </abstract>
        <draft>ietf-pkix-ipki-pkalgs-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3280</doc-id>
        <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>W. Polk</name>
        </author>
        <author>
            <name>W. Ford</name>
        </author>
        <author>
            <name>D. Solo</name>
        </author>
        <date>
            <month>April</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>295556</char-count>
            <page-count>129</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This memo profiles the X.509 v3 certificate and X.509 v2 Certificate Revocation List (CRL) for use in the Internet. [STANDARDS TRACK] </abstract>
        <draft>ietf-pkix-new-part1-12</draft>
        <obsoletes>
            <doc-id>RFC2459</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3281</doc-id>
        <title>An Internet Attribute Certificate Profile for Authorization</title>
        <author>
            <name>S. Farrell</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>April</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>90580</char-count>
            <page-count>40</page-count>
        </format>
        <keywords>
            <kw>electronic mail</kw>
            <kw>email</kw>
            <kw>ipsec</kw>
            <kw>www security</kw>
        </keywords>
        <abstract>This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. [STANDARDS TRACK] </abstract>
        <draft>ietf-pkix-ac509prof-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3282</doc-id>
        <title>Content Language Headers</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>May</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14022</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document defines a "Content-language:" header, for use in cases where one desires to indicate the language of something that has RFC 822-like headers, like MIME body parts or Web documents, and an "Accept-Language:" header for use in cases where one wishes to indicate one's preferences with regard to language. [STANDARDS TRACK] </abstract>
        <draft>alvestrand-content-language-03</draft>
        <obsoletes>
            <doc-id>RFC1766</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3283</doc-id>
        <title>Guide to Internet Calendaring</title>
        <author>
            <name>B. Mahoney</name>
        </author>
        <author>
            <name>G. Babics</name>
        </author>
        <author>
            <name>A. Taler</name>
        </author>
        <date>
            <month>June</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31768</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>scheduling systems</kw>
            <kw>cap</kw>
            <kw>calendar access protocool</kw>
            <kw>itip</kw>
            <kw>imip</kw>
        </keywords>
        <abstract>This document describes the various Internet calendaring and scheduling standards and works in progress, and the relationships between them. Its intent is to provide a context for these documents, assist in their understanding, and potentially aid in the design of standards-based calendaring and scheduling systems. The standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and RFC 2447 (iMIP). The work in progress addressed is "Calendar Access Protocol" (CAP). This document also describes issues and problems that are not solved by these protocols, and that could be targets for future work. This memo provides information for the Internet community. </abstract>
        <draft>ietf-calsch-inetcal-guide-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3284</doc-id>
        <title>The VCDIFF Generic Differencing and Compression Data Format</title>
        <author>
            <name>D. Korn</name>
        </author>
        <author>
            <name>J. MacDonald</name>
        </author>
        <author>
            <name>J. Mogul</name>
        </author>
        <author>
            <name>K. Vo</name>
        </author>
        <date>
            <month>June</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>64035</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>transport</kw>
            <kw>portable</kw>
            <kw>at&amp;t</kw>
            <kw>encoding</kw>
        </keywords>
        <abstract>This memo describes VCDIFF, a general, efficient and portable data format suitable for encoding compressed and/or differencing data so that they can be easily transported among computers. [STANDARDS TRACK] </abstract>
        <draft>korn-vcdiff-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3285</doc-id>
        <title>Using Microsoft Word to create Internet Drafts and RFCs</title>
        <author>
            <name>M. Gahrns</name>
        </author>
        <author>
            <name>T. Hain</name>
        </author>
        <date>
            <month>May</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34556</char-count>
            <page-count>19</page-count>
        </format>
        <abstract>This document describes the steps to configure the Microsoft Word application to produce documents in Internet Draft and RFC format. This memo provides information for the Internet community. </abstract>
        <draft>hain-msword-template-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3286</doc-id>
        <title>An Introduction to the Stream Control Transmission Protocol (SCTP)</title>
        <author>
            <name>L. Ong</name>
        </author>
        <author>
            <name>J. Yoakum</name>
        </author>
        <date>
            <month>May</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22644</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>transport</kw>
            <kw>layer</kw>
            <kw>telephony</kw>
            <kw>signaling</kw>
        </keywords>
        <abstract>This document provides a high level introduction to the capabilities supported by the Stream Control Transmission Protocol (SCTP). It is intended as a guide for potential users of SCTP as a general purpose transport protocol. This memo provides information for the Internet community. </abstract>
        <draft>ong-sigtran-sctpover-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3287</doc-id>
        <title>Remote Monitoring MIB Extensions for Differentiated Services</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <date>
            <month>July</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>249622</char-count>
            <page-count>120</page-count>
        </format>
        <keywords>
            <kw>rmon</kw>
            <kw>management information base</kw>
            <kw>diffserv</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring Differentiated Services (DS) Codepoint usage in packets which contain a DS field, utilizing the monitoring framework defined in the RMON-2 (Remote Network Monitoring Management Version 2) MIB. [STANDARDS TRACK] </abstract>
        <draft>ietf-rmonmib-dsmon-mib-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3288</doc-id>
        <title>Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)</title>
        <author>
            <name>E. O'Tuathail</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>June</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27434</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>binding</kw>
            <kw>markup language</kw>
            <kw>xml</kw>
        </keywords>
        <abstract>This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol core (BEEP). A SOAP binding describes how SOAP messages are transmitted in the network. [STANDARDS TRACK] </abstract>
        <draft>etal-beep-soap-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3289</doc-id>
        <title>Management Information Base for the Differentiated Services Architecture</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>K. Chan</name>
        </author>
        <author>
            <name>A. Smith</name>
        </author>
        <date>
            <month>May</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>239041</char-count>
            <page-count>116</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>diffserv</kw>
            <kw>router</kw>
            <kw>architecture</kw>
        </keywords>
        <abstract>This memo describes an SMIv2 (Structure of Management Information version 2) MIB for a device implementing the Differentiated Services Architecture. It may be used both for monitoring and configuration of a router or switch capable of Differentiated Services functionality. [STANDARDS TRACK] </abstract>
        <draft>ietf-diffserv-mib-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3290</doc-id>
        <title>An Informal Management Model for Diffserv Routers</title>
        <author>
            <name>Y. Bernet</name>
        </author>
        <author>
            <name>S. Blake</name>
        </author>
        <author>
            <name>D. Grossman</name>
        </author>
        <author>
            <name>A. Smith</name>
        </author>
        <date>
            <month>May</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>129443</char-count>
            <page-count>56</page-count>
        </format>
        <keywords>
            <kw>differentiated services</kw>
        </keywords>
        <abstract>This document proposes an informal management model of Differentiated Services (Diffserv) routers for use in their management and configuration. This model defines functional datapath elements (e.g., classifiers, meters, actions, marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers. It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per-hop behavior (PHB) functionalities described in the Diffserv Architecture. This memo provides information for the Internet community. </abstract>
        <draft>ietf-diffserv-model-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3291</doc-id>
        <title>Textual Conventions for Internet Network Addresses</title>
        <author>
            <name>M. Daniele</name>
        </author>
        <author>
            <name>B. Haberman</name>
        </author>
        <author>
            <name>S. Routhier</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>May</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43564</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>tc</kw>
            <kw>mib</kw>
            <kw>layer</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS TRACK] </abstract>
        <draft>ietf-ops-rfc2851-update-06</draft>
        <obsoletes>
            <doc-id>RFC2851</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC4001</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3292</doc-id>
        <title>General Switch Management Protocol (GSMP) V3</title>
        <author>
            <name>A. Doria</name>
        </author>
        <author>
            <name>F. Hellstrand</name>
        </author>
        <author>
            <name>K. Sundell</name>
        </author>
        <author>
            <name>T. Worster</name>
        </author>
        <date>
            <month>June</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>318983</char-count>
            <page-count>137</page-count>
        </format>
        <keywords>
            <kw>switch</kw>
            <kw>label</kw>
            <kw>unicast</kw>
            <kw>multicast</kw>
            <kw>qos</kw>
            <kw>quality of service</kw>
        </keywords>
        <abstract>This document describes the General Switch Management Protocol Version 3 (GSMPv3). The GSMPv3 is an asymmetric protocol that allows one or more external switch controllers to establish and maintain the state of a label switch such as, an ATM, frame relay or MPLS switch. The GSMPv3 allows control of both unicast and multicast switch connection state as well as control of switch system resources and QoS features. [STANDARDS TRACK] </abstract>
        <draft>ietf-gsmp-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3293</doc-id>
        <title>General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP)</title>
        <author>
            <name>T. Worster</name>
        </author>
        <author>
            <name>A. Doria</name>
        </author>
        <author>
            <name>J. Buerkle</name>
        </author>
        <date>
            <month>June</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18206</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This memo specifies the encapsulation of GSMP (General Switch Management Protocol) packets in ATM (Asynchronous Transfer Mode), Ethernet and TCP (Transmission Control Protocol). [STANDARDS TRACK] </abstract>
        <draft>ietf-gsmp-encaps-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3294</doc-id>
        <title>General Switch Management Protocol (GSMP) Applicability</title>
        <author>
            <name>A. Doria</name>
        </author>
        <author>
            <name>K. Sundell</name>
        </author>
        <date>
            <month>June</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18294</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
        </keywords>
        <abstract>This memo provides an overview of the GSMP (General Switch Management Protocol) and includes information relating to its deployment in a IP network in an MPLS environment. It does not discuss deployment in an ATM (Asynchronous Transfer Mode) network or in a raw ethernet configuration. This memo provides information for the Internet community. </abstract>
        <draft>ietf-gsmp-applicability-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3295</doc-id>
        <title>Definitions of Managed Objects for the General Switch Management Protocol (GSMP)</title>
        <author>
            <name>H. Sjostrand</name>
        </author>
        <author>
            <name>J. Buerkle</name>
        </author>
        <author>
            <name>B. Srinivasan</name>
        </author>
        <date>
            <month>June</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>95516</char-count>
            <page-count>47</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>controller</kw>
            <kw>gsmp-mib</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for the use with the network management protocols in the Internet community. In particular, it describes managed objects for the General Switch Management Protocol (GSMP). [STANDARDS TRACK] </abstract>
        <draft>ietf-gsmp-mib-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3296</doc-id>
        <title>Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>July</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27389</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>schema</kw>
            <kw>elements</kw>
            <kw>description</kw>
            <kw>formats</kw>
        </keywords>
        <abstract>This document details schema and protocol elements for representing and managing named subordinate references in Lightweight Directory Access Protocol (LDAP) Directories. [STANDARDS TRACK] </abstract>
        <draft>zeilenga-ldap-namedref-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3297</doc-id>
        <title>Content Negotiation for Messaging Services based on Email</title>
        <author>
            <name>G. Klyne</name>
        </author>
        <author>
            <name>R. Iwazaki</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>July</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>97094</char-count>
            <page-count>46</page-count>
        </format>
        <keywords>
            <kw>facsimile</kw>
        </keywords>
        <abstract>This memo describes a content negotiation mechanism for facsimile, voice and other messaging services that use Internet email. [STANDARDS TRACK] </abstract>
        <draft>ietf-fax-content-negotiation-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3298</doc-id>
        <title>Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements</title>
        <author>
            <name>I. Faynberg</name>
        </author>
        <author>
            <name>J. Gato</name>
        </author>
        <author>
            <name>H. Lu</name>
        </author>
        <author>
            <name>L. Slutsman</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36560</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>support</kw>
        </keywords>
        <abstract>This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service".) The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Similarly, such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN. To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol. This memo provides information for the Internet community. </abstract>
        <draft>ietf-spirits-reqs-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3299</doc-id>
        <title>Request for Comments Summary RFC Numbers 3200-3299</title>
        <author>
            <name>S. Ginoza</name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63813</char-count>
            <page-count>30</page-count>
        </format>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3300</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Reynolds</name>
        </author>
        <author>
            <name>R. Braden</name>
        </author>
        <author>
            <name>S. Ginoza</name>
        </author>
        <author>
            <name>A. De La Cruz</name>
        </author>
        <date>
            <month>November</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>127805</char-count>
            <page-count>49</page-count>
        </format>
        <obsoletes>
            <doc-id>RFC3000</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3600</doc-id>
        </obsoleted-by>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3301</doc-id>
        <title>Layer Two Tunnelling Protocol (L2TP): ATM access network extensions</title>
        <author>
            <name>Y. T'Joens</name>
        </author>
        <author>
            <name>P. Crivellari</name>
        </author>
        <author>
            <name>B. Sales</name>
        </author>
        <date>
            <month>June</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42756</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
        </keywords>
        <draft>ietf-l2tpext-atmext-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3302</doc-id>
        <title>Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration</title>
        <author>
            <name>G. Parsons</name>
        </author>
        <author>
            <name>J. Rafferty</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15183</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>TIFF</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>extensions</kw>
        </keywords>
        <draft>ietf-fax-tiff-regbis-05</draft>
        <notes>moved to draft standard 2/7/05; moved when we pub'd 3949 and 3950.</notes>
        <obsoletes>
            <doc-id>RFC2302</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3303</doc-id>
        <title>Middlebox communication architecture and framework</title>
        <author>
            <name>P. Srisuresh</name>
        </author>
        <author>
            <name>J. Kuthan</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>A. Molitor</name>
        </author>
        <author>
            <name>A. Rayhan</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>91209</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>midcom</kw>
        </keywords>
        <draft>ietf-midcom-framework-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3304</doc-id>
        <title>Middlebox Communications (midcom) Protocol Requirements</title>
        <author>
            <name>R. P. Swale</name>
        </author>
        <author>
            <name>P. A. Mart</name>
        </author>
        <author>
            <name>P. Sijben</name>
        </author>
        <author>
            <name>S. Brim</name>
        </author>
        <author>
            <name>M. Shore</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16187</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>nat</kw>
            <kw>network address protocol</kw>
            <kw>firewall middleboxes</kw>
        </keywords>
        <draft>ietf-midcom-requirements-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3305</doc-id>
        <title>Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations</title>
        <author>
            <name>M. Mealling</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Denenberg</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21793</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>internet engineering task force</kw>
        </keywords>
        <draft>mealling-uri-ig-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3306</doc-id>
        <title>Unicast-Prefix-based IPv6 Multicast Addresses</title>
        <author>
            <name>B. Haberman</name>
        </author>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12713</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>internet protocol</kw>
        </keywords>
        <draft>ietf-ipngwg-uni-based-mcast-03</draft>
        <updated-by>
            <doc-id>RFC3956</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3307</doc-id>
        <title>Allocation Guidelines for IPv6 Multicast Addresses</title>
        <author>
            <name>B. Haberman</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15742</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>internet protocol</kw>
        </keywords>
        <draft>ietf-malloc-ipv6-guide-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3308</doc-id>
        <title>Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension</title>
        <author>
            <name>P. Calhoun</name>
        </author>
        <author>
            <name>W. Luo</name>
        </author>
        <author>
            <name>D. McPherson</name>
        </author>
        <author>
            <name>K. Peirce</name>
        </author>
        <date>
            <month>November</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21536</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>per hop behavior</kw>
            <kw>phb</kw>
            <kw>diffserv</kw>
        </keywords>
        <draft>ietf-l2tpext-ds-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3309</doc-id>
        <title>Stream Control Transmission Protocol (SCTP) Checksum Change</title>
        <author>
            <name>J. Stone</name>
        </author>
        <author>
            <name>R. Stewart</name>
        </author>
        <author>
            <name>D. Otis</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34670</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>adler-32</kw>
            <kw>checksum</kw>
            <kw>error detection</kw>
        </keywords>
        <draft>ietf-tsvwg-sctpcsum-07</draft>
        <updates>
            <doc-id>RFC2960</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3310</doc-id>
        <title>Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)</title>
        <author>
            <name>A. Niemi</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>V. Torvinen</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36985</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>one-time password generation mechanism</kw>
            <kw>umts</kw>
            <kw>universal mobile telecommunications system</kw>
        </keywords>
        <draft>ietf-sip-digest-aka-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3311</doc-id>
        <title>The Session Initiation Protocol (SIP) UPDATE Method</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>October</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28125</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>parameters</kw>
            <kw>media streams</kw>
        </keywords>
        <draft>ietf-sip-update-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3312</doc-id>
        <title>Integration of Resource Management and Session Initiation Protocol (SIP)</title>
        <author>
            <name>G. Camarillo</name>
            <title>Editor</title>
        </author>
        <author>
            <name>W. Marshall</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>October</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>65757</char-count>
            <page-count>30</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>655218</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>130391</char-count>
        </format>
        <keywords>
            <kw>qos</kw>
            <kw>quality of service</kw>
            <kw>precondition</kw>
        </keywords>
        <draft>ietf-sip-manyfolks-resource-07</draft>
        <updated-by>
            <doc-id>RFC4032</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3313</doc-id>
        <title>Private Session Initiation Protocol (SIP) Extensions for Media Authorization</title>
        <author>
            <name>W. Marshall</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36866</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>qos</kw>
            <kw>quality of service</kw>
        </keywords>
        <draft>sip-call-auth-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3314</doc-id>
        <title>Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards</title>
        <author>
            <name>M. Wasserman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48168</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>internet protocol</kw>
        </keywords>
        <draft>ietf-ipv6-3gpp-recommend-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3315</doc-id>
        <title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
        <author>
            <name>R. Droms</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Bound</name>
        </author>
        <author>
            <name>B. Volz</name>
        </author>
        <author>
            <name>T. Lemon</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>M. Carney</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>231402</char-count>
            <page-count>101</page-count>
        </format>
        <keywords>
            <kw>internet protocol</kw>
            <kw>parameters</kw>
            <kw>addresses</kw>
        </keywords>
        <draft>ietf-dhc-dhcpv6-28</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3316</doc-id>
        <title> Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>G. Kuijpers</name>
        </author>
        <author>
            <name>H. Soliman</name>
        </author>
        <author>
            <name>J. Loughney</name>
        </author>
        <author>
            <name>J. Wiljakka</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48741</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>links</kw>
            <kw>bandwidth</kw>
        </keywords>
        <draft>ietf-ipv6-cellular-host-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3317</doc-id>
        <title>Differentiated Services Quality of Service Policy Information Base</title>
        <author>
            <name>K. Chan</name>
        </author>
        <author>
            <name>R. Sahita</name>
        </author>
        <author>
            <name>S. Hahn</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>188553</char-count>
            <page-count>96</page-count>
        </format>
        <keywords>
            <kw>pib</kw>
            <kw>differentiated services architecture</kw>
        </keywords>
        <draft>ietf-diffserv-pib-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3318</doc-id>
        <title>Framework Policy Information Base</title>
        <author>
            <name>R. Sahita</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Hahn</name>
        </author>
        <author>
            <name>K. Chan</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>144530</char-count>
            <page-count>70</page-count>
        </format>
        <draft>ietf-rap-frameworkpib-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3319</doc-id>
        <title>Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>B. Volz</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14444</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>outbound proxy servers</kw>
        </keywords>
        <draft>ietf-sip-dhcpv6-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3320</doc-id>
        <title>Signaling Compression (SigComp)</title>
        <author>
            <name>R. Price</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>J. Christoffersson</name>
        </author>
        <author>
            <name>H. Hannu</name>
        </author>
        <author>
            <name>Z. Liu</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>137035</char-count>
            <page-count>62</page-count>
        </format>
        <keywords>
            <kw>sip</kw>
            <kw>session initiation protocol</kw>
            <kw>udvm</kw>
            <kw>universal decompressor virtual machine</kw>
        </keywords>
        <draft>ietf-rohc-sigcomp-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3321</doc-id>
        <title>Signaling Compression (SigComp) - Extended Operations</title>
        <author>
            <name>H. Hannu</name>
        </author>
        <author>
            <name>J. Christoffersson</name>
        </author>
        <author>
            <name>S. Forsgren</name>
        </author>
        <author>
            <name>K.-C. Leung</name>
        </author>
        <author>
            <name>Z. Liu</name>
        </author>
        <author>
            <name>R. Price</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39433</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>sip</kw>
            <kw>session initiation protocol</kw>
            <kw>udvm</kw>
            <kw>universal decompressor virtual machine</kw>
        </keywords>
        <draft>ietf-rohc-sigcomp-extended-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3322</doc-id>
        <title>Signaling Compression (SigComp) Requirements &amp; Assumptions</title>
        <author>
            <name>H. Hannu</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27533</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>sip</kw>
            <kw>session initiation protocol</kw>
            <kw>wireless</kw>
            <kw>cellular</kw>
            <kw>sdp</kw>
            <kw>session description protocol</kw>
        </keywords>
        <draft>ietf-rohc-signaling-req-assump-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3323</doc-id>
        <title>A Privacy Mechanism for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>November</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54116</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>privacy service</kw>
        </keywords>
        <draft>ietf-sip-privacy-general-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3324</doc-id>
        <title>Short Term Requirements for Network Asserted Identity</title>
        <author>
            <name>M. Watson</name>
        </author>
        <date>
            <month>November</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21964</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>session initiation protocol</kw>
            <kw>sip</kw>
            <kw>ua</kw>
            <kw>user agent</kw>
        </keywords>
        <draft>ietf-sipping-nai-reqs-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3325</doc-id>
        <title>Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks</title>
        <author>
            <name>C. Jennings</name>
        </author>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>M. Watson</name>
        </author>
        <date>
            <month>November</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36170</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>trust domain</kw>
        </keywords>
        <draft>ietf-sip-asserted-identity-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3326</doc-id>
        <title>The Reason Header Field for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>D. Oran</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15695</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>heterogeneous error response forking problem</kw>
            <kw>herfp</kw>
        </keywords>
        <abstract>The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: &lt;sip:alice@pc33.atlanta.com&gt; and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This document defines an extension header field, "Path" which provides such a mechanism. [STANDARDS TRACK]</abstract>
        <draft>ietf-sip-reason-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3327</doc-id>
        <title>Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts</title>
        <author>
            <name>D. Willis</name>
        </author>
        <author>
            <name>B. Hoeneisen</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36493</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>3gpp</kw>
            <kw>register</kw>
            <kw>contact</kw>
            <kw>path</kw>
            <kw>registrar</kw>
            <kw>user agent</kw>
            <kw>ua</kw>
        </keywords>
        <draft>willis-sip-path-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC3328</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC3329</doc-id>
        <title>Security Mechanism Agreement for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>V. Torvinen</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>A. Niemi</name>
        </author>
        <author>
            <name>T. Haukka</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51503</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>ua</kw>
            <kw>user agent</kw>
        </keywords>
        <draft>ietf-sip-sec-agree-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3330</doc-id>
        <title>Special-Use IPv4 Addresses</title>
        <author>
            <name>IANA</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16200</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>internet protocol</kw>
            <kw>space assignments</kw>
        </keywords>
        <draft>iana-special-ipv4-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3331</doc-id>
        <title>Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer</title>
        <author>
            <name>K. Morneault</name>
        </author>
        <author>
            <name>R. Dantu</name>
        </author>
        <author>
            <name>G. Sidebottom</name>
        </author>
        <author>
            <name>B. Bidulock</name>
        </author>
        <author>
            <name>J. Heitz</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>210807</char-count>
            <page-count>94</page-count>
        </format>
        <keywords>
            <kw>sctp</kw>
            <kw>stream control transmission protocol</kw>
            <kw>sg</kw>
            <kw>signaling gateway</kw>
            <kw>media gateway controller</kw>
            <kw>mgc</kw>
        </keywords>
        <draft>ietf-sigtran-m2ua-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3332</doc-id>
        <title>Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)</title>
        <author>
            <name>G. Sidebottom</name>
            <title>Editor</title>
        </author>
        <author>
            <name>K. Morneault</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Pastor-Balbas</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>265055</char-count>
            <page-count>120</page-count>
        </format>
        <keywords>
            <kw>isup</kw>
            <kw>sccp</kw>
            <kw>sctp</kw>
            <kw>stream control tranmission protocol</kw>
            <kw>mgc</kw>
            <kw>media gateway protocol</kw>
            <kw>st</kw>
            <kw>signalling gateway</kw>
        </keywords>
        <draft>ietf-sigtran-m3ua-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3334</doc-id>
        <title>Policy-Based Accounting</title>
        <author>
            <name>T. Zseby</name>
        </author>
        <author>
            <name>S. Zander</name>
        </author>
        <author>
            <name>C. Carle</name>
        </author>
        <date>
            <month>October</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>103014</char-count>
            <page-count>44</page-count>
        </format>
        <keywords>
            <kw>measurement</kw>
            <kw>metering</kw>
            <kw>meter configuration</kw>
            <kw>qos auditing</kw>
            <kw>aaa</kw>
            <kw>aaa architecture</kw>
            <kw>inter-domain accounting</kw>
        </keywords>
        <draft>irtf-aaaarch-pol-acct-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3335</doc-id>
        <title>MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet</title>
        <author>
            <name>T. Harding</name>
        </author>
        <author>
            <name>R. Drummond</name>
        </author>
        <author>
            <name>C. Shih</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59687</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>multipurpose</kw>
            <kw>internet mail extensions</kw>
            <kw>edi</kw>
        </keywords>
        <draft>ietf-ediinet-asl-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3336</doc-id>
        <title>PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2)</title>
        <author>
            <name>B. Thompson</name>
        </author>
        <author>
            <name>T. Koren</name>
        </author>
        <author>
            <name>B. Buffam</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33631</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>point-to-point</kw>
            <kw>protocol</kw>
            <kw>atm</kw>
            <kw>aal2</kw>
            <kw>datagram</kw>
            <kw>packets</kw>
        </keywords>
        <draft>ietf-pppext-ppp-over-aal2-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3337</doc-id>
        <title>Class Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2</title>
        <author>
            <name>B. Thompson</name>
        </author>
        <author>
            <name>T. Koren</name>
        </author>
        <author>
            <name>B. Buffam</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14911</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>point-to-point</kw>
            <kw>protocol</kw>
            <kw>atm</kw>
            <kw>aal2</kw>
            <kw>encapsulation</kw>
        </keywords>
        <draft>ietf-pppext-ppp-over-aal2-class-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3338</doc-id>
        <title>Dual Stack Hosts Using "Bump-in-the-API" (BIA)</title>
        <author>
            <name>S. Lee</name>
        </author>
        <author>
            <name>M-K. Shin</name>
        </author>
        <author>
            <name>Y-J. Kim</name>
        </author>
        <author>
            <name>E. Nordmark</name>
        </author>
        <author>
            <name>A. Durand</name>
        </author>
        <date>
            <month>October</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34480</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
        </keywords>
        <draft>ietf-ngtrans-bia-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3339</doc-id>
        <title>Date and Time on the Internet: Timestamps</title>
        <author>
            <name>G. Klyne</name>
        </author>
        <author>
            <name>C. Newman</name>
        </author>
        <date>
            <month>July</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35064</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>gregorian calendar</kw>
            <kw>iso</kw>
        </keywords>
        <draft>ietf-impp-datetime-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3340</doc-id>
        <title>The Application Exchange Core</title>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>G. Klyne</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>July</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>74266</char-count>
            <page-count>40</page-count>
        </format>
        <keywords>
            <kw>APEX</kw>
        </keywords>
        <draft>ietf-apex-core-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3341</doc-id>
        <title>The Application Exchange (APEX) Access Service</title>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>G. Klyne</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>July</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46675</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>APEX</kw>
        </keywords>
        <draft>ietf-apex-access-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3342</doc-id>
        <title>The Application Exchange (APEX) Option Party Pack, Part Deux!</title>
        <author>
            <name>E. Dixon</name>
        </author>
        <author>
            <name>H. Franklin</name>
        </author>
        <author>
            <name>J. Kint</name>
        </author>
        <author>
            <name>G. Klyne</name>
        </author>
        <author>
            <name>D. New</name>
        </author>
        <author>
            <name>S. Pead</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>M. Schwartz</name>
        </author>
        <date>
            <month>July</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34300</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>datagram</kw>
            <kw>service</kw>
            <kw>core</kw>
            <kw>relaying</kw>
            <kw>mesh</kw>
        </keywords>
        <draft>ietf-apex-party-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3343</doc-id>
        <title>The Application Exchange (APEX) Presence Service</title>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>G. Klyne</name>
        </author>
        <author>
            <name>D. Crocker</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42043</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>endpoint</kw>
        </keywords>
        <draft>ietf-apex-presence-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3344</doc-id>
        <title>IP Mobility Support for IPv4</title>
        <author>
            <name>C. Perkins</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>241041</char-count>
            <page-count>99</page-count>
        </format>
        <keywords>
            <kw>MOBILEIPSUPIP</kw>
            <kw>Internet</kw>
            <kw>Protocol</kw>
        </keywords>
        <obsoletes>
            <doc-id>RFC3220</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3345</doc-id>
        <title>Border Gateway Protocol (BGP) Persistent Route Oscillation Condition</title>
        <author>
            <name>D. McPherson</name>
        </author>
        <author>
            <name>V. Gill</name>
        </author>
        <author>
            <name>D. Walton</name>
        </author>
        <author>
            <name>A. Retana</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38137</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>idr</kw>
            <kw>ibgp</kw>
        </keywords>
        <draft>ietf-idr-route-oscillation-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3346</doc-id>
        <title>Applicability Statement for Traffic Engineering with MPLS</title>
        <author>
            <name>J. Boyle</name>
        </author>
        <author>
            <name>V. Gill</name>
        </author>
        <author>
            <name>A. Hannan</name>
        </author>
        <author>
            <name>D. Cooper</name>
        </author>
        <author>
            <name>D. Awduche</name>
        </author>
        <author>
            <name>B. Christian</name>
        </author>
        <author>
            <name>W.S. Lai</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33754</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>multiprotocol label switching</kw>
            <kw>te</kw>
        </keywords>
        <draft>ietf-tewg-te-applicability-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3347</doc-id>
        <title>Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations</title>
        <author>
            <name>M. Krueger</name>
        </author>
        <author>
            <name>R. Haagens</name>
        </author>
        <date>
            <month>July</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>58097</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>scsi</kw>
            <kw>tcp. storage</kw>
            <kw>fibre channel</kw>
        </keywords>
        <draft>ietf-ips-iscsi-reqmts-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3348</doc-id>
        <title>The Internet Message Action Protocol (IMAP4) Child Mailbox Extension</title>
        <author>
            <name>M. Gahrns</name>
        </author>
        <author>
            <name>R. Cheng</name>
        </author>
        <date>
            <month>July</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11868</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>children</kw>
        </keywords>
        <draft>gahrns-imap-child-mailbox-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3349</doc-id>
        <title>A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force</title>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>July</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7916</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>beep</kw>
        </keywords>
        <draft>mrose-beep-transientid-02</draft>
        <is-also>
            <doc-id>BCP0059</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3351</doc-id>
        <title>User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals</title>
        <author>
            <name>N. Charlton</name>
        </author>
        <author>
            <name>M. Gasson</name>
        </author>
        <author>
            <name>G. Gybels</name>
        </author>
        <author>
            <name>M. Spanner</name>
        </author>
        <author>
            <name>A. van Wijk</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33894</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>relay service</kw>
            <kw>transcoding service</kw>
            <kw>textphone</kw>
        </keywords>
        <draft>ietf-sipping-deaf-req-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3352</doc-id>
        <title>Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7265</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>CLDAP</kw>
            <kw>CLDAP</kw>
            <kw>Presentation</kw>
            <kw>Address</kw>
            <kw>Application</kw>
            <kw>Entity</kw>
            <kw>Title</kw>
        </keywords>
        <draft>zeilenga-cldap-02</draft>
        <obsoletes>
            <doc-id>RFC1798</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3353</doc-id>
        <title>Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment</title>
        <author>
            <name>D. Ooms</name>
        </author>
        <author>
            <name>B. Sales</name>
        </author>
        <author>
            <name>W. Livens</name>
        </author>
        <author>
            <name>A. Acharya</name>
        </author>
        <author>
            <name>F. Griffoul</name>
        </author>
        <author>
            <name>F. Ansari</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>65860</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>inrternet protocol</kw>
            <kw>l2</kw>
            <kw>multicast routing protocoln</kw>
        </keywords>
        <draft>ietf-mpls-multicast-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3354</doc-id>
        <title>Internet Open Trading Protocol Version 2 Requirements</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9671</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>payment</kw>
            <kw>ecommerce</kw>
            <kw>merchant</kw>
            <kw>customer</kw>
            <kw>delivery</kw>
            <kw>signature</kw>
            <kw>messaging</kw>
            <kw>commerce</kw>
            <kw>sale</kw>
        </keywords>
        <draft>ietf-trade-iotp2-req-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3355</doc-id>
        <title>Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5)</title>
        <author>
            <name>A. Singh</name>
        </author>
        <author>
            <name>R. Turner</name>
        </author>
        <author>
            <name>R. Tio</name>
        </author>
        <author>
            <name>S. Nanji</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25114</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>link</kw>
            <kw>dial-up server</kw>
            <kw>asynchronous transfer mode</kw>
        </keywords>
        <draft>ietf-l2tpext-l2tp-atm-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3356</doc-id>
        <title>Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines</title>
        <author>
            <name>G. Fishman</name>
        </author>
        <author>
            <name>S. Bradner</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27149</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>society</kw>
            <kw>engineering</kw>
            <kw>task</kw>
            <kw>force</kw>
        </keywords>
        <draft>fishman-2436bis-02</draft>
        <obsoletes>
            <doc-id>RFC2436</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3357</doc-id>
        <title>One-way Loss Pattern Sample Metrics</title>
        <author>
            <name>R. Koodli</name>
        </author>
        <author>
            <name>R. Ravikanth</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30570</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>packets</kw>
            <kw>voice</kw>
            <kw>video</kw>
            <kw>stream</kw>
        </keywords>
        <draft>ietf-ippm-loss-pattern-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3358</doc-id>
        <title>Optional Checksums in Intermediate System to Intermediate System (ISIS)</title>
        <author>
            <name>R. Koodli</name>
        </author>
        <author>
            <name>R. Ravikanth</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8266</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>type</kw>
            <kw>length</kw>
            <kw>value</kw>
            <kw>complete sequence number</kw>
            <kw>partial data</kw>
        </keywords>
        <draft>ietf-isis-wg-snp-checksum-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3359</doc-id>
        <title>Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System</title>
        <author>
            <name>T. Przygienda</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7843</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>is-is</kw>
            <kw>igp</kw>
            <kw>osi</kw>
            <kw>complete sequence number</kw>
            <kw>partial data</kw>
        </keywords>
        <draft>ietf-isis-wg-tlv-codepoints-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3360</doc-id>
        <title>Inappropriate TCP Resets Considered Harmful</title>
        <author>
            <name>S. Floyd</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46748</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>transmission control protocol</kw>
            <kw>rst</kw>
            <kw>bit</kw>
            <kw>connection</kw>
        </keywords>
        <draft>floyd-tcp-reset-04</draft>
        <is-also>
            <doc-id>BCP0060</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3361</doc-id>
        <title>Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12549</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>proxy servers</kw>
        </keywords>
        <draft>ietf-sip-dhcp-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3362</doc-id>
        <title>Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration</title>
        <author>
            <name>G. Parsons</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8301</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
        </keywords>
        <draft>parsons-itu-t38-reg-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3363</doc-id>
        <title>Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)</title>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>A. Durand</name>
        </author>
        <author>
            <name>B. Fink</name>
        </author>
        <author>
            <name>O. Gudmundsson</name>
        </author>
        <author>
            <name>T. Hain</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11055</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>reverse mapping</kw>
            <kw>label binary</kw>
        </keywords>
        <draft>ietf-dnsext-ipv6-addresses-02</draft>
        <updates>
            <doc-id>RFC2673</doc-id>
            <doc-id>RFC2874</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3364</doc-id>
        <title>Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)</title>
        <author>
            <name>R. Austein</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26544</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>reverse mapping</kw>
            <kw>rrs</kw>
            <kw>resource records</kw>
        </keywords>
        <draft>ietf-dnsext-ipv6-dns-tradeoffs-02</draft>
        <updates>
            <doc-id>RFC2673</doc-id>
            <doc-id>RFC2874</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3365</doc-id>
        <title>Strong Security Requirements for Internet Engineering Task Force Standard Protocols</title>
        <author>
            <name>J. Schiller</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16411</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>ietf</kw>
        </keywords>
        <draft>ietf-saag-whyenc-00</draft>
        <is-also>
            <doc-id>BCP0061</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3366</doc-id>
        <title>Advice to link designers on link Automatic Repeat reQuest (ARQ)</title>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <author>
            <name>L. Wood</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>66097</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>tcp/ip</kw>
            <kw>subnetworks</kw>
        </keywords>
        <draft>ietf-pilc-link-arq-issues-04</draft>
        <is-also>
            <doc-id>BCP0062</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3367</doc-id>
        <title>Common Name Resolution Protocol (CNRP)</title>
        <author>
            <name>N. Popp</name>
        </author>
        <author>
            <name>M. Mealling</name>
        </author>
        <author>
            <name>M. Moseley</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>86889</char-count>
            <page-count>42</page-count>
        </format>
        <keywords>
            <kw>unique resource locators</kw>
            <kw>client applications</kw>
        </keywords>
        <draft>ietf-cnrp-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3368</doc-id>
        <title>The 'go' URI Scheme for the Common Name Resolution Protocol</title>
        <author>
            <name>M. Mealling</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12726</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>uniform resource identifier</kw>
        </keywords>
        <draft>ietf-cnrp-uri-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3369</doc-id>
        <title>Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>113975</char-count>
            <page-count>52</page-count>
        </format>
        <keywords>
            <kw>digitally sign</kw>
            <kw>authenticate</kw>
            <kw>encrypt</kw>
            <kw>arbitrary message content</kw>
        </keywords>
        <draft>ietf-smime-rfc2630bis-08</draft>
        <obsoletes>
            <doc-id>RFC2630</doc-id>
            <doc-id>RFC3211</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3852</doc-id>
        </obsoleted-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3370</doc-id>
        <title>Cryptographic Message Syntax (CMS) Algorithms</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51001</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>digitally sign</kw>
            <kw>authenticate</kw>
            <kw>encrypt</kw>
            <kw>arbitrary message content</kw>
        </keywords>
        <draft>ietf-smime-cmsalg-08</draft>
        <obsoletes>
            <doc-id>RFC2630</doc-id>
            <doc-id>RFC3211</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3371</doc-id>
        <title>Layer Two Tunneling Protocol "L2TP" Management Information Base</title>
        <author>
            <name>E. Caves</name>
        </author>
        <author>
            <name>P. Calhoun</name>
        </author>
        <author>
            <name>R. Wheeler</name>
        </author>
        <date>
            <month>August</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>139974</char-count>
            <page-count>70</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
        </keywords>
        <draft>ietf-l2tpext-l2tp-mib-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3372</doc-id>
        <title>Session Initiation Protocol for Telephones (SIP-T): Context and Architectures</title>
        <author>
            <name>A. Vemuri</name>
        </author>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49893</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>pstn</kw>
            <kw>public switch telephone network</kw>
        </keywords>
        <draft>ietf-sipping-sipt-04</draft>
        <is-also>
            <doc-id>BCP0063</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3373</doc-id>
        <title>Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies</title>
        <author>
            <name>D. Katz</name>
        </author>
        <author>
            <name>R. Saluja</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19522</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>links</kw>
            <kw>handshake</kw>
        </keywords>
        <draft>ietf-isis-3way-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3374</doc-id>
        <title>Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network</title>
        <author>
            <name>J. Kempf</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28245</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>aaa</kw>
            <kw>qos</kw>
            <kw>authentication authorization accounting</kw>
            <kw>quality of service</kw>
            <kw>header compression</kw>
        </keywords>
        <draft>ietf-seamoby-context-transfer-problem-stat-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3375</doc-id>
        <title>Generic Registry-Registrar Protocol Requirements</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46022</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>rrp</kw>
            <kw>client server</kw>
            <kw>domain names</kw>
        </keywords>
        <draft>ietf-provreg-grrp-reqs-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3376</doc-id>
        <title>Internet Group Management Protocol, Version 3</title>
        <author>
            <name>B. Cain</name>
        </author>
        <author>
            <name>S. Deering</name>
        </author>
        <author>
            <name>I. Kouvelas</name>
        </author>
        <author>
            <name>B. Fenner</name>
        </author>
        <author>
            <name>A. Thyagarajan</name>
        </author>
        <date>
            <month>October</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>119726</char-count>
            <page-count>53</page-count>
        </format>
        <keywords>
            <kw>IGMP</kw>
            <kw>IGMP</kw>
            <kw>multicast</kw>
            <kw>routing</kw>
            <kw>IP</kw>
            <kw>Internet Protocol</kw>
        </keywords>
        <draft>ietf-idmr-igmp-v3-11</draft>
        <obsoletes>
            <doc-id>RFC2236</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3377</doc-id>
        <title>Lightweight Directory Access Protocol (v3): Technical Specification</title>
        <author>
            <name>J. Hodges</name>
        </author>
        <author>
            <name>R. Morgan</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9981</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>ldap</kw>
            <kw>ldapv3</kw>
        </keywords>
        <draft>ietf-ldapbis-ldapv3-ts-01</draft>
        <updates>
            <doc-id>RFC2251</doc-id>
            <doc-id>RFC2252</doc-id>
            <doc-id>RFC2253</doc-id>
            <doc-id>RFC2254</doc-id>
            <doc-id>RFC2255</doc-id>
            <doc-id>RFC2256</doc-id>
            <doc-id>RFC2829</doc-id>
            <doc-id>RFC2830</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3378</doc-id>
        <title>EtherIP: Tunneling Ethernet Frames in IP Datagrams</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18803</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>internet protocol</kw>
            <kw>ip 97</kw>
        </keywords>
        <draft>housley-etherip-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3379</doc-id>
        <title>Delegated Path Validation and Delegated Path Discovery Protocol Requirements</title>
        <author>
            <name>D. Pinkas</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32455</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>dpv</kw>
            <kw>dpd</kw>
            <kw>public</kw>
            <kw>key</kw>
            <kw>certificates</kw>
        </keywords>
        <draft>ietf-pkix-dpv-dpd-req-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3380</doc-id>
        <title>Internet Printing Protocol (IPP): Job and Printer Set Operations</title>
        <author>
            <name>T. Hastings</name>
        </author>
        <author>
            <name>R. Herriot</name>
        </author>
        <author>
            <name>C. Kugler</name>
        </author>
        <author>
            <name>H. Lewis</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>132044</char-count>
            <page-count>59</page-count>
        </format>
        <keywords>
            <kw>IPP-E-T</kw>
            <kw>IPP</kw>
            <kw>application</kw>
            <kw>media-type</kw>
            <kw>media</kw>
            <kw>type</kw>
        </keywords>
        <draft>ietf-ipp-job-printer-set-ops-05</draft>
        <updates>
            <doc-id>RFC2910</doc-id>
            <doc-id>RFC2911</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3381</doc-id>
        <title>Internet Printing Protocol (IPP): Job Progress Attributes</title>
        <author>
            <name>T. Hastings</name>
        </author>
        <author>
            <name>H. Lewis</name>
        </author>
        <author>
            <name>R. Bergman</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36595</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>IPP-E-T</kw>
            <kw>IPP</kw>
            <kw>application</kw>
            <kw>media-type</kw>
            <kw>media</kw>
            <kw>type</kw>
        </keywords>
        <draft>ietf-ipp-job-prog-02</draft>
        <updates>
            <doc-id>RFC2910</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3382</doc-id>
        <title>Internet Printing Protocol (IPP): The 'collection' attribute syntax</title>
        <author>
            <name>R. deBry</name>
        </author>
        <author>
            <name>T. Hastings</name>
        </author>
        <author>
            <name>R. Herriot</name>
        </author>
        <author>
            <name>K. Ocke</name>
        </author>
        <author>
            <name>P. Zehler</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>78173</char-count>
            <page-count>38</page-count>
        </format>
        <keywords>
            <kw>IPP-E-T</kw>
            <kw>IPP</kw>
            <kw>application</kw>
            <kw>media-type</kw>
            <kw>media</kw>
            <kw>type</kw>
        </keywords>
        <draft>ietf-ipp-collection-05</draft>
        <updates>
            <doc-id>RFC2910</doc-id>
            <doc-id>RFC2911</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3383</doc-id>
        <title>Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45893</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>guidelines</kw>
            <kw>extensible values</kw>
        </keywords>
        <draft>ietf-ldapbis-iana-09</draft>
        <is-also>
            <doc-id>BCP0064</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3384</doc-id>
        <title>Lightweight Directory Access Protocol (version 3) Replication Requirements</title>
        <author>
            <name>E. Stokes</name>
        </author>
        <author>
            <name>R. Weiser</name>
        </author>
        <author>
            <name>R. Moats</name>
        </author>
        <author>
            <name>R. Huber</name>
        </author>
        <date>
            <month>October</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>66871</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>ldapv3</kw>
            <kw>data interoperability</kw>
            <kw>synchronization</kw>
            <kw>multi-master</kw>
        </keywords>
        <draft>ietf-ldup-replica-req-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3385</doc-id>
        <title>Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations</title>
        <author>
            <name>D. Sheinwald</name>
        </author>
        <author>
            <name>J. Satran</name>
        </author>
        <author>
            <name>P. Thaler</name>
        </author>
        <author>
            <name>V. Cavanna</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53450</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>error detection code</kw>
        </keywords>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3386</doc-id>
        <title>Network Hierarchy and Multilayer Survivability</title>
        <author>
            <name>W. Lai</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. McDysan</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>65345</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>service</kw>
            <kw>provider</kw>
            <kw>packet networks</kw>
            <kw>protection</kw>
            <kw>restoration</kw>
            <kw>recovery</kw>
        </keywords>
        <draft>ietf-tewg-restore-hierarchy-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3387</doc-id>
        <title>Considerations from the Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network</title>
        <author>
            <name>M. Eder</name>
        </author>
        <author>
            <name>H. Chaskar</name>
        </author>
        <author>
            <name>S. Nag</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52693</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>internet protocol</kw>
            <kw>packts</kw>
            <kw>fuel-service</kw>
        </keywords>
        <draft>irtf-smrg-ipsmf-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3388</doc-id>
        <title>Grouping of Media Lines in the Session Description Protocol (SDP)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>G. Eriksson</name>
        </author>
        <author>
            <name>J. Holler</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39365</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>formats</kw>
            <kw>attribute</kw>
            <kw>port</kw>
            <kw>host</kw>
            <kw>interfaces</kw>
            <kw>fid</kw>
            <kw>flow identification</kw>
            <kw>lip synchronization</kw>
            <kw>ls</kw>
        </keywords>
        <draft>ietf-mmusic-fid-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3389</doc-id>
        <title>Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)</title>
        <author>
            <name>R. Zopf</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17018</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>codecs</kw>
            <kw>audio</kw>
            <kw>multimedia</kw>
        </keywords>
        <draft>ietf-avt-rtp-cn-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3390</doc-id>
        <title>Increasing TCP's Initial Window</title>
        <author>
            <name>M. Allman</name>
        </author>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>C. Partridge</name>
        </author>
        <date>
            <month>October</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36177</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>transmission control protocol</kw>
        </keywords>
        <draft>ietf-tsvwg-initwin-04</draft>
        <obsoletes>
            <doc-id>RFC2414</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2581</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3391</doc-id>
        <title>The MIME Application/Vnd.pwg-multiplexed Content-Type</title>
        <author>
            <name>R. Herriot</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54739</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>multipurpose internet mail extensions</kw>
            <kw>media type</kw>
        </keywords>
        <draft>herriot-application-multiplexed-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3392</doc-id>
        <title>Capabilities Advertisement with BGP-4</title>
        <author>
            <name>R. Chandra</name>
        </author>
        <author>
            <name>J. Scudder</name>
        </author>
        <date>
            <month>November</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9885</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw> border</kw>
            <kw>gateway</kw>
            <kw>protocol</kw>
        </keywords>
        <draft>ietf-idr-rfc2842bis-02</draft>
        <obsoletes>
            <doc-id>RFC2842</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3393</doc-id>
        <title>IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)</title>
        <author>
            <name>C. Demichelis</name>
        </author>
        <author>
            <name>P. Chimento</name>
        </author>
        <date>
            <month>November</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47731</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw> internet protocol</kw>
            <kw>ipdv</kw>
        </keywords>
        <draft>ietf-ippm-ipdv-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3394</doc-id>
        <title>Advanced Encryption Standard (AES) Key Wrap Algorithm</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>73072</char-count>
            <page-count>41</page-count>
        </format>
        <keywords>
            <kw>security</kw>
        </keywords>
        <draft>ietf-smime-aes-keywrap-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3395</doc-id>
        <title>Remote Network Monitoring MIB Protocol Identifier Reference Extensions</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <author>
            <name>C. Bucci</name>
        </author>
        <author>
            <name>R. Dietz</name>
        </author>
        <author>
            <name>A. Warth</name>
        </author>
        <date>
            <month>September</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43862</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>RMON-MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <draft>ietf-rmonmib-appverbs-04</draft>
        <updates>
            <doc-id>RFC2895</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3396</doc-id>
        <title>Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)</title>
        <author>
            <name>T. Lemon</name>
        </author>
        <author>
            <name>S. Cheshire</name>
        </author>
        <date>
            <month>November</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18779</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>octet</kw>
            <kw>packet</kw>
            <kw>code</kw>
        </keywords>
        <draft>ietf-dhc-concat-05</draft>
        <updates>
            <doc-id>RFC2131</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3397</doc-id>
        <title>Dynamic Host Configuration Protocol (DHCP) Domain Search Option</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>S. Cheshire</name>
        </author>
        <date>
            <month>November</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15446</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>dns</kw>
            <kw>client</kw>
            <kw>client server</kw>
        </keywords>
        <draft>aboba-dhc-domsearch-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3398</doc-id>
        <title>Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>A. B. Roach</name>
        </author>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>L. Ong</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>166197</char-count>
            <page-count>68</page-count>
        </format>
        <keywords>
            <kw>signaling system no. 7</kw>
            <kw>ss7</kw>
            <kw>pstn</kw>
            <kw>public switched telephone network</kw>
        </keywords>
        <draft>ietf-sipping-isup-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC3400</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC3401</doc-id>
        <title>Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS</title>
        <author>
            <name>M. Mealling</name>
        </author>
        <date>
            <month>October</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10172</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>NAPTR</kw>
            <kw>domain name system</kw>
            <kw>RR</kw>
        </keywords>
        <abstract>This document specifies the exact documents that make up the complete Dynamic Delegation Discovery System (DDDS). DDDS is an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string. This document along with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC 2168 and RFC 2915, as well as updates RFC 2276. This memo provides information for the Internet community. </abstract>
        <draft>ietf-urn-ddds-toc-03</draft>
        <obsoletes>
            <doc-id>RFC2915</doc-id>
            <doc-id>RFC2168</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2276</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3402</doc-id>
        <title>Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm</title>
        <author>
            <name>M. Mealling</name>
        </author>
        <date>
            <month>October</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38925</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>NAPTR</kw>
            <kw>domain name system</kw>
            <kw>RR</kw>
        </keywords>
        <abstract>This document describes the Dynamic Delegation Discovery System (DDDS) algorithm for applying dynamically retrieved string transformation rules to an application-unique string. Well-formed transformation rules will reflect the delegation of management of information associated with the string. This document is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS TRACK] </abstract>
        <draft>ietf-urn-ddds-07</draft>
        <obsoletes>
            <doc-id>RFC2915</doc-id>
            <doc-id>RFC2168</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3403</doc-id>
        <title>Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database</title>
        <author>
            <name>M. Mealling</name>
        </author>
        <date>
            <month>October</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31058</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>NAPTR</kw>
            <kw>domain name system</kw>
            <kw>RR</kw>
        </keywords>
        <abstract>This document describes a Dynamic Delegation Discovery System (DDDS) Database using the Domain Name System (DNS) as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR). Since this document obsoletes RFC 2915, it is the official specification for the NAPTR DNS Resource Record. It is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS TRACK] </abstract>
        <draft>ietf-urn-dns-ddds-database-09</draft>
        <obsoletes>
            <doc-id>RFC2915</doc-id>
            <doc-id>RFC2168</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3404</doc-id>
        <title>Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)</title>
        <author>
            <name>M. Mealling</name>
        </author>
        <date>
            <month>October</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40124</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>NAPTR</kw>
            <kw>domain name system</kw>
            <kw>RR</kw>
        </keywords>
        <abstract>This document describes a specification for taking Uniform Resource Identifiers (URI) and locating an authoritative server for information about that URI. The method used to locate that authoritative server is the Dynamic Delegation Discovery System. This document is part of a series that is specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS TRACK] </abstract>
        <draft>ietf-urn-uri-res-ddds-07</draft>
        <obsoletes>
            <doc-id>RFC2915</doc-id>
            <doc-id>RFC2168</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3405</doc-id>
        <title>Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures</title>
        <author>
            <name>M. Mealling</name>
        </author>
        <date>
            <month>October</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19469</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>uniform resource identifiers</kw>
        </keywords>
        <abstract>This document is fifth in a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-urn-net-procedures-11</draft>
        <is-also>
            <doc-id>BCP0065</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3406</doc-id>
        <title>Uniform Resource Names (URN) Namespace Definition Mechanisms</title>
        <author>
            <name>L. Daigle</name>
        </author>
        <author>
            <name>D. van Gulik</name>
        </author>
        <author>
            <name>R. Iannella</name>
        </author>
        <author>
            <name>P. Faltstrom</name>
        </author>
        <date>
            <month>October</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43707</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>namespaces</kw>
            <kw>applications</kw>
            <kw>structure</kw>
        </keywords>
        <abstract>This document lays out general definitions of and mechanisms for establishing Uniform Resource Names (URN) "namespaces". The URN WG has defined a syntax for URNs in RFC 2141, as well as some proposed mechanisms for their resolution and use in Internet applications in RFC 3401 and RFC 3405. The whole rests on the concept of individual "namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed in RFC 2288. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-urn-rfc2611bis-04</draft>
        <obsoletes>
            <doc-id>RFC2611</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0066</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3407</doc-id>
        <title>Session Description Protocol (SDP) Simple Capability Declaration</title>
        <author>
            <name>F. Andreasen</name>
        </author>
        <date>
            <month>October</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21133</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>SDPng</kw>
        </keywords>
        <abstract>This document defines a set of Session Description Protocol (SDP) attributes that enables SDP to provide a minimal and backwards compatible capability declaration mechanism. Such capability declarations can be used as input to a subsequent session negotiation, which is done by means outside the scope of this document. This provides a simple and limited solution to the general capability negotiation problem being addressed by the next generation of SDP, also known as SDPng. [STANDARDS TRACK] </abstract>
        <draft>andreasen-mmusic-sdp-simcap-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3408</doc-id>
        <title>Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile</title>
        <author>
            <name>Z. Liu</name>
        </author>
        <author>
            <name>K. Le</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14805</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>single-octet</kw>
            <kw>packet size</kw>
        </keywords>
        <abstract>This document defines an additional mode of the link-layer assisted RObust Header Compression (ROHC) profile, also known as the zero-byte profile, beyond the two defined in RFC 3242. Zero-byte header compression exists in order to prevent the single-octet ROHC header from pushing a packet voice stream into the next higher fixed packet size for the radio. It is usable in certain widely deployed older air interfaces. This document adds the zero-byte operation for ROHC Bidirectional Reliable mode (R-mode) to the ones specified for Unidirectional (U-mode) and Bidirectional Optimistic (O-mode) modes of header compression in RFC 3242. [STANDARDS TRACK] </abstract>
        <draft>ietf-rohc-rtp-lla-r-mode-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3409</doc-id>
        <title>Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression</title>
        <author>
            <name>K. Svanbro</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25815</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>rohc</kw>
            <kw>algorithms</kw>
        </keywords>
        <abstract>This document describes lower layer guidelines for robust header compression (ROHC) and the requirements ROHC puts on lower layers. The purpose of this document is to support the incorporation of robust header compression algorithms, as specified in the ROHC working group, into different systems such as those specified by Third Generation Partnership Project (3GPP), 3GPP Project 2 (3GPP2), European Technical Standards Institute (ETSI), etc. This document covers only lower layer guidelines for compression of RTP/UDP/IP and UDP/IP headers as specified in [RFC3095]. Both general guidelines and guidelines specific for cellular systems are discussed in this document. This memo provides information for the Internet community. </abstract>
        <draft>ietf-rohc-rtp-lower-layer-guidelines-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3410</doc-id>
        <title>Introduction and Applicability Statements for Internet-Standard Management Framework</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>R. Mundy</name>
        </author>
        <author>
            <name>D. Partain</name>
        </author>
        <author>
            <name>B. Stewart</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>61461</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>snmp</kw>
            <kw>simple</kw>
            <kw>protocol</kw>
            <kw>snmpv3</kw>
        </keywords>
        <abstract>The purpose of this document is to provide an overview of the third version of the Internet-Standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-Standard Management Framework (SNMPv1) and the second Internet-Standard Management Framework (SNMPv2). The architecture is designed to be modular to allow the evolution of the Framework over time. The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended. The document also recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be retired by moving them to Historic status. This document obsoletes RFC 2570. This memo provides information for the Internet community. </abstract>
        <draft>ietf-snmpv3-rfc2570bis-03</draft>
        <obsoletes>
            <doc-id>RFC2570</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3411</doc-id>
        <title>An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks</title>
        <author>
            <name>D. Harrington</name>
        </author>
        <author>
            <name>R. Presuhn</name>
        </author>
        <author>
            <name>B. Wijnen</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>140096</char-count>
            <page-count>64</page-count>
        </format>
        <keywords>
            <kw>ARCH-SNMP</kw>
            <kw>simple</kw>
            <kw>protocol</kw>
            <kw>network</kw>
            <kw>management</kw>
        </keywords>
        <abstract>This document describes an architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. This document obsoletes RFC 2571. [STANDARDS TRACK] </abstract>
        <draft>ietf-snmpv3-arch-v2-02</draft>
        <obsoletes>
            <doc-id>RFC2571</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0062</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3412</doc-id>
        <title>Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)</title>
        <author>
            <name>J. Case</name>
        </author>
        <author>
            <name>D. Harrington</name>
        </author>
        <author>
            <name>R. Presuhn</name>
        </author>
        <author>
            <name>B. Wijnen</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>95710</char-count>
            <page-count>43</page-count>
        </format>
        <keywords>
            <kw>MPD-SNMP</kw>
            <kw>processing</kw>
            <kw>models</kw>
            <kw>multiple</kw>
        </keywords>
        <abstract>This document describes the Message Processing and Dispatching for Simple Network Management Protocol (SNMP) messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. This document obsoletes RFC 2572. [STANDARDS TRACK] </abstract>
        <draft>ietf-snmpv3-mpd-v2-02</draft>
        <obsoletes>
            <doc-id>RFC2572</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0062</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3413</doc-id>
        <title>Simple Network Management Protocol (SNMP) Applications</title>
        <author>
            <name>D. Levi</name>
        </author>
        <author>
            <name>P. Meyer</name>
        </author>
        <author>
            <name>B. Stewart</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>153719</char-count>
            <page-count>74</page-count>
        </format>
        <keywords>
            <kw>SNMP-APP</kw>
            <kw>simple</kw>
            <kw>network</kw>
            <kw>management</kw>
            <kw>protocol</kw>
            <kw>proxy</kw>
            <kw>operations</kw>
            <kw>command</kw>
        </keywords>
        <abstract>This document describes five types of Simple Network Management Protocol (SNMP) applications which make use of an SNMP engine as described in STD 62, RFC 3411. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This document also defines Management Information Base (MIB) modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. This document obsoletes RFC 2573. [STANDARDS TRACK] </abstract>
        <draft>ietf-snmpv3-appl-v3-01</draft>
        <obsoletes>
            <doc-id>RFC2573</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0062</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3414</doc-id>
        <title>User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)</title>
        <author>
            <name>U. Blumenthal</name>
        </author>
        <author>
            <name>B. Wijnen</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>193558</char-count>
            <page-count>88</page-count>
        </format>
        <keywords>
            <kw>USM-SNMPV3</kw>
            <kw>message</kw>
            <kw>level</kw>
            <kw>mib</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This document describes the User-based Security Model (USM) for Simple Network Management Protocol (SNMP) version 3 for use in the SNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a Management Information Base (MIB) for remotely monitoring/managing the configuration parameters for this Security Model. This document obsoletes RFC 2574. [STANDARDS TRACK] </abstract>
        <draft>ietf-snmpv3-usm-v2-rfc2574bis-01</draft>
        <obsoletes>
            <doc-id>RFC2574</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0062</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3415</doc-id>
        <title>View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)</title>
        <author>
            <name>B. Wijnen</name>
        </author>
        <author>
            <name>R. Presuhn</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>82046</char-count>
            <page-count>39</page-count>
        </format>
        <keywords>
            <kw>VACM-SNMP</kw>
            <kw>mib</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This document describes the View-based Access Control Model (VACM) for use in the Simple Network Management Protocol (SNMP) architecture. It defines the Elements of Procedure for controlling access to management information. This document also includes a Management Information Base (MIB) for remotely managing the configuration parameters for the View- based Access Control Model. This document obsoletes RFC 2575. [STANDARDS TRACK] </abstract>
        <draft>ietf-snmpv3-vacm-v2-01</draft>
        <obsoletes>
            <doc-id>RFC2575</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0062</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3416</doc-id>
        <title>Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)</title>
        <author>
            <name>R. Presuhn</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>70043</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>OPS-MIB</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version 2</kw>
        </keywords>
        <abstract>This document defines version 2 of the protocol operations for the Simple Network Management Protocol (SNMP). It defines the syntax and elements of procedure for sending, receiving, and processing SNMP PDUs. This document obsoletes RFC 1905. [STANDARDS TRACK] </abstract>
        <draft>ietf-snmpv3-update-proto-08</draft>
        <obsoletes>
            <doc-id>RFC1905</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0062</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3417</doc-id>
        <title>Transport Mappings for the Simple Network Management Protocol (SNMP)</title>
        <author>
            <name>R. Presuhn</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38650</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>TRANS-MIB</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version</kw>
            <kw>2</kw>
        </keywords>
        <abstract>This document defines the transport of Simple Network Management Protocol (SNMP) messages over various protocols. This document obsoletes RFC 1906. [STANDARDS TRACK] </abstract>
        <draft>ietf-snmpv3-update-transmap-08</draft>
        <obsoletes>
            <doc-id>RFC1906</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0062</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3418</doc-id>
        <title>Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)</title>
        <author>
            <name>R. Presuhn</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49096</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>SNMPv2-MIB</kw>
            <kw>Simple</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>Protocol</kw>
            <kw>Version</kw>
            <kw>2</kw>
        </keywords>
        <abstract>This document defines managed objects which describe the behavior of a Simple Network Management Protocol (SNMP) entity. This document obsoletes RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). [STANDARDS TRACK] </abstract>
        <draft>ietf-snmpv3-update-mib-07</draft>
        <obsoletes>
            <doc-id>RFC1907</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0062</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3419</doc-id>
        <title>Textual Conventions for Transport Addresses</title>
        <author>
            <name>M. Daniele</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37466</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract>This document introduces a Management Information Base (MIB) module that defines textual conventions to represent commonly used transport-layer addressing information. The definitions are compatible with the concept of TAddress/TDomain pairs introduced by the Structure of Management Information version 2 (SMIv2) and support the Internet transport protocols over IPv4 and IPv6. [STANDARDS TRACK] </abstract>
        <draft>ietf-ops-taddress-mib-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3420</doc-id>
        <title>Internet Media Type message/sipfrag</title>
        <author>
            <name>R. Sparks</name>
        </author>
        <date>
            <month>November</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14745</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>mime</kw>
            <kw>multipurpose internet mail extesions</kw>
        </keywords>
        <abstract>This document registers the message/sipfrag Multipurpose Internet Mail Extensions (MIME) media type. This type is similar to message/sip, but allows certain subsets of well formed Session Initiation Protocol (SIP) messages to be represented instead of requiring a complete SIP message. In addition to end-to-end security uses, message/sipfrag is used with the REFER method to convey information about the status of a referenced request. [STANDARDS TRACK] </abstract>
        <draft>ietf-sip-sipfrag-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3421</doc-id>
        <title>Select and Sort Extensions for the Service Location Protocol (SLP)</title>
        <author>
            <name>W. Zhao</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>E. Guttman</name>
        </author>
        <author>
            <name>C. Bisdikian</name>
        </author>
        <author>
            <name>W. Jerome</name>
        </author>
        <date>
            <month>November</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15260</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>user agent</kw>
            <kw>url</kw>
            <kw>service reply</kw>
            <kw>ua</kw>
            <kw>svrrply</kw>
        </keywords>
        <abstract>This document defines two extensions (Select and Sort) for the Service Location Protocol (SLP). These extensions allow a User Agent (UA) to request that the Uniform Resource Locator (URL) entries in a Service Reply (SrvRply) be limited to the specified number, or be sorted according to the specified sort key list. Using these two extensions together can facilitate discovering the best match, such as finding a service that has the maximum speed or the minimum load. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>zhao-slp-customization-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3422</doc-id>
        <title>Forwarding Media Access Control (MAC) Frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS)</title>
        <author>
            <name>O. Okamoto</name>
        </author>
        <author>
            <name>M. Maruyama</name>
        </author>
        <author>
            <name>T. Sajima</name>
        </author>
        <date>
            <month>November</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37576</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>tunneling</kw>
            <kw>ethernet frames</kw>
        </keywords>
        <abstract>This memo describes a method for forwarding media access control (MAC) frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS), thus providing a way to unify MAPOS network environment and MAC-based Local Area Network (LAN) environment. This memo provides information for the Internet community. </abstract>
        <draft>okamoto-mac-over-mapos-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3423</doc-id>
        <title>XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0</title>
        <author>
            <name>K. Zhang</name>
        </author>
        <author>
            <name>E. Elkin</name>
        </author>
        <date>
            <month>November</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>97731</char-count>
            <page-count>45</page-count>
        </format>
        <keywords>
            <kw>data</kw>
            <kw>delivery</kw>
            <kw>message</kw>
            <kw>format</kw>
            <kw>template-based</kw>
            <kw>client/server</kw>
        </keywords>
        <abstract>This document defines the Common Reliable Accounting for Network Element (CRANE) protocol that enables efficient and reliable delivery of any data, mainly accounting data from Network Elements to any systems, such as mediation systems and Business Support Systems (BSS)/ Operations Support Systems (OSS). The protocol is developed to address the critical needs for exporting high volume of accounting data from NE's with efficient use of network, storage, and processing resources. This document specifies the architecture of the protocol and the message format, which MUST be supported by all CRANE protocol implementations. This memo provides information for the Internet community. </abstract>
        <draft>kzhang-crane-protocol-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3424</doc-id>
        <title>IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation</title>
        <author>
            <name>L. Daigle</name>
            <title>Editor</title>
        </author>
        <author>
            <name>IAB</name>
        </author>
        <date>
            <month>November</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18165</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>nat</kw>
            <kw>middleboxes</kw>
        </keywords>
        <abstract>As a result of the nature of Network Address Translation (NAT) Middleboxes, communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers. Various proposals have been made for "UNilateral Self-Address Fixing (UNSAF)" processes. These are processes whereby some originating endpoint attempts to determine or fix the address (and port) by which it is known to another endpoint - e.g., to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections. This document outlines the reasons for which these proposals can be considered at best as short term fixes to specific problems and the specific issues to be carefully evaluated before creating an UNSAF proposal. This memo provides information for the Internet community. </abstract>
        <draft>iab-unsaf-considerations-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3425</doc-id>
        <title>Obsoleting IQUERY</title>
        <author>
            <name>D. Lawrence</name>
        </author>
        <date>
            <month>November</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8615</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>dns lookups</kw>
            <kw>domain</kw>
        </keywords>
        <abstract>The IQUERY method of performing inverse DNS lookups, specified in RFC 1035, has not been generally implemented and has usually been operationally disabled where it has been implemented. Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using pointer (PTR) queries and reverse-mapping records is preferable. Consequently, this document deprecates the IQUERY operation, declaring it entirely obsolete. This document updates RFC 1035. [STANDARDS TRACK] </abstract>
        <draft>ietf-dnsext-obsolete-iquery-04</draft>
        <updates>
            <doc-id>RFC1035</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3426</doc-id>
        <title>General Architectural and Policy Considerations</title>
        <author>
            <name>S. Floyd</name>
        </author>
        <date>
            <month>November</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54868</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>internet architecture</kw>
        </keywords>
        <abstract>This document suggests general architectural and policy questions that the IETF community has to address when working on new standards and protocols. We note that this document contains questions to be addressed, as opposed to guidelines or architectural principles to be followed. This memo provides information for the Internet community. </abstract>
        <draft>iab-considerations-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3427</doc-id>
        <title>Change Process for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>A. Mankin</name>
        </author>
        <author>
            <name>S. Bradner</name>
        </author>
        <author>
            <name>R. Mahy</name>
        </author>
        <author>
            <name>D. Willis</name>
        </author>
        <author>
            <name>J. Ott</name>
        </author>
        <author>
            <name>B. Rosen</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26234</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>sipping</kw>
        </keywords>
        <abstract>This memo documents a process intended to apply architectural discipline to the future development of the Session Initiation Protocol (SIP). There have been concerns with regards to new SIP proposals. Specifically, that the addition of new SIP features can be damaging towards security and/or greatly increase the complexity of the protocol. The Transport Area directors, along with the SIP and Session Initiation Proposal Investigation (SIPPING) working group chairs, have provided suggestions for SIP modifications and extensions. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>tsvarea-sipchange-03</draft>
        <updated-by>
            <doc-id>RFC3968</doc-id>
            <doc-id>RFC3969</doc-id>
        </updated-by>
        <is-also>
            <doc-id>BCP0067</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3428</doc-id>
        <title>Session Initiation Protocol (SIP) Extension for Instant Messaging</title>
        <author>
            <name>B. Campbell</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>C. Huitema</name>
        </author>
        <author>
            <name>D. Gurle</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41475</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>im</kw>
            <kw>message method</kw>
        </keywords>
        <abstract>Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. This document proposes the MESSAGE method, an extension to the Session Initiation Protocol (SIP) that allows the transfer of Instant Messages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. [STANDARDS TRACK] </abstract>
        <draft>ietf-sip-message-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3429</doc-id>
        <title>Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions</title>
        <author>
            <name>H. Ohta</name>
        </author>
        <date>
            <month>November</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10903</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>reserved lavel values</kw>
        </keywords>
        <abstract>This document describes the assignment of one of the reserved label values defined in RFC 3032 (MPLS label stack encoding) to the 'Operation and Maintenance (OAM) Alert Label' that is used by user-plane Multiprotocol Label Switching Architecture (MPLS) OAM functions for identification of MPLS OAM packets. This memo provides information for the Internet community. </abstract>
        <draft>ohta-mpls-label-value-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3430</doc-id>
        <title>Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping</title>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21527</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>snmp</kw>
            <kw>tcp</kw>
        </keywords>
        <abstract>This memo defines a transport mapping for using the Simple Network Management Protocol (SNMP) over TCP. The transport mapping can be used with any version of SNMP. This document extends the transport mappings defined in STD 62, RFC 3417. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>irtf-nmrg-snmp-tcp-09</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3431</doc-id>
        <title>Sieve Extension: Relational Tests</title>
        <author>
            <name>W. Segmuller</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12849</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>sieve mail</kw>
            <kw>filtering language</kw>
        </keywords>
        <abstract>This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators. In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields. [STANDARDS TRACK] </abstract>
        <draft>segmuller-sieve-relation-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3432</doc-id>
        <title>Network performance measurement with periodic streams</title>
        <author>
            <name>V. Raisanen</name>
        </author>
        <author>
            <name>G. Grotefeld</name>
        </author>
        <author>
            <name>A. Morton</name>
        </author>
        <date>
            <month>November</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52493</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>cbr</kw>
            <kw>constant bit rate</kw>
            <kw>periodic sampling</kw>
            <kw>poisson sampling</kw>
        </keywords>
        <abstract>This memo describes a periodic sampling method and relevant metrics for assessing the performance of IP networks. First, the memo motivates periodic sampling and addresses the question of its value as an alternative to the Poisson sampling described in RFC 2330. The benefits include applicability to active and passive measurements, simulation of constant bit rate (CBR) traffic (typical of multimedia communication, or nearly CBR, as found with voice activity detection), and several instances in which analysis can be simplified. The sampling method avoids predictability by mandating random start times and finite length tests. Following descriptions of the sampling method and sample metric parameters, measurement methods and errors are discussed. Finally, we give additional information on periodic measurements, including security considerations. [STANDARDS TRACK] </abstract>
        <draft>ietf-ippm-npmps-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3433</doc-id>
        <title>Entity Sensor Management Information Base</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <author>
            <name>K.C. Norseth</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31857</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>physical sensors</kw>
            <kw>snmp</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for extending the Entity MIB (RFC 2737) to provide generalized access to information related to physical sensors, which are often found in networking equipment (such as chassis temperature, fan RPM, power supply voltage). [STANDARDS TRACK] </abstract>
        <draft>ietf-entmib-sensor-mib-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3434</doc-id>
        <title>Remote Monitoring MIB Extensions for High Capacity Alarms</title>
        <author>
            <name>A. Bierman</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51072</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>rmon</kw>
            <kw>counter64</kw>
            <kw>smiv2</kw>
            <kw>snmp</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for extending the alarm thresholding capabilities found in the Remote Monitoring (RMON) MIB (RFC 2819), to provide similar threshold monitoring of objects based on the Counter64 data type. [STANDARDS TRACK] </abstract>
        <draft>ietf-rmonmib-hc-alarm-mib-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3435</doc-id>
        <title>Media Gateway Control Protocol (MGCP) Version 1.0</title>
        <author>
            <name>F. Andreasen</name>
        </author>
        <author>
            <name>B. Foster</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>467084</char-count>
            <page-count>210</page-count>
        </format>
        <keywords>
            <kw>voice</kw>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>VoIP</kw>
        </keywords>
        <abstract>This document describes an application programming interface and a corresponding protocol (MGCP) which is used between elements of a decomposed multimedia gateway. The decomposed multimedia gateway consists of a Call Agent, which contains the call control "intelligence", and a media gateway which contains the media functions, e.g., conversion from TDM voice to Voice over IP. Media gateways contain endpoints on which the Call Agent can create, modify and delete connections in order to establish and control media sessions with other multimedia endpoints. Also, the Call Agent can instruct the endpoints to detect certain events and generate signals. The endpoints automatically communicate changes in service state to the Call Agent. Furthermore, the Call Agent can audit endpoints as well as the connections on endpoints. The basic and general MGCP protocol is defined in this document, however most media gateways will need to implement one or more MGCP packages, which define extensions to the protocol suitable for use with specific types of media gateways. Such packages are defined in separate documents. This memo provides information for the Internet community. </abstract>
        <draft>andreasen-mgcp-rfc2705bis-05</draft>
        <obsoletes>
            <doc-id>RFC2705</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3661</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3436</doc-id>
        <title>Transport Layer Security over Stream Control Transmission Protocol</title>
        <author>
            <name>A. Jungmaier</name>
        </author>
        <author>
            <name>E. Rescorla</name>
        </author>
        <author>
            <name>M. Tuexen</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16333</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>sctp</kw>
            <kw>tls</kw>
        </keywords>
        <abstract>This document describes the usage of the Transport Layer Security (TLS) protocol, as defined in RFC 2246, over the Stream Control Transmission Protocol (SCTP), as defined in RFC 2960 and RFC 3309. The user of TLS can take advantage of the features provided by SCTP, namely the support of multiple streams to avoid head of line blocking and the support of multi-homing to provide network level fault tolerance. Additionally, discussions of extensions of SCTP are also supported, meaning especially the support of dynamic reconfiguration of IP- addresses. [STANDARDS TRACK] </abstract>
        <draft>ietf-tsvwg-tls-over-sctp-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3437</doc-id>
        <title>Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation</title>
        <author>
            <name>W. Palter</name>
        </author>
        <author>
            <name>W. Townsley</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20820</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>l2tp</kw>
            <kw>lcp</kw>
        </keywords>
        <abstract>This document defines extensions to the Layer Two Tunneling Protocol (L2TP) for enhanced support of link-specific Point to Point Protocol (PPP) options. PPP endpoints typically have direct access to the common physical media connecting them and thus have detailed knowledge about the media that is in use. When the L2TP is used, the two PPP peers are no longer directly connected over the same physical media. Instead, L2TP inserts a virtual connection over some or all of the PPP connection by tunneling PPP frames over a packet switched network such as IP. Under some conditions, an L2TP endpoint may need to negotiate PPP Link Control Protocol (LCP) options at a location which may not have access to all of the media information necessary for proper participation in the LCP negotiation. This document provides a mechanism for communicating desired LCP options between L2TP endpoints in advance of PPP LCP negotiation at the far end of an L2TP tunnel, as well as a mechanism for communicating the negotiated LCP options back to where the native PPP link resides. [STANDARDS TRACK] </abstract>
        <draft>ietf-l2tpext-link-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3438</doc-id>
        <title>Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update</title>
        <author>
            <name>W. Townsley</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9135</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>L2TP</kw>
            <kw>ppp</kw>
            <kw>point-to-point</kw>
            <kw>protocol</kw>
            <kw>packets</kw>
        </keywords>
        <abstract>This document describes updates to the Internet Assigned Numbers Authority (IANA) considerations for the Layer Two Tunneling Protocol (L2TP). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-l2tpext-rfc2661-iana-01</draft>
        <is-also>
            <doc-id>BCP0068</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3439</doc-id>
        <title>Some Internet Architectural Guidelines and Philosophy</title>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>70333</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>IAB</kw>
        </keywords>
        <abstract>This document extends RFC 1958 by outlining some of the philosophical guidelines to which architects and designers of Internet backbone networks should adhere. We describe the Simplicity Principle, which states that complexity is the primary mechanism that impedes efficient scaling, and discuss its implications on the architecture, design and engineering issues found in large scale Internet backbones. This memo provides information for the Internet community. </abstract>
        <draft>ymbk-arch-guidelines-03</draft>
        <updates>
            <doc-id>RFC1958</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3440</doc-id>
        <title>Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines</title>
        <author>
            <name>F. Ly</name>
        </author>
        <author>
            <name>G. Bathrick</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>76058</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>simple network management protocol</kw>
            <kw>mib</kw>
            <kw>adsl</kw>
            <kw>asymmetric digital subscriber line</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes additional managed objects used for managing Asymmetric Digital Subscriber Line (ADSL) interfaces not covered by the ADSL Line MIB (RFC 2662). [STANDARDS TRACK] </abstract>
        <draft>ietf-adslmib-adslext-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3441</doc-id>
        <title>Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP)</title>
        <author>
            <name>R. Kumar</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>122455</char-count>
            <page-count>50</page-count>
        </format>
        <keywords>
            <kw>connection</kw>
            <kw>codec profile</kw>
        </keywords>
        <abstract>This document describes an Asynchronous Transfer Mode (ATM) package for the Media Gateway Control Protocol (MGCP). This package includes new Local Connection Options, ATM-specific events and signals, and ATM connection parameters. Also included is a description of codec and profile negotiation. It extends the MGCP that is currently being deployed in a number of products. Implementers should be aware of developments in the IETF Megaco Working Group and ITU SG16, which are currently working on a potential successor to this protocol. This memo provides information for the Internet community. </abstract>
        <draft>rajeshkumar-mgcp-atm-package-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3442</doc-id>
        <title>The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4</title>
        <author>
            <name>T. Lemon</name>
        </author>
        <author>
            <name>S. Cheshire</name>
        </author>
        <author>
            <name>B. Volz</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19370</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>Dynamic</kw>
            <kw>Host</kw>
            <kw>Configuration</kw>
            <kw>Protocol</kw>
            <kw>Bootstrap</kw>
        </keywords>
        <abstract>This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. The network destinations in these routes are classless - each routing table entry includes a subnet mask. [STANDARDS TRACK] </abstract>
        <draft>ietf-dhc-csr-07</draft>
        <updates>
            <doc-id>RFC2132</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3443</doc-id>
        <title>Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks</title>
        <author>
            <name>P. Agarwal</name>
        </author>
        <author>
            <name>B. Akyol</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18749</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>label stack encoding</kw>
            <kw>uniform model</kw>
            <kw>pipe model</kw>
        </keywords>
        <abstract>This document describes Time To Live (TTL) processing in hierarchical Multi-Protocol Label Switching (MPLS) networks and is motivated by the need to formalize a TTL-transparent mode of operation for an MPLS label-switched path. It updates RFC 3032, "MPLS Label Stack Encoding". TTL processing in both Pipe and Uniform Model hierarchical tunnels are specified with examples for both "push" and "pop" cases. The document also complements RFC 3270, "MPLS Support of Differentiated Services" and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks. [STANDARDS TRACK] </abstract>
        <draft>ietf-mpls-ttl-04</draft>
        <updates>
            <doc-id>RFC3032</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3444</doc-id>
        <title>On the Difference between Information Models and Data Models</title>
        <author>
            <name>A. Pras</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18596</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>network management</kw>
        </keywords>
        <abstract>There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models. This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin. This memo provides information for the Internet community. </abstract>
        <draft>irtf-nmrg-im-dm-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3445</doc-id>
        <title>Limiting the Scope of the KEY Resource Record (RR)</title>
        <author>
            <name>D. Massey</name>
        </author>
        <author>
            <name>S. Rose</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20947</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>DNS-SECEXT</kw>
            <kw>dns</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This document limits the Domain Name System (DNS) KEY Resource Record (RR) to only keys used by the Domain Name System Security Extensions (DNSSEC). The original KEY RR used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys with the same record type is a mistake. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY RR Data. As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are redefined. Three existing application key sub-types are changed to reserved, but the format of the KEY record is not changed. This document updates RFC 2535. [STANDARDS TRACK] </abstract>
        <draft>ietf-dnsext-restrict-key-for-dnssec-04</draft>
        <obsoleted-by>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4035</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2535</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3446</doc-id>
        <title>Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)</title>
        <author>
            <name>D. Kim</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <author>
            <name>H. Kilmer</name>
        </author>
        <author>
            <name>D. Farinacci</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14792</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>sparse mode</kw>
            <kw>single shared-tree</kw>
        </keywords>
        <abstract>This document describes a mechanism to allow for an arbitrary number of Rendevous Points (RPs) per group in a single shared-tree Protocol Independent Multicast-Sparse Mode (PIM-SM) domain. This memo provides information for the Internet community. </abstract>
        <draft>ietf-mboned-anycast-rp-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3447</doc-id>
        <title>Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1</title>
        <author>
            <name>J. Jonsson</name>
        </author>
        <author>
            <name>B. Kaliski</name>
        </author>
        <date>
            <month>February</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>143173</char-count>
            <page-count>72</page-count>
        </format>
        <keywords>
            <kw>data</kw>
            <kw>public</kw>
            <kw>key</kw>
            <kw>cryptosystem</kw>
        </keywords>
        <abstract>This memo represents a republication of PKCS #1 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process. This memo provides information for the Internet community. </abstract>
        <draft>jonsson-pkcs1-v2dot1-00</draft>
        <obsoletes>
            <doc-id>RFC2437</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3448</doc-id>
        <title>TCP Friendly Rate Control (TFRC): Protocol Specification</title>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>J. Padhye</name>
        </author>
        <author>
            <name>J. Widmer</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52657</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>congestion</kw>
            <kw>unicast</kw>
            <kw>streaming media</kw>
        </keywords>
        <abstract>This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance. [STANDARDS TRACK] </abstract>
        <draft>ietf-tsvwg-tfrc-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3449</doc-id>
        <title>TCP Performance Implications of Network Path Asymmetry</title>
        <author>
            <name>H. Balakrishnan</name>
        </author>
        <author>
            <name>V. Padmanabhan</name>
        </author>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <author>
            <name>M. Sooriyabandara</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>108839</char-count>
            <page-count>41</page-count>
        </format>
        <keywords>
            <kw>links</kw>
            <kw>sender</kw>
            <kw>receiver</kw>
            <kw>ack</kw>
        </keywords>
        <abstract>This document describes TCP performance problems that arise because of asymmetric effects. These problems arise in several access networks, including bandwidth-asymmetric networks and packet radio subnetworks, for different underlying reasons. However, the end result on TCP performance is the same in both cases: performance often degrades significantly because of imperfection and variability in the ACK feedback from the receiver to the sender. The document details several mitigations to these effects, which have either been proposed or evaluated in the literature, or are currently deployed in networks. These solutions use a combination of local link- layer techniques, subnetwork, and end-to-end mechanisms, consisting of: (i) techniques to manage the channel used for the upstream bottleneck link carrying the ACKs, typically using header compression or reducing the frequency of TCP ACKs, (ii) techniques to handle this reduced ACK frequency to retain the TCP sender's acknowledgment-triggered self- clocking and (iii) techniques to schedule the data and ACK packets in the reverse direction to improve performance in the presence of two-way traffic. Each technique is described, together with known issues, and recommendations for use. A summary of the recommendations is provided at the end of the document. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-pilc-asym-08</draft>
        <is-also>
            <doc-id>BCP0069</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3450</doc-id>
        <title>Asynchronous Layered Coding (ALC) Protocol Instantiation</title>
        <author>
            <name>M. Luby</name>
        </author>
        <author>
            <name>J. Gemmell</name>
        </author>
        <author>
            <name>L. Vicisano</name>
        </author>
        <author>
            <name>L. Rizzo</name>
        </author>
        <author>
            <name>J. Crowcroft</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>86022</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>content</kw>
            <kw>delivery</kw>
            <kw>congestion</kw>
            <kw>control</kw>
            <kw>receivers</kw>
        </keywords>
        <abstract>This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol. Asynchronous Layered Coding combines the Layered Coding Transport (LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-rmt-pi-alc-08</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3451</doc-id>
        <title>Layered Coding Transport (LCT) Building Block</title>
        <author>
            <name>M. Luby</name>
        </author>
        <author>
            <name>J. Gemmell</name>
        </author>
        <author>
            <name>L. Vicisano</name>
        </author>
        <author>
            <name>L. Rizzo</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>J. Crowcroft</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>72594</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>content</kw>
            <kw>stream</kw>
            <kw>delivery</kw>
            <kw>multicast</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract>Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-rmt-bb-lct-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3452</doc-id>
        <title>Forward Error Correction (FEC) Building Block</title>
        <author>
            <name>M. Luby</name>
        </author>
        <author>
            <name>L. Vicisano</name>
        </author>
        <author>
            <name>J. Gemmell</name>
        </author>
        <author>
            <name>L. Rizzo</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>J. Crowcroft</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38368</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>content</kw>
            <kw>stream</kw>
            <kw>delivery</kw>
            <kw>multicast</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract>This document generally describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for data transport. The primary focus of this document is the application of FEC codes to one-to-many reliable data transport using IP multicast. This document describes what information is needed to identify a specific FEC code, what information needs to be communicated out-of-band to use the FEC code, and what information is needed in data packets to identify the encoding symbols they carry. The procedures for specifying FEC codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. This document should be read in conjunction with and uses the terminology of the companion document titled, "The Use of Forward Error Correction (FEC) in Reliable Multicast". This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-rmt-bb-fec-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3453</doc-id>
        <title>The Use of Forward Error Correction (FEC) in Reliable Multicast</title>
        <author>
            <name>M. Luby</name>
        </author>
        <author>
            <name>L. Vicisano</name>
        </author>
        <author>
            <name>J. Gemmell</name>
        </author>
        <author>
            <name>L. Rizzo</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>J. Crowcroft</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46853</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>ip</kw>
            <kw>internet protocol</kw>
            <kw>data transport</kw>
        </keywords>
        <abstract>This memo describes the use of Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for one-to-many reliable data transport using IP multicast. One of the key properties of FEC codes in this context is the ability to use the same packets containing FEC data to simultaneously repair different packet loss patterns at multiple receivers. Different classes of FEC codes and some of their basic properties are described and terminology relevant to implementing FEC in a reliable multicast protocol is introduced. Examples are provided of possible abstract formats for packets carrying FEC. This memo provides information for the Internet community. </abstract>
        <draft>ietf-rmt-info-fec-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3454</doc-id>
        <title>Preparation of Internationalized Strings ("stringprep")</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>M. Blanchet</name>
        </author>
        <date>
            <month>December</month>
            <year>2002</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>138684</char-count>
            <page-count>91</page-count>
        </format>
        <keywords>
            <kw>unicode text</kw>
            <kw>internationalization</kw>
        </keywords>
        <abstract>This document describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings. This document does not specify how protocols should prepare text strings. Protocols must create profiles of stringprep in order to fully specify the processing options. [STANDARDS TRACK] </abstract>
        <draft>hoffman-stringprep-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3455</doc-id>
        <title>Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)</title>
        <author>
            <name>M. Garcia-Martin</name>
        </author>
        <author>
            <name>E. Henrikson</name>
        </author>
        <author>
            <name>D. Mills</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>79620</char-count>
            <page-count>34</page-count>
        </format>
        <abstract>This document describes a set of private Session Initiation Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses. This memo provides information for the Internet community. </abstract>
        <draft>garcia-sipping-3gpp-p-headers-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3456</doc-id>
        <title>Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode</title>
        <author>
            <name>B. Patel</name>
        </author>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>S. Kelly</name>
        </author>
        <author>
            <name>V. Gupta</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40340</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract>This memo explores the requirements for host configuration in IPsec tunnel mode, and describes how the Dynamic Host Configuration Protocol (DHCPv4) may be leveraged for configuration. In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a "virtual" address from the corporate network, and then tunneling traffic via IPsec from the host's ISP-assigned address to the corporate security gateway. In IPv4, DHCP provides for such remote host configuration. [STANDARDS TRACK] </abstract>
        <draft>ietf-ipsec-dhcp-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3457</doc-id>
        <title>Requirements for IPsec Remote Access Scenarios</title>
        <author>
            <name>S. Kelly</name>
        </author>
        <author>
            <name>S. Ramamoorthi</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>75167</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>ipsra</kw>
            <kw>common remote access scenarios</kw>
        </keywords>
        <abstract>IPsec offers much promise as a secure remote access mechanism. However, there are a number of differing remote access scenarios, each having some shared and some unique requirements. A thorough understanding of these requirements is necessary in order to effectively evaluate the suitability of a specific set of mechanisms for any particular remote access scenario. This document enumerates the requirements for a number of common remote access scenarios. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ipsra-reqmts-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3458</doc-id>
        <title>Message Context for Internet Mail</title>
        <author>
            <name>E. Burger</name>
        </author>
        <author>
            <name>E. Candell</name>
        </author>
        <author>
            <name>C. Eliot</name>
        </author>
        <author>
            <name>G. Klyne</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34181</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>user agent</kw>
            <kw>ua</kw>
        </keywords>
        <abstract>This memo describes a new RFC 2822 message header, "Message-Context". This header provides information about the context and presentation characteristics of a message. A receiving user agent (UA) may use this information as a hint to optimally present the message. [STANDARDS TRACK] </abstract>
        <draft>ietf-vpim-hint-08</draft>
        <updated-by>
            <doc-id>RFC3938</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3459</doc-id>
        <title>Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter</title>
        <author>
            <name>E. Burger</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54282</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>body parts</kw>
            <kw>content-disposition</kw>
        </keywords>
        <abstract>This document describes the use of a mechanism for identifying body parts that a sender deems critical in a multi-part Internet mail message. The mechanism described is a parameter to Content-Disposition, as described by RFC 3204. By knowing what parts of a message the sender deems critical, a content gateway can intelligently handle multi-part messages when providing gateway services to systems of lesser capability. Critical content can help a content gateway to decide what parts to forward. It can indicate how hard a gateway should try to deliver a body part. It can help the gateway to pick body parts that are safe to silently delete when a system of lesser capability receives a message. In addition, critical content can help the gateway chose the notification strategy for the receiving system. Likewise, if the sender expects the destination to do some processing on a body part, critical content allows the sender to mark body parts that the receiver must process. [STANDARDS TRACK] </abstract>
        <draft>ietf-vpim-cc-08</draft>
        <updates>
            <doc-id>RFC3204</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3460</doc-id>
        <title>Policy Core Information Model (PCIM) Extensions</title>
        <author>
            <name>B. Moore</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>212453</char-count>
            <page-count>93</page-count>
        </format>
        <keywords>
            <kw>CIM</kw>
            <kw>common</kw>
            <kw>schema</kw>
            <kw>object-oriented</kw>
        </keywords>
        <abstract>This document specifies a number of changes to the Policy Core Information Model (PCIM, RFC 3060). Two types of changes are included. First, several completely new elements are introduced, for example, classes for header filtering, that extend PCIM into areas that it did not previously cover. Second, there are cases where elements of PCIM (for example, policy rule priorities) are deprecated, and replacement elements are defined (in this case, priorities tied to associations that refer to policy rules). Both types of changes are done in such a way that, to the extent possible, interoperability with implementations of the original PCIM model is preserved. This document updates RFC 3060. [STANDARDS TRACK] </abstract>
        <draft>ietf-policy-pcim-ext-08</draft>
        <updates>
            <doc-id>RFC3060</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3461</doc-id>
        <title>Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)</title>
        <author>
            <name>K. Moore</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>76076</char-count>
            <page-count>38</page-count>
        </format>
        <keywords>
            <kw>SMTP-DSN</kw>
            <kw>simple</kw>
            <kw>mail</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify (a) that Delivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS TRACK] </abstract>
        <draft>moore-rfc1891bis-02</draft>
        <obsoletes>
            <doc-id>RFC1891</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3798</doc-id>
            <doc-id>RFC3885</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3462</doc-id>
        <title>The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages</title>
        <author>
            <name>G. Vaudreuil</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12186</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>MIME-RPT</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
        </keywords>
        <abstract>The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports. This document is part of a four document set describing the delivery status report service. This collection includes the Simple Mail Transfer Protocol (SMTP) extensions to request delivery status reports, a MIME content for the reporting of delivery reports, an enumeration of extended status codes, and a multipart container for the delivery report, the original message, and a human-friendly summary of the failure. [STANDARDS TRACK] </abstract>
        <draft>vaudreuil-1892bis-02</draft>
        <obsoletes>
            <doc-id>RFC1892</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3463</doc-id>
        <title>Enhanced Mail System Status Codes</title>
        <author>
            <name>G. Vaudreuil</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31832</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>EMS-CODE</kw>
            <kw>simple</kw>
            <kw>mail</kw>
            <kw>transfer</kw>
            <kw>protocol</kw>
            <kw>SMTP</kw>
        </keywords>
        <abstract>This document defines a set of extended status codes for use within the mail system for delivery status reports, tracking, and improved diagnostics. In combination with other information provided in the Delivery Status Notification (DSN) delivery report, these codes facilitate media and language independent rendering of message delivery status. [STANDARDS TRACK] </abstract>
        <draft>vaudreuil-1893bis-03</draft>
        <obsoletes>
            <doc-id>RFC1893</doc-id>
        </obsoletes>
        <updated-by>
            <doc-id>RFC3886</doc-id>
        </updated-by>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3464</doc-id>
        <title>An Extensible Message Format for Delivery Status Notifications</title>
        <author>
            <name>K. Moore</name>
        </author>
        <author>
            <name>G. Vaudreuil</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>83060</char-count>
            <page-count>40</page-count>
        </format>
        <keywords>
            <kw>DSN</kw>
            <kw>Multipurpose</kw>
            <kw>Internet</kw>
            <kw>Mail</kw>
            <kw>Extensions</kw>
            <kw>Content</kw>
            <kw>Type</kw>
        </keywords>
        <abstract>This memo defines a Multipurpose Internet Mail Extensions (MIME) content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used in Internet electronic mail. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "Local Area Network (LAN)-based" systems), the Delivery Status Notification (DSN) protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses and error codes, in addition to those normally used in Internet mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail. [STANDARDS TRACK] </abstract>
        <draft>vaudreuil-1894bis-02</draft>
        <obsoletes>
            <doc-id>RFC1894</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3465</doc-id>
        <title>TCP Congestion Control with Appropriate Byte Counting (ABC)</title>
        <author>
            <name>M. Allman</name>
        </author>
        <date>
            <month>February</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23486</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>transmission control protocol</kw>
            <kw>security performance</kw>
        </keywords>
        <abstract>This document proposes a small modification to the way TCP increases its congestion window. Rather than the traditional method of increasing the congestion window by a constant amount for each arriving acknowledgment, the document suggests basing the increase on the number of previously unacknowledged bytes each ACK covers. This change improves the performance of TCP, as well as closes a security hole TCP receivers can use to induce the sender into increasing the sending rate too rapidly. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>allman-tcp-abc-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3466</doc-id>
        <title>A Model for Content Internetworking (CDI)</title>
        <author>
            <name>M. Day</name>
        </author>
        <author>
            <name>B. Cain</name>
        </author>
        <author>
            <name>G. Tomlinson</name>
        </author>
        <author>
            <name>P. Rzewski</name>
        </author>
        <date>
            <month>February</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37684</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>distribution peering</kw>
        </keywords>
        <abstract>Content (distribution) internetworking (CDI) is the technology for interconnecting content networks, sometimes previously called "content peering" or "CDN peering". A common vocabulary helps the process of discussing such interconnection and interoperation. This document introduces content networks and content internetworking, and defines elements for such a common vocabulary. This memo provides information for the Internet community. </abstract>
        <draft>ietf-cdi-model-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3467</doc-id>
        <title>Role of the Domain Name System (DNS)</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>February</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>84570</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>history</kw>
            <kw>internationalization</kw>
            <kw>unicode</kw>
            <kw>ascii</kw>
            <kw>multilingual names</kw>
        </keywords>
        <abstract>This document reviews the original function and purpose of the domain name system (DNS). It contrasts that history with some of the purposes for which the DNS has recently been applied and some of the newer demands being placed upon it or suggested for it. A framework for an alternative to placing these additional stresses on the DNS is then outlined. This document and that framework are not a proposed solution, only a strong suggestion that the time has come to begin thinking more broadly about the problems we are encountering and possible approaches to solving them. This memo provides information for the Internet community. </abstract>
        <draft>klensin-dns-role-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3468</doc-id>
        <title>The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols</title>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>G. Swallow</name>
        </author>
        <date>
            <month>February</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22072</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>rsvp-te</kw>
            <kw>ldp</kw>
            <kw>resource reservation protocol label distribution</kw>
        </keywords>
        <abstract>This document documents the consensus reached by the Multiprotocol Label Switching (MPLS) Working Group within the IETF to focus its efforts on "Resource Reservation Protocol (RSVP)-TE: Extensions to RSVP for Label- Switched Paths (LSP) Tunnels" (RFC 3209) as the MPLS signalling protocol for traffic engineering applications and to undertake no new efforts relating to "Constraint-Based LSP Setup using Label Distribution Protocol (LDP)" (RFC 3212). The recommendations of section 6 have been accepted by the IESG. This memo provides information for the Internet community. </abstract>
        <draft>andersson-mpls-sig-decision-03</draft>
        <updates>
            <doc-id>RFC3212</doc-id>
            <doc-id>RFC3472</doc-id>
            <doc-id>RFC3475</doc-id>
            <doc-id>RFC3476</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3469</doc-id>
        <title>Framework for Multi-Protocol Label Switching (MPLS)-based Recovery</title>
        <author>
            <name>V. Sharma</name>
            <title>Editor</title>
        </author>
        <author>
            <name>F. Hellstrand</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>89331</char-count>
            <page-count>40</page-count>
        </format>
        <keywords>
            <kw>routing traffic</kw>
        </keywords>
        <abstract>Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switching routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. Restart issues are not included in this framework. This memo provides information for the Internet community. </abstract>
        <draft>ietf-mpls-recovery-frmwrk-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3470</doc-id>
        <title>Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <author>
            <name>M. Rose</name>
        </author>
        <author>
            <name>L. Masinter</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>64252</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>data</kw>
            <kw>documents</kw>
            <kw>structure</kw>
        </keywords>
        <abstract>The Extensible Markup Language (XML) is a framework for structuring data. While it evolved from Standard Generalized Markup Language (SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data. There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>hollenbeck-ietf-xml-guidelines-07</draft>
        <is-also>
            <doc-id>BCP0070</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3471</doc-id>
        <title>Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description</title>
        <author>
            <name>L. Berger</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>72105</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>mpls</kw>
            <kw>sonet/sdh</kw>
        </keywords>
        <abstract>This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents. [STANDARDS TRACK] </abstract>
        <draft>ietf-mpls-generalized-signaling-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3472</doc-id>
        <title>Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions</title>
        <author>
            <name>P. Ashwood-Smith</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Berger</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49006</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>mpls</kw>
            <kw>sonet/sdh</kw>
        </keywords>
        <abstract>This document describes extensions to Multi-Protocol Label Switching (MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS TRACK] </abstract>
        <draft>ietf-mpls-generalized-cr-ldp-07</draft>
        <updated-by>
            <doc-id>RFC3468</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3473</doc-id>
        <title>Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions</title>
        <author>
            <name>L. Berger</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>91808</char-count>
            <page-count>42</page-count>
        </format>
        <keywords>
            <kw>mpls</kw>
            <kw>sonet/sdh</kw>
        </keywords>
        <abstract>This document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS TRACK] </abstract>
        <draft>ietf-mpls-generalized-rsvp-te-09</draft>
        <updated-by>
            <doc-id>RFC4003</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3474</doc-id>
        <title>Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON)</title>
        <author>
            <name>Z. Lin</name>
        </author>
        <author>
            <name>D. Pendarakis</name>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52551</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>sonet</kw>
            <kw>sdh</kw>
        </keywords>
        <abstract>The Generalized MultiProtocol Label Switching (GMPLS) suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) as well as Optical Transport Networks (OTNs). This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using Resource Reservation Protocol - Traffic Engineering (RSVP-TE). It proposes additional extensions to these signaling protocols to support the capabilities of an ASON network. This document proposes appropriate extensions towards the resolution of additional requirements identified and communicated by the ITU-T Study Group 15 in support of ITU's ASON standardization effort. This memo provides information for the Internet community. </abstract>
        <draft>lin-ccamp-gmpls-ason-rsvpte-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3475</doc-id>
        <title>Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON)</title>
        <author>
            <name>O. Aboul-Magd</name>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29995</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>label switching protocol</kw>
            <kw>itu-t</kw>
        </keywords>
        <abstract>Automatic Switched Optical Network (ASON) is an architecture, specified by ITU-T Study Group 15, for the introduction of a control plane for optical networks. The ASON architecture specifies a set of reference points that defines the relationship between the ASON architectural entities. Signaling over interfaces defined in those reference points can make use of protocols that are defined by the IETF in the context of Generalized Multi-Protocol Label Switching (GMPLS) work. This document describes Constraint-Based LSP setup using LDP (CR-LDP) extensions for signaling over the interfaces defined in the ASON reference points. The purpose of the document is to request that the IANA assigns code points necessary for the CR-LDP extensions. The protocol specifications for the use of the CR-LDP extensions are found in ITU-T documents. This memo provides information for the Internet community. </abstract>
        <draft>aboulmagd-ccamp-crldp-ason-ext-02</draft>
        <updated-by>
            <doc-id>RFC3468</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3476</doc-id>
        <title>Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extensions for Optical UNI Signaling</title>
        <author>
            <name>B. Rajagopalan</name>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22009</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>oif</kw>
            <kw>optical interworking forum</kw>
            <kw>uni</kw>
            <kw>user network interface</kw>
        </keywords>
        <abstract>The Optical Interworking Forum (OIF) has defined extensions to the Label Distribution Protocol (LDP) and the Resource ReSerVation Protocol (RSVP) for optical User Network Interface (UNI) signaling. These extensions consist of a set of new data objects and error codes. This document describes these extensions. This memo provides information for the Internet community. </abstract>
        <draft>bala-uni-ldp-rsvp-extensions-04</draft>
        <updated-by>
            <doc-id>RFC3468</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3477</doc-id>
        <title>Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)</title>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <date>
            <month>January</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19899</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>mpls-te</kw>
            <kw>traffic engineering</kw>
        </keywords>
        <abstract>Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Resource ReSerVation Protocol (RSVP) for Label Switched Path (LSP) Tunnels (RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. [STANDARDS TRACK] </abstract>
        <draft>ietf-mpls-rsvp-unnum-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3478</doc-id>
        <title>Graceful Restart Mechanism for Label Distribution Protocol</title>
        <author>
            <name>M. Leelanivas</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>R. Aggarwal</name>
        </author>
        <date>
            <month>February</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29248</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>ldp</kw>
            <kw>mpls</kw>
        </keywords>
        <abstract>This document describes a mechanism that helps to minimize the negative effects on MPLS traffic caused by Label Switching Router's (LSR's) control plane restart, specifically by the restart of its Label Distribution Protocol (LDP) component, on LSRs that are capable of preserving the MPLS forwarding component across the restart. The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter needs to implement only a subset of the mechanism described in this document). Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here. The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actual MPLS forwarding state has to be preserved; the mechanism does not require any of the LDP-related states to be preserved across the restart. The procedures described in this document apply to downstream unsolicited label distribution. Extending these procedures to downstream on demand label distribution is for further study. [STANDARDS TRACK] </abstract>
        <draft>ietf-mpls-ldp-restart-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3479</doc-id>
        <title>Fault Tolerance for the Label Distribution Protocol (LDP)</title>
        <author>
            <name>A. Farrel</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>115778</char-count>
            <page-count>52</page-count>
        </format>
        <keywords>
            <kw>mpls</kw>
            <kw>multiprotocol label switching</kw>
            <kw>cr-ldp</kw>
            <kw>high availability restart</kw>
        </keywords>
        <abstract>Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including Label Distribution Protocol (LDP), the switching hardware and TCP, are implementation specific. This document identifies issues in the LDP specification in RFC 3036, "LDP Specification", that make it difficult to implement an FT LSR using the current LDP protocols, and defines enhancements to the LDP specification to ease such FT LSR implementations. The issues and extensions described here are equally applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP" (CR-LDP). [STANDARDS TRACK] </abstract>
        <draft>ietf-mpls-ldp-ft-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3480</doc-id>
        <title>Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)</title>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>A. Kullberg</name>
        </author>
        <date>
            <month>February</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17076</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>mpls</kw>
            <kw>multiprotocol label switching</kw>
            <kw>traffic engineering</kw>
            <kw>mpls-te</kw>
        </keywords>
        <abstract>Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Constraint-Routing Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling protocols that are needed in order to support unnumbered links. [STANDARDS TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3481</doc-id>
        <title>TCP over Second (2.5G) and Third (3G) Generation Wireless Networks</title>
        <author>
            <name>H. Inamura</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Montenegro</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Ludwig</name>
        </author>
        <author>
            <name>A. Gurtov</name>
        </author>
        <author>
            <name>F. Khafizov</name>
        </author>
        <date>
            <month>February</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>61528</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>paths</kw>
            <kw>algorithm stacks</kw>
        </keywords>
        <abstract>This document describes a profile for optimizing TCP to adapt so that it handles paths including second (2.5G) and third (3G) generation wireless networks. It describes the relevant characteristics of 2.5G and 3G networks, and specific features of example deployments of such networks. It then recommends TCP algorithm choices for nodes known to be starting or ending on such paths, and it also discusses open issues. The configuration options recommended in this document are commonly found in modern TCP stacks, and are widely available standards-track mechanisms that the community considers safe for use on the general Internet. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-pilc-2.5g3g-12</draft>
        <is-also>
            <doc-id>BCP0071</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3482</doc-id>
        <title>Number Portability in the Global Switched Telephone Network (GSTN): An Overview</title>
        <author>
            <name>M. Foster</name>
        </author>
        <author>
            <name>T. McGarry</name>
        </author>
        <author>
            <name>J. Yu</name>
        </author>
        <date>
            <month>February</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>78552</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>e.164</kw>
            <kw>telephony routing</kw>
        </keywords>
        <abstract>This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN). NP is a regulatory imperative seeking to liberalize local telephony service competition, by enabling end-users to retain telephone numbers while changing service providers. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints that establish relevant parameters for NP implementation, most of which are not network technology specific. Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony works-in-progress with the IETF. This memo provides information for the Internet community. </abstract>
        <draft>ietf-enum-e164-gstn-np-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3483</doc-id>
        <title>Framework for Policy Usage Feedback for Common Open Policy Service with Policy Provisioning (COPS-PR)</title>
        <author>
            <name>D. Rawlins</name>
        </author>
        <author>
            <name>A. Kulkarni</name>
        </author>
        <author>
            <name>M. Bokaemper</name>
        </author>
        <author>
            <name>K. Chan</name>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19869</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>accounting</kw>
            <kw>policy decision</kw>
            <kw>point</kw>
            <kw>bdp</kw>
        </keywords>
        <abstract>Common Open Policy Services (COPS) Protocol (RFC 2748), defines the capability of reporting information to the Policy Decision Point (PDP). The types of report information are success, failure and accounting of an installed state. This document focuses on the COPS Report Type of Accounting and the necessary framework for the monitoring and reporting of usage feedback for an installed state. This memo provides information for the Internet community. </abstract>
        <draft>ietf-rap-feedback-frwk-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3484</doc-id>
        <title>Default Address Selection for Internet Protocol version 6 (IPv6)</title>
        <author>
            <name>R. Draves</name>
        </author>
        <date>
            <month>February</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>55076</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>source</kw>
            <kw>address destination</kw>
        </keywords>
        <abstract>This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. [STANDARDS TRACK] </abstract>
        <draft>ietf-ipv6-default-addr-select-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3485</doc-id>
        <title>The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)</title>
        <author>
            <name>M. Garcia-Martin</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>J. Ott</name>
        </author>
        <author>
            <name>R. Price</name>
        </author>
        <author>
            <name>A. B. Roach</name>
        </author>
        <date>
            <month>February</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>80195</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>algorithm</kw>
        </keywords>
        <abstract>The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol can be compressed by using Signaling Compression (SigComp). Similarly, the Session Description Protocol (SDP) is a text-based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This memo defines the SIP/SDP-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent. [STANDARDS TRACK] </abstract>
        <draft>ietf-sipping-sigcomp-sip-dictionary-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3486</doc-id>
        <title>Compressing the Session Initiation Protocol (SIP)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>February</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24181</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document describes a mechanism to signal that compression is desired for one or more Session Initiation Protocol (SIP) messages. It also states when it is appropriate to send compressed SIP messages to a SIP entity. [STANDARDS TRACK] </abstract>
        <draft>ietf-sip-compression-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3487</doc-id>
        <title>Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>February</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39615</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>circuit switched network resources</kw>
            <kw>end system resources</kw>
            <kw>proxy resources</kw>
            <kw>emergency preparedness communications</kw>
        </keywords>
        <abstract>This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). This memo provides information for the Internet community. </abstract>
        <draft>ietf-ieprep-sip-reqs-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3488</doc-id>
        <title>Cisco Systems Router-port Group Management Protocol (RGMP)</title>
        <author>
            <name>I. Wu</name>
        </author>
        <author>
            <name>T. Eckert</name>
        </author>
        <date>
            <month>February</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37152</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>multicast</kw>
            <kw>switches packet</kw>
        </keywords>
        <abstract>This document describes the Router-port Group Management Protocol (RGMP). This protocol was developed by Cisco Systems and is used between multicast routers and switches to restrict multicast packet forwarding in switches to those routers where the packets may be needed. RGMP is designed for backbone switched networks where multiple, high speed routers are interconnected. This memo provides information for the Internet community. </abstract>
        <draft>wu-rgmp-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3489</doc-id>
        <title>STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>J. Weinberger</name>
        </author>
        <author>
            <name>C. Huitema</name>
        </author>
        <author>
            <name>R. Mahy</name>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>117562</char-count>
            <page-count>47</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>applications</kw>
            <kw>firewalls</kw>
        </keywords>
        <abstract>Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol (IP) addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. [STANDARDS TRACK] </abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3490</doc-id>
        <title>Internationalizing Domain Names in Applications (IDNA)</title>
        <author>
            <name>P. Faltstrom</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>A. Costello</name>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51943</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>idn</kw>
            <kw>ascii</kw>
            <kw>characters</kw>
        </keywords>
        <abstract>Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism called Internationalizing Domain Names in Applications (IDNA) for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so-called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text. [STANDARDS TRACK] </abstract>
        <draft>ietf-idn-idna-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3491</doc-id>
        <title>Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>M. Blanchet</name>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10316</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>idna</kw>
            <kw>applications</kw>
        </keywords>
        <abstract>This document describes how to prepare internationalized domain name (IDN) labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the Domain Name System (DNS). [STANDARDS TRACK] </abstract>
        <draft>ietf-idn-nameprep-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3492</doc-id>
        <title>Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)</title>
        <author>
            <name>A. Costello</name>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>67439</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
            <kw>syntax</kw>
            <kw>string host label</kw>
        </keywords>
        <abstract>Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. [STANDARDS TRACK] </abstract>
        <draft>ietf-idn-punycode-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3493</doc-id>
        <title>Basic Socket Interface Extensions for IPv6</title>
        <author>
            <name>R. Gilligan</name>
        </author>
        <author>
            <name>S. Thomson</name>
        </author>
        <author>
            <name>J. Bound</name>
        </author>
        <author>
            <name>J. McCann</name>
        </author>
        <author>
            <name>W. Stevens</name>
        </author>
        <date>
            <month>February</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>82570</char-count>
            <page-count>39</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>api</kw>
            <kw>application</kw>
            <kw>program</kw>
            <kw>interface</kw>
            <kw>tcp</kw>
            <kw>transmission control</kw>
        </keywords>
        <abstract>The de facto standard Application Program Interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document. This memo provides information for the Internet community. </abstract>
        <obsoletes>
            <doc-id>RFC2553</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3494</doc-id>
        <title>Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9225</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>DAP</kw>
            <kw>interactive</kw>
            <kw>access</kw>
            <kw>X.500</kw>
            <kw>LDAP</kw>
            <kw>lightweight directory protocol</kw>
            <kw>STR-REP</kw>
            <kw>directory names</kw>
            <kw>representing names</kw>
        </keywords>
        <abstract>This document recommends the retirement of version 2 of the Lightweight Directory Access Protocol (LDAPv2) and other dependent specifications, and discusses the reasons for doing so. This document recommends RFC 1777, 1778, 1779, 1781, and 2559 (as well as documents they superseded) be moved to Historic status. This memo provides information for the Internet community. </abstract>
        <draft>zeilenga-ldapv2-04</draft>
        <obsoletes>
            <doc-id>RFC1484</doc-id>
            <doc-id>RFC1485</doc-id>
            <doc-id>RFC1487</doc-id>
            <doc-id>RFC1777</doc-id>
            <doc-id>RFC1778</doc-id>
            <doc-id>RFC1779</doc-id>
            <doc-id>RFC1781</doc-id>
            <doc-id>RFC2559</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3495</doc-id>
        <title>Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration</title>
        <author>
            <name>B. Beser</name>
        </author>
        <author>
            <name>P. Duffy</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26817</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>packetcable media terminal adapter</kw>
            <kw>mta</kw>
        </keywords>
        <abstract>This document defines a Dynamic Host Configuration Protocol (DHCP) option that will be used to configure various devices deployed within CableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). The option content defined within this document will be extended as future CableLabs client devices are developed. [STANDARDS TRACK] </abstract>
        <draft>ietf-dhc-packetable-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3496</doc-id>
        <title>Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering</title>
        <author>
            <name>A. G. Malis</name>
        </author>
        <author>
            <name>T. Hsiao</name>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11431</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>diff-serv</kw>
            <kw>diffserv</kw>
            <kw>rsvp-te</kw>
            <kw>resource reservation protocol</kw>
        </keywords>
        <abstract>This document specifies a Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) signaling extension for support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering. This memo provides information for the Internet community. </abstract>
        <draft>malis-diff-te-serviceclass-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3497</doc-id>
        <title>RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video</title>
        <author>
            <name>L. Gharai</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>G. Goncher</name>
        </author>
        <author>
            <name>A. Mankin</name>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26094</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>real-time transport protocol</kw>
            <kw>hdtv</kw>
            <kw>high definition television</kw>
        </keywords>
        <abstract>This memo specifies an RTP payload format for encapsulating uncompressed High Definition Television (HDTV) as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 292M. SMPTE is the main standardizing body in the motion imaging industry and the SMPTE 292M standard defines a bit-serial digital interface for local area HDTV transport. [STANDARDS TRACK] </abstract>
        <draft>ietf-avt-smpte292-video-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3498</doc-id>
        <title>Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) Architectures</title>
        <author>
            <name>J. Kuhfeld</name>
        </author>
        <author>
            <name>J. Johnson</name>
        </author>
        <author>
            <name>M. Thatcher</name>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>78701</char-count>
            <page-count>43</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>tcp/ip transmission control protocol</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing networks using Synchronous Optical Network (SONET) linear Automatic Protection Switching (APS) architectures. [STANDARDS TRACK] </abstract>
        <draft>ietf-atommib-sonetaps-mib-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3499</doc-id>
        <title>Request for Comments Summary RFC Numbers 3400-3499</title>
        <author>
            <name>S. Ginoza</name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>88033</char-count>
            <page-count>38</page-count>
        </format>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-not-issued-entry>
        <doc-id>RFC3500</doc-id>
    </rfc-not-issued-entry>
    <rfc-entry>
        <doc-id>RFC3501</doc-id>
        <title>INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1</title>
        <author>
            <name>M. Crispin</name>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>227640</char-count>
            <page-count>108</page-count>
        </format>
        <keywords>
            <kw>IMAPv4</kw>
            <kw>imap</kw>
            <kw>imapv4rev1</kw>
        </keywords>
        <abstract>The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server. IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. [STANDARDS TRACK] </abstract>
        <draft>crispin-imapv-20</draft>
        <obsoletes>
            <doc-id>RFC2060</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3502</doc-id>
        <title>Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension</title>
        <author>
            <name>M. Crispin</name>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13379</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>IMAPv4</kw>
            <kw>imap</kw>
            <kw>imapv4rev1</kw>
        </keywords>
        <abstract>This document describes the multiappending extension to the Internet Message Access Protocol (IMAP) (RFC 3501). This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server. A server which supports this extension indicates this with a capability name of "MULTIAPPEND". [STANDARDS TRACK] </abstract>
        <draft>crispin-imap-multiappend-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3503</doc-id>
        <title>Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP)</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16937</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>mua</kw>
            <kw>mail user agent</kw>
            <kw>imap4</kw>
        </keywords>
        <abstract>The Message Disposition Notification (MDN) facility defined in RFC 2298 provides a means by which a message can request that message processing by the recipient be acknowledged as well as a format to be used for such acknowledgements. However, it doesn't describe how multiple Mail User Agents (MUAs) should handle the generation of MDNs in an Internet Message Access Protocol (IMAP4) environment. This document describes how to handle MDNs in such an environment and provides guidelines for implementers of IMAP4 that want to add MDN support to their products. [STANDARDS TRACK] </abstract>
        <draft>melnikov-imap-mdn-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3504</doc-id>
        <title>Internet Open Trading Protocol (IOTP) Version 1, Errata</title>
        <author>
            <name>D. Eastlake</name>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8655</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>commerce</kw>
            <kw>payment</kw>
            <kw>system</kw>
            <kw>merchant</kw>
            <kw>system</kw>
            <kw>xml</kw>
            <kw>extensible</kw>
            <kw>markup</kw>
            <kw>language</kw>
            <kw>security</kw>
        </keywords>
        <abstract>Since the publication of the RFCs specifying Version 1.0 of the Internet Open Trading Protocol (IOTP), some errors have been noted. This informational document lists these errors and provides corrections for them. This memo provides information for the Internet community. </abstract>
        <draft>ietf-trade-iotp-v1-errata-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3505</doc-id>
        <title>Electronic Commerce Modeling Language (ECML): Version 2 Requirements</title>
        <author>
            <name>D. Eastlake</name>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13915</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>xml</kw>
            <kw>extensible markup language</kw>
        </keywords>
        <abstract>This document lists the design principles, scope, and requirements for the Electronic Commerce Modeling Language (ECML) version 2 specification. It includes requirements as they relate to Extensible Markup Language (XML) syntax, data model, format, and payment processing. This memo provides information for the Internet community. </abstract>
        <draft>ietf-trade-ecml2-req-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3506</doc-id>
        <title>Requirements and Design for Voucher Trading System (VTS)</title>
        <author>
            <name>K. Fujimura</name>
        </author>
        <author>
            <name>D. Eastlake</name>
        </author>
        <date>
            <month>March</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30945</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>generic voucher language</kw>
            <kw>gvl</kw>
        </keywords>
        <abstract>Crediting loyalty points and collecting digital coupons or gift certificates are common functions in purchasing and trading transactions. These activities can be generalized using the concept of a "voucher", which is a digital representation of the right to claim goods or services. This document presents a Voucher Trading System (VTS) that circulates vouchers securely and its terminology; it lists design principles and requirements for VTS and the Generic Voucher Language (GVL), with which diverse types of vouchers can be described. This memo provides information for the Internet community. </abstract>
        <draft>ietf-trade-drt-requirements-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3507</doc-id>
        <title>Internet Content Adaptation Protocol (ICAP)</title>
        <author>
            <name>J. Elson</name>
        </author>
        <author>
            <name>A. Cerpa</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>98772</char-count>
            <page-count>49</page-count>
        </format>
        <keywords>
            <kw>http</kw>
            <kw>hyper-text markup protocol</kw>
            <kw>request</kw>
            <kw>response</kw>
            <kw>client server</kw>
        </keywords>
        <abstract>ICAP, the Internet Content Adaption Protocol, is a protocol aimed at providing simple object-based content vectoring for HTTP services. ICAP is, in essence, a lightweight protocol for executing a "remote procedure call" on HTTP messages. It allows ICAP clients to pass HTTP messages to ICAP servers for some sort of transformation or other processing ("adaptation"). The server executes its transformation service on messages and sends back responses to the client, usually with modified messages. Typically, the adapted messages are either HTTP requests or HTTP responses. This memo provides information for the Internet community. </abstract>
        <draft>elson-icap-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3508</doc-id>
        <title>H.323 Uniform Resource Locator (URL) Scheme Registration</title>
        <author>
            <name>O. Levin</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10983</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>itu-t</kw>
            <kw>packet networks</kw>
        </keywords>
        <abstract>ITU-T Recommendation H.323 version 4 introduced an H.323-specific Uniform Resource Locator (URL). This document reproduces the H323-URL definition found in H.323, and is published as an RFC for ease of access and registration with the Internet Assigned Numbers Authority (IANA). This memo provides information for the Internet community. </abstract>
        <draft>levin-iptel-h323-url-scheme-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3509</doc-id>
        <title>Alternative Implementations of OSPF Area Border Routers</title>
        <author>
            <name>A. Zinin</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <author>
            <name>D. Yeung</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24326</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>traffic</kw>
            <kw>backbone</kw>
        </keywords>
        <abstract>Open Shortest Path First (OSPF) is a link-state intra-domain routing protocol used for routing in IP networks. Though the definition of the Area Border Router (ABR) in the OSPF specification does not require a router with multiple attached areas to have a backbone connection, it is actually necessary to provide successful routing to the inter-area and external destinations. If this requirement is not met, all traffic destined for the areas not connected to such an ABR or out of the OSPF domain, is dropped. This document describes alternative ABR behaviors implemented in Cisco and IBM routers. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ospf-abr-alt-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3510</doc-id>
        <title>Internet Printing Protocol/1.1: IPP URL Scheme</title>
        <author>
            <name>R. Herriot</name>
        </author>
        <author>
            <name>I. McDonald</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22009</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>IPP-E-T</kw>
            <kw>IPP</kw>
            <kw>application</kw>
            <kw>media-type</kw>
            <kw>media</kw>
            <kw>type</kw>
        </keywords>
        <abstract>This memo defines the "ipp" URL (Uniform Resource Locator) scheme. This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by expanding and clarifying Section 5, "IPP URL Scheme", of RFC 2910. An "ipp" URL is used to specify the network location of a print service that supports the IPP Protocol (RFC 2910), or of a network resource (for example, a print job) managed by such a print service. [STANDARDS TRACK] </abstract>
        <draft>ietf-ipp-url-scheme-05</draft>
        <updates>
            <doc-id>RFC2910</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3511</doc-id>
        <title>Benchmarking Methodology for Firewall Performance</title>
        <author>
            <name>B. Hickman</name>
        </author>
        <author>
            <name>D. Newman</name>
        </author>
        <author>
            <name>S. Tadjudin</name>
        </author>
        <author>
            <name>T. Martin</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>67916</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>client server</kw>
            <kw>traffic</kw>
            <kw>authentication</kw>
            <kw>web caching</kw>
        </keywords>
        <abstract>This document discusses and defines a number of tests that may be used to describe the performance characteristics of firewalls. In addition to defining the tests, this document also describes specific formats for reporting the results of the tests. This document is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF). This memo provides information for the Internet community. </abstract>
        <draft>ietf-bmwg-firewall-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3512</doc-id>
        <title>Configuring Networks and Devices with Simple Network Management Protocol (SNMP)</title>
        <author>
            <name>M. MacFaden</name>
        </author>
        <author>
            <name>D. Partain</name>
        </author>
        <author>
            <name>J. Saperia</name>
        </author>
        <author>
            <name>W. Tackabury</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>196529</char-count>
            <page-count>83</page-count>
        </format>
        <keywords>
            <kw>internet standard framework</kw>
        </keywords>
        <abstract>This document is written for readers interested in the Internet Standard Management Framework and its protocol, the Simple Network Management Protocol (SNMP). In particular, it offers guidance in the effective use of SNMP for configuration management. This information is relevant to vendors that build network elements, management application developers, and those that acquire and deploy this technology in their networks. This memo provides information for the Internet community. </abstract>
        <draft>ietf-snmpconf-bcp-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3513</doc-id>
        <title>Internet Protocol Version 6 (IPv6) Addressing Architecture</title>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>S. Deering</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53920</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>unicast</kw>
            <kw>anycast</kw>
            <kw>multicast</kw>
            <kw>node</kw>
        </keywords>
        <abstract>This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. [STANDARDS TRACK] </abstract>
        <draft>ietf-ipngwg-addr-arch-v3-11</draft>
        <obsoletes>
            <doc-id>RFC2373</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3514</doc-id>
        <title>The Security Flag in the IPv4 Header</title>
        <author>
            <name>S. Bellovin</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11211</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>evil</kw>
            <kw>evil bit</kw>
        </keywords>
        <abstract>Firewalls, packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. We define a security flag in the IPv4 header as a means of distinguishing the two cases. This memo provides information for the Internet community. </abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3515</doc-id>
        <title>The Session Initiation Protocol (SIP) Refer Method</title>
        <author>
            <name>R. Sparks</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47788</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>resource request</kw>
            <kw>call transfer</kw>
        </keywords>
        <abstract>This document defines the REFER method. This Session Initiation Protocol (SIP) extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer. In addition to the REFER method, this document defines the refer event package and the Refer-To request header. [STANDARDS TRACK] </abstract>
        <draft>ietf-sip-refer-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3516</doc-id>
        <title>IMAP4 Binary Content Extension</title>
        <author>
            <name>L. Nerenberg</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14598</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>internet message acess procotol</kw>
        </keywords>
        <abstract>This memo defines the Binary extension to the Internet Message Access Protocol (IMAP4). It provides a mechanism for IMAP4 clients and servers to exchange message body data without using a MIME content-transfer- encoding. [STANDARDS TRACK] </abstract>
        <draft>nerenberg-imap-binary-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3517</doc-id>
        <title>A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP</title>
        <author>
            <name>E. Blanton</name>
        </author>
        <author>
            <name>M. Allman</name>
        </author>
        <author>
            <name>K. Fall</name>
        </author>
        <author>
            <name>L. Wang</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27855</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>transmission control protocol</kw>
            <kw>retransmission</kw>
            <kw>congestion control</kw>
        </keywords>
        <abstract>This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 2581), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. [STANDARDS TRACK] </abstract>
        <draft>allman-tcp-sack-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3518</doc-id>
        <title>Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP)</title>
        <author>
            <name>M. Higashiyama</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>T. Liao</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>82102</char-count>
            <page-count>40</page-count>
        </format>
        <keywords>
            <kw>PPP-BCP</kw>
            <kw>point-to-point</kw>
            <kw>datagrams</kw>
            <kw>network</kw>
        </keywords>
        <abstract>The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) and proposes a family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring Remote Bridging for PPP links. This document obsoletes RFC 2878, which was based on the IEEE 802.1D- 1993 MAC Bridge. This document extends that specification by improving support for bridge control packets. [STANDARDS TRACK] </abstract>
        <draft>ietf-pppext-rfc2878bis-01</draft>
        <obsoletes>
            <doc-id>RFC2878</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3519</doc-id>
        <title>Mobile IP Traversal of Network Address Translation (NAT) Devices</title>
        <author>
            <name>H. Levkowetz</name>
        </author>
        <author>
            <name>S. Vaarala</name>
        </author>
        <date>
            <month>May</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>80522</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>Internet Protocol</kw>
            <kw>datagram</kw>
            <kw>traffic</kw>
            <kw>Mobile IP</kw>
            <kw>NAT</kw>
            <kw>NAPT</kw>
            <kw>traversal</kw>
            <kw>tunnelling</kw>
            <kw>tunneling</kw>
            <kw>UDP</kw>
            <kw>private address space</kw>
            <kw>keepalives</kw>
            <kw>port 434</kw>
            <kw>MIP</kw>
            <kw>MIPv4</kw>
            <kw>network address translation</kw>
        </keywords>
        <abstract>Mobile IP's datagram tunnelling is incompatible with Network Address Translation (NAT). This document presents extensions to the Mobile IP protocol and a tunnelling method which permits mobile nodes using Mobile IP to operate in private address networks which are separated from the public internet by NAT devices. The NAT traversal is based on using the Mobile IP Home Agent UDP port for encapsulated data traffic. [STANDARDS TRACK] </abstract>
        <draft>ietf-mobileip-nat-traversal-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3520</doc-id>
        <title>Session Authorization Policy Element</title>
        <author>
            <name>L-N. Hamer</name>
        </author>
        <author>
            <name>B. Gage</name>
        </author>
        <author>
            <name>B. Kosinski</name>
        </author>
        <author>
            <name>H. Shieh</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63445</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>admission control</kw>
            <kw>resource reservation</kw>
        </keywords>
        <abstract>This document describes the representation of a session authorization policy element for supporting policy-based per-session authorization and admission control. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to co-ordinate actions between the signaling and transport planes. This document describes how a process on a system authorizes the reservation of resources by a host and then provides that host with a session authorization policy element which can be inserted into a resource reservation protocol (e.g., the Resource ReSerVation Protocol (RSVP) PATH message) to facilitate proper and secure reservation of those resources within the network. We describe the encoding of session authorization information as a policy element conforming to the format of a Policy Data object (RFC 2750) and provide details relating to operations, processing rules and error scenarios. [STANDARDS TRACK] </abstract>
        <draft>ietf-rap-rsvp-authsession-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3521</doc-id>
        <title>Framework for Session Set-up with Media Authorization</title>
        <author>
            <name>L-N. Hamer</name>
        </author>
        <author>
            <name>B. Gage</name>
        </author>
        <author>
            <name>H. Shieh</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59548</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>qos</kw>
            <kw>quality of service</kw>
            <kw>streams</kw>
            <kw>linkage</kw>
            <kw>policy control</kw>
            <kw>admission</kw>
            <kw>theft service</kw>
            <kw>resource reservation</kw>
            <kw>token</kw>
        </keywords>
        <abstract>Establishing multimedia streams must take into account requirements for end-to-end QoS, authorization of network resource usage and accurate accounting for resources used. During session set up, policies may be enforced to ensure that the media streams being requested lie within the bounds of the service profile established for the requesting host. Similarly, when a host requests resources to provide a certain QoS for a packet flow, policies may be enforced to ensure that the required resources lie within the bounds of the resource profile established for the requesting host. To prevent fraud and to ensure accurate billing, this document describes various scenarios and mechanisms that provide the linkage required to verify that the resources being used to provide a requested QoS are in- line with the media streams requested (and authorized) for the session. This memo provides information for the Internet community. </abstract>
        <draft>ietf-rap-session-auth-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3522</doc-id>
        <title>The Eifel Detection Algorithm for TCP</title>
        <author>
            <name>R. Ludwig</name>
        </author>
        <author>
            <name>M. Meyer</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33731</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>transmission control protocol</kw>
            <kw>loss recovery</kw>
            <kw>timestamps</kw>
        </keywords>
        <abstract>The Eifel detection algorithm allows a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily. It requires that the TCP Timestamps option defined in RFC 1323 be enabled for a connection. The Eifel detection algorithm makes use of the fact that the TCP Timestamps option eliminates the retransmission ambiguity in TCP. Based on the timestamp of the first acceptable ACK that arrives during loss recovery, it decides whether loss recovery was entered unnecessarily. The Eifel detection algorithm provides a basis for future TCP enhancements. This includes response algorithms to back out of loss recovery by restoring a TCP sender's congestion control state. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-tsvwg-tcp-eifel-alg-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3523</doc-id>
        <title>Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology</title>
        <author>
            <name>J. Polk</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10190</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>naming convetions</kw>
            <kw>phone</kw>
        </keywords>
        <abstract>This document defines the topology naming conventions that are to be used in reference to Internet Emergency Preparedness (IEPREP) phone calls. These naming conventions should be used to focus the IEPREP Working Group during discussions and when writing requirements, gap analysis and other solutions documents. This memo provides information for the Internet community. </abstract>
        <draft>polk-ieprep-scenarios-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3524</doc-id>
        <title>Mapping of Media Streams to Resource Reservation Flows</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>A. Monrad</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11249</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>sdp</kw>
            <kw>session description protocol</kw>
            <kw>srf</kw>
            <kw>single</kw>
        </keywords>
        <abstract>This document defines an extension to the Session Description Protocol (SDP) grouping framework. It allows requesting a group of media streams to be mapped into a single resource reservation flow. The SDP syntax needed is defined, as well as a new "semantics" attribute called Single Reservation Flow (SRF). [STANDARDS TRACK] </abstract>
        <draft>ietf-mmusic-reservation-flows-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3525</doc-id>
        <title>Gateway Control Protocol Version 1</title>
        <author>
            <name>C. Groves</name>
        </author>
        <author>
            <name>M. Pantaleo</name>
        </author>
        <author>
            <name>T. Anderson</name>
        </author>
        <author>
            <name>T. Taylor</name>
            <title>Editors</title>
        </author>
        <date>
            <month>June</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>439674</char-count>
            <page-count>213</page-count>
        </format>
        <keywords>
            <kw> MEGACO</kw>
            <kw>H.248</kw>
            <kw>media</kw>
            <kw>gateway</kw>
            <kw>control</kw>
        </keywords>
        <abstract>This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e., a Media Gateway and a Media Gateway Controller. The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805. This document replaces RFC 3015. It is the result of continued cooperation between the IETF Megaco Working Group and ITU-T Study Group 16. It incorporates the original text of RFC 3015, modified by corrections and clarifications discussed on the Megaco E-mail list and incorporated into the Study Group 16 Implementor's Guide for Recommendation H.248. The present version of this document underwent ITU-T Last Call as Recommendation H.248 Amendment 1. Because of ITU-T renumbering, it was published by the ITU-T as Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1. Users of this specification are advised to consult the H.248 Sub-series Implementors' Guide at http://www.itu.int/itudoc/itu-t/com16/implgd for additional corrections and clarifications. [STANDARDS TRACK] </abstract>
        <draft>ietf-megaco-3015corr-02</draft>
        <obsoletes>
            <doc-id>RFC3015</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3526</doc-id>
        <title>More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)</title>
        <author>
            <name>T. Kivinen</name>
        </author>
        <author>
            <name>M. Kojo</name>
        </author>
        <date>
            <month>May</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19166</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>bit groups</kw>
        </keywords>
        <abstract>This document defines new Modular Exponential (MODP) Groups for the Internet Key Exchange (IKE) protocol. It documents the well known and used 1536 bit group 5, and also defines new 2048, 3072, 4096, 6144, and 8192 bit Diffie-Hellman groups numbered starting at 14. The selection of the primes for theses groups follows the criteria established by Richard Schroeppel. [STANDARDS TRACK] </abstract>
        <draft>ietf-ipsec-ike-modp-groups-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3527</doc-id>
        <title>Link Selection sub-option for the Relay Agent Information Option for DHCPv4</title>
        <author>
            <name>K. Kinnear</name>
        </author>
        <author>
            <name>M. Stapp</name>
        </author>
        <author>
            <name>R. Johnson</name>
        </author>
        <author>
            <name>J. Kumarasamy</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16831</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>dynamic host configuration protocol</kw>
        </keywords>
        <abstract>This document describes the link selection sub-option of the relay- agent-information option for the Dynamic Host Configuration Protocol (DHCPv4). The giaddr specifies an IP address which determines both a subnet, and thereby a link on which a Dynamic Host Configuration Protocol (DHCP) client resides as well as an IP address that can be used to communicate with the relay agent. The subnet-selection option allows the functions of the giaddr to be split so that when one entity is performing as a DHCP proxy, it can specify the subnet/link from which to allocate an IP address, which is different from the IP address with which it desires to communicate with the DHCP server. Analogous situations exist where the relay agent needs to specify the subnet/link on which a DHCP client resides, which is different from an IP address that can be used to communicate with the relay agent. [STANDARDS TRACK] </abstract>
        <draft>ietf-dhc-agent-subnet-selection-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3528</doc-id>
        <title>Mesh-enhanced Service Location Protocol (mSLP)</title>
        <author>
            <name>W. Zhao</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>E. Guttman</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35208</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>da</kw>
            <kw>directory agent</kw>
            <kw>slpda</kw>
            <kw>service agent</kw>
            <kw>sa</kw>
            <kw>slpv2</kw>
        </keywords>
        <abstract>This document describes the Mesh-enhanced Service Location Protocol (mSLP). mSLP enhances the Service Location Protocol (SLP) with a scope-based fully-meshed peering Directory Agent (DA) architecture. Peer DAs exchange new service registrations in shared scopes via anti- entropy and direct forwarding. mSLP improves the reliability and consistency of SLP DA services, and simplifies Service Agent (SA) registrations in systems with multiple DAs. mSLP is backward compatible with SLPv2 and can be deployed incrementally. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>zhao-slp-da-interaction-16</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3529</doc-id>
        <title>Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP)</title>
        <author>
            <name>W. Harold</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23314</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>format</kw>
            <kw>messages</kw>
            <kw>clients</kw>
            <kw>servers</kw>
        </keywords>
        <abstract>Markup Language-Remote Procedure Calling protocol that works over the Internet. It defines an XML format for messages that are transfered between clients and servers using HTTP. An XML-RPC message encodes either a procedure to be invoked by the server, along with the parameters to use in the invocation, or the result of an invocation. Procedure parameters and results can be scalars, numbers, strings, dates, etc.; they can also be complex record and list structures. This document specifies a how to use the Blocks Extensible Exchange Protocol (BEEP) to transfer messages encoded in the XML-RPC format between clients and servers. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>harold-beep-xmlrpc-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3530</doc-id>
        <title>Network File System (NFS) version 4 Protocol</title>
        <author>
            <name>S. Shepler</name>
        </author>
        <author>
            <name>B. Callaghan</name>
        </author>
        <author>
            <name>D. Robinson</name>
        </author>
        <author>
            <name>R. Thurlow</name>
        </author>
        <author>
            <name>C. Beame</name>
        </author>
        <author>
            <name>M. Eisler</name>
        </author>
        <author>
            <name>D. Noveck</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>600988</char-count>
            <page-count>275</page-count>
        </format>
        <keywords>
            <kw>NFSv4</kw>
            <kw>network</kw>
            <kw>file</kw>
            <kw>system</kw>
        </keywords>
        <abstract>The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. This document replaces RFC 3010 as the definition of the NFS version 4 protocol. [STANDARDS TRACK] </abstract>
        <draft>ietf-nfsv4-rfc3010bis-04</draft>
        <obsoletes>
            <doc-id>RFC3010</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3531</doc-id>
        <title>A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block</title>
        <author>
            <name>M. Blanchet</name>
        </author>
        <date>
            <month>April</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11314</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>address plan</kw>
            <kw>addressing</kw>
            <kw>range</kw>
            <kw>space</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract>This document proposes a method to manage the assignment of bits of an IPv6 address block or range. When an organisation needs to make an address plan for its subnets or when an ISP needs to make an address plan for its customers, this method enables the organisation to postpone the final decision on the number of bits to partition in the address space they have. It does it by keeping the bits around the borders of the partition to be free as long as possible. This scheme is applicable to any bits addressing scheme using bits with partitions in the space, but its first intended use is for IPv6. It is a generalization of RFC 1219 and can be used for IPv6 assignments. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ipb6-ipaddressassign-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3532</doc-id>
        <title>Requirements for the Dynamic Partitioning of Switching Elements</title>
        <author>
            <name>T. Anderson</name>
        </author>
        <author>
            <name>J. Buerkle</name>
        </author>
        <date>
            <month>May</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25119</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>atm</kw>
            <kw>asynchronous transfer mode</kw>
        </keywords>
        <abstract>This document identifies a set of requirements for the mechanisms used to dynamically reallocate the resources of a switching element (e.g., an ATM switch) to its partitions. These requirements are particularly critical in the case of an operator creating a switch partition and then leasing control of that partition to a third party. This memo provides information for the Internet community. </abstract>
        <draft>ietf-gsmp-dyn-part-reqs-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3533</doc-id>
        <title>The Ogg Encapsulation Format Version 0</title>
        <author>
            <name>S. Pfeiffer</name>
        </author>
        <date>
            <month>May</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32045</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>bitstream</kw>
            <kw>media streams</kw>
            <kw>video</kw>
            <kw>audio</kw>
            <kw>xiph.org</kw>
            <kw>multimedia</kw>
            <kw>media interleading format</kw>
            <kw>video bitstream packaging</kw>
            <kw>audio bitstream packaging</kw>
            <kw>free encapsulation format</kw>
            <kw>stream based storage of codec data</kw>
            <kw>framed bitstream</kw>
        </keywords>
        <abstract>This document describes the Ogg bitstream format version 0, which is a general, freely-available encapsulation format for media streams. It is able to encapsulate any kind and number of video and audio encoding formats as well as other data streams in a single bitstream. This memo provides information for the Internet community. This memo provides information for the Internet community. </abstract>
        <draft>pfeiffer-ogg-fileformat-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3534</doc-id>
        <title>The application/ogg Media Type</title>
        <author>
            <name>L. Walleij</name>
        </author>
        <date>
            <month>May</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10013</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>mime</kw>
            <kw>multipurpose internet mail extenstions</kw>
        </keywords>
        <abstract>The Ogg Bitstream Format aims at becoming a general, freely-available standard for transporting multimedia content across computing platforms and networks. The intention of this document is to define the MIME media type application/ogg to refer to this kind of content when transported across the Internet. It is the intention of the Ogg Bitstream Format developers that it be usable without intellectual property concerns. [STANDARDS TRACK] </abstract>
        <draft>walleij-ogg-mediatype-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3535</doc-id>
        <title>Overview of the 2002 IAB Network Management Workshop</title>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>May</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42566</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>Internet Architecture Board</kw>
        </keywords>
        <abstract>This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Network Management. The workshop was hosted by CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The goal of the workshop was to continue the important dialog started between network operators and protocol developers, and to guide the IETFs focus on future work regarding network management. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community. This memo provides information for the Internet community. </abstract>
        <draft>iab-nm-workshop-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3536</doc-id>
        <title>Terminology Used in Internationalization in the IETF</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>May</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>64284</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>internet engineering task force</kw>
        </keywords>
        <abstract>This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This memo provides information for the Internet community. </abstract>
        <draft>hoffman-i18n-terms-11</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3537</doc-id>
        <title>Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>May</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16885</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document defines two methods for wrapping an HMAC (Hashed Message Authentication Code) key. The first method defined uses a Triple DES (Data Encryption Standard) key to encrypt the HMAC key. The second method defined uses an AES (Advanced Encryption Standard) key to encrypt the HMAC key. One place that such an algorithm is used is for the Authenticated Data type in CMS (Cryptographic Message Syntax). [PROPOSED STANDARD] </abstract>
        <draft>ietf-smime-hmac-key-wrap-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3538</doc-id>
        <title>Secure Electronic Transaction (SET) Supplement for the v1.0 Internet Open Trading Protocol (IOTP)</title>
        <author>
            <name>Y. Kawatsura</name>
        </author>
        <date>
            <month>June</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>103475</char-count>
            <page-count>56</page-count>
        </format>
        <keywords>
            <kw>payment</kw>
            <kw>input</kw>
            <kw>output</kw>
            <kw>parameter</kw>
        </keywords>
        <abstract>This document describes detailed Input/Output parameters for the Internet Open Trading Protocol (IOTP) Payment Application Programming Interface (API). It also describes procedures in the Payment Bridge for the use of SET (SET Secure Electronic Transaction) as the payment protocol within Version 1.0 of the IOTP. This memo provides information for the Internet community. </abstract>
        <draft>ietf-trade-iotp-v1.0-set-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3539</doc-id>
        <title>Authentication, Authorization and Accounting (AAA) Transport Profile</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>J. Wood</name>
        </author>
        <date>
            <month>June</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>93110</char-count>
            <page-count>41</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document discusses transport issues that arise within protocols for Authentication, Authorization and Accounting (AAA). It also provides recommendations on the use of transport by AAA protocols. This includes usage of standards-track RFCs as well as experimental proposals. [STANDARDS TRACK] </abstract>
        <draft>ietf-aaa-transport-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3540</doc-id>
        <title>Robust Explicit Congestion Notification (ECN) Signaling with Nonces</title>
        <author>
            <name>N. Spring</name>
        </author>
        <author>
            <name>D. Wetherall</name>
        </author>
        <author>
            <name>D. Ely</name>
        </author>
        <date>
            <month>June</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30081</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>congestion control</kw>
            <kw>tcp</kw>
            <kw>traffic control protocol</kw>
        </keywords>
        <abstract>This note describes the Explicit Congestion Notification (ECN)-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender. It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth. The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP header, and requires a flag in the TCP header. It is computationally efficient for both routers and hosts. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-tsvwg-tcp-nonce-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3541</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for the Web3D Consortium (Web3D)</title>
        <author>
            <name>A. Walsh</name>
        </author>
        <date>
            <month>May</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11358</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>virtual reality monitoring language</kw>
            <kw>vrml</kw>
            <kw>extensible markup language</kw>
            <kw>x3d</kw>
            <kw>xml</kw>
            <kw>dtd</kw>
            <kw>document type definition</kw>
        </keywords>
        <abstract>This document describes a Uniform Resource Name (URN) namespace for the Web3D Consortium (Web3D) for naming persistent resources such as technical documents and specifications, Virtual Reality Modeling Language (VRML) and Extensible 3D (X3D) files and resources, Extensible Markup Language (XML) Document Type Definitions (DTDs), XML Schemas, namespaces, style sheets, media assets, and other resources produced or managed by Web3D. This memo provides information for the Internet community. </abstract>
        <draft>walsh-urn-web3d-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3542</doc-id>
        <title>Advanced Sockets Application Program Interface (API) for IPv6</title>
        <author>
            <name>W. Stevens</name>
        </author>
        <author>
            <name>M. Thomas</name>
        </author>
        <author>
            <name>E. Nordmark</name>
        </author>
        <author>
            <name>T. Jinmei</name>
        </author>
        <date>
            <month>May</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>173028</char-count>
            <page-count>77</page-count>
        </format>
        <keywords>
            <kw>application</kw>
            <kw>program</kw>
            <kw>interface</kw>
        </keywords>
        <abstract>This document provides sockets Application Program Interface (API) to support "advanced" IPv6 applications, as a supplement to a separate specification, RFC 3493. The expected applications include Ping, Traceroute, routing daemons and the like, which typically use raw sockets to access IPv6 or ICMPv6 header fields. This document proposes some portable interfaces for applications that use raw sockets under IPv6. There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface), IPv6 extension headers, and path Maximum Transmission Unit (MTU) information. This document provides API access to these features too. Additionally, some extended interfaces to libraries for the "r" commands are defined. The extension will provide better backward compatibility to existing implementations that are not IPv6-capable. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ipngwg-rfc2292bis-09</draft>
        <obsoletes>
            <doc-id>RFC2292</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3543</doc-id>
        <title>Registration Revocation in Mobile IPv4</title>
        <author>
            <name>S. Glass</name>
        </author>
        <author>
            <name>M. Chandra</name>
        </author>
        <date>
            <month>August</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>81805</char-count>
            <page-count>33</page-count>
        </format>
        <keywords>
            <kw>internet protocol</kw>
        </keywords>
        <abstract>This document defines a Mobile IPv4 Registration Revocation mechanism whereby a mobility agent involved in providing Mobile IP services to a mobile node can notify the other mobility agent providing Mobile IP services to the same mobile node of the termination of this registration. The mechanism is also usable by a home agent to notify a co-located mobile node of the termination of its binding as well. Moreover, the mechanism provides for this notification to be acknowledged. A signaling mechanism already defined by the Mobile IPv4 protocol is leveraged as a way to inform a mobile node of the revocation of its binding. [STANDARDS TRACK] </abstract>
        <draft>ietf-mobileip-reg-revok-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3544</doc-id>
        <title>IP Header Compression over PPP</title>
        <author>
            <name>M. Engan</name>
        </author>
        <author>
            <name>S. Casner</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>T. Koren</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27627</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>IPCOM-PPP</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>point-to-point</kw>
            <kw>datagrams</kw>
        </keywords>
        <abstract>This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol (RFC 1661). It defines extensions to the PPP Control Protocols for IPv4 and IPv6 (RFC 1332, RFC 2472). Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols as specified in RFC 2507, RFC 2508 and RFC 3545. [STANDARDS TRACK] </abstract>
        <draft>koren-pppext-rfc2509bis-03</draft>
        <obsoletes>
            <doc-id>RFC2509</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3545</doc-id>
        <title>Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering</title>
        <author>
            <name>T. Koren</name>
        </author>
        <author>
            <name>S. Casner</name>
        </author>
        <author>
            <name>J. Geevarghese</name>
        </author>
        <author>
            <name>B. Thompson</name>
        </author>
        <author>
            <name>P. Ruddy</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48278</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>point to point</kw>
            <kw>header</kw>
        </keywords>
        <abstract>This document describes a header compression scheme for point to point links with packet loss and long delays. It is based on Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression described in RFC 2508. CRTP does not perform well on such links: packet loss results in context corruption and due to the long delay, many more packets are discarded before the context is repaired. To correct the behavior of CRTP over such links, a few extensions to the protocol are specified here. The extensions aim to reduce context corruption by changing the way the compressor updates the context at the decompressor: updates are repeated and include updates to full and differential context parameters. With these extensions, CRTP performs well over links with packet loss, packet reordering and long delays. [STANDARDS TRACK] </abstract>
        <draft>ietf-avt-crtp-enhance-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3546</doc-id>
        <title>Transport Layer Security (TLS) Extensions</title>
        <author>
            <name>S. Blake-Wilson</name>
        </author>
        <author>
            <name>M. Nystrom</name>
        </author>
        <author>
            <name>D. Hopwood</name>
        </author>
        <author>
            <name>J. Mikkelsen</name>
        </author>
        <author>
            <name>T. Wright</name>
        </author>
        <date>
            <month>June</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63437</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>transport</kw>
            <kw>protocol</kw>
            <kw>layer</kw>
            <kw>authentication</kw>
            <kw>privacy</kw>
        </keywords>
        <abstract>This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms. The extensions may be used by TLS clients and servers. The extensions are backwards compatible - communication is possible between TLS 1.0 clients that support the extensions and TLS 1.0 servers that do not support the extensions, and vice versa. [STANDARDS TRACK] </abstract>
        <draft>ietf-tls-extensions-06</draft>
        <updates>
            <doc-id>RFC2246</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3547</doc-id>
        <title>The Group Domain of Interpretation</title>
        <author>
            <name>M. Baugher</name>
        </author>
        <author>
            <name>B. Weis</name>
        </author>
        <author>
            <name>T. Hardjono</name>
        </author>
        <author>
            <name>H. Harney</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>108901</char-count>
            <page-count>48</page-count>
        </format>
        <keywords>
            <kw>isamkp</kw>
            <kw>doi</kw>
            <kw>key management</kw>
            <kw>security</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract>This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. The GDOI manages group security associations, which are used by IPSEC and potentially other data security protocols running at the IP or application layers. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. [STANDARDS TRACK] </abstract>
        <draft>ietf-msec-gdoi-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3548</doc-id>
        <title>The Base16, Base32, and Base64 Data Encodings</title>
        <author>
            <name>S. Josefsson</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26363</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>schemes</kw>
            <kw>data</kw>
            <kw>line-feeds</kw>
            <kw>alphabets</kw>
            <kw>base encoding</kw>
            <kw>hex</kw>
        </keywords>
        <abstract>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, and use of different encoding alphabets. This memo provides information for the Internet community. </abstract>
        <draft>josefsson-base-encoding-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3549</doc-id>
        <title>Linux Netlink as an IP Services Protocol</title>
        <author>
            <name>J. Salim</name>
        </author>
        <author>
            <name>H. Khosravi</name>
        </author>
        <author>
            <name>A. Kleen</name>
        </author>
        <author>
            <name>A. Kuznetsov</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>72161</char-count>
            <page-count>33</page-count>
        </format>
        <keywords>
            <kw>internet protocol messaging system</kw>
        </keywords>
        <abstract>This document describes Linux Netlink, which is used in Linux both as an intra-kernel messaging system as well as between kernel and user space. The focus of this document is to describe Netlink's functionality as a protocol between a Forwarding Engine Component (FEC) and a Control Plane Component (CPC), the two components that define an IP service. As a result of this focus, this document ignores other uses of Netlink, including its use as a intra-kernel messaging system, as an inter- process communication scheme (IPC), or as a configuration tool for other non-networking or non-IP network services (such as decnet, etc.). This document is intended as informational in the context of prior art for the ForCES IETF working group. This memo provides information for the Internet community. </abstract>
        <draft>ietf-forces-netlink-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3550</doc-id>
        <title>RTP: A Transport Protocol for Real-Time Applications</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>S.  Casner</name>
        </author>
        <author>
            <name>R. Frederick</name>
        </author>
        <author>
            <name>V. Jacobson</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>259985</char-count>
            <page-count>104</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>630740</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>504117</char-count>
        </format>
        <keywords>
            <kw>RTP</kw>
            <kw>end-to-end</kw>
            <kw>network</kw>
            <kw>audio</kw>
            <kw>video</kw>
            <kw>RTCP</kw>
        </keywords>
        <abstract>This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS TRACK] </abstract>
        <draft>ietf-avt-rtp-new-12</draft>
        <notes>Upgraded to full standard 5/17/04.</notes>
        <obsoletes>
            <doc-id>RFC1889</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0064</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3551</doc-id>
        <title>RTP Profile for Audio and Video Conferences with Minimal Control</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>S. Casner</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>106621</char-count>
            <page-count>44</page-count>
        </format>
        <format>
            <file-format>PS</file-format>
            <char-count>317286</char-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>237831</char-count>
        </format>
        <keywords>
            <kw>RTP-AV</kw>
            <kw>end-to-end</kw>
            <kw>network</kw>
            <kw>conference</kw>
        </keywords>
        <abstract>This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. [STANDARDS TRACK] </abstract>
        <draft>ietf-avt-profile-new-13</draft>
        <notes>Upgraded to full standard 5/17/04.</notes>
        <obsoletes>
            <doc-id>RFC1890</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0065</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3552</doc-id>
        <title>Guidelines for Writing RFC Text on Security Considerations</title>
        <author>
            <name>E. Rescorla</name>
        </author>
        <author>
            <name>B. Korver</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>110393</char-count>
            <page-count>44</page-count>
        </format>
        <keywords>
            <kw>Request for Comment</kw>
        </keywords>
        <abstract>All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>iab-sec-cons-03</draft>
        <is-also>
            <doc-id>BCP0072</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3553</doc-id>
        <title>An IETF URN Sub-namespace for Registered Protocol Parameters</title>
        <author>
            <name>M. Mealling</name>
        </author>
        <author>
            <name>L. Masinter</name>
        </author>
        <author>
            <name>T. Hardie</name>
        </author>
        <author>
            <name>G. Klyne</name>
        </author>
        <date>
            <month>June</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14815</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>syntax</kw>
            <kw>uniform resource names</kw>
        </keywords>
        <abstract>This document describes a new sub-delegation for the 'ietf' URN namespace for registered protocol items. The 'ietf' URN namespace is defined in RFC 2648 as a root for persistent URIs that refer to IETF- defined resources. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>mealling-iana-urn-04</draft>
        <is-also>
            <doc-id>BCP0073</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3554</doc-id>
        <title>On the Use of Stream Control Transmission Protocol (SCTP) with IPsec</title>
        <author>
            <name>S. Bellovin</name>
        </author>
        <author>
            <name>J. Ioannidis</name>
        </author>
        <author>
            <name>A. Keromytis</name>
        </author>
        <author>
            <name>R. Stewart</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20102</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>ike</kw>
            <kw>internet key exchange</kw>
            <kw>security</kw>
        </keywords>
        <abstract>This document describes functional requirements for IPsec (RFC 2401) and Internet Key Exchange (IKE) (RFC 2409) to facilitate their use in securing SCTP (RFC 2960) traffic. [STANDARDS TRACK] </abstract>
        <draft>ietf-ipsec-sctp-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3555</doc-id>
        <title>MIME Type Registration of RTP Payload Formats</title>
        <author>
            <name>S. Casner</name>
        </author>
        <author>
            <name>P. Hoschka</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>56618</char-count>
            <page-count>45</page-count>
        </format>
        <keywords>
            <kw>real time transport protocol</kw>
            <kw>multipurpose internet mail extensions</kw>
        </keywords>
        <abstract>This document defines the procedure to register RTP Payload Formats as audio, video or other MIME subtype names. This is useful in a text- based format or control protocol to identify the type of an RTP transmission. This document also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences as MIME subtypes. Some of these may also be used for transfer modes other than RTP. [STANDARDS TRACK] </abstract>
        <draft>ietf-avt-rtp-mime-06</draft>
        <updated-by>
            <doc-id>RFC3625</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3556</doc-id>
        <title>Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth</title>
        <author>
            <name>S. Casner</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15310</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>real time transport protocol</kw>
            <kw>real-time</kw>
        </keywords>
        <abstract>This document defines an extension to the Session Description Protocol (SDP) to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTP Control Protocol (RTCP) packets in a Real-time Transport Protocol (RTP) session. [STANDARDS TRACK] </abstract>
        <draft>ietf-avt-rtcp-bw-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3557</doc-id>
        <title>RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding</title>
        <author>
            <name>Q. Xie</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29692</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>real time transport protocol</kw>
            <kw>real-time</kw>
            <kw>dsr</kw>
        </keywords>
        <abstract>This document specifies an RTP payload format for encapsulating European Telecommunications Standards Institute (ETSI) European Standard (ES) 201 108 front-end signal processing feature streams for distributed speech recognition (DSR) systems. [STANDARDS TRACK] </abstract>
        <draft>ietf-avt-dsr-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3558</doc-id>
        <title>RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)</title>
        <author>
            <name>A. Li</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49787</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>real time transport protocol</kw>
            <kw>real-time</kw>
            <kw>bundled</kw>
            <kw>interleaved</kw>
        </keywords>
        <abstract>This document describes the RTP payload format for Enhanced Variable Rate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech. Two sub-formats are specified for different application scenarios. A bundled/interleaved format is included to reduce the effect of packet loss on speech quality and amortize the overhead of the RTP header over more than one speech frame. A non-bundled format is also supported for conversational applications. [STANDARDS TRACK] </abstract>
        <draft>ietf-avt-evrc-smv-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3559</doc-id>
        <title>Multicast Address Allocation MIB</title>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>June</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>68239</char-count>
            <page-count>37</page-count>
        </format>
        <keywords>
            <kw>maas</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multicast address allocation. [STANDARDS TRACK] </abstract>
        <draft>ietf-malloc-malloc-mib-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3560</doc-id>
        <title>Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37381</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>security encryption</kw>
        </keywords>
        <abstract>This document describes the conventions for using the RSAES-OAEP key transport algorithm with the Cryptographic Message Syntax (CMS). The CMS specifies the enveloped-data content type, which consists of an encrypted content and encrypted content-encryption keys for one or more recipients. The RSAES-OAEP key transport algorithm can be used to encrypt content-encryption keys for intended recipients. [STANDARDS TRACK] </abstract>
        <draft>ietf-smime-cms-rsaes-oaep-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3561</doc-id>
        <title>Ad hoc On-Demand Distance Vector (AODV) Routing</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>E. Belding-Royer</name>
        </author>
        <author>
            <name>S. Das</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>90356</char-count>
            <page-count>37</page-count>
        </format>
        <keywords>
            <kw>unicast</kw>
            <kw>multiple nodes</kw>
        </keywords>
        <abstract>The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), avoiding problems (such as "counting to infinity") associated with classical distance vector protocols. This memo defines an Experimental Protocol for the Internet community. </abstract>
        <draft>ietf-manet-aodv-13</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3562</doc-id>
        <title>Key Management Considerations for the TCP MD5 Signature Option</title>
        <author>
            <name>M. Leech</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14965</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw> bgp</kw>
            <kw>border gateway protocol</kw>
            <kw>security</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract>The TCP MD5 Signature Option (RFC 2385), used predominantly by BGP, has seen significant deployment in critical areas of Internet infrastructure. The security of this option relies heavily on the quality of the keying material used to compute the MD5 signature. This document addresses the security requirements of that keying material. This memo provides information for the Internet community. </abstract>
        <draft>ietf-idr-md5-keys-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3563</doc-id>
        <title>Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development</title>
        <author>
            <name>A. Zinin</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14974</char-count>
            <page-count>8</page-count>
        </format>
        <abstract>This document contains the text of the agreement signed between ISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of the IS-IS routing protocol. The agreement includes definitions of the related work scopes for the two organizations, request for creation and maintenance of an IS-IS registry by IANA, as well as collaboration guidelines. This memo provides information for the Internet community. </abstract>
        <draft>zinin-ietf-jtc1-aggr-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3564</doc-id>
        <title>Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering</title>
        <author>
            <name>F. Le Faucheur</name>
        </author>
        <author>
            <name>W. Lai</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>50808</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>multi-protocol label switching</kw>
            <kw>bandwidth constraints model</kw>
            <kw>overbooking</kw>
        </keywords>
        <abstract>This document presents Service Provider requirements for support of Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering (DS- TE). Its objective is to provide guidance for the definition, selection and specification of a technical solution addressing these requirements. Specification for this solution itself is outside the scope of this document. A problem statement is first provided. Then, the document describes example applications scenarios identified by Service Providers where existing MPLS Traffic Engineering mechanisms fall short and Diff-Serv-aware Traffic Engineering can address the needs. The detailed requirements that need to be addressed by the technical solution are also reviewed. Finally, the document identifies the evaluation criteria that should be considered for selection and definition of the technical solution. This memo provides information for the Internet community. </abstract>
        <draft>ietf-tewg-diff-te-reqts-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3565</doc-id>
        <title>Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>J. Schaad</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26773</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>data encoding</kw>
        </keywords>
        <abstract>This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm for encryption with the Cryptographic Message Syntax (CMS). [STANDARDS TRACK] </abstract>
        <draft>ietf-smime-aes-alg-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3566</doc-id>
        <title>The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec</title>
        <author>
            <name>S. Frankel</name>
        </author>
        <author>
            <name>H. Herbert</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24645</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>authentication</kw>
            <kw>hash security</kw>
        </keywords>
        <abstract>A Message Authentication Code (MAC) is a key-dependent one way hash function. One popular way to construct a MAC algorithm is to use a block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of operation. The classic CBC-MAC algorithm, while secure for messages of a pre-selected fixed length, has been shown to be insecure across messages of varying lengths such as the type found in typical IP datagrams. This memo specifies the use of AES in CBC mode with a set of extensions to overcome this limitation. This new algorithm is named AES-XCBC-MAC-96. [STANDARDS TRACK] </abstract>
        <draft>ietf-ipsec-ciph-aes-xcbc-mac-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3567</doc-id>
        <title>Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication</title>
        <author>
            <name>T. Li</name>
        </author>
        <author>
            <name>R. Atkinson</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13467</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>iso</kw>
            <kw>international standards organization</kw>
        </keywords>
        <abstract>This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. This memo provides information for the Internet community. </abstract>
        <draft>ietf-isis-hmac-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3568</doc-id>
        <title>Known Content Network (CN) Request-Routing Mechanisms</title>
        <author>
            <name>A. Barbir</name>
        </author>
        <author>
            <name>B. Cain</name>
        </author>
        <author>
            <name>R. Nair</name>
        </author>
        <author>
            <name>O. Spatscheck</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42443</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>metrics</kw>
            <kw>routing</kw>
            <kw>redirection</kw>
        </keywords>
        <abstract>This document presents a summary of Request-Routing techniques that are used to direct client requests to surrogates based on various policies and a possible set of metrics. The document covers techniques that were commonly used in the industry on or before December 2000. In this memo, the term Request-Routing represents techniques that is commonly called content routing or content redirection. In principle, Request-Routing techniques can be classified under: DNS Request-Routing, Transport-layer Request-Routing, and Application-layer Request-Routing. This memo provides information for the Internet community. </abstract>
        <draft>ietf-cdi-known-request-routing-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3569</doc-id>
        <title>An Overview of Source-Specific Multicast (SSM)</title>
        <author>
            <name>S. Bhattacharyya</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29387</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>routing applications</kw>
            <kw>deployment interoperability</kw>
        </keywords>
        <abstract>The purpose of this document is to provide an overview of Source-Specific Multicast (SSM) and issues related to its deployment. It discusses how the SSM service model addresses the challenges faced in inter-domain multicast deployment, changes needed to routing protocols and applications to deploy SSM and interoperability issues with current multicast service models. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ssm-overview-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3570</doc-id>
        <title>Content Internetworking (CDI) Scenarios</title>
        <author>
            <name>P. Rzewski</name>
        </author>
        <author>
            <name>M. Day</name>
        </author>
        <author>
            <name>D. Gilletti</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42432</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>production networks</kw>
        </keywords>
        <abstract>In describing content internetworking as a technology targeted for use in production networks, it is useful to provide examples of the sequence of events that may occur when two content networks decide to interconnect. The scenarios presented here seek to provide some concrete examples of what content internetworking is, and also to provide a basis for evaluating content internetworking proposals. This memo provides information for the Internet community. </abstract>
        <draft>ietf-cdi-scenarios-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3571</doc-id>
        <title>Framework Policy Information Base for Usage Feedback</title>
        <author>
            <name>D. Rawlins</name>
        </author>
        <author>
            <name>A. Kulkarni</name>
        </author>
        <author>
            <name>K. Ho Chan</name>
        </author>
        <author>
            <name>M. Bokaemper</name>
        </author>
        <author>
            <name>D. Dutt</name>
        </author>
        <date>
            <month>August</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>70894</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
            <kw>pib</kw>
        </keywords>
        <abstract>This document describes a portion of the Policy Information Base (PIB) to control policy usage collection and reporting in a device. The provisioning classes specified here allow a Policy Decision Point (PDP) to select which policy objects should collect usage information, what information should be collected and when it should be reported. This PIB requires the presence of other PIBs (defined elsewhere) that provide the policy objects from which usage information is collected. This memo provides information for the Internet community. </abstract>
        <draft>ietf-rap-feedback-fr-pib-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3572</doc-id>
        <title>Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH)</title>
        <author>
            <name>T. Ogura</name>
        </author>
        <author>
            <name>M. Maruyama</name>
        </author>
        <author>
            <name>T. Yoshida</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30607</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>ipv6</kw>
            <kw>synchronous optical network</kw>
            <kw>synchronous digital hierarchy</kw>
        </keywords>
        <abstract>Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link- layer protocol that provides multiple access capability over a Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH). This document specifies the frame format for encapsulating an IPv6 datagram in a MAPOS frame. It also specifies the method of forming IPv6 interface identifiers, the method of detecting duplicate addresses, and the format of the Source/Target Link-layer Addresses option field used in IPv6 Neighbor Discovery messages. This memo provides information for the Internet community. </abstract>
        <draft>ogura-ipv6-mapos-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3573</doc-id>
        <title>Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP)</title>
        <author>
            <name>I. Goyret</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22758</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>ppp</kw>
            <kw>point to point</kw>
            <kw>point-to-point</kw>
            <kw>pstn</kw>
            <kw>public switched telephone network</kw>
        </keywords>
        <abstract>The Layer 2 Tunneling Protocol (L2TP) defines a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. It is common for these PPP sessions to be established using modems connected over the public switched telephone network. One of the standards governing modem operation defines procedures that enable a client modem to put the call on hold and later, re-establish the modem link with minimal delay and without having to redial. While the modem call is on hold, the client phone line can be used to place or receive other calls. The L2TP base protocol does not provide any means to signal these events from the L2TP Access Controller (LAC), where the modem is physically connected, to the L2TP Network Server (LNS), where the PPP session is handled. This document describes a method to let the LNS know when a client modem connected to a LAC has placed the call on hold. [STANDARDS TRACK] </abstract>
        <draft>ietf-l2tpext-v92-moh-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3574</doc-id>
        <title>Transition Scenarios for 3GPP Networks</title>
        <author>
            <name>J. Soininen</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23359</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>third generation parnership project</kw>
            <kw>packet</kw>
            <kw>ipv6</kw>
            <kw>ipv4</kw>
            <kw>internet</kw>
        </keywords>
        <abstract>This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e., General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g., in the Internet. GPRS network internal transition scenarios, i.e., between different GPRS elements in the network, are out of scope. The purpose of the document is to list the scenarios for further discussion and study. This memo provides information for the Internet community. </abstract>
        <draft>ietf-v6ops-3gpp-cases-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3575</doc-id>
        <title>IANA Considerations for RADIUS (Remote Authentication Dial In User Service)</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15539</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>internet assigned numbers authority</kw>
            <kw>encryption</kw>
            <kw>NAS</kw>
            <kw>Network</kw>
            <kw>Access</kw>
            <kw>Server</kw>
        </keywords>
        <abstract>This document describes the IANA considerations for the Remote Authentication Dial In User Service (RADIUS). [STANDARDS TRACK] </abstract>
        <draft>aboba-radius-iana-07</draft>
        <updates>
            <doc-id>RFC2865</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3576</doc-id>
        <title>Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)</title>
        <author>
            <name>M. Chiba</name>
        </author>
        <author>
            <name>G. Dommety</name>
        </author>
        <author>
            <name>M. Eklund</name>
        </author>
        <author>
            <name>D. Mitton</name>
        </author>
        <author>
            <name>B. Aboba</name>
        </author>
        <date>
            <month>July</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>70027</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>nas</kw>
            <kw>network access server</kw>
        </keywords>
        <abstract>This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. This memo provides information for the Internet community. </abstract>
        <draft>chiba-radius-dynamic-authorization-20</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3577</doc-id>
        <title>Introduction to the Remote Monitoring (RMON) Family of MIB Modules</title>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <author>
            <name>R. Cole</name>
        </author>
        <author>
            <name>C. Kalbfleisch</name>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <date>
            <month>August</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>68551</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>management information base</kw>
        </keywords>
        <abstract>The Remote Monitoring (RMON) Framework consists of a number of interrelated documents. This memo describes these documents and how they relate to one another. This memo provides information for the Internet community. </abstract>
        <draft>ietf-rmonmib-framework-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3578</doc-id>
        <title>Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>A. B. Roach</name>
        </author>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>L. Ong</name>
        </author>
        <date>
            <month>August</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26667</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>pstn</kw>
            <kw>public switched telephone network</kw>
        </keywords>
        <abstract>This document describes a way to map Integrated Services Digital Network User Part (ISUP) overlap signalling to Session Initiation Protocol (SIP). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN). [STANDARDS TRACK] </abstract>
        <draft>ietf-sipping-overlap-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3579</doc-id>
        <title>RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>P. Calhoun</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>104469</char-count>
            <page-count>46</page-count>
        </format>
        <keywords>
            <kw>RADIUS</kw>
            <kw>encryption</kw>
            <kw>NAS</kw>
            <kw>Network</kw>
            <kw>Access</kw>
            <kw>Server</kw>
        </keywords>
        <abstract>This document defines Remote Authentication Dial In User Service (RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method- specific code, which resides on the RADIUS server. While EAP was originally developed for use with PPP, it is now also in use with IEEE 802. This memo provides information for the Internet community. </abstract>
        <draft>aboba-radius-rfc2869bis-22</draft>
        <updates>
            <doc-id>RFC2869</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3580</doc-id>
        <title>IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines</title>
        <author>
            <name>P. Congdon</name>
        </author>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>A. Smith</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>J. Roese</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>66136</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>AAA</kw>
            <kw>authentication</kw>
            <kw>authorization and accounting</kw>
        </keywords>
        <abstract>This document provides suggestions on Remote Authentication Dial In User Service (RADIUS) usage by IEEE 802.1X Authenticators. The material in this document is also included within a non-normative Appendix within the IEEE 802.1X specification, and is being presented as an IETF RFC for informational purposes. This memo provides information for the Internet community. </abstract>
        <draft>congdon-radius-8021x-29</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3581</doc-id>
        <title>An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>August</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>66133</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>report client server</kw>
        </keywords>
        <abstract>The Session Initiation Protocol (SIP) operates over UDP and TCP, among others. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This behavior is not desirable in many cases, most notably, when the client is behind a Network Address Translator (NAT). This extension defines a new parameter for the Via header field, called "rport", that allows a client to request that the server send the response back to the source IP address and port from which the request originated. [STANDARDS TRACK] </abstract>
        <draft>ietf-sip-symmetric-response-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3582</doc-id>
        <title>Goals for IPv6 Site-Multihoming Architectures</title>
        <author>
            <name>J. Abley</name>
        </author>
        <author>
            <name>B. Black</name>
        </author>
        <author>
            <name>V. Gill</name>
        </author>
        <date>
            <month>August</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17045</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>internet protocol</kw>
            <kw>multi6</kw>
        </keywords>
        <abstract>This document outlines a set of goals for proposed new IPv6 site- multihoming architectures. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented here. This memo provides information for the Internet community. </abstract>
        <draft>ietf-multi6-multihoming-requirements-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3583</doc-id>
        <title>Requirements of a Quality of Service (QoS) Solution for Mobile IP</title>
        <author>
            <name>H. Chaskar</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22541</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>internet protocol</kw>
            <kw>routing packets</kw>
            <kw>node</kw>
        </keywords>
        <abstract>Mobile IP ensures correct routing of packets to a mobile node as the mobile node changes its point of attachment to the Internet. However, it is also required to provide proper Quality of Service (QoS) forwarding treatment to the mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP. This document describes requirements for an IP QoS mechanism for its satisfactory operation with Mobile IP. This memo provides information for the Internet community. </abstract>
        <draft>ietf-nsis-qos-requirements-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3584</doc-id>
        <title>Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework</title>
        <author>
            <name>R. Frye</name>
        </author>
        <author>
            <name>D. Levi</name>
        </author>
        <author>
            <name>S. Routhier</name>
        </author>
        <author>
            <name>B. Wijnen</name>
        </author>
        <date>
            <month>August</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>115222</char-count>
            <page-count>51</page-count>
        </format>
        <keywords>
            <kw>SNMP</kw>
            <kw>simple network management protocol</kw>
            <kw>mib information base</kw>
        </keywords>
        <abstract>The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). This document also describes how to convert MIB modules from SMIv1 format to SMIv2 format. This document obsoletes RFC 2576. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. </abstract>
        <draft>ietf-snmpv3-coex-v2-04</draft>
        <obsoletes>
            <doc-id>RFC2576</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0074</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3585</doc-id>
        <title>IPsec Configuration Policy Information Model</title>
        <author>
            <name>J. Jason</name>
        </author>
        <author>
            <name>L. Rafalow</name>
        </author>
        <author>
            <name>E. Vyncke</name>
        </author>
        <date>
            <month>August</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>187308</char-count>
            <page-count>88</page-count>
        </format>
        <keywords>
            <kw>ike</kw>
            <kw>internet key exchange protocol</kw>
            <kw>core</kw>
            <kw>pcim</kw>
        </keywords>
        <abstract>This document presents an object-oriented information model of IP Security (IPsec) policy designed to facilitate agreement about the content and semantics of IPsec policy, and enable derivations of task- specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec-enabled endpoints. The information model described in this document models the configuration parameters defined by IPSec. The information model also covers the parameters found by the Internet Key Exchange protocol (IKE). Other key exchange protocols could easily be added to the information model by a simple extension. Further extensions can further be added easily due to the object-oriented nature of the model. This information model is based upon the core policy classes as defined in the Policy Core Information Model (PCIM) and in the Policy Core Information Model Extensions (PCIMe). [STANDARDS TRACK] </abstract>
        <draft>ietf-ipsp-config-policy-model-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3586</doc-id>
        <title>IP Security Policy (IPSP) Requirements</title>
        <author>
            <name>M. Blaze</name>
        </author>
        <author>
            <name>A. Keromytis</name>
        </author>
        <author>
            <name>M. Richardson</name>
        </author>
        <author>
            <name>L. Sanchez</name>
        </author>
        <date>
            <month>August</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22068</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>data integrity</kw>
            <kw>authentication</kw>
            <kw>host network</kw>
        </keywords>
        <abstract>This document describes the problem space and solution requirements for developing an IP Security Policy (IPSP) configuration and management framework. The IPSP architecture provides a scalable, decentralized framework for managing, discovering and negotiating the host and network security policies that govern access, authorization, authentication, confidentiality, data integrity, and other IP Security properties. This document highlights such architectural components and presents their functional requirements. [STANDARDS TRACK] </abstract>
        <draft>ietf-ipsp-requirements-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3587</doc-id>
        <title>IPv6 Global Unicast Address Format</title>
        <author>
            <name>R. Hinden</name>
        </author>
        <author>
            <name>S. Deering</name>
        </author>
        <author>
            <name>E. Nordmark</name>
        </author>
        <date>
            <month>August</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8783</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>architecture</kw>
            <kw>routing</kw>
        </keywords>
        <abstract>This document obsoletes RFC 2374, "An IPv6 Aggregatable Global Unicast Address Format". It defined an IPv6 address allocation structure that includes Top Level Aggregator (TLA) and Next Level Aggregator (NLA). This document makes RFC 2374 and the TLA/NLA structure historic. This memo provides information for the Internet community. </abstract>
        <draft>ietf-ipv6-unicast-aggr-v2-03</draft>
        <obsoletes>
            <doc-id>RFC2374</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3588</doc-id>
        <title>Diameter Base Protocol</title>
        <author>
            <name>P. Calhoun</name>
        </author>
        <author>
            <name>J. Loughney</name>
        </author>
        <author>
            <name>E. Guttman</name>
        </author>
        <author>
            <name>G. Zorn</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>341261</char-count>
            <page-count>147</page-count>
        </format>
        <keywords>
            <kw>aaa</kw>
            <kw>authentication authorization accounting</kw>
            <kw>ip mobility</kw>
        </keywords>
        <abstract>The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization &amp; Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. [STANDARDS TRACK] </abstract>
        <draft>ietf-aaa-diameter-17</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3589</doc-id>
        <title>Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5</title>
        <author>
            <name>J. Loughney</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8010</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>iana</kw>
            <kw>allocation</kw>
        </keywords>
        <abstract>This document describes the IANA's allocation of a block of Diameter Command Codes for the Third Generation Partnership Project (3GPP) Release 5. This document does not pass judgment on the usage of these command codes. Further more, these command codes are for use for Release 5. For future releases, these codes cannot be reused, but must be allocated according to the Diameter Base specification. This memo provides information for the Internet community. </abstract>
        <draft>loughney-aaa-cc-3gpp-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3590</doc-id>
        <title>Source Address Selection for the Multicast Listener Discovery (MLD) Protocol</title>
        <author>
            <name>B. Haberman</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11554</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>MLD-IPv6</kw>
            <kw>internet protocol</kw>
            <kw>routher</kw>
            <kw>packets</kw>
        </keywords>
        <abstract>It has come to light that there is an issue with the selection of a suitable IPv6 source address for Multicast Listener Discovery (MLD) messages when a node is performing stateless address autoconfiguration. This document is intended to clarify the rules on selecting an IPv6 address to use for MLD messages. [STANDARDS TRACK] </abstract>
        <draft>ietf-magma-mld-source-07</draft>
        <updates>
            <doc-id>RFC2710</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3591</doc-id>
        <title>Definitions of Managed Objects for the Optical Interface Type</title>
        <author>
            <name>H-K. Lam</name>
        </author>
        <author>
            <name>M. Stewart</name>
        </author>
        <author>
            <name>A. Huynh</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>310815</char-count>
            <page-count>174</page-count>
        </format>
        <keywords>
            <kw>management information base</kw>
            <kw>mib</kw>
            <kw>snmp</kw>
            <kw>simple network management protocol</kw>
            <kw>otn</kw>
            <kw>optical transport network</kw>
            <kw>itu-t</kw>
            <kw>performance monitoring</kw>
            <kw>configuration</kw>
            <kw>dwdm</kw>
            <kw>optical tranmission session</kw>
            <kw>optical multiplex section</kw>
            <kw>optical channel</kw>
            <kw>otuk</kw>
            <kw>odukt</kw>
            <kw>oduk</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with Simple Network Management Protocol (SNMP) in TCP/IP-based internets. In particular, it defines objects for managing Optical Interfaces associated with WavelengthDivision Multiplexing systems or characterized by the Optical Transport Network (OTN) in accordance with the OTN architecture defined in ITU-T Recommendation G.872. The MIB module defined in this memo can be used for performance monitoring and/or configuration of such optical interface. [STANDARDS TRACK] </abstract>
        <draft>ietf-atommib-opticalmib-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3592</doc-id>
        <title>Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type</title>
        <author>
            <name>K. Tesink</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>143588</char-count>
            <page-count>73</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types. This memo replaces RFC 2558. Changes relative to RFC 2558 are summarized in the MIB module's REVISION clause. [STANDARDS TRACK] </abstract>
        <draft>ietf-atommib-rfc2558bis-01</draft>
        <obsoletes>
            <doc-id>RFC2558</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3593</doc-id>
        <title>Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals</title>
        <author>
            <name>K. Tesink</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20363</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
            <kw>data</kw>
        </keywords>
        <abstract>This document defines a set of Textual Conventions for MIB modules that make use of performance history data based on 15 minute intervals. This memo replaces RFC 2493. Changes relative to RFC 2493 are summarized in the MIB module's REVISION clause. [STANDARDS TRACK] </abstract>
        <draft>ietf-atommib-rfc2493bis-01</draft>
        <obsoletes>
            <doc-id>RFC2493</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3594</doc-id>
        <title>PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option</title>
        <author>
            <name>P. Duffy</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12521</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>dynamic host configuration protocol</kw>
        </keywords>
        <abstract>This document defines a new sub-option for the DHCP CableLabs Client Configuration (CCC) Option. This new sub-option will be used to direct CableLabs Client Devices (CCDs) to invalidate security tickets stored in CCD non volatile memory (i.e., locally persisted security tickets). [STANDARDS TRACK] </abstract>
        <draft>ietf-dhc-pktc-kerb-tckt-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3595</doc-id>
        <title>Textual Conventions for IPv6 Flow Label</title>
        <author>
            <name>B. Wijnen</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11746</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract>This MIB module defines textual conventions to represent the commonly used IPv6 Flow Label. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS TRACK] </abstract>
        <draft>ietf-ops-ipv6-flowlabel-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3596</doc-id>
        <title>DNS Extensions to Support IP Version 6</title>
        <author>
            <name>S. Thomson</name>
        </author>
        <author>
            <name>C. Huitema</name>
        </author>
        <author>
            <name>V. Ksinant</name>
        </author>
        <author>
            <name>M. Souissi</name>
        </author>
        <date>
            <month>October</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14093</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>internet protocol</kw>
            <kw>domain name system</kw>
            <kw>DNS</kw>
            <kw>zone</kw>
        </keywords>
        <abstract>This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS TRACK] </abstract>
        <draft>ietf-dnsext-rfc1886bis-03</draft>
        <obsoletes>
            <doc-id>RFC3152</doc-id>
            <doc-id>RFC1886</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3597</doc-id>
        <title>Handling of Unknown DNS Resource Record (RR) Types</title>
        <author>
            <name>A. Gustafsson</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17559</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>domain name system</kw>
            <kw>name server software</kw>
            <kw>compression</kw>
            <kw>transparency</kw>
        </keywords>
        <abstract>Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. [STANDARDS TRACK] </abstract>
        <draft>ietf-dnsext-unknown-rrs-06</draft>
        <updates>
            <doc-id>RFC2163</doc-id>
            <doc-id>RFC2535</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4035</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3598</doc-id>
        <title>Sieve Email Filtering -- Subaddress Extension</title>
        <author>
            <name>K. Murchison</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11151</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>users</kw>
            <kw>detailed addressing language</kw>
            <kw>address</kw>
            <kw>part</kw>
            <kw>test</kw>
            <kw>detail</kw>
            <kw>filter</kw>
            <kw>mailbox</kw>
        </keywords>
        <abstract>On email systems that allow for "subaddressing" or "detailed addressing" (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses. This document defines an extension to the Sieve mail filtering language that allows users to compare against the user and detail parts of an address. [STANDARDS TRACK] </abstract>
        <draft>murchison-sieve-subaddress-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3599</doc-id>
        <title>Request for Comments Summary RFC Numbers 3500-3599</title>
        <author>
            <name>S. Ginoza</name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>76893</char-count>
            <page-count>34</page-count>
        </format>
        <abstract>This RFC is a slightly annotated list of the 100 RFCs from RFC 3500 through RFC 3599. This is a status report on these RFCs.</abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3600</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Reynolds</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Ginoza</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>134338</char-count>
            <page-count>50</page-count>
        </format>
        <abstract>This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 2, 2003. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1.</abstract>
        <obsoletes>
            <doc-id>RFC3300</doc-id>
        </obsoletes>
        <obsoleted-by>
            <doc-id>RFC3700</doc-id>
        </obsoleted-by>
        <is-also>
            <doc-id>STD0001</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3601</doc-id>
        <title>Text String Notation for Dial Sequences and Global Switched Telephone Network (GSTN) / E.164 Addresses</title>
        <author>
            <name>C. Allocchio</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18572</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>notations</kw>
            <kw>dtmf</kw>
            <kw>dual tone multifrequency</kw>
            <kw>telephony</kw>
            <kw>e-mail addresses</kw>
            <kw>urls</kw>
            <kw>integrated messaging</kw>
            <kw>3gpp</kw>
        </keywords>
        <abstract>This memo describes the full set of notations needed to represent a text string in a Dial Sequence. A Dial Sequence is normally composed of Dual Tone Multi Frequency (DTMF) elements, plus separators and additional "actions" (such as "wait for dialtone", "pause for N secs", etc.) which could be needed to successfully establish the connection with the target service: this includes the cases where subaddresses or DTMF menu navigation apply.</abstract>
        <draft>allocchio-gstn-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3602</doc-id>
        <title>The AES-CBC Cipher Algorithm and Its Use with IPsec</title>
        <author>
            <name>S. Frankel</name>
        </author>
        <author>
            <name>R. Glenn</name>
        </author>
        <author>
            <name>S. Kelly</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30254</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>ipsec</kw>
            <kw>encapsulating</kw>
            <kw>security</kw>
            <kw>payload</kw>
        </keywords>
        <abstract>This document describes the use of the Advanced Encryption Standard (AES) Cipher Algorithm in Cipher Block Chaining (CBC) Mode, with an explicit Initialization Vector (IV), as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP).</abstract>
        <draft>ietf-ipsec-ciph-aes-cbc-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3603</doc-id>
        <title>Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture</title>
        <author>
            <name>W. Marshall</name>
            <title>Editor</title>
        </author>
        <author>
            <name>F. Andreasen</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>67509</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>network access coordination</kw>
        </keywords>
        <abstract>In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) (RFC3261) for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required.</abstract>
        <draft>dcsgroup-sipping-proxy-proxy-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3604</doc-id>
        <title>Requirements for Adding Optical Support to the General Switch Management Protocol version 3 (GSMPv3)</title>
        <author>
            <name>H. Khosravi</name>
        </author>
        <author>
            <name>G. Kullgren</name>
        </author>
        <author>
            <name>S. Shew</name>
        </author>
        <author>
            <name>J. Sadler</name>
        </author>
        <author>
            <name>A. Watanabe</name>
        </author>
        <date>
            <month>October</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30805</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>controllers</kw>
            <kw>routers</kw>
            <kw>formats</kw>
            <kw>codes</kw>
        </keywords>
        <abstract>This memo provides requirements for adding optical switching support to the General Switch Management Protocol (GSMP). It also contains clarifications and suggested changes to the GSMPv3 specification.</abstract>
        <draft>ietf-gsmp-reqs-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3605</doc-id>
        <title>Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)</title>
        <author>
            <name>C. Huitema</name>
        </author>
        <date>
            <month>October</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17270</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>nat</kw>
            <kw>network access translation</kw>
            <kw>port mapping</kw>
        </keywords>
        <abstract>The Session Description Protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these ports have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP.</abstract>
        <draft>ietf-mmusic-sdp4nat-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3606</doc-id>
        <title>Definitions of Supplemental Managed Objects for ATM Interface</title>
        <author>
            <name>F. Ly</name>
        </author>
        <author>
            <name>M. Noto</name>
        </author>
        <author>
            <name>A. Smith</name>
        </author>
        <author>
            <name>E. Spiegel</name>
        </author>
        <author>
            <name>K. Tesink</name>
        </author>
        <date>
            <month>November</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>183610</char-count>
            <page-count>94</page-count>
        </format>
        <keywords>
            <kw>asynchronous transfer mode</kw>
            <kw>mib</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract>This memo defines objects used for managing ATM-based interfaces, devices, and services, in addition to those defined in RFC 2515, the ATM-MIB, to provide additional support for the management of ATM Switched Virtual Connections (SVCs) and ATM Permanent Virtual Connections (PVCs).</abstract>
        <draft>ietf-atommib-atm2-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3607</doc-id>
        <title>Chinese Lottery Cryptanalysis Revisited: The Internet as a Codebreaking Tool</title>
        <author>
            <name>M. Leech</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14526</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>security encryption</kw>
            <kw>des</kw>
            <kw>data standard</kw>
            <kw>distributed cryptanalysis</kw>
            <kw>computer virus</kw>
            <kw>network worm</kw>
            <kw>codebreaking</kw>
        </keywords>
        <abstract>This document revisits the so-called Chinese Lottery massively-parallel cryptanalytic attack. It explores Internet-based analogues to the Chinese Lottery, and their potentially-serious consequences.</abstract>
        <draft>leech-chinese-lottery-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3608</doc-id>
        <title>Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration</title>
        <author>
            <name>D. Willis</name>
        </author>
        <author>
            <name>B. Hoeneisen</name>
        </author>
        <date>
            <month>October</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35628</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>user agent</kw>
            <kw>domain</kw>
            <kw>register</kw>
        </keywords>
        <abstract>This document defines a Session Initiation Protocol (SIP) extension header field used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering user agent (UA) of a service route that the UA may use to request outbound services from the registrar's domain.</abstract>
        <draft>ietf-sip-scvrtdicso-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3609</doc-id>
        <title>Tracing Requirements for Generic Tunnels</title>
        <author>
            <name>R. Bonica</name>
        </author>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17859</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>traceroute</kw>
            <kw>application</kw>
            <kw>IP</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract>This document specifies requirements for a generic route-tracing application. It also specifies requirements for a protocol that will support that application. Network operators will use the generic route-tracing application to verify proper operation of the IP forwarding plane. They will also use the application to discover details regarding tunnels that support IP forwarding. The generic route-tracing application, specified herein, supports a superset of the functionality that "traceroute" currently offers. Like traceroute, the generic route-tracing application can discover the forwarding path between two interfaces that are contained by an IP network. Unlike traceroute, this application can reveal details regarding tunnels that support the IP forwarding path.</abstract>
        <draft>ietf-ccamp-tracereq-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3610</doc-id>
        <title>Counter with CBC-MAC (CCM)</title>
        <author>
            <name>D. Whiting</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>N. Ferguson </name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>64509</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>authentication</kw>
            <kw>encryption</kw>
            <kw>security</kw>
            <kw>ciphers</kw>
        </keywords>
        <abstract>Counter with CBC-MAC (CCM) is a generic authenticated encryption block cipher mode. CCM is defined for use with 128-bit block ciphers, such as the Advanced Encryption Standard (AES).</abstract>
        <draft>housley-ccm-mode-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3611</doc-id>
        <title>RTP Control Protocol Extended Reports (RTCP XR)</title>
        <author>
            <name>T. Friedman</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. Caceres</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Clark</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>126736</char-count>
            <page-count>55</page-count>
        </format>
        <keywords>
            <kw>real time transport protocol</kw>
            <kw>packet</kw>
            <kw>type</kw>
            <kw>sdp</kw>
            <kw>session description</kw>
            <kw>blocks</kw>
        </keywords>
        <abstract>This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides.</abstract>
        <draft>ietf-avt-rtcp-report-extns-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3612</doc-id>
        <title>Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP)</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35677</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>mpls</kw>
            <kw>fault tolerence</kw>
            <kw>high availability</kw>
            <kw>multiprotocol label switching</kw>
            <kw>cr-ldp</kw>
            <kw>high availability restart</kw>
        </keywords>
        <abstract>This document provides guidance on when it is advisable to implement some form of Label Distribution Protocol (LDP) restart mechanism and which approach might be more suitable. The issues and extensions described in this document are equally applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP".</abstract>
        <draft>ietf-mpls-ldp-restart-applic-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3613</doc-id>
        <title>Definition of a Uniform Resource Name (URN) Namespace for the Middleware Architecture Committee for Education (MACE)</title>
        <author>
            <name>R. Morgan</name>
        </author>
        <author>
            <name>K. Hazelton</name>
        </author>
        <date>
            <month>October</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14296</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>internet2</kw>
            <kw>middleware</kw>
        </keywords>
        <abstract>This document describes a Uniform Resource Name (URN) namespace for the Internet2 Middleware Architecture Committee for Education (MACE). This namespace is for naming persistent resources defined by MACE, its working groups and other designated subordinates.</abstract>
        <draft>hazelton-mace-urn-namespace-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3614</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for the Motion Picture Experts Group (MPEG)</title>
        <author>
            <name>J. Smith</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10457</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>iso</kw>
            <kw>international organization standardization</kw>
            <kw>multimedia</kw>
            <kw>metadata</kw>
            <kw>xml</kw>
            <kw>classification</kw>
            <kw>schemes</kw>
            <kw>digital rights management</kw>
        </keywords>
        <abstract>This document describes a Uniform Resource Name (URN) namespace for the Motion Picture Experts Group (MPEG) for naming persistent resources as part of the MPEG standards. Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by MPEG.</abstract>
        <draft>smith-urn-mpeg-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3615</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for SWIFT Financial Messaging</title>
        <author>
            <name>J. Gustin</name>
        </author>
        <author>
            <name>A. Goyens</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7352</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>messaging service</kw>
            <kw>interface software</kw>
        </keywords>
        <abstract>This document describes a Uniform Resource Name (URN) namespace that is managed by SWIFT for usage within messages standardized by SWIFT.</abstract>
        <draft>gustin-goyens-urn-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3616</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for Foundation for Intelligent Physical Agents (FIPA)</title>
        <author>
            <name>F. Bellifemine</name>
        </author>
        <author>
            <name>I. Constantinescu</name>
        </author>
        <author>
            <name>S. Willmott</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13352</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>URN NID</kw>
            <kw>Uniform Resource Name Namespace Identification</kw>
        </keywords>
        <abstract>This document describes a Uniform Resource Name Namespace Identification (URN NID) for the Foundation for Intelligent Physical Agents (FIPA). This URN NID will be used for identification of standard components published by the FIPA standards body in the area of Agent technology.</abstract>
        <draft>bellifemine-urn-fipa-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3617</doc-id>
        <title>Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)</title>
        <author>
            <name>E. Lear</name>
        </author>
        <date>
            <month>October</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11848</char-count>
            <page-count>7</page-count>
        </format>
        <abstract>The Trivial File Transfer Protocol (TFTP) is a very simple TRIVIAL protocol that has been in use on the Internet for quite a long time. While this document discourages its continued use, largely due to security concerns, we do define a Uniform Resource Identifier (URI) scheme, as well as discuss the protocol's applicability.</abstract>
        <draft>lear-tftp-uri-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3618</doc-id>
        <title>Multicast Source Discovery Protocol (MSDP)</title>
        <author>
            <name>B. Fenner</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Meyer</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42238</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>ipv4</kw>
            <kw>pim-sm</kw>
            <kw>independent multicast</kw>
            <kw>sparse-mode</kw>
            <kw>rp</kw>
            <kw>rendezvous point</kw>
        </keywords>
        <abstract>The Multicast Source Discovery Protocol (MSDP) describes a mechanism to connect multiple IP Version 4 Protocol Independent Multicast Sparse-Mode (PIM-SM) domains together. Each PIM-SM domain uses its own independent Rendezvous Point (RP) and does not have to depend on RPs in other domains. This document reflects existing MSDP implementations.</abstract>
        <draft>ietf-msdp-spec-20</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3619</doc-id>
        <title>Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1</title>
        <author>
            <name>S. Shah</name>
        </author>
        <author>
            <name>M. Yip</name>
        </author>
        <date>
            <month>October</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14440</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>ethernet rings</kw>
            <kw>robust</kw>
        </keywords>
        <abstract>This document describes the Ethernet Automatic Protection Switching (EAPS) (tm) technology invented by Extreme Networks to increase the availability and robustness of Ethernet rings. An Ethernet ring built using EAPS can have resilience comparable to that provided by SONET rings, at a lower cost and with fewer constraints (e.g., ring size).</abstract>
        <draft>shah-extreme-eaps-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3620</doc-id>
        <title>The TUNNEL Profile</title>
        <author>
            <name>D. New</name>
        </author>
        <date>
            <month>October</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35365</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>beep</kw>
            <kw>blocks extensible exchange protocol</kw>
            <kw>firewall</kw>
            <kw>application layer</kw>
        </keywords>
        <abstract>This memo describes a Blocks Extensible Exchange Protocol (BEEP) profile that allows a BEEP peer to serve as an application-layer proxy. It allows authorized users to access services through a firewall.</abstract>
        <draft>ietf-idwg-beep-tunnel-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3621</doc-id>
        <title>Power Ethernet MIB</title>
        <author>
            <name>A. Berger</name>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37294</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>management information base</kw>
            <kw>data terminal equipment power</kw>
            <kw>dte</kw>
            <kw>power sourcing equipment</kw>
            <kw>pse</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This document proposes an extension to the Ethernet-like Interfaces MIB with a set of objects for managing Power Sourcing Equipment (PSE).</abstract>
        <draft>ietf-hubmib-power-ethernet-mib-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3622</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for the Liberty Alliance Project</title>
        <author>
            <name>M. Mealling</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11432</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>federated network identity</kw>
        </keywords>
        <abstract>This document describes a Uniform Resource Name (URN) namespace that will identify various objects within the Liberty Architecture for federated network identity.</abstract>
        <draft>mealling-liberty-urn-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3623</doc-id>
        <title>Graceful OSPF Restart</title>
        <author>
            <name>J. Moy</name>
        </author>
        <author>
            <name>P. Pillay-Esnault</name>
        </author>
        <author>
            <name>A. Lindem</name>
        </author>
        <date>
            <month>November</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38757</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>open shortest path first</kw>
            <kw>non-stop forwarding</kw>
        </keywords>
        <abstract>This memo documents an enhancement to the OSPF routing protocol, whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This is called "graceful restart" or "non-stop forwarding". A restarting router may not be capable of adjusting its forwarding in a timely manner when the network topology changes. In order to avoid the possible resulting routing loops, the procedure in this memo automatically reverts to a normal OSPF restart when such a topology change is detected, or when one or more of the restarting router's neighbors do not support the enhancements in this memo. Proper network operation during a graceful restart makes assumptions upon the operating environment of the restarting router; these assumptions are also documented.</abstract>
        <draft>ietf-ospf-hitless-restart-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3624</doc-id>
        <title>The Media Gateway Control Protocol (MGCP) Bulk Audit Package</title>
        <author>
            <name>B. Foster</name>
        </author>
        <author>
            <name>D. Auerbach</name>
        </author>
        <author>
            <name>F. Andreasen</name>
        </author>
        <date>
            <month>November</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34391</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>call agent</kw>
            <kw>endpoints</kw>
            <kw>naming conventions</kw>
        </keywords>
        <abstract>The base Media Gateway Control Protocol (MGCP) includes audit commands that only allow a Call Agent to audit endpoint and/or connection state one endpoint at a time. This document describes a new MGCP package for bulk auditing of a group of gateway endpoints. It allows a Call Agent to determine the endpoint naming convention, the list of instantiated endpoints as well connection and endpoint state for the group of endpoints.</abstract>
        <draft>foster-mgcp-bulkaudits-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3625</doc-id>
        <title>The QCP File Format and Media Types for Speech Data</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <author>
            <name>H. Garudadri</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28603</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>13k</kw>
            <kw>qcelp</kw>
            <kw>audio</kw>
            <kw>multimedia</kw>
            <kw>voip</kw>
            <kw>real time transport protocol</kw>
            <kw>multipurpose internet mail extensions</kw>
        </keywords>
        <abstract>RFC 2658 specifies the streaming format for 3GPP2 13KK vocoder (High Rate Speech Service Option 17 for Wideband Spread Spectrum Communications Systems, also known as QCELP 13K vocoder) data, but does not specify a storage format. Many implementations have been using the "QCP" file format (named for its file extension) for exchanging QCELP 13K data as well as Enhanced Variable Rate Coder (EVRC) and Selectable Mode Vocoders (SMV) data. (For example, Eudora(r), QuickTime(r), and cmda2000(r) handsets). This document specifies the QCP file format and updates the audio/qcelp media registration to specify this format for storage, and registers the audio/evrc-qcp and audio/smv-qcp media types for EVRC and SMV (respectively) data stored in this format.</abstract>
        <draft>gellens-qcp-01</draft>
        <updates>
            <doc-id>RFC3555</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3626</doc-id>
        <title>Optimized Link State Routing Protocol (OLSR)</title>
        <author>
            <name>T. Clausen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Jacquet</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>161265</char-count>
            <page-count>75</page-count>
        </format>
        <keywords>
            <kw>mobile ad hoc</kw>
            <kw>wireless multipoint relays</kw>
            <kw>mpr</kw>
            <kw>mprs</kw>
        </keywords>
        <abstract>This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs). MPRs are selected nodes which forward broadcast messages during the flooding process. This technique substantially reduces the message overhead as compared to a classical flooding mechanism, where every node retransmits each message when it receives the first copy of the message. In OLSR, link state information is generated only by nodes elected as MPRs. Thus, a second optimization is achieved by minimizing the number of control messages flooded in the network. As a third optimization, an MPR node may chose to report only links between itself and its MPR selectors. Hence, as contrary to the classic link state algorithm, partial link state information is distributed in the network. This information is then used for route calculation. OLSR provides optimal routes (in terms of number of hops). The protocol is particularly suitable for large and dense networks as the technique of MPRs works well in this context.</abstract>
        <draft>ietf-manet-olsr-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3627</doc-id>
        <title>Use of /127 Prefix Length Between Routers Considered Harmful</title>
        <author>
            <name>P. Savola</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12436</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>address space</kw>
            <kw>anycast</kw>
        </keywords>
        <abstract>In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links between routers. Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This document discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers.</abstract>
        <draft>savola-ipv6-127-prefixlen-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3628</doc-id>
        <title>Policy Requirements for Time-Stamping Authorities (TSAs)</title>
        <author>
            <name>D. Pinkas</name>
        </author>
        <author>
            <name>N. Pope</name>
        </author>
        <author>
            <name>J. Ross</name>
        </author>
        <date>
            <month>November</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>92941</char-count>
            <page-count>43</page-count>
        </format>
        <keywords>
            <kw>tokens</kw>
            <kw>public key certificates</kw>
        </keywords>
        <abstract>This document defines requirements for a baseline time-stamp policy for Time-Stamping Authorities (TSAs) issuing time-stamp tokens, supported by public key certificates, with an accuracy of one second or better. A TSA may define its own policy which enhances the policy defined in this document. Such a policy shall incorporate or further constrain the requirements identified in this document.</abstract>
        <draft>ietf-pkix-pr-tsa-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3629</doc-id>
        <title>UTF-8, a transformation format of ISO 10646</title>
        <author>
            <name>F. Yergeau</name>
        </author>
        <date>
            <month>November</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33856</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>UTF-8</kw>
            <kw>UCS</kw>
            <kw>Transformation</kw>
            <kw>Format</kw>
        </keywords>
        <abstract>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</abstract>
        <draft>yergeau-rfc2279bis-05</draft>
        <obsoletes>
            <doc-id>RFC2279</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0063</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3630</doc-id>
        <title>Traffic Engineering (TE) Extensions to OSPF Version 2</title>
        <author>
            <name>D. Katz</name>
        </author>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>D. Yeung</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27717</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>open-shortest</kw>
            <kw>path</kw>
            <kw>first</kw>
            <kw>ink</kw>
            <kw>state</kw>
            <kw>advertisement</kw>
        </keywords>
        <abstract>This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.</abstract>
        <draft>katz-yeung-ospf-traffic-10</draft>
        <updates>
            <doc-id>RFC2370</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3631</doc-id>
        <title>Security Mechanisms for the Internet</title>
        <author>
            <name>S. Bellovin</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Schiller</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Kaufman</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47064</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>protocol</kw>
            <kw>host compromise</kw>
            <kw>dos</kw>
            <kw>denial of service</kw>
        </keywords>
        <abstract>Security must be built into Internet Protocols for those protocols to offer their services securely. Many security problems can be traced to improper implementations. However, even a proper implementation will have security problems if the fundamental protocol is itself exploitable. Exactly how security should be implemented in a protocol will vary, because of the structure of the protocol itself. However, there are many protocols for which standard Internet security mechanisms, already developed, may be applicable. The precise one that is appropriate in any given situation can vary. We review a number of different choices, explaining the properties of each.</abstract>
        <draft>iab-secmech-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3632</doc-id>
        <title>VeriSign Registry Registrar Protocol (RRP) Version 2.0.0</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <author>
            <name>S. Veeramachaneni</name>
        </author>
        <author>
            <name>S. Yalamanchilli</name>
        </author>
        <date>
            <month>November</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13490</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>RRP</kw>
            <kw>shared</kw>
            <kw>registration</kw>
            <kw>system</kw>
            <kw>gLTD</kw>
            <kw>ccTLD</kw>
            <kw>top level domain</kw>
        </keywords>
        <abstract>This document updates version 1.1.0 of the Network Solutions Inc. (NSI) Registry Registrar Protocol (RRP) specified in RFC 2832. The changes described in this document combined with the base specification documented in RFC 2832 specify version 2.0.0 of the VeriSign Registry Registrar Protocol.</abstract>
        <draft>hollenbeck-rfc2832bis-02</draft>
        <updates>
            <doc-id>RFC2832</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3633</doc-id>
        <title>IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6</title>
        <author>
            <name>O. Troan</name>
        </author>
        <author>
            <name>R. Droms</name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45308</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>automated delegation router</kw>
        </keywords>
        <abstract>The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using the Dynamic Host Configuration Protocol (DHCP). This mechanism is intended for delegating a long-lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned.</abstract>
        <draft>ietf-dhc-dhcpv6-opt-prefix-delegation-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3634</doc-id>
        <title>Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option</title>
        <author>
            <name>K. Luehrs</name>
        </author>
        <author>
            <name>R. Woundy</name>
        </author>
        <author>
            <name>J. Bevilacqua</name>
        </author>
        <author>
            <name>N. Davoust</name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13163</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document defines a new sub-option for the CableLabs Client Configuration (CCC) Dynamic Host Configuration Protocol (DHCP) option code for conveying the network addresses of Key Distribution Center (KDC) servers.</abstract>
        <draft>ietf-dhc-suboptions-kdc-serveraddress-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3635</doc-id>
        <title>Definitions of Managed Objects for the Ethernet-like Interface Types</title>
        <author>
            <name>J. Flick</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>154476</char-count>
            <page-count>64</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Ethernet-like interfaces. This memo obsoletes RFC 2665. It updates that specification by including management information useful for the management of 10 Gigabit per second (Gb/s) Ethernet interfaces.</abstract>
        <draft>ietf-hubmib-etherif-mib-v3-03</draft>
        <obsoletes>
            <doc-id>RFC2665</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3636</doc-id>
        <title>Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)</title>
        <author>
            <name>J. Flick</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>139990</char-count>
            <page-count>62</page-count>
        </format>
        <keywords>
            <kw>MAU-MIB</kw>
            <kw>management</kw>
            <kw>information</kw>
            <kw>base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 Medium Attachment Units (MAUs). This memo obsoletes RFC 2668. This memo extends that specification by including management information useful for the management of 10 gigabit per second (Gb/s) MAUs. This memo also obsoletes RFC 1515.</abstract>
        <draft>ietf-hubmib-mau-mib-v3-04</draft>
        <obsoletes>
            <doc-id>RFC2668</doc-id>
            <doc-id>RFC1515</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3637</doc-id>
        <title>Definitions of Managed Objects for the Ethernet WAN Interface Sublayer</title>
        <author>
            <name>C.M. Heard</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>78785</char-count>
            <page-count>37</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract>This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing the Ethernet Wide Area Network (WAN) Interface Sublayer (WIS). The MIB module defined in this memo is an extension of the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface MIB and is implemented in conjunction with it and with the Ethernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB, the Interfaces Group MIB, and the Inverted Stack Table MIB.</abstract>
        <draft>ietf-hubmib-wis-mib-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3638</doc-id>
        <title>Applicability Statement for Reclassification of RFC 1643 to Historic Status</title>
        <author>
            <name>J. Flick</name>
        </author>
        <author>
            <name>C. M. Heard</name>
        </author>
        <date>
            <month>September</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8676</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>ETHER-MIB</kw>
            <kw>MIB</kw>
            <kw>Network</kw>
            <kw>Management</kw>
            <kw>SNMP</kw>
            <kw>Ethernet</kw>
        </keywords>
        <abstract>This memo recommends that RFC 1643 be reclassified as an Historic document and provides the supporting motivation for that recommendation.</abstract>
        <draft>ietf-hubmib-1643-to-historic-01</draft>
        <obsoletes>
            <doc-id>RFC1643</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3639</doc-id>
        <title>Considerations on the use of a Service Identifier in Packet Headers</title>
        <author>
            <name>M. St. Johns</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Huston</name>
            <title>Editor</title>
        </author>
        <author>
            <name>IAB</name>
        </author>
        <date>
            <month>October</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15389</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>port fields</kw>
            <kw>protocol number</kw>
        </keywords>
        <abstract>This memo describes some considerations relating to the use of IP protocol number fields and payload protocol (e.g., TCP) port fields to identify particular services that may be associated with that port number or protocol number.</abstract>
        <draft>iab-service-id-considerations-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3640</doc-id>
        <title>RTP Payload Format for Transport of MPEG-4 Elementary Streams</title>
        <author>
            <name>J. van der Meer</name>
        </author>
        <author>
            <name>D. Mackie</name>
        </author>
        <author>
            <name>V. Swaminathan</name>
        </author>
        <author>
            <name>D. Singer</name>
        </author>
        <author>
            <name>P. Gentric</name>
        </author>
        <date>
            <month>November</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>102606</char-count>
            <page-count>43</page-count>
        </format>
        <keywords>
            <kw>real time transport protocol</kw>
            <kw>audio video streams</kw>
        </keywords>
        <abstract>The Motion Picture Experts Group (MPEG) Committee (ISO/IEC JTC1/SC29 WG11) is a working group in ISO that produced the MPEG-4 standard. MPEG defines tools to compress content such as audio-visual information into elementary streams. This specification defines a simple, but generic RTP payload format for transport of any non-multiplexed MPEG-4 elementary stream.</abstract>
        <draft>ietf-avt-mpeg4-simple-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3641</doc-id>
        <title>Generic String Encoding Rules (GSER) for ASN.1 Types</title>
        <author>
            <name>S. Legg</name>
        </author>
        <date>
            <month>October</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34207</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>asn.1</kw>
            <kw>abstract syntax notation</kw>
        </keywords>
        <abstract>This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Generic String Encoding Rules (GSER), that produce a human readable text encoding for values of any given ASN.1 data type.</abstract>
        <draft>legg-ldap-gser-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3642</doc-id>
        <title>Common Elements of Generic String Encoding Rules (GSER) Encodings</title>
        <author>
            <name>S. Legg</name>
        </author>
        <date>
            <month>October</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27774</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>asn.1</kw>
            <kw>abstract syntax notation</kw>
        </keywords>
        <abstract>The Generic String Encoding Rules (GSER) describe a human readable text encoding for an Abstract Syntax Notation One (ASN.1) value of any ASN.1 type. Specifications making use of GSER may wish to provide an equivalent Augmented Backus-Naur Form (ABNF) description of the GSER encoding for a particular ASN.1 type as a convenience for implementors. This document supports such specifications by providing equivalent ABNF for the GSER encodings for ASN.1 types that commonly occur in Lightweight Directory Access Protocol (LDAP) syntaxes.</abstract>
        <draft>legg-ldap-gser-abnf-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3643</doc-id>
        <title>Fibre Channel (FC) Frame Encapsulation</title>
        <author>
            <name>R. Weber</name>
        </author>
        <author>
            <name>M. Rajagopal</name>
        </author>
        <author>
            <name>F. Travostino</name>
        </author>
        <author>
            <name>M. O'Donnell</name>
        </author>
        <author>
            <name>C. Monia</name>
        </author>
        <author>
            <name>M. Merhar</name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39980</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>ips</kw>
            <kw>ip storage</kw>
            <kw>frame header</kw>
        </keywords>
        <abstract>This document describes the common Fibre Channel (FC) frame encapsulation format and a procedure for the measurement and calculation of frame transit time through the IP network. This specification is intended for use by any IETF protocol that encapsulates FC frames.</abstract>
        <draft>ietf-ips-fcencapsulation-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3644</doc-id>
        <title>Policy Quality of Service (QoS) Information Model</title>
        <author>
            <name>Y. Snir</name>
        </author>
        <author>
            <name>Y. Ramberg</name>
        </author>
        <author>
            <name>J. Strassner</name>
        </author>
        <author>
            <name>R. Cohen</name>
        </author>
        <author>
            <name>B. Moore</name>
        </author>
        <date>
            <month>November</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>170150</char-count>
            <page-count>73</page-count>
        </format>
        <keywords>
            <kw>integrated differentiated</kw>
            <kw>object oriented</kw>
        </keywords>
        <abstract>This document presents an object-oriented information model for representing Quality of Service (QoS) network management policies. This document is based on the IETF Policy Core Information Model and its extensions. It defines an information model for QoS enforcement for differentiated and integrated services using policy. It is important to note that this document defines an information model, which by definition is independent of any particular data storage mechanism and access protocol.</abstract>
        <draft>ietf-policy-qos-info-model-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3645</doc-id>
        <title>Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)</title>
        <author>
            <name>S. Kwan</name>
        </author>
        <author>
            <name>P. Garg</name>
        </author>
        <author>
            <name>J. Gilroy</name>
        </author>
        <author>
            <name>L. Esibov</name>
        </author>
        <author>
            <name>J. Westhead</name>
        </author>
        <author>
            <name>R. Hall</name>
        </author>
        <date>
            <month>October</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>56162</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>TSIG</kw>
            <kw>domain name system</kw>
            <kw>transaction</kw>
            <kw>signature</kw>
        </keywords>
        <abstract>The Secret Key Transaction Authentication for DNS (TSIG) protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) (RFC2743). This document updates RFC 2845.</abstract>
        <draft>ietf-dnsext-gss-tsig-06</draft>
        <updates>
            <doc-id>RFC2845</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3646</doc-id>
        <title>DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
        <author>
            <name>R. Droms</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13312</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>domain name system</kw>
            <kw>service</kw>
            <kw>server</kw>
            <kw>client</kw>
        </keywords>
        <abstract>This document describes Dynamic Host Configuration Protocol for IPv6 (DHCPv6) options for passing a list of available DNS recursive name servers and a domain search list to a client.</abstract>
        <draft>ietf-dhc-dhcpv6-opt-dnsconfig-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3647</doc-id>
        <title>Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework</title>
        <author>
            <name>S. Chokhani</name>
        </author>
        <author>
            <name>W. Ford</name>
        </author>
        <author>
            <name>R. Sabett</name>
        </author>
        <author>
            <name>C. Merrill</name>
        </author>
        <author>
            <name>S. Wu</name>
        </author>
        <date>
            <month>November</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>228124</char-count>
            <page-count>94</page-count>
        </format>
        <keywords>
            <kw>pkix</kw>
            <kw>encryption</kw>
            <kw>security</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement. This document supersedes RFC 2527.</abstract>
        <draft>ietf-pkix-ipki-new-rfc2527-02</draft>
        <obsoletes>
            <doc-id>RFC2527</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3648</doc-id>
        <title>Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol</title>
        <author>
            <name>J. Whitehead</name>
        </author>
        <author>
            <name>J. Reschke</name>
            <title>Editor</title>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>57147</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>server client semantics</kw>
            <kw>ordering</kw>
            <kw>orderpatch method</kw>
            <kw>position header</kw>
            <kw>ordering-type header</kw>
        </keywords>
        <abstract>This specification extends the Web Distributed Authoring and Versioning (WebDAV) Protocol to support the server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering.</abstract>
        <draft>ietf-webdav-ordering-protocol-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3649</doc-id>
        <title>HighSpeed TCP for Large Congestion Windows</title>
        <author>
            <name>S. Floyd</name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>79801</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>transmission control protocol</kw>
            <kw>round-trip</kw>
            <kw>rate packet</kw>
        </keywords>
        <abstract>The proposals in this document are experimental. While they may be deployed in the current Internet, they do not represent a consensus that this is the best method for high-speed congestion control. In particular, we note that alternative experimental proposals are likely to be forthcoming, and it is not well understood how the proposals in this document will interact with such alternative proposals. This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. The congestion control mechanisms of the current Standard TCP constrains the congestion windows that can be achieved by TCP in realistic environments. For example, for a Standard TCP connection with 1500-byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of 83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours). This is widely acknowledged as an unrealistic constraint. To address his limitation of TCP, this document proposes HighSpeed TCP, and solicits experimentation and feedback from the wider community.</abstract>
        <draft>ietf-tsvwg-highspeed-01</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3650</doc-id>
        <title>Handle System Overview</title>
        <author>
            <name>S. Sun</name>
        </author>
        <author>
            <name>L. Lannom</name>
        </author>
        <author>
            <name>B. Boesch</name>
        </author>
        <date>
            <month>November</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54927</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>name service</kw>
        </keywords>
        <abstract>This document provides an overview of the Handle System in terms of its namespace and service architecture, as well as its relationship to other Internet services such as DNS, LDAP/X.500, and URNs. The Handle System is a general-purpose global name service that allows secured name resolution and administration over networks such as the Internet. The Handle System manages handles, which are unique names for digital objects and other Internet resources.</abstract>
        <draft>sun-handle-system-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3651</doc-id>
        <title>Handle System Namespace and Service Definition</title>
        <author>
            <name>S. Sun</name>
        </author>
        <author>
            <name>S. Reilly</name>
        </author>
        <author>
            <name>L. Lannom</name>
        </author>
        <date>
            <month>November</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>104479</char-count>
            <page-count>41</page-count>
        </format>
        <keywords>
            <kw>name service</kw>
        </keywords>
        <abstract>The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. This document provides a detailed description of the Handle System namespace, and its data, service, and operation models. The namespace definition specifies the handle syntax and its semantic structure. The data model defines the data structures used by the Handle System protocol and any pre-defined data types for carrying out the handle service. The service model provides definitions of various Handle System components and explains how they work together over the network. Finally, the Handle System operation model describes its service operation in terms of messages transmitted between client and server, and the client authentication process based on the Handle System authentication protocol.</abstract>
        <draft>sun-handle-system-def-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3652</doc-id>
        <title>Handle System Protocol (ver 2.1) Specification</title>
        <author>
            <name>S. Sun</name>
        </author>
        <author>
            <name>S. Reilly</name>
        </author>
        <author>
            <name>L. Lannom</name>
        </author>
        <author>
            <name>J. Petrone</name>
        </author>
        <date>
            <month>November</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>124380</char-count>
            <page-count>53</page-count>
        </format>
        <keywords>
            <kw>name service</kw>
        </keywords>
        <abstract>The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. This document describes the protocol used for client software to access the Handle System for both handle resolution and administration. The protocol specifies the procedure for a client software to locate the responsible handle server of any given handle. It also defines the messages exchanged between the client and server for any handle operation.</abstract>
        <draft>sun-handle-system-protocol-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3653</doc-id>
        <title>XML-Signature XPath Filter 2.0</title>
        <author>
            <name>J. Boyer</name>
        </author>
        <author>
            <name>M. Hughes</name>
        </author>
        <author>
            <name>J. Reagle</name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32258</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>extensible markup language</kw>
            <kw>digital signature</kw>
        </keywords>
        <abstract>XML Signature recommends a standard means for specifying information content to be digitally signed and for representing the resulting digital signatures in XML. Some applications require the ability to specify a subset of a given XML document as the information content to be signed. The XML Signature specification meets this requirement with the XPath transform. However, this transform can be difficult to implement efficiently with existing technologies. This specification defines a new XML Signature transform to facilitate the development of efficient document subsetting implementations that interoperate under similar performance profiles. This document is the W3C XML Signature XPath-Filter 2.0 Recommendation. This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.</abstract>
        <draft>ietf-xmldsig-xpf2-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3654</doc-id>
        <title>Requirements for Separation of IP Control and Forwarding</title>
        <author>
            <name>H. Khosravi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>T. Anderson</name>
            <title>Editor</title>
        </author>
        <date>
            <month>November</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40418</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>forces</kw>
            <kw>forwarding control</kw>
            <kw>element separation data</kw>
        </keywords>
        <abstract>This document introduces the Forwarding and Control Element Separation (ForCES) architecture and defines a set of associated terminology. This document also defines a set of architectural, modeling, and protocol requirements to logically separate the control and data forwarding planes of an IP (IPv4, IPv6, etc.) networking device.</abstract>
        <draft>ietf-forces-requirements-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3655</doc-id>
        <title>Redefinition of DNS Authenticated Data (AD) bit</title>
        <author>
            <name>B. Wellington</name>
        </author>
        <author>
            <name>O. Gudmundsson</name>
        </author>
        <date>
            <month>November</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15646</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>DNS-SECEXT</kw>
            <kw>dns</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>This document alters the specification defined in RFC 2535. Based on implementation experience, the Authenticated Data (AD) bit in the DNS header is not useful. This document redefines the AD bit such that it is only set if all answers or records proving that no answers exist in the response has been cryptographically verified or otherwise meets the server's local security policy.</abstract>
        <draft>ietf-dnsext-ad-is-secure-06</draft>
        <obsoleted-by>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4035</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2535</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3656</doc-id>
        <title>The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol</title>
        <author>
            <name>R. Siemborski</name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35509</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>imap</kw>
            <kw>pop3</kw>
            <kw>post office protocol</kw>
            <kw>internet message access</kw>
        </keywords>
        <abstract>As the demand for high-performance mail delivery agents increases, it becomes apparent that single-machine solutions are inadequate to the task, both because of capacity limits and that the failure of the single machine means a loss of mail delivery for all users. It is preferable to allow many machines to share the responsibility of mail delivery. The Mailbox Update (MUPDATE) protocol allows a group of Internet Message Access Protocol (IMAP) or Post Office Protocol - Version 3 (POP3) servers to function with a unified mailbox namespace. This document is intended to serve as a reference guide to that protocol.</abstract>
        <draft>siemborski-mupdate-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3657</doc-id>
        <title>Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>S. Moriai</name>
        </author>
        <author>
            <name>A. Kato</name>
        </author>
        <date>
            <month>January</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26282</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>mail content</kw>
            <kw>key</kw>
        </keywords>
        <abstract>This document specifies the conventions for using the Camellia encryption algorithm for encryption with the Cryptographic Message Syntax (CMS).</abstract>
        <draft>ietf-smime-camellia-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3658</doc-id>
        <title>Delegation Signer (DS) Resource Record (RR)</title>
        <author>
            <name>O. Gudmundsson</name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42120</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>zone cut</kw>
            <kw>zone key</kw>
            <kw>security</kw>
            <kw>dns</kw>
            <kw>domain name system</kw>
        </keywords>
        <abstract>The delegation signer (DS) resource record (RR) is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference. This document defines the DS RR, gives examples of how it is used and describes the implications on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC 1035, RFC 2535, RFC 3008 and RFC 3090.</abstract>
        <draft>ietf-dnsext-delegation-signer-15</draft>
        <obsoleted-by>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4035</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3090</doc-id>
            <doc-id>RFC3008</doc-id>
            <doc-id>RFC2535</doc-id>
            <doc-id>RFC1035</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC3755</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3660</doc-id>
        <title>Basic Media Gateway Control Protocol (MGCP) Packages</title>
        <author>
            <name>B. Foster</name>
        </author>
        <author>
            <name>F. Andreasen</name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>145147</char-count>
            <page-count>64</page-count>
        </format>
        <keywords>
            <kw>generic</kw>
            <kw>line</kw>
            <kw>trunk</kw>
            <kw>handset</kw>
            <kw>dtmf</kw>
            <kw>dual tone multifrequency</kw>
        </keywords>
        <abstract>This document provides a basic set of Media Gateway Control Protocol (MGCP) packages. The generic, line, trunk, handset, RTP, DTMF (Dual Tone Multifrequency), announcement server and script packages are updates of packages from RFC 2705 with additional explanation and in some cases new versions of these packages. In addition to these, five new packages are defined here. These are the signal list, resource reservation, media format, supplementary services and digit map extension packages.</abstract>
        <draft>foster-mgcp-basic-packages-10</draft>
        <updates>
            <doc-id>RFC2705</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3661</doc-id>
        <title>Media Gateway Control Protocol (MGCP) Return Code Usage</title>
        <author>
            <name>B. Foster</name>
        </author>
        <author>
            <name>C. Sivachelvan</name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49898</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>guidelines</kw>
            <kw>call agent</kw>
            <kw>implementation</kw>
        </keywords>
        <abstract>This document provides implementation guidelines for the use of return codes in RFC 3435, Media Gateway Control Protocol (MGCP) Version 1.0. Return codes in RFC 3435 do not cover all possible specific situations that may ever occur in a gateway. That is not possible and not necessary. What is important is to ensure that the Call Agent that receives a return code behaves appropriately and consistently for the given situation. The purpose of this document is to provide implementation guidelines to ensure that consistency.</abstract>
        <draft>foster-mgcp-returncodes-03</draft>
        <updates>
            <doc-id>RFC3435</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3662</doc-id>
        <title>A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services</title>
        <author>
            <name>R. Bless</name>
        </author>
        <author>
            <name>K. Nichols</name>
        </author>
        <author>
            <name>K. Wehrle</name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39029</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>traffic network</kw>
            <kw>ds</kw>
            <kw>le</kw>
        </keywords>
        <abstract>This document proposes a differentiated services per-domain behavior (PDB) whose traffic may be "starved" (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's "best-effort" or "normal Internet traffic" model, where prolonged starvation indicates network problems. In this sense, the proposed PDB's traffic is forwarded with a "lower" priority than the normal "best-effort" Internet traffic, thus the PDB is called "Lower Effort" (LE). Use of this PDB permits a network operator to strictly limit the effect of its traffic on "best-effort"/"normal" or all other Internet traffic. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic.</abstract>
        <draft>bless-diffserv-pdb-le-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3663</doc-id>
        <title>Domain Administrative Data in Lightweight Directory Access Protocol (LDAP)</title>
        <author>
            <name>A. Newton</name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42260</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>referral types</kw>
            <kw>well-known</kw>
        </keywords>
        <abstract>Domain registration data has typically been exposed to the general public via Nicname/Whois for administrative purposes. This document describes the Referral Lightweight Directory Access Protocol (LDAP) Service, an experimental service using LDAP and well-known LDAP types to make domain administrative data available.</abstract>
        <draft>newton-ldap-whois-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3664</doc-id>
        <title>The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>January</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6711</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>ipsec</kw>
            <kw>advanced encryption standard</kw>
            <kw>mac</kw>
            <kw>message authentication code</kw>
        </keywords>
        <abstract>Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard (AES). This document describes such an algorithm, called AES-XCBC-PRF-128.</abstract>
        <draft>ietf-ipsec-aes-xcbc-prf-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3665</doc-id>
        <title>Session Initiation Protocol (SIP) Basic Call Flow Examples</title>
        <author>
            <name>A. Johnston</name>
        </author>
        <author>
            <name>S. Donovan</name>
        </author>
        <author>
            <name>R. Sparks</name>
        </author>
        <author>
            <name>C. Cunningham</name>
        </author>
        <author>
            <name>K. Summers</name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>163159</char-count>
            <page-count>94</page-count>
        </format>
        <keywords>
            <kw>user agent</kw>
            <kw>client proxy</kw>
            <kw>redirect</kw>
        </keywords>
        <abstract>This document gives examples of Session Initiation Protocol (SIP) call flows. Elements in these call flows include SIP User Agents and Clients, SIP Proxy and Redirect Servers. Scenarios include SIP Registration and SIP session establishment. Call flow diagrams and message details are shown.</abstract>
        <draft>ietf-sipping-basic-call-flows-02</draft>
        <is-also>
            <doc-id>BCP0075</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3666</doc-id>
        <title>Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows</title>
        <author>
            <name>A. Johnston</name>
        </author>
        <author>
            <name>S. Donovan</name>
        </author>
        <author>
            <name>R. Sparks</name>
        </author>
        <author>
            <name>C. Cunningham</name>
        </author>
        <author>
            <name>K. Summers</name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>200478</char-count>
            <page-count>118</page-count>
        </format>
        <keywords>
            <kw>user proxy</kw>
            <kw>gateway</kw>
            <kw>telephony</kw>
        </keywords>
        <abstract>This document contains best current practice examples of Session Initiation Protocol (SIP) call flows showing interworking with the Public Switched Telephone Network (PSTN). Elements in these call flows include SIP User Agents, SIP Proxy Servers, and PSTN Gateways. Scenarios include SIP to PSTN, PSTN to SIP, and PSTN to PSTN via SIP. PSTN telephony protocols are illustrated using ISDN (Integrated Services Digital Network), ISUP (ISDN User Part), and FGB (Feature Group B) circuit associated signaling. PSTN calls are illustrated using global telephone numbers from the PSTN and private extensions served on by a PBX (Private Branch Exchange). Call flow diagrams and message details are shown.</abstract>
        <draft>ietf-sipping-pstn-call-flows-02</draft>
        <is-also>
            <doc-id>BCP0076</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3667</doc-id>
        <title>IETF Rights in Contributions</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43297</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>intellectual property rights</kw>
            <kw>copyright</kw>
            <kw>ipr</kw>
        </keywords>
        <abstract>The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3668, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>ietf-ipr-submission-rights-08</draft>
        <obsoleted-by>
            <doc-id>RFC3978</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2026</doc-id>
        </updates>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3668</doc-id>
        <title>Intellectual Property Rights in IETF Technology</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41365</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>ipr</kw>
            <kw>copyright</kw>
        </keywords>
        <abstract>The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and, with RFC 3667, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>ietf-ipr-technology-rights-12</draft>
        <obsoleted-by>
            <doc-id>RFC3979</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC2026</doc-id>
            <doc-id>RFC2028</doc-id>
        </updates>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3669</doc-id>
        <title>Guidelines for Working Groups on Intellectual Property Issues</title>
        <author>
            <name>S. Brim</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40946</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>ipr</kw>
            <kw>copyright</kw>
        </keywords>
        <abstract>This memo lays out a conceptual framework and rules of thumb useful for working groups dealing with Intellectual Property Rights (IPR) issues. It documents specific examples of how IPR issues have been dealt with in the IETF. This memo provides information for the Internet community.</abstract>
        <draft>ietf-ipr-wg-guidelines-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3670</doc-id>
        <title>Information Model for Describing Network Device QoS Datapath Mechanisms</title>
        <author>
            <name>B. Moore</name>
        </author>
        <author>
            <name>D. Durham</name>
        </author>
        <author>
            <name>J. Strassner</name>
        </author>
        <author>
            <name>A. Westerinen</name>
        </author>
        <author>
            <name>W. Weiss</name>
        </author>
        <date>
            <month>January</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>221687</char-count>
            <page-count>97</page-count>
        </format>
        <keywords>
            <kw>quality of service</kw>
            <kw>host</kw>
            <kw>netowrk devices</kw>
            <kw>traffic</kw>
        </keywords>
        <abstract>The purpose of this document is to define an information model to describe the quality of service (QoS) mechanisms inherent in different network devices, including hosts. Broadly speaking, these mechanisms describe the properties common to selecting and conditioning traffic through the forwarding path (datapath) of a network device. This selection and conditioning of traffic in the datapath spans both major QoS architectures: Differentiated Services and Integrated Services. This document should be used with the QoS Policy Information Model (QPIM) to model how policies can be defined to manage and configure the QoS mechanisms (i.e., the classification, marking, metering, dropping, queuing, and scheduling functionality) of devices. Together, these two documents describe how to write QoS policy rules to configure and manage the QoS mechanisms present in the datapaths of devices. This document, as well as QPIM, are information models. That is, they represent information independent of a binding to a specific type of repository</abstract>
        <draft>ietf-policy-qos-device-info-model-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3671</doc-id>
        <title>Collective Attributes in the Lightweight Directory Access Protocol (LDAP)</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17912</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>x.500</kw>
            <kw>information model schema</kw>
        </keywords>
        <abstract>X.500 collective attributes allow common characteristics to be shared between collections of entries. This document summarizes the X.500 information model for collective attributes and describes use of collective attributes in LDAP (Lightweight Directory Access Protocol). This document provides schema definitions for collective attributes for use in LDAP.</abstract>
        <draft>zeilenga-ldap-collective-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3672</doc-id>
        <title>Subentries in the Lightweight Directory Access Protocol (LDAP)</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24447</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>special subtree</kw>
        </keywords>
        <abstract>In X.500 directories, subentries are special entries used to hold information associated with a subtree or subtree refinement. This document adapts X.500 subentries mechanisms for use with the Lightweight Directory Access Protocol (LDAP).</abstract>
        <draft>zeilenga-ldap-subentry-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3673</doc-id>
        <title>Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10003</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>user mechanisms</kw>
            <kw>extension</kw>
        </keywords>
        <abstract>The Lightweight Directory Access Protocol (LDAP) supports a mechanism for requesting the return of all user attributes but not all operational attributes. This document describes an LDAP extension which clients may use to request the return of all operational attributes.</abstract>
        <draft>zeilenga-ldap-opattrs-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3674</doc-id>
        <title>Feature Discovery in Lightweight Directory Access Protocol (LDAP)</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10282</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>elective extensions</kw>
            <kw>mechanisms</kw>
        </keywords>
        <abstract>The Lightweight Directory Access Protocol (LDAP) is an extensible protocol with numerous elective features. This document introduces a general mechanism for discovery of elective features and extensions which cannot be discovered using existing mechanisms.</abstract>
        <draft>zeilenga-ldap-features-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3675</doc-id>
        <title>.sex Considered Dangerous</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53211</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>top level domains</kw>
            <kw>tld</kw>
            <kw>ip addresses</kw>
            <kw>internet protocol filters</kw>
        </keywords>
        <abstract>Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag "adult" or "unsafe" material or the like. This document explains why this is an ill considered idea from the legal, philosophical, and particularly, the technical points of view.</abstract>
        <draft>eastlake-xxx-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3676</doc-id>
        <title>The Text/Plain Format and DelSp Parameters</title>
        <author>
            <name>R. Gellens</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42441</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>media type</kw>
            <kw>mime</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extension</kw>
        </keywords>
        <abstract>This specification establishes two parameters (Format and DelSP) to be used with the Text/Plain media type. In the presence of these parameters, trailing whitespace is used to indicate flowed lines and a canonical quote indicator is used to indicate quoted lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain, yet provides for superior wrapping/flowing, and quoting. This document supersedes the one specified in RFC 2646, "The Text/Plain Format Parameter", and adds the DelSp parameter to accommodate languages/coded character sets in which ASCII spaces are not used or appear rarely. [STANDARDS TRACK]</abstract>
        <draft>gellens-format-bis-04</draft>
        <obsoletes>
            <doc-id>RFC2646</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3677</doc-id>
        <title>IETF ISOC Board of Trustee Appointment Procedures</title>
        <author>
            <name>L. Daigle</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Internet Architecture Board </name>
        </author>
        <date>
            <month>December</month>
            <year>2003</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13008</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>internet society</kw>
            <kw>bot</kw>
            <kw>engineering task force</kw>
        </keywords>
        <abstract>This memo outlines the process by which the IETF makes a selection of an Internet Society (ISOC) Board of Trustees appointment.</abstract>
        <draft>iab-isocbot-01</draft>
        <is-also>
            <doc-id>BCP0077</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3678</doc-id>
        <title>Socket Interface Extensions for Multicast Source Filters</title>
        <author>
            <name>D. Thaler</name>
        </author>
        <author>
            <name>B. Fenner</name>
        </author>
        <author>
            <name>B. Quinn</name>
        </author>
        <date>
            <month>January</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36320</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>ip</kw>
            <kw>internet protocol</kw>
            <kw>application program interface</kw>
            <kw>apis</kw>
            <kw>input</kw>
            <kw>output</kw>
        </keywords>
        <abstract>The Internet Group Management Protocol (IGMPv3) for IPv4 and the Multicast Listener Discovery (MLDv2) for IPv6 add the capability for applications to express source filters on multicast group memberships, which allows receiver applications to determine the set of senders (sources) from which to accept multicast traffic. This capability also simplifies support of one-to-many type multicast applications. This document specifies new socket options and functions to manage source filters for IP Multicast group memberships. It also defines the socket structures to provide input and output arguments to these new application program interfaces (APIs). These extensions are designed to provide access to the source filtering features, while introducing a minimum of change into the system and providing complete compatibility for existing multicast applications.</abstract>
        <draft>ietf-magma-msf-api-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3679</doc-id>
        <title>Unused Dynamic Host Configuration Protocol (DHCP) Option Codes</title>
        <author>
            <name>R. Droms</name>
        </author>
        <date>
            <month>January</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13804</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>dynamic</kw>
            <kw>host</kw>
            <kw>configuration</kw>
            <kw>protocol</kw>
            <kw>internet</kw>
            <kw>assigned</kw>
            <kw>numbers</kw>
            <kw>authority</kw>
        </keywords>
        <abstract>Prior to the publication of RFC 2489 (which was updated by RFC 2939), several option codes were assigned to proposed Dynamic Host Configuration Protocol (DHCP) options that were subsequently never used. This document lists those unused option codes and directs IANA to make these option codes available for assignment to other DHCP options in the future. The document also lists several option codes that are not currently documented in an RFC but should not be made available for reassignment to future DHCP options.</abstract>
        <draft>ietf-dhc-unused-optioncodes-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3680</doc-id>
        <title>A Session Initiation Protocol (SIP) Event Package for Registrations</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35403</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>REGISTER</kw>
            <kw>event package name</kw>
            <kw>event package parameters</kw>
        </keywords>
        <abstract>This document defines a Session Initiation Protocol (SIP) event package for registrations. Through its REGISTER method, SIP allows a user agent to create, modify, and delete registrations. Registrations can also be altered by administrators in order to enforce policy. As a result, these registrations represent a piece of state in the network that can change dynamically. There are many cases where a user agent would like to be notified of changes in this state. This event package defines a mechanism by which those user agents can request and obtain such notifications. [STANDARDS TRACK]</abstract>
        <draft>ietf-sipping-reg-event-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3681</doc-id>
        <title>Delegation of E.F.F.3.IP6.ARPA</title>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>R. Fink</name>
        </author>
        <date>
            <month>January</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7137</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>dns</kw>
            <kw>domain name system</kw>
        </keywords>
        <abstract>This document discusses the need for delegation of the E.F.F.3.IP6.ARPA DNS zone in order to enable reverse lookups for 6bone addresses, and makes specific recommendations for the process needed to accomplish this.</abstract>
        <draft>ymbk-6bone-arpa-delegation-01</draft>
        <is-also>
            <doc-id>BCP0080</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3682</doc-id>
        <title>The Generalized TTL Security Mechanism (GTSM)</title>
        <author>
            <name>V. Gill</name>
        </author>
        <author>
            <name>J. Heasley</name>
        </author>
        <author>
            <name>D. Meyer</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23321</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>time to live</kw>
            <kw>packet hop limit</kw>
        </keywords>
        <abstract>The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to protect a protocol stack from CPU-utilization based attacks has been proposed in many settings (see for example, RFC 2461). This document generalizes these techniques for use by other protocols such as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP), Bidirectional Forwarding Detection, and Label Distribution Protocol (LDP) (RFC 3036). While the Generalized TTL Security Mechanism (GTSM) is most effective in protecting directly connected protocol peers, it can also provide a lower level of protection to multi-hop sessions. GTSM is not directly applicable to protocols employing flooding mechanisms (e.g., multicast), and use of multi-hop GTSM should be considered on a case-by-case basis. This memo defines an Experimental Protocol for the Internet community.</abstract>
        <draft>gill-gtsh-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3683</doc-id>
        <title>A Practice for Revoking Posting Rights to IETF Mailing Lists</title>
        <author>
            <name>M. Rose</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15698</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>All self-governing bodies have ways of managing the scope of participant interaction. The IETF uses a consensus-driven process for developing computer-communications standards in an open fashion. An important part of this consensus-driven process is the pervasive use of mailing lists for discussion. Notably, in a small number of cases, a participant has engaged in a "denial-of-service" attack to disrupt the consensus-driven process. Regrettably, as these bad faith attacks become more common, the IETF needs to establish a practice that reduces or eliminates these attacks. This memo recommends such a practice for use by the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>mrose-ietf-posting-04</draft>
        <is-also>
            <doc-id>BCP0083</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3684</doc-id>
        <title>Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)</title>
        <author>
            <name>R. Ogier</name>
        </author>
        <author>
            <name>F. Templin</name>
        </author>
        <author>
            <name>M. Lewis</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>107963</char-count>
            <page-count>46</page-count>
        </format>
        <keywords>
            <kw>proactive routing</kw>
            <kw>ad-hoc networks</kw>
            <kw>neighbor discovery</kw>
            <kw>link-state routing</kw>
            <kw>mobile ad-hoc network</kw>
            <kw>mobile mesh network</kw>
            <kw>packet radio network</kw>
            <kw>wireless communications</kw>
        </keywords>
        <abstract>Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) is a proactive, link-state routing protocol designed for mobile ad-hoc networks, which provides hop-by-hop routing along shortest paths to each destination. Each node running TBRPF computes a source tree (providing paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification of Dijkstra's algorithm. To minimize overhead, each node reports only *part* of its source tree to neighbors. TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree. Each node also has the option to report additional topology information (up to the full topology), to provide improved robustness in highly mobile networks. TBRPF performs neighbor discovery using "differential" HELLO messages which report only *changes* in the status of neighbors. This results in HELLO messages that are much smaller than those of other link-state routing protocols such as OSPF. This memo defines an Experimental Protocol for the Internet community.</abstract>
        <draft>ietf-manet-tbrpf-11</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3685</doc-id>
        <title>SIEVE Email Filtering: Spamtest and VirusTest Extensions</title>
        <author>
            <name>C. Daboo</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17436</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>messages</kw>
            <kw>portable commands</kw>
        </keywords>
        <abstract>The SIEVE mail filtering language "spamtest" and "virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric 'scores'. It is the responsibility of the underlying SIEVE implementation to do the actual checks that result in values returned by the tests. [PROPOSED STANDARD]</abstract>
        <draft>daboo-sieve-spamtest-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3686</doc-id>
        <title>Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>January</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43777</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>authentication vector</kw>
            <kw>cipher block</kw>
        </keywords>
        <abstract>This document describes the use of Advanced Encryption Standard (AES) Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) confidentiality mechanism.</abstract>
        <draft>ietf-ipsec-ciph-aes-ctr-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3687</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules</title>
        <author>
            <name>S. Legg</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>96256</char-count>
            <page-count>42</page-count>
        </format>
        <keywords>
            <kw>syntax data schema</kw>
        </keywords>
        <abstract>The syntaxes of attributes in a Lightweight Directory Access Protocol (LDAP) or X.500 directory range from simple data types, such as text string, integer, or boolean, to complex structured data types, such as the syntaxes of the directory schema operational attributes. Matching rules defined for the complex syntaxes usually only provide the most immediately useful matching capability. This document defines generic matching rules that can match any user selected component parts in an attribute value of any arbitrarily complex attribute syntax. [PROPOSED STANDARD]</abstract>
        <draft>legg-ldapext-component-matching-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3688</doc-id>
        <title>The IETF XML Registry</title>
        <author>
            <name>M. Mealling</name>
        </author>
        <date>
            <month>January</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17325</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>extensible markup language</kw>
        </keywords>
        <abstract>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</abstract>
        <draft>mealling-iana-xmlns-registry-05</draft>
        <is-also>
            <doc-id>BCP0081</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3689</doc-id>
        <title>General Requirements for Emergency Telecommunication Service (ETS)</title>
        <author>
            <name>K. Carlberg</name>
        </author>
        <author>
            <name>R. Atkinson</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21680</char-count>
            <page-count>10</page-count>
        </format>
        <abstract>This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). This memo provides information for the Internet community.</abstract>
        <draft>ietf-ieprep-ets-general-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3690</doc-id>
        <title>IP Telephony Requirements for Emergency Telecommunication Service (ETS)</title>
        <author>
            <name>K. Carlberg</name>
        </author>
        <author>
            <name>R. Atkinson</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13919</char-count>
            <page-count>7</page-count>
        </format>
        <abstract>This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in RFC 3689. Solutions to these requirements are not presented in this document. This memo provides information for the Internet community.</abstract>
        <draft>ietf-ieprep-ets-telephony-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3691</doc-id>
        <title>Internet Message Access Protocol (IMAP) UNSELECT command</title>
        <author>
            <name>A. Melnikov</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8436</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>mailbox session client</kw>
        </keywords>
        <abstract>This document defines an UNSELECT command that can be used to close the current mailbox in an Internet Message Access Protocol - version 4 (IMAP4) session without expunging it. Certain types of IMAP clients need to release resources associated with the selected mailbox without selecting a different mailbox. While IMAP4 provides this functionality (via a SELECT command with a nonexistent mailbox name or reselecting the same mailbox with EXAMINE command), a more clean solution is desirable. [STANDARDS TRACK]</abstract>
        <draft>melnikov-imap-unselect-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3692</doc-id>
        <title>Assigning Experimental and Testing Numbers Considered Useful</title>
        <author>
            <name>T. Narten</name>
        </author>
        <date>
            <month>January</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15054</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>iana</kw>
            <kw>internet assigned numbers authority</kw>
            <kw>values</kw>
            <kw>implementations</kw>
        </keywords>
        <abstract>When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. For example, to test a new DHCP option, one needs an option number to identify the new function. This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified.</abstract>
        <draft>narten-iana-experimental-allocations-05</draft>
        <updates>
            <doc-id>RFC2434</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0082</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3693</doc-id>
        <title>Geopriv Requirements</title>
        <author>
            <name>J. Cuellar</name>
        </author>
        <author>
            <name>J. Morris</name>
        </author>
        <author>
            <name>D. Mulligan</name>
        </author>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>J. Polk</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>68881</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>security privacy</kw>
            <kw>lo</kw>
            <kw>location object</kw>
        </keywords>
        <abstract>Location-based services, navigation applications, emergency services, management of equipment in the field, and other location-dependent services need geographic location information about a Target (such as a user, resource or other entity). There is a need to securely gather and transfer location information for location services, while at the same time protect the privacy of the individuals involved. This document focuses on the authorization, security and privacy requirements for such location-dependent services. Specifically, it describes the requirements for the Geopriv Location Object (LO) and for the protocols that use this Location Object. This LO is envisioned to be the primary data structure used in all Geopriv protocol exchanges to securely transfer location data. This memo provides information for the Internet community.</abstract>
        <draft>ietf-geopriv-reqs-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3694</doc-id>
        <title>Threat Analysis of the Geopriv Protocol</title>
        <author>
            <name>M. Danley</name>
        </author>
        <author>
            <name>D. Mulligan</name>
        </author>
        <author>
            <name>J. Morris</name>
        </author>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44364</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>privacy security</kw>
            <kw>data information</kw>
        </keywords>
        <abstract>This document provides some analysis of threats against the Geopriv protocol architecture. It focuses on protocol threats, threats that result from the storage of data by entities in the architecture, and threats posed by the abuse of information yielded by Geopriv. Some security properties that meet these threats are enumerated as a reference for Geopriv requirements. This memo provides information for the Internet community.</abstract>
        <draft>ietf-geopriv-threat-analysis-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3695</doc-id>
        <title>Compact Forward Error Correction (FEC) Schemes</title>
        <author>
            <name>M. Luby</name>
        </author>
        <author>
            <name>L. Vicisano</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32012</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>content</kw>
            <kw>stream</kw>
            <kw>delivery</kw>
            <kw>multicast</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract>This document introduces some Forward Error Correction (FEC) schemes that supplement the FEC schemes described in RFC 3452. The primary benefits of these additional FEC schemes are that they are designed for reliable bulk delivery of large objects using a more compact FEC Payload ID, and they can be used to sequentially deliver blocks of an object of indeterminate length. Thus, they more flexibly support different delivery models with less packet header overhead. This document also describes the Fully-Specified FEC scheme corresponding to FEC Encoding ID 0. This Fully-Specified FEC scheme requires no FEC coding and is introduced primarily to allow simple interoperability testing between different implementations of protocol instantiations that use the FEC building block. This memo defines an Experimental Protocol for the Internet community.</abstract>
        <draft>ietf-rmt-bb-fec-supp-compact-01</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3696</doc-id>
        <title>Application Techniques for Checking and Transformation of Names</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39238</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>top-level domains</kw>
            <kw>tlds</kw>
        </keywords>
        <abstract>Many Internet applications have been designed to deduce top-level domains (or other domain name labels) from partial information. The introduction of new top-level domains, especially non-country-code ones, has exposed flaws in some of the methods used by these applications. These flaws make it more difficult, or impossible, for users of the applications to access the full Internet. This memo discusses some of the techniques that have been used and gives some guidance for minimizing their negative impact as the domain name environment evolves. This document draws summaries of the applicable rules together in one place and supplies references to the actual standards. This memo provides information for the Internet community.</abstract>
        <draft>klensin-name-filters-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3697</doc-id>
        <title>IPv6 Flow Label Specification</title>
        <author>
            <name>J. Rajahalme</name>
        </author>
        <author>
            <name>A. Conta</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <author>
            <name>S. Deering</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21296</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>nodes</kw>
            <kw>packets</kw>
        </keywords>
        <abstract>This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 source nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. [STANDARDS TRACK]</abstract>
        <draft>ietf-ipv6-flow-label-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3698</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP): Additional Matching Rules</title>
        <author>
            <name>K. Zeilenga</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17562</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>directory services</kw>
        </keywords>
        <abstract>This document provides a collection of matching rules for use with the Lightweight Directory Access Protocol (LDAP). As these matching rules are simple adaptations of matching rules specified for use with the X.500 Directory, most are already in wide use. [STANDARDS TRACK]</abstract>
        <draft>zeilenga-ldap-user-schema-mr-00</draft>
        <updates>
            <doc-id>RFC2798</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3700</doc-id>
        <title>Internet Official Protocol Standards</title>
        <author>
            <name>J. Reynolds</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Ginoza</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>148273</char-count>
            <page-count>54</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 22, 2004. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. [STANDARDS TRACK]</abstract>
        <obsoletes>
            <doc-id>RFC3600</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>STD0001</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3701</doc-id>
        <title>6bone (IPv6 Testing Address Allocation) Phaseout</title>
        <author>
            <name>R. Fink</name>
        </author>
        <author>
            <name>R. Hinden</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12019</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>protocol</kw>
            <kw>protocotype</kw>
            <kw>software</kw>
            <kw>architecture</kw>
        </keywords>
        <abstract>The 6bone was established in 1996 by the IETF as an IPv6 Testbed network to enable various IPv6 testing as well as to assist in the transitioning of IPv6 into the Internet. It operates under the IPv6 address allocation 3FFE::/16 from RFC 2471. As IPv6 is beginning its production deployment it is appropriate to plan for the phaseout of the 6bone. This document establishes a plan for a multi-year phaseout of the 6bone and its address allocation on the assumption that the IETF is the appropriate place to determine this. This document obsoletes RFC 2471, "IPv6 Testing Address Allocation", December, 1998. RFC 2471 will become historic. This memo provides information for the Internet community.</abstract>
        <draft>fink-6bone-phaseout-04</draft>
        <obsoletes>
            <doc-id>RFC2471</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3702</doc-id>
        <title>Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Loughney</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31243</char-count>
            <page-count>15</page-count>
        </format>
        <abstract>As Session Initiation Protocol (SIP) services are deployed on the Internet, there is a need for authentication, authorization, and accounting of SIP sessions. This document sets out the basic requirements for this work. This memo provides information for the Internet community.</abstract>
        <draft>ietf-sipping-aaa-req-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3703</doc-id>
        <title>Policy Core Lightweight Directory Access Protocol (LDAP) Schema</title>
        <author>
            <name>J. Strassner</name>
        </author>
        <author>
            <name>B. Moore</name>
        </author>
        <author>
            <name>R. Moats</name>
        </author>
        <author>
            <name>E. Ellesson</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>142983</char-count>
            <page-count>61</page-count>
        </format>
        <keywords>
            <kw>mapping classes</kw>
        </keywords>
        <abstract>This document defines a mapping of the Policy Core Information Model to a form that can be implemented in a directory that uses Lightweight Directory Access Protocol (LDAP) as its access protocol. This model defines two hierarchies of object classes: structural classes representing information for representing and controlling policy data as specified in RFC 3060, and relationship classes that indicate how instances of the structural classes are related to each other. Classes are also added to the LDAP schema to improve the performance of a client's interactions with an LDAP server when the client is retrieving large amounts of policy-related information. These classes exist only to optimize LDAP retrievals: there are no classes in the information model that correspond to them. [STANDARDS TRACK]</abstract>
        <draft>ietf-policy-core-schema-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3704</doc-id>
        <title>Ingress Filtering for Multihomed Networks</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>P. Savola</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35942</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>ISP</kw>
            <kw>Internet Service Provider</kw>
            <kw>Internet Protocol</kw>
            <kw>DOS</kw>
        </keywords>
        <abstract>BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>savola-bcp38-multihoming-update-03</draft>
        <updates>
            <doc-id>RFC2827</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0084</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3705</doc-id>
        <title>High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals</title>
        <author>
            <name>B. Ray</name>
        </author>
        <author>
            <name>R. Abbi</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24158</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>management information base</kw>
        </keywords>
        <abstract>This document presents a set of High Capacity Textual Conventions for use in MIB modules which require performance history based upon 15 minute intervals. The Textual Conventions defined in this document extend the conventions presented in RFC 3593 to 64 bit resolution using the conventions presented in RFC 2856. [STANDARDS TRACK]</abstract>
        <draft>ietf-adslmib-hc-tc-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3706</doc-id>
        <title>A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers</title>
        <author>
            <name>G. Huang</name>
        </author>
        <author>
            <name>S. Beaulieu</name>
        </author>
        <author>
            <name>D. Rochefort</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30196</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>security authentication</kw>
            <kw>dead peer detection</kw>
            <kw>dpd</kw>
            <kw>keepalive</kw>
        </keywords>
        <abstract>This document describes the method detecting a dead Internet Key Exchange (IKE) peer that is presently in use by a number of vendors. The method, called Dead Peer Detection (DPD) uses IPSec traffic patterns to minimize the number of IKE messages that are needed to confirm liveness. DPD, like other keepalive mechanisms, is needed to determine when to perform IKE peer failover, and to reclaim lost resources. This memo provides information for the Internet community.</abstract>
        <draft>ietf-ipsec-dpd-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3707</doc-id>
        <title>Cross Registry Internet Service Protocol (CRISP) Requirements</title>
        <author>
            <name>A. Newton</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52411</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>directory services domain</kw>
        </keywords>
        <abstract>Internet registries expose administrative and operational data via varying directory services. This document defines functional requirements for the directory services of domain registries and the common base requirements for extending the use of these services for other types of Internet registries. This memo provides information for the Internet community.</abstract>
        <draft>ietf-crisp-requirements-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3708</doc-id>
        <title>Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions</title>
        <author>
            <name>E. Blanton</name>
        </author>
        <author>
            <name>M. Allman</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20818</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>TCP and Stream Control Transmission Protocol (SCTP) provide notification of duplicate segment receipt through Duplicate Selective Acknowledgement (DSACKs) and Duplicate Transmission Sequence Number (TSN) notification, respectively. This document presents conservative methods of using this information to identify unnecessary retransmissions for various applications. This memo defines an Experimental Protocol for the Internet community.</abstract>
        <draft>ietf-tsvwg-dsack-use-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3709</doc-id>
        <title>Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates</title>
        <author>
            <name>S. Santesson</name>
        </author>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>T. Freeman</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46453</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>authentication</kw>
            <kw>security identification</kw>
        </keywords>
        <abstract>This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates. [STANDARDS TRACK]</abstract>
        <draft>ietf-pkix-logotypes-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3710</doc-id>
        <title>An IESG charter</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24912</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>internet engineering steering group</kw>
        </keywords>
        <abstract>This memo provides a charter for the Internet Engineering Steering Group (IESG), a management function of the Internet Engineering Task Force (IETF). It is meant to document the charter of the IESG as it is presently understood. This memo provides information for the Internet community.</abstract>
        <draft>iesg-charter-03</draft>
        <updated-by>
            <doc-id>RFC3932</doc-id>
        </updated-by>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3711</doc-id>
        <title>The Secure Real-time Transport Protocol (SRTP)</title>
        <author>
            <name>M. Baugher</name>
        </author>
        <author>
            <name>D. McGrew</name>
        </author>
        <author>
            <name>M. Naslund</name>
        </author>
        <author>
            <name>E. Carrara</name>
        </author>
        <author>
            <name>K. Norrman</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>134270</char-count>
            <page-count>56</page-count>
        </format>
        <keywords>
            <kw>authentication</kw>
            <kw>traffic</kw>
            <kw>cryptographic</kw>
        </keywords>
        <abstract>This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS TRACK]</abstract>
        <draft>ietf-avt-srtp-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3712</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP): Schema for Printer Services</title>
        <author>
            <name>P. Fleming</name>
        </author>
        <author>
            <name>I. McDonald</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>62301</char-count>
            <page-count>33</page-count>
        </format>
        <keywords>
            <kw>object classes</kw>
            <kw>attributes</kw>
        </keywords>
        <abstract>This document defines a schema, object classes and attributes, for printers and printer services, for use with directories that support Lightweight Directory Access Protocol v3 (LDAP-TS). This document is based on the printer attributes listed in Appendix E of Internet Printing Protocol/1.1 (IPP) (RFC 2911). A few additional printer attributes are based on definitions in the Printer MIB (RFC 1759). This memo provides information for the Internet community.</abstract>
        <draft>fleming-ldap-printer-schema-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3713</doc-id>
        <title>A Description of the Camellia Encryption Algorithm</title>
        <author>
            <name>M. Matsui</name>
        </author>
        <author>
            <name>J. Nakajima</name>
        </author>
        <author>
            <name>S. Moriai</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25031</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>key</kw>
            <kw>cryptographic</kw>
        </keywords>
        <abstract>This document describes the Camellia encryption algorithm. Camellia is a block cipher with 128-bit block size and 128-, 192-, and 256-bit keys. The algorithm description is presented together with key scheduling part and data randomizing part. This memo provides information for the Internet community.</abstract>
        <draft>nakajima-camellia-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3714</doc-id>
        <title>IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet</title>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>J. Kempf</name>
            <title>Editors</title>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>81368</char-count>
            <page-count>32</page-count>
        </format>
        <keywords>
            <kw>end-to-end</kw>
            <kw>qos</kw>
            <kw>qualify of service</kw>
            <kw>voip</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract>This document discusses IAB concerns about effective end-to-end congestion control for best-effort voice traffic in the Internet. These concerns have to do with fairness, user quality, and with the dangers of congestion collapse. The concerns are particularly relevant in light of the absence of a widespread Quality of Service (QoS) deployment in the Internet, and the likelihood that this situation will not change much in the near term. This document is not making any recommendations about deployment paths for Voice over Internet Protocol (VoIP) in terms of QoS support, and is not claiming that best-effort service can be relied upon to give acceptable performance for VoIP. We are merely observing that voice traffic is occasionally deployed as best-effort traffic over some links in the Internet, that we expect this occasional deployment to continue, and that we have concerns about the lack of effective end-to-end congestion control for this best-effort voice traffic. This memo provides information for the Internet community.</abstract>
        <draft>iab-congestion-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3715</doc-id>
        <title>IPsec-Network Address Translation (NAT) Compatibility Requirements</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>W. Dixon</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43476</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>virtual private networks</kw>
            <kw>vpns</kw>
            <kw>intranet</kw>
        </keywords>
        <abstract>This document describes known incompatibilities between Network Address Translation (NAT) and IPsec, and describes the requirements for addressing them. Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of Virtual Private Networks (VPNs) is to provide telecommuter access to the corporate Intranet. Today, NATs are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier in the deployment of IPsec in one of its principal uses. This memo provides information for the Internet community.</abstract>
        <draft>ietf-ipsec-nat-reqts-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3716</doc-id>
        <title>The IETF in the Large:  Administration and Execution</title>
        <author>
            <name>IAB Advisory Committee</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>91326</char-count>
            <page-count>40</page-count>
        </format>
        <abstract>In the fall of 2003, the IETF Chair and the IAB Chair formed an IAB Advisory Committee (AdvComm), with a mandate to review the existing IETF administrative structure and relationships (RFC Editor, IETF Secretariat, IANA) and to propose changes to the IETF management process or structure to improve the overall functioning of the IETF. The AdvComm mandate did not include the standards process itself. This memo provides information for the Internet community.</abstract>
        <draft>iab-advcomm-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3717</doc-id>
        <title>IP over Optical Networks: A Framework</title>
        <author>
            <name>B. Rajagopalan</name>
        </author>
        <author>
            <name>J. Luciani</name>
        </author>
        <author>
            <name>D. Awduche</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>124421</char-count>
            <page-count>48</page-count>
        </format>
        <keywords>
            <kw>transport infrastructure</kw>
            <kw>routers</kw>
            <kw>high-speed</kw>
        </keywords>
        <abstract>The Internet transport infrastructure is moving towards a model of high-speed routers interconnected by optical core networks. The architectural choices for the interaction between IP and optical network layers, specifically, the routing and signaling aspects, are maturing. At the same time, a consensus has emerged in the industry on utilizing IP-based protocols for the optical control plane. This document defines a framework for IP over Optical networks, considering both the IP-based control plane for optical networks as well as IP-optical network interactions (together referred to as "IP over optical networks"). This memo provides information for the Internet community.</abstract>
        <draft>ietf-ipo-framework-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3718</doc-id>
        <title>A Summary of Unicode Consortium Procedures, Policies, Stability, and Public Access</title>
        <author>
            <name>R. McGowan</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25865</char-count>
            <page-count>11</page-count>
        </format>
        <abstract>This memo describes various internal workings of the Unicode Consortium for the benefit of participants in the IETF. It is intended solely for informational purposes. Included are discussions of how the decision-making bodies of the Consortium work and their procedures, as well as information on public access to the character encoding &amp; standardization processes.</abstract>
        <draft>rmcgowan-unicode-procs-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3719</doc-id>
        <title>Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)</title>
        <author>
            <name>J. Parker</name>
            <title>Editor</title>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33941</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>routing</kw>
            <kw>routeing</kw>
            <kw>interior gateway protocol</kw>
            <kw>igp</kw>
            <kw>conformance</kw>
            <kw>ip traffic</kw>
        </keywords>
        <abstract>This document discusses a number of differences between the Intermediate System to Intermediate System (IS-IS) protocol as described in ISO 10589 and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol. A companion document discusses differences between the protocol described in RFC 1195 and the protocol as it is deployed today for routing IP traffic. This memo provides information for the Internet community.</abstract>
        <draft>ietf-isis-iso-interoperable-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3720</doc-id>
        <title>Internet Small Computer Systems Interface (iSCSI)</title>
        <author>
            <name>J. Satran</name>
        </author>
        <author>
            <name>K. Meth</name>
        </author>
        <author>
            <name>C. Sapuntzakis</name>
        </author>
        <author>
            <name>M. Chadalapaka</name>
        </author>
        <author>
            <name>E. Zeidner</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>578468</char-count>
            <page-count>257</page-count>
        </format>
        <keywords>
            <kw>transport protocol</kw>
            <kw>tcp</kw>
            <kw>transmission control protocol</kw>
        </keywords>
        <abstract>This document describes a transport protocol for Internet Small Computer Systems Interface (iSCSI) that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI architecture model. SCSI is a popular family of protocols that enable systems to communicate with I/O devices, especially storage devices. SCSI protocols are request/response application protocols with a common standardized architecture model and basic command set, as well as standardized command sets for different device classes (disks, tapes, media-changers etc.). As system interconnects move from the classical bus structure to a network structure, SCSI has to be mapped to network transport protocols. IP networks now meet the performance requirements of fast system interconnects and as such are good candidates to "carry" SCSI. [STANDARDS TRACK]</abstract>
        <draft>ietf-ips-iscsi-20</draft>
        <updated-by>
            <doc-id>RFC3980</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3721</doc-id>
        <title>Internet Small Computer Systems Interface (iSCSI) Naming and Discovery</title>
        <author>
            <name>M. Bakke</name>
        </author>
        <author>
            <name>J. Hafner</name>
        </author>
        <author>
            <name>J. Hufferd</name>
        </author>
        <author>
            <name>K. Voruganti</name>
        </author>
        <author>
            <name>M. Krueger</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47564</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>targets</kw>
            <kw>environments</kw>
            <kw>scalibilty</kw>
            <kw>target</kw>
            <kw>initiator</kw>
            <kw>scsi</kw>
            <kw>device name</kw>
        </keywords>
        <abstract>This document provides examples of the Internet Small Computer Systems Interface (iSCSI; or SCSI over TCP) name construction and discussion of discovery of iSCSI resources (targets) by iSCSI initiators. This document complements the iSCSI protocol document. Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions. This memo provides information for the Internet community.</abstract>
        <draft>ietf-ips-iscsi-name-disc-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3722</doc-id>
        <title>String Profile for Internet Small Computer Systems Interface (iSCSI) Names</title>
        <author>
            <name>M. Bakke</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14702</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>transport</kw>
            <kw>unique</kw>
            <kw>global</kw>
        </keywords>
        <abstract>This document describes how to prepare internationalized iSCSI names to increase the likelihood that name input and comparison work in ways that make sense for typical users throughout the world. The Internet Small Computer Systems Interface (iSCSI) protocol provides a way for hosts to access SCSI devices over an IP network. The iSCSI end-points, called initiators and targets, each have a globally-unique name that must be transcribable, as well as easily compared. [STANDARDS TRACK]</abstract>
        <draft>ietf-ips-iscsi-string-prep-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3723</doc-id>
        <title>Securing Block Storage Protocols over IP</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>J. Tseng</name>
        </author>
        <author>
            <name>J. Walker</name>
        </author>
        <author>
            <name>V. Rangan</name>
        </author>
        <author>
            <name>F. Travostino</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>171673</char-count>
            <page-count>70</page-count>
        </format>
        <keywords>
            <kw>internet</kw>
            <kw>threat models</kw>
            <kw>performance</kw>
            <kw>security</kw>
        </keywords>
        <abstract>This document discusses how to secure block storage and storage discovery protocols running over IP (Internet Protocol) using IPsec and IKE (Internet Key Exchange). Threat models and security protocols are developed for iSCSI (Internet Protocol Small Computer System Interface), iFCP (Internet Fibre Channel Storage Networking) and FCIP (Fibre Channel over TCP/IP), as well as the iSNS (Internet Storage Name Server) and SLPv2 (Service Location Protocol v2) discovery protocols. Performance issues and resource constraints are analyzed. [STANDARDS TRACK]</abstract>
        <draft>ietf-ips-security-19</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3724</doc-id>
        <title>The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture</title>
        <author>
            <name>J. Kempf</name>
        </author>
        <author>
            <name>R. Austein</name>
            <title>Editors</title>
        </author>
        <author>
            <name>IAB</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37206</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>architectural guideline</kw>
        </keywords>
        <abstract>The end-to-end principle is the core architectural guideline of the Internet. In this document, we briefly examine the development of the end-to-end principle as it has been applied to the Internet architecture over the years. We discuss current trends in the evolution of the Internet architecture in relation to the end-to-end principle, and try to draw some conclusion about the evolution of the end-to-end principle, and thus for the Internet architecture which it supports, in light of these current trends. This memo provides information for the Internet community.</abstract>
        <draft>iab-e2e-futures-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3725</doc-id>
        <title>Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>77308</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>Third party call control refers to the ability of one entity to create a call in which communication is actually between other parties. Third party call control is possible using the mechanisms specified within the Session Initiation Protocol (SIP). However, there are several possible approaches, each with different benefits and drawbacks. This document discusses best current practices for the usage of SIP for third party call control. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>ietf-sipping-3pcc-06</draft>
        <is-also>
            <doc-id>BCP0085</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3726</doc-id>
        <title>Requirements for Signaling Protocols</title>
        <author>
            <name>M. Brunner</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>98020</char-count>
            <page-count>42</page-count>
        </format>
        <keywords>
            <kw>rsvp</kw>
            <kw>resource reservation protocol</kw>
            <kw>middleboxes</kw>
            <kw>nsis</kw>
        </keywords>
        <abstract>This document defines requirements for signaling across different network environments, such as across administrative and/or technology domains. Signaling is mainly considered for Quality of Service (Qos) such as the Resource Reservation Protocol (RSVP). However, in recent years, several other applications of signaling have been defined. For example, signaling for label distribution in Multiprotocol Label Switching (MPLS) or signaling to middleboxes. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. This document presents the assumptions before listing the requirements. The requirements are grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility. This memo provides information for the Internet community.</abstract>
        <draft>ietf-nsis-req-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3727</doc-id>
        <title>ASN.1 Module Definition for the LDAP and X.500 Component Matching Rules</title>
        <author>
            <name>S. Legg</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8297</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>lightweight directory access protocol</kw>
        </keywords>
        <abstract>This document updates the specification of the component matching rules for Lightweight Directory Access Protocol (LDAP) and X.500 directories (RFC3687) by collecting the Abstract Syntax Notation One (ASN.1) definitions of the component matching rules into an appropriately identified ASN.1 module so that other specifications may reference the component matching rule definitions from within their own ASN.1 modules. [STANDARDS TRACK]</abstract>
        <draft>legg-ldap-cmr-module-00</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3728</doc-id>
        <title>Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL)</title>
        <author>
            <name>B. Ray</name>
        </author>
        <author>
            <name>R. Abbi</name>
        </author>
        <date>
            <month>February</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>147232</char-count>
            <page-count>76</page-count>
        </format>
        <keywords>
            <kw>management information base</kw>
            <kw>mib</kw>
        </keywords>
        <abstract>This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing Very High Speed Digital Subscriber Line (VDSL) interfaces. [STANDARDS TRACK]</abstract>
        <draft>ietf-adslmib-vdsl-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3729</doc-id>
        <title>Application Performance Measurement MIB</title>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>131354</char-count>
            <page-count>61</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for measuring the application performance as experienced by end-users. [STANDARDS TRACK]</abstract>
        <draft>ietf-rmonmib-apm-mib-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3730</doc-id>
        <title>Extensible Provisioning Protocol (EPP)</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>134337</char-count>
            <page-count>69</page-count>
        </format>
        <keywords>
            <kw>shared framework mapping</kw>
        </keywords>
        <abstract>This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. [STANDARDS TRACK]</abstract>
        <draft>ietf-provreg-epp-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3731</doc-id>
        <title>Extensible Provisioning Protocol (EPP) Domain Name Mapping</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>92527</char-count>
            <page-count>45</page-count>
        </format>
        <keywords>
            <kw>syntax</kw>
            <kw>semantics</kw>
        </keywords>
        <abstract>This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. [STANDARDS TRACK]</abstract>
        <draft>ietf-provreg-epp-domain-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3732</doc-id>
        <title>Extensible Provisioning Protocol (EPP) Host Mapping</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>57082</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>syntax</kw>
            <kw>semantics</kw>
        </keywords>
        <abstract>This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. [STANDARDS TRACK]</abstract>
        <draft>ietf-provreg-epp-host-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3733</doc-id>
        <title>Extensible Provisioning Protocol (EPP) Contact Mapping</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>83091</char-count>
            <page-count>41</page-count>
        </format>
        <keywords>
            <kw>syntax</kw>
            <kw>semantics</kw>
        </keywords>
        <abstract>This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. [STANDARDS TRACK]</abstract>
        <draft>ietf-provreg-epp-contact-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3734</doc-id>
        <title>Extensible Provisioning Protocol (EPP) Transport Over TCP</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19550</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>mapping</kw>
            <kw>client</kw>
            <kw>server</kw>
            <kw>tls</kw>
            <kw>transport layer security</kw>
        </keywords>
        <abstract>This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. [STANDARDS TRACK]</abstract>
        <draft>ietf-provreg-epp-tcp-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3735</doc-id>
        <title>Guidelines for Extending the Extensible Provisioning Protocol (EPP)</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27326</char-count>
            <page-count>13</page-count>
        </format>
        <abstract>The Extensible Provisioning Protocol (EPP) is an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document presents guidelines for use of EPP's extension mechanisms to define new features and object management capabilities. This memo provides information for the Internet community.</abstract>
        <draft>ietf-provreg-epp-ext-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3736</doc-id>
        <title>Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6</title>
        <author>
            <name>R. Droms</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18510</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>Stateless Dynamic Host Configuration Protocol service for IPv6 (DHCPv6) is used by nodes to obtain configuration information, such as the addresses of DNS recursive name servers, that does not require the maintenance of any dynamic state for individual clients. A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. This document explains which parts of RFC 3315 must be implemented in each of the different kinds of DHCP agents so that agent can support stateless DHCP. [STANDARDS TRACK]</abstract>
        <draft>ietf-dhc-dhcpv6-stateless-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3737</doc-id>
        <title>IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules</title>
        <author>
            <name>B. Wijnen</name>
        </author>
        <author>
            <name>A. Bierman</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13127</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>management information base</kw>
            <kw>internet assigned numbers authority</kw>
        </keywords>
        <abstract>This document defines the procedures for IANA to administer and maintain the Object Identifier (OID) tree under the Remote Monitoring (rmon) root. This memo also documents the currently assigned values. [STANDARDS TRACK]</abstract>
        <draft>ietf-rmonmib-rmon-oid-assignments-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3738</doc-id>
        <title>Wave and Equation Based Rate Control (WEBRC) Building Block</title>
        <author>
            <name>M. Luby</name>
        </author>
        <author>
            <name>V. Goyal</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>82584</char-count>
            <page-count>32</page-count>
        </format>
        <keywords>
            <kw>congestion control</kw>
            <kw>data delivery</kw>
            <kw>multicast</kw>
            <kw>ip</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract>This document specifies Wave and Equation Based Rate Control (WEBRC), which provides rate and congestion control for data delivery. WEBRC is specifically designed to support protocols using IP multicast. It provides multiple-rate, congestion-controlled delivery to receivers, i.e., different receivers joined to the same session may be receiving packets at different rates depending on the bandwidths of their individual connections to the sender and on competing traffic along these connections. WEBRC requires no feedback from receivers to the sender, i.e., it is a completely receiver-driven congestion control protocol. Thus, it is designed to scale to potentially massive numbers of receivers attached to a session from a single sender. Furthermore, because each individual receiver adjusts to the available bandwidth between the sender and that receiver, there is the potential to deliver data to each individual receiver at the fastest possible rate for that receiver, even in a highly heterogeneous network architecture, using a single sender. This memo defines an Experimental Protocol for the Internet community.</abstract>
        <draft>ietf-rmt-bb-webrc-04</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3739</doc-id>
        <title>Internet X.509 Public Key Infrastructure: Qualified Certificates Profile</title>
        <author>
            <name>S. Santesson</name>
        </author>
        <author>
            <name>M. Nystrom</name>
        </author>
        <author>
            <name>T. Polk</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>67436</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>syntax</kw>
        </keywords>
        <abstract>This document forms a certificate profile, based on RFC 3280, for identity certificates issued to natural persons. The profile defines specific conventions for certificates that are qualified within a defined legal framework, named Qualified Certificates. However, the profile does not define any legal requirements for such Qualified Certificates. The goal of this document is to define a certificate profile that supports the issuance of Qualified Certificates independent of local legal requirements. The profile is however not limited to Qualified Certificates and further profiling may facilitate specific local needs. [STANDARDS TRACK]</abstract>
        <draft>ietf-pkix-sonof3039-06</draft>
        <obsoletes>
            <doc-id>RFC3039</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3740</doc-id>
        <title>The Multicast Group Security Architecture</title>
        <author>
            <name>T. Hardjono</name>
        </author>
        <author>
            <name>B. Weis</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>65531</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>data packets</kw>
        </keywords>
        <abstract>This document provides an overview and rationale of the multicast security architecture used to secure data packets of large multicast groups. The document begins by introducing a Multicast Security Reference Framework, and proceeds to identify the security services that may be part of a secure multicast solution. This memo provides information for the Internet community.</abstract>
        <draft>ietf-msec-arch-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3741</doc-id>
        <title>Exclusive XML Canonicalization, Version 1.0</title>
        <author>
            <name>J. Boyer</name>
        </author>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <author>
            <name>J. Reagle</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35403</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>extensible markup language</kw>
            <kw>namespace</kw>
        </keywords>
        <abstract>Canonical XML specifies a standard serialization of XML that, when applied to a subdocument, includes the subdocument's ancestor context including all of the namespace declarations and attributes in the "xml:" namespace. However, some applications require a method which, to the extent practical, excludes ancestor context from a canonicalized subdocument. For example, one might require a digital signature over an XML payload (subdocument) in an XML message that will not break when that subdocument is removed from its original message and/or inserted into a different context. This requirement is satisfied by Exclusive XML Canonicalization. This memo provides information for the Internet community.</abstract>
        <draft>ietf-xmldsig-xc14n-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3742</doc-id>
        <title>Limited Slow-Start for TCP with Large Congestion Windows</title>
        <author>
            <name>S. Floyd</name>
        </author>
        <date>
            <month>March</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14840</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>transmission control protocol</kw>
        </keywords>
        <abstract>This document describes an optional modification for TCP's slow-start for use with TCP connections with large congestion windows. For TCP connections that are able to use congestion windows of thousands (or tens of thousands) of MSS-sized segments (for MSS the sender's MAXIMUM SEGMENT SIZE), the current slow-start procedure can result in increasing the congestion window by thousands of segments in a single round-trip time. Such an increase can easily result in thousands of packets being dropped in one round-trip time. This is often counter-productive for the TCP flow itself, and is also hard on the rest of the traffic sharing the congested link. This note describes Limited Slow-Start as an optional mechanism for limiting the number of segments by which the congestion window is increased for one window of data during slow-start, in order to improve performance for TCP connections with large congestion windows. This memo defines an Experimental Protocol for the Internet community.</abstract>
        <draft>ietf-tsvwg-slowstart-00</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3743</doc-id>
        <title>Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean</title>
        <author>
            <name>K. Konishi</name>
        </author>
        <author>
            <name>K. Huang</name>
        </author>
        <author>
            <name>H. Qian</name>
        </author>
        <author>
            <name>Y. Ko</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>74963</char-count>
            <page-count>33</page-count>
        </format>
        <abstract>Achieving internationalized access to domain names raises many complex issues. These are associated not only with basic protocol design, such as how names are represented on the network, compared, and converted to appropriate forms, but also with issues and options for deployment, transition, registration, and administration. The IETF Standards for Internationalized Domain Names, known as "IDNA", focuses on access to domain names in a range of scripts that is broader in scope than the original ASCII. The development process made it clear that use of characters with similar appearances and/or interpretations created potential for confusion, as well as difficulties in deployment and transition. The conclusion was that, while those issues were important, they could best be addressed administratively rather than through restrictions embedded in the protocols. This document defines a set of guidelines for applying restrictions of that type for Chinese, Japanese and Korean (CJK) scripts and the zones that use them and, perhaps, the beginning of a framework for thinking about other zones, languages, and scripts. This memo provides information for the Internet community.</abstract>
        <draft>jseng-idn-admin-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3744</doc-id>
        <title>Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol</title>
        <author>
            <name>G. Clemm</name>
        </author>
        <author>
            <name>J. Reschke</name>
        </author>
        <author>
            <name>E. Sedlar</name>
        </author>
        <author>
            <name>J. Whitehead</name>
        </author>
        <date>
            <month>May</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>146623</char-count>
            <page-count>72</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document specifies a set of methods, headers, message bodies, properties, and reports that define Access Control extensions to the WebDAV Distributed Authoring Protocol. This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such as HyperText Transfer Protocol (HTTP) method invocations) by a given principal. A lightweight representation of principals as Web resources supports integration of a wide range of user management repositories. Search operations allow discovery and manipulation of principals using human names. [STANDARDS TRACK]</abstract>
        <draft>ietf-webdav-acl-13</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3745</doc-id>
        <title>MIME Type Registrations for JPEG 2000 (ISO/IEC 15444)</title>
        <author>
            <name>D. Singer</name>
        </author>
        <author>
            <name>R. Clark</name>
        </author>
        <author>
            <name>D. Lee</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31224</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>multipurpose internet mail extensions</kw>
            <kw>joint photographic experts group</kw>
        </keywords>
        <abstract>This document serves to register and document the standard MIME types associated with the ISO/IEC 15444 standards, commonly known as JPEG 2000 (Joint Photographic Experts Group). [STANDARDS TRACK]</abstract>
        <draft>singer-jp2-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3746</doc-id>
        <title>Forwarding and Control Element Separation (ForCES) Framework</title>
        <author>
            <name>L. Yang</name>
        </author>
        <author>
            <name>R. Dantu</name>
        </author>
        <author>
            <name>T. Anderson</name>
        </author>
        <author>
            <name>R. Gopal</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>98660</char-count>
            <page-count>40</page-count>
        </format>
        <keywords>
            <kw>network elements</kw>
        </keywords>
        <abstract>This document defines the architectural framework for the ForCES (Forwarding and Control Element Separation) network elements, and identifies the associated entities and their interactions. This is memo provides information for the Internet community.</abstract>
        <draft>ietf-forces-framework-13</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3747</doc-id>
        <title>The Differentiated Services Configuration MIB</title>
        <author>
            <name>H. Hazewinkel</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. Partain</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51659</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>management information base</kw>
            <kw>diffserv</kw>
        </keywords>
        <abstract>This memo describes a MIB module that provides a conceptual layer between high-level "network-wide" policy definitions that effect configuration of the Differentiated Services (diffserv) subsystem and the instance-specific information that would include such details as the parameters for all the queues associated with each interface in a system. This essentially provides an interface for configuring differentiated services at a conceptually higher layer than that of the Differentiated Services MIB. [PROPOSED STANDARD]</abstract>
        <draft>ietf-snmpconf-diffpolicy-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3748</doc-id>
        <title>Extensible Authentication Protocol (EAP)</title>
        <author>
            <name>B. Aboba</name>
        </author>
        <author>
            <name>L. Blunk</name>
        </author>
        <author>
            <name>J. Vollbrecht</name>
        </author>
        <author>
            <name>J. Carlson</name>
        </author>
        <author>
            <name>H. Levkowetz</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>157994</char-count>
            <page-count>67</page-count>
        </format>
        <keywords>
            <kw>PPP-EAP</kw>
            <kw>data link layers</kw>
            <kw>ppp</kw>
            <kw>point-to-point</kw>
            <kw>ieee 802</kw>
        </keywords>
        <abstract>This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS TRACK]</abstract>
        <draft>ietf-eap-rfc2284bis-09</draft>
        <obsoletes>
            <doc-id>RFC2284</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3749</doc-id>
        <title>Transport Layer Security Protocol Compression Methods</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>May</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16411</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>tls</kw>
            <kw>lossless data compression</kw>
            <kw>handshake protocol</kw>
        </keywords>
        <abstract>The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and to then apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with a lossless data compression algorithm for use with TLS, and it describes a method for the specification of additional TLS compression methods. [STANDARDS TRACK]</abstract>
        <draft>ietf-tls-compression-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3750</doc-id>
        <title>Unmanaged Networks IPv6 Transition Scenarios</title>
        <author>
            <name>C. Huitema</name>
        </author>
        <author>
            <name>R. Austein</name>
        </author>
        <author>
            <name>S. Satapati</name>
        </author>
        <author>
            <name>R. van der Pol</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48153</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>single subnet</kw>
            <kw>gateway</kw>
            <kw>isp</kw>
            <kw>internet service provider</kw>
        </keywords>
        <abstract>This document defines the scenarios in which IPv6 transition mechanisms are to be used in unmanaged networks. In order to evaluate the suitability of these mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the "unmanaged network", which typically corresponds to a home or small office network. The scenarios are specific to a single subnet, and are defined in terms of IP connectivity supported by the gateway and the Internet Service Provider (ISP). We first examine the generic requirements of four classes of applications: local, client, peer to peer and server. Then, for each scenario, we infer transition requirements by analyzing the needs for smooth migration of applications from IPv4 to IPv6. This memo provides information for the Internet community.</abstract>
        <draft>ietf-v6ops-unman-scenarios-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3751</doc-id>
        <title>Omniscience Protocol Requirements</title>
        <author>
            <name>S. Bradner</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20771</char-count>
            <page-count>9</page-count>
        </format>
        <abstract>There have been a number of legislative initiatives in the U.S. and elsewhere over the past few years to use the Internet to actively interfere with allegedly illegal activities of Internet users. This memo proposes a number of requirements for a new protocol, the Omniscience Protocol, that could be used to enable such efforts. This memo provides information for the Internet community.</abstract>
        <draft>bradner-op-req-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3752</doc-id>
        <title>Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios</title>
        <author>
            <name>A. Barbir</name>
        </author>
        <author>
            <name>E. Burger</name>
        </author>
        <author>
            <name>R. Chen</name>
        </author>
        <author>
            <name>S. McHenry</name>
        </author>
        <author>
            <name>H. Orman</name>
        </author>
        <author>
            <name>R. Penno</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29481</char-count>
            <page-count>14</page-count>
        </format>
        <abstract>This memo provides a discussion of use cases and deployment scenarios for Open Pluggable Edge Services (OPES). The work examines services that could be performed to requests and/or responses. This memo provides information for the Internet community.</abstract>
        <draft>ietf-opes-scenarios-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3753</doc-id>
        <title>Mobility Related Terminology</title>
        <author>
            <name>J. Manner</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Kojo</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>74143</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>networks</kw>
            <kw>ip</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract>There is a need for common definitions of terminology in the work to be done around IP mobility. This document defines terms for mobility related terminology. The document originated out of work done in the Seamoby Working Group but has broader applicability for terminology used in IETF-wide discourse on technology for mobility and IP networks. Other working groups dealing with mobility may want to take advantage of this terminology. This memo provides information for the Internet community.</abstract>
        <draft>ietf-seamoby-mobility-terminology-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3754</doc-id>
        <title>IP Multicast in Differentiated Services (DS) Networks</title>
        <author>
            <name>R. Bless</name>
        </author>
        <author>
            <name>K. Wehrle</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>86533</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>internet protocol</kw>
        </keywords>
        <abstract>This document discusses the problems of IP Multicast use in Differentiated Services (DS) networks, expanding on the discussion in RFC 2475 ("An Architecture of Differentiated Services"). It also suggests possible solutions to these problems, describes a potential implementation model, and presents simulation results. This memo provides information for the Internet community.</abstract>
        <draft>bless-diffserv-multicast-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3755</doc-id>
        <title>Legacy Resolver Compatibility for Delegation Signer (DS)</title>
        <author>
            <name>S. Weiler</name>
        </author>
        <date>
            <month>May</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19812</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>dnssec</kw>
            <kw>DNS Security</kw>
            <kw>rr</kw>
            <kw>resource record</kw>
            <kw>DNS-SECEXT</kw>
            <kw>dns</kw>
            <kw>authentication</kw>
            <kw>nsec</kw>
            <kw>nextsecure</kw>
        </keywords>
        <abstract>As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed. Many deployed nameservers understand variants of these semantics. Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document changes the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions. [STANDARDS TRACK]</abstract>
        <draft>ietf-dnsext-dnssec-2535typecode-change-06</draft>
        <obsoleted-by>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4035</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3658</doc-id>
            <doc-id>RFC2535</doc-id>
        </updates>
        <updated-by>
            <doc-id>RFC3757</doc-id>
            <doc-id>RFC3845</doc-id>
        </updated-by>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3756</doc-id>
        <title>IPv6 Neighbor Discovery (ND) Trust Models and Threats</title>
        <author>
            <name>P. Nikander</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Kempf</name>
        </author>
        <author>
            <name>E. Nordmark</name>
        </author>
        <date>
            <month>May</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>56674</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>authentication</kw>
            <kw>security key management</kw>
        </keywords>
        <draft>ietf-send-psreq-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3757</doc-id>
        <title>Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag</title>
        <author>
            <name>O. Kolkman</name>
        </author>
        <author>
            <name>J. Schlyter</name>
        </author>
        <author>
            <name>E. Lewis</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16868</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>dnssec</kw>
        </keywords>
        <abstract>With the Delegation Signer (DS) resource record (RR), the concept of a public key acting as a secure entry point (SEP) has been introduced. During exchanges of public keys with the parent there is a need to differentiate SEP keys from other public keys in the Domain Name System KEY (DNSKEY) resource record set. A flag bit in the DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP. The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what DNSKEYs are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC 2535 and RFC 3755. [STANDARDS TRACK]</abstract>
        <draft>ietf-dnsext-keyrr-key-signing-flag-12</draft>
        <obsoleted-by>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4035</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3755</doc-id>
            <doc-id>RFC2535</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3758</doc-id>
        <title>Stream Control Transmission Protocol (SCTP) Partial Reliability Extension</title>
        <author>
            <name>R. Stewart</name>
        </author>
        <author>
            <name>M. Ramalho</name>
        </author>
        <author>
            <name>Q. Xie</name>
        </author>
        <author>
            <name>M. Tuexen</name>
        </author>
        <author>
            <name>P. Conrad</name>
        </author>
        <date>
            <month>May</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>50999</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>init</kw>
            <kw>init ack</kw>
            <kw>forward tsn</kw>
        </keywords>
        <abstract>This memo describes an extension to the Stream Control Transmission Protocol (SCTP) that allows an SCTP endpoint to signal to its peer that it should move the cumulative ack point forward. When both sides of an SCTP association support this extension, it can be used by an SCTP implementation to provide partially reliable data transmission service to an upper layer protocol. This memo describes the protocol extensions, which consist of a new parameter for INIT and INIT ACK, and a new FORWARD TSN chunk type, and provides one example of a partially reliable service that can be provided to the upper layer via this mechanism. [STANDARDS TRACK]</abstract>
        <draft>ietf-tsvwg-prsctp-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3759</doc-id>
        <title>RObust Header Compression (ROHC): Terminology and Channel Mapping Examples</title>
        <author>
            <name>L-E. Jonsson</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>50168</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>encapsulating</kw>
            <kw>security</kw>
            <kw>payload</kw>
            <kw>real-time</kw>
            <kw>transport</kw>
            <kw>protocol</kw>
            <kw>user</kw>
            <kw>datagram</kw>
        </keywords>
        <abstract>This document aims to clarify terms and concepts presented in RFC 3095. RFC 3095 defines a Proposed Standard framework with profiles for RObust Header Compression (ROHC). The standard introduces various concepts which might be difficult to understand and especially to relate correctly to the surrounding environments where header compression may be used. This document aims at clarifying these aspects of ROHC, discussing terms such as ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts, and how these terms relate to other terms, like network elements and IP interfaces, commonly used, for example, when addressing MIB issues. This memo provides information for the Internet community.</abstract>
        <draft>ietf-rohc-terminology-and-examples-02</draft>
        <updates>
            <doc-id>RFC3095</doc-id>
        </updates>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3760</doc-id>
        <title>Securely Available Credentials (SACRED) - Credential Server Framework</title>
        <author>
            <name>D. Gustafson</name>
        </author>
        <author>
            <name>M. Just</name>
        </author>
        <author>
            <name>M. Nystrom</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49910</char-count>
            <page-count>22</page-count>
        </format>
        <abstract>As the number, and more particularly the number of different types, of devices connecting to the Internet increases, credential mobility becomes an issue for IETF standardization. This document responds to the requirements on protocols for secure exchange of credentials listed in RFC 3157, by presenting an abstract protocol framework. This memo provides information for the Internet community.</abstract>
        <draft>ietf-sacred-framework-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3761</doc-id>
        <title>The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)</title>
        <author>
            <name>P. Faltstrom</name>
        </author>
        <author>
            <name>M. Mealling</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41559</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>domain name system</kw>
        </keywords>
        <abstract>This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC 3401. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401. [STANDARDS TRACK]</abstract>
        <draft>ietf-enum-rfc2916bis-07</draft>
        <obsoletes>
            <doc-id>RFC2916</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3762</doc-id>
        <title>Telephone Number Mapping (ENUM) Service Registration for H.323</title>
        <author>
            <name>O. Levin</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8450</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>multimedia</kw>
            <kw>packet based network</kw>
        </keywords>
        <abstract>The H.323 specification defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. This document registers a Telephone Number Mapping (ENUM) service for H.323 according to specifications and guidelines in RFC 3761. [STANDARDS TRACK]</abstract>
        <draft>ietf-enum-h323-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3763</doc-id>
        <title>One-way Active Measurement Protocol (OWAMP) Requirements</title>
        <author>
            <name>S. Shalunov</name>
        </author>
        <author>
            <name>B. Teitelbaum</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23360</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>performance metrics</kw>
            <kw>delay</kw>
            <kw>unidirectional</kw>
        </keywords>
        <abstract>With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. This document specifies requirements for a one-way active measurement protocol (OWAMP) standard. The protocol can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss. This memo provides information for the Internet community.</abstract>
        <draft>ietf-ippm-owdp-reqs-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status></publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3764</doc-id>
        <title>enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17604</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>aor</kw>
            <kw>electronic number</kw>
        </keywords>
        <abstract>This document registers an Electronic Number (ENUM) service for the Session Initiation Protocol (SIP), pursuant to the guidelines in RFC 3761. Specifically, this document focuses on provisioning SIP addresses-of-record in ENUM. [STANDARDS TRACK]</abstract>
        <draft>ietf-enum-sip-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3765</doc-id>
        <title>NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control</title>
        <author>
            <name>G. Huston</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16500</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>peer connections</kw>
            <kw>propagated</kw>
        </keywords>
        <abstract>This document describes the use of a scope control Border Gateway Protocol (BGP) community. This well-known advisory transitive community allows an origin AS to specify the extent to which a specific route should be externally propagated. In particular this community, NOPEER, allows an origin AS to specify that a route with this attribute need not be advertised across bilateral peer connections. This memo provides information for the Internet community.</abstract>
        <draft>ietf-ptomaine-nopeer-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3766</doc-id>
        <title>Determining Strengths For Public Keys Used For Exchanging Symmetric Keys</title>
        <author>
            <name>H. Orman</name>
        </author>
        <author>
            <name>P. Hoffman</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>55939</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>cryptography algorithms</kw>
            <kw>integers</kw>
        </keywords>
        <abstract>Implementors of systems that use public key cryptography to exchange symmetric keys need to make the public keys resistant to some predetermined level of attack. That level of attack resistance is the strength of the system, and the symmetric keys that are exchanged must be at least as strong as the system strength requirements. The three quantities, system strength, symmetric key strength, and public key strength, must be consistently matched for any network protocol usage. While it is fairly easy to express the system strength requirements in terms of a symmetric key length and to choose a cipher that has a key length equal to or exceeding that requirement, it is harder to choose a public key that has a cryptographic strength meeting a symmetric key strength requirement. This document explains how to determine the length of an asymmetric key as a function of a symmetric key strength requirement. Some rules of thumb for estimating equivalent resistance to large-scale attacks on various algorithms are given. The document also addresses how changing the sizes of the underlying large integers (moduli, group sizes, exponents, and so on) changes the time to use the algorithms for key exchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>orman-public-key-lengths-08</draft>
        <is-also>
            <doc-id>BCP0086</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3767</doc-id>
        <title>Securely Available Credentials Protocol</title>
        <author>
            <name>S. Farrell</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49552</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>beep</kw>
            <kw>blocks extensible exchange protocol</kw>
            <kw>xml</kw>
            <kw>extensible mark up language</kw>
        </keywords>
        <abstract>This document describes a protocol whereby a user can acquire cryptographic credentials (e.g., private keys, PKCS #15 structures) from a credential server, using a workstation that has locally trusted software installed, but with no user-specific configuration. The protocol's payloads are described in XML. This memo also specifies a Blocks Extensible Exchange Protocol (BEEP) profile of the protocol. Security requirements are met by mandating support for TLS and/or DIGEST-MD5 (through BEEP). [STANDARDS TRACK]</abstract>
        <draft>ietf-sacred-protocol-bss-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3768</doc-id>
        <title>Virtual Router Redundancy Protocol (VRRP)</title>
        <author>
            <name>R. Hinden</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59969</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>VRRP</kw>
            <kw>vrrp</kw>
            <kw>lan</kw>
            <kw>local</kw>
            <kw>area</kw>
            <kw>network</kw>
            <kw>ip</kw>
            <kw>internet</kw>
            <kw>protocol</kw>
        </keywords>
        <abstract>This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. [STANDARDS TRACK]</abstract>
        <draft>ietf-vrrp-spec-v2-10</draft>
        <obsoletes>
            <doc-id>RFC2338</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3769</doc-id>
        <title>Requirements for IPv6 Prefix Delegation</title>
        <author>
            <name>S. Miyakawa</name>
        </author>
        <author>
            <name>R. Droms</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10287</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>internet protocol version 6</kw>
        </keywords>
        <abstract>This document describes requirements for how IPv6 address prefixes should be delegated to an IPv6 subscriber's network (or "site"). This memo provides information for the Internet community.</abstract>
        <draft>ietf-ipv6-prefix-delegation-requirement-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3770</doc-id>
        <title>Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <author>
            <name>T. Moore</name>
        </author>
        <date>
            <month>May</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18635</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>ssid</kw>
            <kw>system service identifiers</kw>
            <kw>eap</kw>
        </keywords>
        <abstract>This document defines two EAP extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). [STANDARDS TRACK]</abstract>
        <draft>ietf-pkix-wlan-extns-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3771</doc-id>
        <title>The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message</title>
        <author>
            <name>R. Harrison</name>
        </author>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17114</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>LDAPv3</kw>
            <kw>LDAv3</kw>
            <kw>x.500</kw>
        </keywords>
        <abstract>This document defines and describes the IntermediateResponse message, a general mechanism for defining single-request/multiple-response operations in Lightweight Directory Access Protocol (LDAP). The IntermediateResponse message is defined in such a way that the protocol behavior of existing LDAP operations is maintained. This message is intended to be used in conjunction with the LDAP ExtendedRequest and ExtendedResponse to define new single-request/multiple-response operations or in conjunction with a control when extending existing LDAP operations in a way that requires them to return intermediate response information. [STANDARDS TRACK]</abstract>
        <draft>rharrison-ldap-intermediate-resp-01</draft>
        <updates>
            <doc-id>RFC2251</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3772</doc-id>
        <title>Point-to-Point Protocol (PPP) Vendor Protocol</title>
        <author>
            <name>J. Carlson</name>
        </author>
        <author>
            <name>R. Winslow</name>
        </author>
        <date>
            <month>May</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19846</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>link control protocol</kw>
            <kw>lcp</kw>
        </keywords>
        <abstract>The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. The PPP Vendor Extensions document adds vendor-specific general-purpose Configuration Option and Code numbers. This document extends these features to cover vendor-specific Network, Authentication, and Control Protocols. [STANDARDS TRACK]</abstract>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3773</doc-id>
        <title>High-Level Requirements for Internet Voice Mail</title>
        <author>
            <name>E. Candell</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19156</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>ivm</kw>
            <kw>internet voice messaging</kw>
            <kw>voice profile for internet mail</kw>
            <kw>vpim</kw>
        </keywords>
        <abstract>This document describes the high-level requirements for Internet Voice Mail (IVM) and establishes a baseline of desired functionality against which proposed MIME profiles for Internet Voice Messaging can be judged. IVM is an extension of the Voice Profile for Internet Mail (VPIM) version 2 designed to support interoperability with desktop clients. Other goals for this version of VPIM include expanded interoperability with unified messaging systems, conformance to Internet standards, and backward compatibility with voice messaging systems currently running in a VPIM enabled environment. This document does not include goals that were met fully by VPIM version 2. This memo provides information for the Internet community.</abstract>
        <draft>ietf-vpim-ivm-goals-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3774</doc-id>
        <title>IETF Problem Statement</title>
        <author>
            <name>E. Davies</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>55172</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>ietf</kw>
            <kw>process</kw>
            <kw>problem</kw>
            <kw>analysis</kw>
        </keywords>
        <abstract>This memo summarizes perceived problems in the structure, function, and processes of the Internet Engineering Task Force (IETF). We are attempting to identify these problems, so that they can be addressed and corrected by the IETF community. The problems have been digested and categorized from an extensive discussion which took place on the 'problem-statement' mailing list from November 2002 to September 2003. The problem list has been further analyzed in an attempt to determine the root causes at the heart of the perceived problems: The result will be used to guide the next stage of the process in the Problem Statement working group which is to recommend the structures and processes that will carry out the corrections. This memo provides information for the Internet community.</abstract>
        <draft>ietf-problem-issue-statement-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3775</doc-id>
        <title>Mobility Support in IPv6</title>
        <author>
            <name>D. Johnson</name>
        </author>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>J. Arkko</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>393514</char-count>
            <page-count>165</page-count>
        </format>
        <keywords>
            <kw>internet protocol</kw>
            <kw>nodes</kw>
        </keywords>
        <abstract>This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. [STANDARDS TRACK]</abstract>
        <draft>ietf-mobileip-ipv6-24</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3776</doc-id>
        <title>Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>V. Devarapalli</name>
        </author>
        <author>
            <name>F. Dupont</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>87076</char-count>
            <page-count>40</page-count>
        </format>
        <keywords>
            <kw>security</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract>Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node. Mobile IPv6 base document defines the main requirements these nodes must follow. This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order. [STANDARDS TRACK]</abstract>
        <draft>ietf-mobileip-mipv6-ha-ipsec-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3777</doc-id>
        <title>IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees</title>
        <author>
            <name>J. Galvin</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>76395</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>Internet Architecture Board</kw>
            <kw>Engineering Steering Group</kw>
        </keywords>
        <abstract>The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self-consistent, organized compilation of the process as it was known at the time of publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>ietf-nomcom-rfc2727bis-09</draft>
        <obsoletes>
            <doc-id>RFC2727</doc-id>
        </obsoletes>
        <is-also>
            <doc-id>BCP0010</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3778</doc-id>
        <title>The application/pdf Media Type</title>
        <author>
            <name>E. Taft</name>
        </author>
        <author>
            <name>J. Pravetz</name>
        </author>
        <author>
            <name>S. Zilles</name>
        </author>
        <author>
            <name>L. Masinter</name>
        </author>
        <date>
            <month>May</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29891</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>portable document format</kw>
            <kw>document exchange</kw>
            <kw>digital signatures</kw>
        </keywords>
        <abstract>PDF, the 'Portable Document Format', is a general document representation language that has been in use for document exchange on the Internet since 1993. This document provides an overview of the PDF format, explains the mechanisms for digital signatures and encryption within PDF files, and updates the media type registration of 'application/pdf'. This memo provides information for the Internet community.</abstract>
        <draft>zilles-pdf-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3779</doc-id>
        <title>X.509 Extensions for IP Addresses and AS Identifiers</title>
        <author>
            <name>C. Lynn</name>
        </author>
        <author>
            <name>S. Kent</name>
        </author>
        <author>
            <name>K. Seo</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>60732</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>allocation</kw>
            <kw>atrribute certificate</kw>
            <kw>authorization</kw>
            <kw>autonomous system number authorization</kw>
            <kw>certificate</kw>
            <kw>delegation</kw>
            <kw>internet registry</kw>
            <kw>ip address authorization</kw>
            <kw>public key infrastructure</kw>
            <kw>right-to-use</kw>
            <kw>secure allocation</kw>
        </keywords>
        <abstract>This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. [STANDARDS TRACK]</abstract>
        <draft>ietf-pkix-x509-ipaddr-as-extn-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3780</doc-id>
        <title>SMIng - Next Generation Structure of Management Information</title>
        <author>
            <name>F. Strauss</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>May</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>141049</char-count>
            <page-count>64</page-count>
        </format>
        <keywords>
            <kw>data definition language</kw>
        </keywords>
        <abstract>This memo defines the base SMIng (Structure of Management Information, Next Generation) language. SMIng is a data definition language that provides a protocol-independent representation for management information. Separate RFCs define mappings of SMIng to specific management protocols, including SNMP. This memo defines an Experimental Protocol for the Internet community.</abstract>
        <draft>irtf-nmrg-sming-07</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3781</doc-id>
        <title>Next Generation Structure of Management Information (SMIng) Mappings to the Simple Network Management Protocol (SNMP)</title>
        <author>
            <name>F. Strauss</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>May</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>112267</char-count>
            <page-count>49</page-count>
        </format>
        <keywords>
            <kw>data definition language</kw>
        </keywords>
        <abstract>SMIng (Structure of Management Information, Next Generation) (RFC3780), is a protocol-independent data definition language for management information. This memo defines an SMIng language extension that specifies the mapping of SMIng definitions of identities, classes, and their attributes and events to dedicated definitions of nodes, scalar objects, tables and columnar objects, and notifications, for application to the SNMP management framework. This memo defines an Experimental Protocol for the Internet community.</abstract>
        <draft>irtf-nmrg-sming-snmp-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3782</doc-id>
        <title>The NewReno Modification to TCP's Fast Recovery Algorithm</title>
        <author>
            <name>S. Floyd</name>
        </author>
        <author>
            <name>T. Henderson</name>
        </author>
        <author>
            <name>A. Gurtov</name>
        </author>
        <date>
            <month>April</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49603</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>Transmission</kw>
            <kw>Control</kw>
            <kw>Protocol</kw>
        </keywords>
        <abstract>The purpose of this document is to advance NewReno TCP's Fast Retransmit and Fast Recovery algorithms in RFC 2582 from Experimental to Standards Track status. The main change in this document relative to RFC 2582 is to specify the Careful variant of NewReno's Fast Retransmit and Fast Recovery algorithms. The base algorithm described in RFC 2582 did not attempt to avoid unnecessary multiple Fast Retransmits that can occur after a timeout. However, RFC 2582 also defined "Careful" and "Less Careful" variants that avoid these unnecessary Fast Retransmits, and recommended the Careful variant. This document specifies the previously-named "Careful" variant as the basic version of NewReno TCP. [STANDARDS TRACK]</abstract>
        <draft>ietf-tsvwg-newreno-02</draft>
        <obsoletes>
            <doc-id>RFC2582</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3783</doc-id>
        <title>Small Computer Systems Interface (SCSI) Command Ordering Considerations with iSCSI</title>
        <author>
            <name>M. Chadalapaka</name>
        </author>
        <author>
            <name>R. Elliott</name>
        </author>
        <date>
            <month>May</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32358</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>Internet Small Computer Systems Interface</kw>
            <kw>iscsi</kw>
        </keywords>
        <abstract>Internet Small Computer Systems Interface (iSCSI) is a Small Computer Systems Interface (SCSI) transport protocol designed to run on top of TCP. The iSCSI session abstraction is equivalent to the classic SCSI "I_T nexus", which represents the logical relationship between an Initiator and a Target (I and T) required in order to communicate via the SCSI family of protocols. The iSCSI session provides an ordered command delivery from the SCSI initiator to the SCSI target. This document goes into the design considerations that led to the iSCSI session model as it is defined today, relates the SCSI command ordering features defined in T10 specifications to the iSCSI concepts, and finally provides guidance to system designers on how true command ordering solutions can be built based on iSCSI. This memo provides information for the Internet community.</abstract>
        <draft>ietf-ips-command-ordering-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3784</doc-id>
        <title>Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)</title>
        <author>
            <name>H. Smit</name>
        </author>
        <author>
            <name>T. Li</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27422</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>link state protocol</kw>
            <kw>lsp</kw>
        </keywords>
        <abstract>This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations. This memo provides information for the Internet community.</abstract>
        <draft>ietf-isis-traffic-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3785</doc-id>
        <title>Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric</title>
        <author>
            <name>F. Le Faucheur</name>
        </author>
        <author>
            <name>R. Uppili</name>
        </author>
        <author>
            <name>A. Vedrenne</name>
        </author>
        <author>
            <name>P. Merckx</name>
        </author>
        <author>
            <name>T. Telkamp</name>
        </author>
        <date>
            <month>May</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17475</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>link</kw>
            <kw>bandwidth router</kw>
        </keywords>
        <abstract>This document describes a common practice on how the existing metric of Interior Gateway Protocols (IGP) can be used as an alternative metric to the Traffic Engineering (TE) metric for Constraint Based Routing of MultiProtocol Label Switching (MPLS) Traffic Engineering tunnels. This effectively results in the ability to perform Constraint Based Routing with optimization of one metric (e.g., link bandwidth) for some Traffic Engineering tunnels (e.g., Data Trunks) while optimizing another metric (e.g., propagation delay) for some other tunnels with different requirements (e.g., Voice Trunks). No protocol extensions or modifications are required. This text documents current router implementations and deployment practices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>ietf-tewg-te-metric-igp-02</draft>
        <is-also>
            <doc-id>BCP0087</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3786</doc-id>
        <title>Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit</title>
        <author>
            <name>A. Hermelin</name>
        </author>
        <author>
            <name>S. Previdi</name>
        </author>
        <author>
            <name>M. Shand</name>
        </author>
        <date>
            <month>May</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>29164</char-count>
            <page-count>14</page-count>
        </format>
        <abstract>This document describes a mechanism that allows a system to originate more than 256 Link State PDU (LSP) fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO/IEC 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. This memo provides information for the Internet community.</abstract>
        <draft>ietf-isis-ext-lsp-frags-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3787</doc-id>
        <title>Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS)</title>
        <author>
            <name>J. Parker</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25426</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>routing traffic</kw>
        </keywords>
        <abstract>This document discusses a number of differences between the Intermediate System to Intermediate System (IS-IS) protocol used to route IP traffic as described in RFC 1195 and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol to route IP traffic. A companion document describes the differences between the protocol described in ISO 10589 and current practice. This memo provides information for the Internet community.</abstract>
        <draft>ietf-isis-ip-interoperable-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3788</doc-id>
        <title>Security Considerations for Signaling Transport (SIGTRAN) Protocols</title>
        <author>
            <name>J. Loughney</name>
        </author>
        <author>
            <name>M. Tuexen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Pastor-Balbas</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27125</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document discusses how Transport Layer Security (TLS) and IPsec can be used to secure communication for SIGTRAN protocols. The main goal is to recommend the minimum security means that a SIGTRAN node must implement in order to attain secured communication. The support of IPsec is mandatory for all nodes running SIGTRAN protocols. TLS support is optional. [STANDARDS TRACK]</abstract>
        <draft>ietf-sigtran-security-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3789</doc-id>
        <title>Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents</title>
        <author>
            <name>P. Nesser</name>
        </author>
        <author>
            <name>II</name>
        </author>
        <author>
            <name>A. Bergstrom</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22842</char-count>
            <page-count>10</page-count>
        </format>
        <abstract>This document is a general overview and introduction to the v6ops IETF workgroup project of documenting all usage of IPv4 addresses in IETF standards track and experimental RFCs. It is broken into seven documents conforming to the current IETF areas. It also describes the methodology used during documentation, which types of RFCs have been documented, and provides a concatenated summary of results. This memo provides information for the Internet community.</abstract>
        <draft>ietf-v6ops-ipv4survey-intro-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3790</doc-id>
        <title>Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents</title>
        <author>
            <name>C. Mickles</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Nesser</name>
        </author>
        <author>
            <name>II</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>102694</char-count>
            <page-count>49</page-count>
        </format>
        <abstract>This document seeks to document all usage of IPv4 addresses in currently deployed IETF Internet Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.</abstract>
        <draft>ietf-v6ops-ipv4survey-int-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3791</doc-id>
        <title>Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents</title>
        <author>
            <name>C. Olvera</name>
        </author>
        <author>
            <name>P. Nesser</name>
        </author>
        <author>
            <name>II</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27567</char-count>
            <page-count>15</page-count>
        </format>
        <abstract>This investigation work seeks to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.</abstract>
        <draft>ietf-v6ops-ipv4survey-routing-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3792</doc-id>
        <title>Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents</title>
        <author>
            <name>P. Nesser</name>
        </author>
        <author>
            <name>II</name>
        </author>
        <author>
            <name>A. Bergstrom</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46398</char-count>
            <page-count>25</page-count>
        </format>
        <abstract>This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.</abstract>
        <draft>ietf-v6ops-ipv4survey-sec-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3793</doc-id>
        <title>Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents</title>
        <author>
            <name>P. Nesser</name>
        </author>
        <author>
            <name>II</name>
        </author>
        <author>
            <name>A. Bergstrom</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11624</char-count>
            <page-count>6</page-count>
        </format>
        <abstract>This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.</abstract>
        <draft>ietf-v6ops-ipv4survey-subip-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3794</doc-id>
        <title>Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents</title>
        <author>
            <name>P. Nesser</name>
        </author>
        <author>
            <name>II</name>
        </author>
        <author>
            <name>A. Bergstrom</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>60001</char-count>
            <page-count>31</page-count>
        </format>
        <abstract>This document seeks to document all usage of IPv4 addresses in currently deployed IETF Transport Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.</abstract>
        <draft>ietf-v6ops-ipv4survey-trans-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3795</doc-id>
        <title>Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents</title>
        <author>
            <name>R. Sofia</name>
        </author>
        <author>
            <name>P. Nesser</name>
        </author>
        <author>
            <name>II</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>92584</char-count>
            <page-count>50</page-count>
        </format>
        <abstract>This document describes IPv4 addressing dependencies in an attempt to clarify the necessary steps in re-designing and re-implementing specifications to become network address independent, or at least, to dually support IPv4 and IPv6. This transition requires several interim steps, one of them being the evolution of current IPv4 dependent specifications to a format independent of the type of IP addressing schema used. Hence, it is hoped that specifications will be re-designed and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6. To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards (Full, Draft, and Proposed) as well as Experimental RFCs. Hence, this document describes IPv4 addressing dependencies that deployed IETF Application Area documented Standards may experience. This memo provides information for the Internet community.</abstract>
        <draft>ietf-v6ops-ipv4survey-apps-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3796</doc-id>
        <title>Survey of IPv4 Addresses in Currently Deployed IETF Operations &amp; Management Area Standards Track and Experimental Documents</title>
        <author>
            <name>P. Nesser</name>
        </author>
        <author>
            <name>II</name>
        </author>
        <author>
            <name>A. Bergstrom</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>78400</char-count>
            <page-count>43</page-count>
        </format>
        <abstract>This document seeks to record all usage of IPv4 addresses in currently deployed IETF Operations &amp; Management Area accepted standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed), as well as Experimental RFCs, will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.</abstract>
        <draft>ietf-v6ops-ipv4survey-ops-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3797</doc-id>
        <title>Publicly Verifiable Nominations Committee (NomCom) Random Selection</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39883</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>Internet Engineering Task Force</kw>
            <kw>IETF</kw>
        </keywords>
        <abstract>This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. As an example, the selection of the voting members of the IETF Nominations Committee (NomCom) from the pool of eligible volunteers is used. Similar techniques would be applicable to other cases. This memo provides information for the Internet community.</abstract>
        <draft>eastlake-rfc2777bis-selection-04</draft>
        <obsoletes>
            <doc-id>RFC2777</doc-id>
        </obsoletes>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3798</doc-id>
        <title>Message Disposition Notification</title>
        <author>
            <name>T. Hansen</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Vaudreuil</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>64049</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>EMF-MDN</kw>
            <kw>MDN</kw>
            <kw>media-type</kw>
            <kw>MIME</kw>
            <kw>multipurpose internet mail extensions</kw>
        </keywords>
        <abstract>This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. [STANDARDS TRACK]</abstract>
        <draft>vaudreuil-mdnbis-05</draft>
        <obsoletes>
            <doc-id>RFC2298</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC3461</doc-id>
            <doc-id>RFC2046</doc-id>
        </updates>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3801</doc-id>
        <title>Voice Profile for Internet Mail - version 2 (VPIMv2)</title>
        <author>
            <name>G. Vaudreuil</name>
        </author>
        <author>
            <name>G. Parsons</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>118122</char-count>
            <page-count>55</page-count>
        </format>
        <keywords>
            <kw>MIME-VP2</kw>
            <kw>vpim</kw>
            <kw>messaging</kw>
        </keywords>
        <abstract>This document specifies a restricted profile of the Internet multimedia messaging protocols for use between voice processing server platforms. The profile is referred to as the Voice Profile for Internet Mail (VPIM) in this document. These platforms have historically been special-purpose computers and often do not have the same facilities normally associated with a traditional Internet Email-capable computer. As a result, VPIM also specifies additional functionality, as it is needed. This profile is intended to specify the minimum common set of features to allow interworking between conforming systems. This document obsoletes RFC 2421 and describes version 2 of the profile with greater precision. No protocol changes were made in this revision. A list of changes from RFC 2421 are noted in Appendix F. Appendix A summarizes the protocol profiles of this version of VPIM. [STANDARDS TRACK]</abstract>
        <draft>ietf-vpim-vpimv2r2-05</draft>
        <obsoletes>
            <doc-id>RFC2421</doc-id>
            <doc-id>RFC2423</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3802</doc-id>
        <title>Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration</title>
        <author>
            <name>G. Vaudreuil</name>
        </author>
        <author>
            <name>G. Parsons</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11686</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>MIME-ADPCM</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>audio</kw>
        </keywords>
        <abstract>This document describes the registration of the MIME sub-type audio/32KADPCM Adaptive Differential Pulse Code Modulation for toll quality audio. This audio encoding is defined by the ITU-T in Recommendation G.726. [STANDARDS TRACK]</abstract>
        <draft>ietf-vpim-vpimv2r2-32k-03</draft>
        <obsoletes>
            <doc-id>RFC2422</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3803</doc-id>
        <title>Content Duration MIME Header Definition</title>
        <author>
            <name>G. Vaudreuil</name>
        </author>
        <author>
            <name>G. Parsons</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8213</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>CONT-DUR</kw>
            <kw>multipurpose internet mail extensions</kw>
            <kw>time</kw>
            <kw>media</kw>
        </keywords>
        <abstract>This document describes the MIME header Content-Duration that is intended for use with any time varying media content (typically audio/* or video/*). [STANDARDS TRACK]</abstract>
        <draft>ietf-vpim-vpimv2r2-dur-03</draft>
        <obsoletes>
            <doc-id>RFC2424</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3804</doc-id>
        <title>Voice Profile for Internet Mail (VPIM) Addressing</title>
        <author>
            <name>G. Parsons</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26122</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>formats</kw>
        </keywords>
        <abstract>This document lists the various Voice Profile for Internet Mail (VPIM) email address formats that are currently in common use and defines several new address formats for special case usage. Requirements are imposed on the formats of addresses used in VPIM submission mode. [STANDARDS TRACK]</abstract>
        <draft>ietf-vpim-address-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3805</doc-id>
        <title>Printer MIB v2</title>
        <author>
            <name>R. Bergman</name>
        </author>
        <author>
            <name>H. Lewis</name>
        </author>
        <author>
            <name>I. McDonald</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>366952</char-count>
            <page-count>171</page-count>
        </format>
        <keywords>
            <kw>Print-MIB</kw>
            <kw>Management Information Base</kw>
            <kw>snmp</kw>
            <kw>management</kw>
        </keywords>
        <abstract>This document provides definitions of models and manageable objects for printing environments. The objects included in this MIB apply to physical, as well as logical entities within a printing device. This document obsoletes RFC 1759. [STANDARDS TRACK]</abstract>
        <draft>ietf-printmib-mib-info-15</draft>
        <obsoletes>
            <doc-id>RFC1759</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3806</doc-id>
        <title>Printer Finishing MIB</title>
        <author>
            <name>R. Bergman</name>
        </author>
        <author>
            <name>H. Lewis</name>
        </author>
        <author>
            <name>I. McDonald</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>109654</char-count>
            <page-count>53</page-count>
        </format>
        <keywords>
            <kw>finisher</kw>
            <kw>snmp</kw>
        </keywords>
        <abstract>This document defines a MIB module for the management of printer finishing device subunits. The finishing device subunits applicable to this MIB are an integral part of the Printer System. This MIB applies only to a Finisher Device that is connected to a Printer System. This memo provides information for the Internet community.</abstract>
        <draft>ietf-printmib-finishing-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3807</doc-id>
        <title>V5.2-User Adaptation Layer (V5UA)</title>
        <author>
            <name>E. Weilandt</name>
        </author>
        <author>
            <name>N. Khanchandani</name>
        </author>
        <author>
            <name>S. Rao</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49748</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>v5</kw>
            <kw>v5.1</kw>
            <kw>v5.2</kw>
            <kw>backhauling</kw>
            <kw>imap</kw>
            <kw>sctp</kw>
            <kw>isdn</kw>
            <kw>access network</kw>
            <kw>c-path</kw>
            <kw>c-channel</kw>
            <kw>efa</kw>
            <kw>envelope function address</kw>
            <kw>lapv5</kw>
            <kw>pstn</kw>
            <kw>v5ptm</kw>
            <kw>mgc</kw>
            <kw>gateway controller</kw>
            <kw>gateway</kw>
        </keywords>
        <abstract>This document defines a mechanism for the backhauling of V5.2 messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol may be used between a Signaling Gateway (SG) and a Media Gateway controller (MGC). It is assumed that the SG receives V5.2 signaling over a standard V5.2 interface. This document builds on the ISDN User Adaptation Layer Protocol (RFC 3057). It defines all necessary extensions to the IUA Protocol needed for the V5UA protocol implementation. [STANDARDS TRACK]</abstract>
        <draft>ietf-sigtran-v5ua-04</draft>
        <updates>
            <doc-id>RFC3057</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3808</doc-id>
        <title>IANA Charset MIB</title>
        <author>
            <name>I. McDonald</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25245</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>management information base</kw>
            <kw>IANACharset</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This IANA Charset MIB is now an IANA registry. In particular, a single textual convention 'IANACharset' is defined that may be used to specify charset labels in MIB objects. 'IANACharset' was extracted from Printer MIB v2 (RFC 3805). 'IANACharset' was originally defined (and mis-named) as 'CodedCharSet' in Printer MIB v1 (RFC 1759). A tool has been written in C, that may be used by IANA to regenerate this IANA Charset MIB, when future charsets are registered in accordance with the IANA Charset Registration Procedures (RFC 2978). This memo provides information for the Internet community.</abstract>
        <draft>mcdonald-iana-charset-mib-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3809</doc-id>
        <title>Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)</title>
        <author>
            <name>A. Nagarajan</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>60576</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>service engineering</kw>
        </keywords>
        <abstract>This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies. All PPVPN technologies are expected to meet the umbrella set of requirements described in this document. This memo provides information for the Internet community.</abstract>
        <draft>ietf-l3vpn-generic-reqts-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3810</doc-id>
        <title>Multicast Listener Discovery Version 2 (MLDv2) for IPv6</title>
        <author>
            <name>R. Vida</name>
            <title>Editor</title>
        </author>
        <author>
            <name>L. Costa</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>153579</char-count>
            <page-count>62</page-count>
        </format>
        <keywords>
            <kw>ssm</kw>
            <kw>source filtering</kw>
            <kw>igmp</kw>
            <kw>group management</kw>
            <kw>mld</kw>
        </keywords>
        <abstract>This document updates RFC 2710, and it specifies Version 2 of the ulticast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. [STANDARDS TRACK]</abstract>
        <draft>vida-mld-v2-08</draft>
        <updates>
            <doc-id>RFC2710</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3811</doc-id>
        <title>Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management</title>
        <author>
            <name>T. Nadeau</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Cucchiara</name>
            <title>Editor</title>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40353</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>management information base</kw>
        </keywords>
        <abstract>This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Multiprotocol Label Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations. [STANDARDS TRACK]</abstract>
        <draft>ietf-mpls-tc-mib-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3812</doc-id>
        <title>Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)</title>
        <author>
            <name>C. Srinivasan</name>
        </author>
        <author>
            <name>A. Viswanathan</name>
        </author>
        <author>
            <name>T. Nadeau</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>136475</char-count>
            <page-count>68</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). [STANDARDS TRACK]</abstract>
        <draft>ietf-mpls-te-mib-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3813</doc-id>
        <title>Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)</title>
        <author>
            <name>C. Srinivasan</name>
        </author>
        <author>
            <name>A. Viswanathan</name>
        </author>
        <author>
            <name>T. Nadeau</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>116120</char-count>
            <page-count>60</page-count>
        </format>
        <abstract>This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Multiprotocol Label Switching (MPLS) Label Switching Router (LSR). [STANDARDS TRACK]</abstract>
        <draft>ietf-mpls-lsr-mib-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3814</doc-id>
        <title>Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB)</title>
        <author>
            <name>T. Nadeau</name>
        </author>
        <author>
            <name>C. Srinivasan</name>
        </author>
        <author>
            <name>A. Viswanathan</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>87518</char-count>
            <page-count>42</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for defining, configuring, and monitoring Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS). [STANDARDS TRACK]</abstract>
        <draft>ietf-mpls-ftn-mib-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3815</doc-id>
        <title>Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)</title>
        <author>
            <name>J. Cucchiara</name>
        </author>
        <author>
            <name>H. Sjostrand</name>
        </author>
        <author>
            <name>J. Luciani</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>215916</char-count>
            <page-count>106</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP). [STANDARDS TRACK]</abstract>
        <draft>ietf-mpls-ldp-mib-14</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3816</doc-id>
        <title>Definitions of Managed Objects for RObust Header Compression (ROHC)</title>
        <author>
            <name>J. Quittek</name>
        </author>
        <author>
            <name>M. Stiemerling</name>
        </author>
        <author>
            <name>H. Hartenstein</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>104947</char-count>
            <page-count>53</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow monitoring of running instances of RObust Header Compression (ROHC). The managed objects defined in this memo are grouped into three MIB modules. The ROHC-MIB module defines managed objects shared by all ROHC profiles, the ROHC-UNCOMPRESSED-MIB module defines managed objects specific to the ROHC uncompressed profile, the ROHC-RTP-MIB module defines managed objects specific to the ROHC RTP (Real-Time Transport Protocol) profile, the ROHC UDP (User Datagram Protocol) profile, the ROHC ESP (Encapsulating Security Payload) profile, and the ROHC LLA (Link Layer Assisted) profile. [STANDARDS TRACK]</abstract>
        <draft>ietf-rohc-mib-rtp-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3817</doc-id>
        <title>Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE)</title>
        <author>
            <name>W. Townsley</name>
        </author>
        <author>
            <name>R. da Silva</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37765</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>point-to-point</kw>
        </keywords>
        <abstract>The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. Layer Two Tunneling Protocol (L2TP), facilitates the tunneling of PPP packets across an intervening packet-switched network. And yet a third protocol, PPP over Ethernet (PPPoE) describes how to build PPP sessions and to encapsulate PPP packets over Ethernet. L2TP Active Discovery Relay for PPPoE describes a method to relay Active Discovery and Service Selection functionality from PPPoE over the reliable control channel within L2TP. Two new L2TP control message types and associated PPPoE-specific Attribute Value Pairs (AVPs) for L2TP are defined. This relay mechanism provides enhanced integration of a specific feature in the PPPoE tunneling protocol with L2TP. This memo provides information for the Internet community.</abstract>
        <draft>dasilva-l2tp-relaysvc-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3818</doc-id>
        <title>IANA Considerations for the Point-to-Point Protocol (PPP)</title>
        <author>
            <name>V. Schryver</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6321</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>The charter of the Point-to-Point Protocol (PPP) Extensions working group (pppext) includes the responsibility to "actively advance PPP's most useful extensions to full standard, while defending against further enhancements of questionable value." In support of that charter, the allocation of PPP protocol and other assigned numbers will no longer be "first come first served." This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>schryver-pppext-iana-01</draft>
        <is-also>
            <doc-id>BCP0088</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3819</doc-id>
        <title>Advice for Internet Subnetwork Designers</title>
        <author>
            <name>P. Karn</name>
            <title>Editor</title>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>G. Fairhurst</name>
        </author>
        <author>
            <name>D. Grossman</name>
        </author>
        <author>
            <name>R. Ludwig</name>
        </author>
        <author>
            <name>J. Mahdavi</name>
        </author>
        <author>
            <name>G. Montenegro</name>
        </author>
        <author>
            <name>J. Touch</name>
        </author>
        <author>
            <name>L. Wood</name>
        </author>
        <date>
            <month>July</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>152174</char-count>
            <page-count>60</page-count>
        </format>
        <keywords>
            <kw>digital communication equipment</kw>
            <kw>link-layer protocols</kw>
            <kw>packet-switched local networks</kw>
        </keywords>
        <abstract>This document provides advice to the designers of digital communication equipment, link-layer protocols, and packet-switched local networks (collectively referred to as subnetworks), who wish to support the Internet protocols but may be unfamiliar with the Internet architecture and the implications of their design choices on the performance and efficiency of the Internet. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>ietf-pilc-link-design-15</draft>
        <is-also>
            <doc-id>BCP0089</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3820</doc-id>
        <title>Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile</title>
        <author>
            <name>S. Tuecke</name>
        </author>
        <author>
            <name>V. Welch</name>
        </author>
        <author>
            <name>D. Engert</name>
        </author>
        <author>
            <name>L. Pearlman</name>
        </author>
        <author>
            <name>M. Thompson</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>86374</char-count>
            <page-count>37</page-count>
        </format>
        <keywords>
            <kw>authentication</kw>
            <kw>security credentials</kw>
            <kw>restricted delegation</kw>
            <kw>single-signon</kw>
            <kw>delegation of rights</kw>
        </keywords>
        <abstract>This document forms a certificate profile for Proxy Certificates, based on X.509 Public Key Infrastructure (PKI) certificates as defined in RFC 3280, for use in the Internet. The term Proxy Certificate is used to describe a certificate that is derived from, and signed by, a normal X.509 Public Key End Entity Certificate or by another Proxy Certificate for the purpose of providing restricted proxying and delegation within a PKI based authentication system. [STANDARDS TRACK]</abstract>
        <draft>ietf-pkix-proxy-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3821</doc-id>
        <title>Fibre Channel Over TCP/IP (FCIP)</title>
        <author>
            <name>M. Rajagopal</name>
        </author>
        <author>
            <name>E. Rodriguez</name>
        </author>
        <author>
            <name>R. Weber</name>
        </author>
        <date>
            <month>July</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>165907</char-count>
            <page-count>74</page-count>
        </format>
        <keywords>
            <kw>storage area networks</kw>
            <kw>IP-based networks</kw>
            <kw>unified storage area network</kw>
        </keywords>
        <abstract>Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks. [STANDARDS TRACK]</abstract>
        <draft>ietf-ips-fcovertcpip-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3822</doc-id>
        <title>Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)</title>
        <author>
            <name>D. Peterson</name>
        </author>
        <date>
            <month>July</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22859</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>dynamic discovery</kw>
        </keywords>
        <abstract>This document defines the use of Service Location Protocol version 2 (SLPv2) by Fibre Channel over TCP/IP (FCIP) Entities. [STANDARDS TRACK]</abstract>
        <draft>ietf-ips-fcip-slp-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3823</doc-id>
        <title>MIME Media Type for the Systems Biology Markup Language (SBML)</title>
        <author>
            <name>B. Kovitz</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14577</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>sub-type application/sbml+xml</kw>
            <kw>systems biology community</kw>
        </keywords>
        <abstract>This document registers the MIME sub-type application/sbml+xml, a media type for SBML, the Systems Biology Markup Language. SBML is defined by The SBML Team at the California Institute of Technology and interested members of the systems biology community. This memo provides information for the Internet community.</abstract>
        <draft>sbml-media-type-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3824</doc-id>
        <title>Using E.164 numbers with the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <author>
            <name>H. Liu</name>
        </author>
        <author>
            <name>J. Yu</name>
        </author>
        <author>
            <name>B. Campbell</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36535</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>telephone records</kw>
            <kw>applications</kw>
        </keywords>
        <abstract>There are a number of contexts in which telephone numbers are employed by Session Initiation Protocol (SIP) applications, many of which can be addressed by ENUM. Although SIP was one of the primary applications for which ENUM was created, there is nevertheless a need to define procedures for integrating ENUM with SIP implementations. This document illustrates how the two protocols might work in concert, and clarifies the authoring and processing of ENUM records for SIP applications. It also provides guidelines for instances in which ENUM, for whatever reason, cannot be used to resolve a telephone number. This memo provides information for the Internet community.</abstract>
        <draft>ietf-sipping-e164-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3825</doc-id>
        <title>Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information</title>
        <author>
            <name>J. Polk</name>
        </author>
        <author>
            <name>J. Schnizlein</name>
        </author>
        <author>
            <name>M. Linsner</name>
        </author>
        <date>
            <month>July</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31715</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>dhcp</kw>
            <kw>lci</kw>
            <kw>geographic location</kw>
        </keywords>
        <abstract>This document specifies a Dynamic Host Configuration Protocol Option for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes latitude, longitude, and altitude, with resolution indicators for each. The reference datum for these values is also included. [STANDARDS TRACK]</abstract>
        <draft>ietf-geopriv-dhcp-lci-option-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3826</doc-id>
        <title>The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model</title>
        <author>
            <name>U. Blumenthal</name>
        </author>
        <author>
            <name>F. Maino</name>
        </author>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32821</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>management information base</kw>
            <kw>simple network management protocol</kw>
        </keywords>
        <abstract>This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits. [STANDARDS TRACK]</abstract>
        <draft>blumenthal-aes-usm-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3827</doc-id>
        <title>Additional Snoop Datalink Types</title>
        <author>
            <name>K. Sarcar</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6344</char-count>
            <page-count>4</page-count>
        </format>
        <abstract>The snoop file format provides a way to store and exchange datalink layer packet traces. This document describes extensions to this file format to support new media. This memo provides information for the Internet community.</abstract>
        <draft>sarcar-snoop-new-types-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3828</doc-id>
        <title>The Lightweight User Datagram Protocol (UDP-Lite)</title>
        <author>
            <name>L-A. Larzon</name>
        </author>
        <author>
            <name>M. Degermark</name>
        </author>
        <author>
            <name>S. Pink</name>
        </author>
        <author>
            <name>L-E. Jonsson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Fairhurst</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27193</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document describes the Lightweight User Datagram Protocol (UDP-Lite), which is similar to the User Datagram Protocol (UDP) (RFC 768), but can also serve applications in error-prone network environments that prefer to have partially damaged payloads delivered rather than discarded. If this feature is not used, UDP-Lite is semantically identical to UDP. [STANDARDS TRACK]</abstract>
        <draft>ietf-tsvwg-udp-lite-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3829</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls</title>
        <author>
            <name>R. Weltman</name>
        </author>
        <author>
            <name>M. Smith</name>
        </author>
        <author>
            <name>M. Wahl</name>
        </author>
        <date>
            <month>July</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11986</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>bind operation</kw>
        </keywords>
        <abstract>This document extends the Lightweight Directory Access Protocol (LDAP) bind operation with a mechanism for requesting and returning the authorization identity it establishes. Specifically, this document defines the Authorization Identity Request and Response controls for use with the Bind operation. This memo provides information for the Internet community.</abstract>
        <draft>weltman-ldapv3-auth-response-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3830</doc-id>
        <title>MIKEY: Multimedia Internet KEYing</title>
        <author>
            <name>J. Arkko</name>
        </author>
        <author>
            <name>E. Carrara</name>
        </author>
        <author>
            <name>F. Lindholm</name>
        </author>
        <author>
            <name>M. Naslund</name>
        </author>
        <author>
            <name>K. Norrman</name>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>145238</char-count>
            <page-count>66</page-count>
        </format>
        <keywords>
            <kw>key management scheme</kw>
            <kw>real-time applications</kw>
        </keywords>
        <abstract>This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication). In particular, its use to support the Secure Real-time Transport Protocol is described in detail. Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols. [STANDARDS TRACK]</abstract>
        <draft>ietf-msec-mikey-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3831</doc-id>
        <title>Transmission of IPv6 Packets over Fibre Channel</title>
        <author>
            <name>C. DeSanti</name>
        </author>
        <date>
            <month>July</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53328</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>addresses</kw>
            <kw>link-local</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract>This document specifies the way of encapsulating IPv6 packets over Fibre Channel, and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Fibre Channel networks. [STANDARDS TRACK]</abstract>
        <draft>ietf-imss-ipv6-over-fibre-channel-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3832</doc-id>
        <title>Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV</title>
        <author>
            <name>W. Zhao</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>E. Guttman</name>
        </author>
        <author>
            <name>C. Bisdikian</name>
        </author>
        <author>
            <name>W. Jerome</name>
        </author>
        <date>
            <month>July</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15602</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>DNS-SRV</kw>
            <kw>domain</kw>
            <kw>name</kw>
            <kw>system</kw>
            <kw>resource</kw>
            <kw>record</kw>
        </keywords>
        <abstract>Remote service discovery refers to discovering desired services in given remote (i.e., non-local) DNS domains. This document describes remote service discovery in the Service Location Protocol (SLP) via DNS SRV. It defines the DNS SRV Resource Records for SLP Directory Agent services, discusses various issues in using SLP and DNS SRV together for remote service discovery, and gives the steps for discovering desired services in remote DNS domains. This memo defines an Experimental Protocol for the Internet community.</abstract>
        <draft>zhao-slp-remote-da-discovery-06</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3833</doc-id>
        <title>Threat Analysis of the Domain Name System (DNS)</title>
        <author>
            <name>D. Atkins</name>
        </author>
        <author>
            <name>R. Austein</name>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39303</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>data disclosure</kw>
            <kw>security</kw>
            <kw>authentication</kw>
        </keywords>
        <abstract>Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. This memo provides information for the Internet community.</abstract>
        <draft>ietf-dnsext-dns-threats-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3834</doc-id>
        <title>Recommendations for Automatic Responses to Electronic Mail</title>
        <author>
            <name>K. Moore</name>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53119</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>automatic mail responders</kw>
        </keywords>
        <abstract>This memo makes recommendations for software that automatically responds to incoming electronic mail messages, including "out of the office" or "vacation" response generators, mail filtering software, email-based information services, and other automatic responders. The purpose of these recommendations is to discourage undesirable behavior which is caused or aggravated by such software, to encourage uniform behavior (where appropriate) among automatic mail responders, and to clear up some sources of confusion among implementors of automatic email responders. [STANDARDS TRACK]</abstract>
        <draft>moore-auto-email-response-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3835</doc-id>
        <title>An Architecture for Open Pluggable Edge Services (OPES)</title>
        <author>
            <name>A. Barbir</name>
        </author>
        <author>
            <name>R. Penno</name>
        </author>
        <author>
            <name>R. Chen</name>
        </author>
        <author>
            <name>M. Hofmann</name>
        </author>
        <author>
            <name>H. Orman</name>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36113</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>application service</kw>
            <kw>data stream service</kw>
            <kw>data consumer</kw>
            <kw>data dispatcher architecture</kw>
        </keywords>
        <abstract>This memo defines an architecture that enables the creation of an application service in which a data provider, a data consumer, and zero or more application entities cooperatively implement a data stream service. This memo provides information for the Internet community.</abstract>
        <draft>ietf-opes-architecture-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3836</doc-id>
        <title>Requirements for Open Pluggable Edge Services (OPES) Callout Protocols</title>
        <author>
            <name>A. Beck</name>
        </author>
        <author>
            <name>M. Hofmann</name>
        </author>
        <author>
            <name>H. Orman</name>
        </author>
        <author>
            <name>R. Penno</name>
        </author>
        <author>
            <name>A. Terzis</name>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28438</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>callout protocol</kw>
            <kw>remote execution</kw>
            <kw>OPES services</kw>
        </keywords>
        <abstract>This document specifies the requirements that the OPES (Open Pluggable Edge Services) callout protocol must satisfy in order to support the remote execution of OPES services. The requirements are intended to help evaluate possible protocol candidates, as well as to guide the development of such protocols. This memo provides information for the Internet community.</abstract>
        <draft>ietf-opes-protocol-reqs-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3837</doc-id>
        <title>Security Threats and Risks for Open Pluggable Edge Services (OPES)</title>
        <author>
            <name>A. Barbir</name>
        </author>
        <author>
            <name>O. Batuner</name>
        </author>
        <author>
            <name>B. Srinivas</name>
        </author>
        <author>
            <name>M. Hofmann</name>
        </author>
        <author>
            <name>H. Orman</name>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31883</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>threat discovery</kw>
            <kw>threat analysis</kw>
        </keywords>
        <abstract>The document investigates the security threats associated with the Open Pluggable Edge Services (OPES) and discusses the effects of security threats on the underlying architecture. The main goal of this document is threat discovery and analysis. The document does not specify or recommend any solutions. This memo provides information for the Internet community.</abstract>
        <draft>ietf-opes-threats-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3838</doc-id>
        <title>Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES)</title>
        <author>
            <name>A. Barbir</name>
        </author>
        <author>
            <name>O. Batuner</name>
        </author>
        <author>
            <name>A. Beck</name>
        </author>
        <author>
            <name>T. Chan</name>
        </author>
        <author>
            <name>H. Orman</name>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38739</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>opes flow</kw>
        </keywords>
        <abstract>This document describes policy, authorization, and enforcement requirements for the selection of the services to be applied to a given Open Pluggable Edge Services (OPES) flow. This memo provides information for the Internet community.</abstract>
        <draft>ietf-opes-authorization-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3839</doc-id>
        <title>MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files</title>
        <author>
            <name>R. Castagno</name>
        </author>
        <author>
            <name>D. Singer</name>
        </author>
        <date>
            <month>July</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15645</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>standard MIME types</kw>
            <kw>3GPP multimedia file format</kw>
            <kw>ISO Media File Format</kw>
        </keywords>
        <abstract>This document serves to register and document the standard MIME types associated with the 3GPP multimedia file format, which is part of the family based on the ISO Media File Format. [STANDARDS TRACK]</abstract>
        <draft>singer-avt-3gpp-mime-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3840</doc-id>
        <title>Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>P. Kyzivat</name>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>81360</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>ua</kw>
            <kw>contact header field</kw>
        </keywords>
        <abstract>This specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field. [STANDARDS TRACK]</abstract>
        <draft>ietf-sip-callee-caps-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3841</doc-id>
        <title>Caller Preferences for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <author>
            <name>P. Kyzivat</name>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>61382</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
            <kw>Uniform Resource Identifiers</kw>
            <kw>URI</kw>
            <kw>Accept-Contact</kw>
            <kw>Reject-Contact</kw>
            <kw>Request-Disposition</kw>
        </keywords>
        <abstract>This document describes a set of extensions to the Session Initiation Protocol (SIP) which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which Uniform Resource Identifiers (URI) a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining three new request header fields, Accept-Contact, Reject-Contact, and Request-Disposition, which specify the caller's preferences. [STANDARDS TRACK]</abstract>
        <draft>ietf-sip-callerprefs-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3842</doc-id>
        <title>A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>R. Mahy</name>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36877</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>message waiting status</kw>
            <kw>message summary</kw>
        </keywords>
        <abstract>This document describes a Session Initiation Protocol (SIP) event package to carry message waiting status and message summaries from a messaging system to an interested User Agent. [STANDARDS TRACK]</abstract>
        <draft>ietf-sipping-mwi-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3843</doc-id>
        <title>RObust Header Compression (ROHC): A Compression Profile for IP</title>
        <author>
            <name>L-E. Jonsson</name>
        </author>
        <author>
            <name>G. Pelletier</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33549</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>compression protocols</kw>
        </keywords>
        <abstract>The original RObust Header Compression (ROHC) RFC (RFC 3095) defines a framework for header compression, along with compression protocols (profiles) for IP/UDP/RTP, IP/ESP (Encapsulating Security Payload), IP/UDP, and also a profile for uncompressed packet streams. However, no profile was defined for compression of IP only, which has been identified as a missing piece in RFC 3095. This document defines a ROHC compression profile for IP, similar to the IP/UDP profile defined by RFC 3095, but simplified to exclude UDP, and enhanced to compress IP header chains of arbitrary length. [STANDARDS TRACK]</abstract>
        <draft>ietf-rohc-ip-only-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3844</doc-id>
        <title>IETF Problem Resolution Process</title>
        <author>
            <name>E. Davies</name>
        </author>
        <author>
            <name>J. Hofmann</name>
            <title>Editors</title>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>44841</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>ietf</kw>
            <kw>process</kw>
            <kw>problem</kw>
            <kw>analysis</kw>
        </keywords>
        <abstract>This Informational document records the history of discussions in the Problem WG during 2003 of how to resolve the problems described in the IETF Problem Statement. It decomposes each of the problems described into a few areas for improvement and categorizes them as either problems affecting the routine processes used to create standards or problems affecting the fundamental structure and practices of the IETF. Expeditious and non-disruptive solutions are proposed for the problems affecting routine processes. The document also lists suggested ways to handle the development of solutions for the structure and practices problems proposed in IETF discussions. Neither the working group nor the wider IETF has reached consensus on a recommendation for any of the proposals. This document therefore has no alternative but to suggest that the search for structure and practices solutions be handed back to the control of the IESG. While there was working group consensus on the processes for short-term and medium term improvements, there was no working group consensus on the proposals for longer-term improvements. This document therefore includes longer-term improvement proposals only as a matter of record; they must not be regarded as recommendations from the working group. This memo provides information for the Internet community.</abstract>
        <draft>ietf-problem-process-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3845</doc-id>
        <title>DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format</title>
        <author>
            <name>J. Schlyter</name>
            <title>Editor</title>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14793</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>dnssec</kw>
            <kw>DNS Security</kw>
            <kw>rr</kw>
            <kw>resource record</kw>
            <kw>DNS-SECEXT</kw>
            <kw>dns</kw>
            <kw>authentication</kw>
            <kw>nsec</kw>
            <kw>nextsecure</kw>
        </keywords>
        <abstract>This document redefines the wire format of the "Type Bit Map" field in the DNS NextSECure (NSEC) resource record RDATA format to cover the full resource record (RR) type space. [STANDARDS TRACK]</abstract>
        <draft>ietf-dnsext-nsec-rdata-06</draft>
        <obsoleted-by>
            <doc-id>RFC4033</doc-id>
            <doc-id>RFC4034</doc-id>
            <doc-id>RFC4035</doc-id>
        </obsoleted-by>
        <updates>
            <doc-id>RFC3755</doc-id>
            <doc-id>RFC2535</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3846</doc-id>
        <title>Mobile IPv4 Extension for Carrying Network Access Identifiers</title>
        <author>
            <name>F. Johansson</name>
        </author>
        <author>
            <name>T. Johansson</name>
        </author>
        <date>
            <month>June</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16834</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>nai</kw>
            <kw>internet protocol</kw>
            <kw>home aaa server</kw>
            <kw>ha server</kw>
            <kw>home agents</kw>
        </keywords>
        <abstract>When a mobile node moves between two foreign networks, it has to be re-authenticated. If the home network has both multiple Authentication Authorization and Accounting (AAA) servers and Home Agents (HAs) in use, the Home AAA server may not have sufficient information to process the re-authentication correctly (i.e., to ensure that the same HA continues to be used). This document defines a Mobile IP extension that carries identities for the Home AAA and HA servers in the form of Network Access Identifiers (NAIs). The extension allows a Home Agent to pass its identity (and that of the Home AAA server) to the mobile node, which can then pass it on to the local AAA server when changing its point of attachment. This extension may also be used in other situations requiring communication of a NAI between Mobile IP nodes. [STANDARDS TRACK]</abstract>
        <draft>ietf-mip4-aaa-nai-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3847</doc-id>
        <title>Restart Signaling for Intermediate System to Intermediate System (IS-IS)</title>
        <author>
            <name>M. Shand</name>
        </author>
        <author>
            <name>L. Ginsberg</name>
        </author>
        <date>
            <month>July</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>50023</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>LSP database synchronization</kw>
            <kw>transient routing disruption</kw>
            <kw>database synchronization</kw>
        </keywords>
        <abstract>This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. This document additionally describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. This memo provides information for the Internet community.</abstract>
        <draft>ietf-isis-restart-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3848</doc-id>
        <title>ESMTP and LMTP Transmission Types Registration</title>
        <author>
            <name>C. Newman</name>
        </author>
        <date>
            <month>July</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7916</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>smtp</kw>
            <kw>simple mail transfer protocol </kw>
        </keywords>
        <abstract>This registers seven new mail transmission types (ESMTPA, ESMTPS, ESMTPSA, LMTP, LMTPA, LMTPS, LMTPSA) for use in the "with" clause of a Received header in an Internet message. [STANDARDS TRACK]</abstract>
        <draft>newman-esmtpsa-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3849</doc-id>
        <title>IPv6 Address Prefix Reserved for Documentation</title>
        <author>
            <name>G. Huston</name>
        </author>
        <author>
            <name>A. Lord</name>
        </author>
        <author>
            <name>P. Smith</name>
        </author>
        <date>
            <month>July</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7872</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>unicast</kw>
            <kw>site-local</kw>
            <kw>link-local</kw>
        </keywords>
        <abstract>To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 unicast address prefix is reserved for use in examples in RFCs, books, documentation, and the like. Since site-local and link-local unicast addresses have special meaning in IPv6, these addresses cannot be used in many example situations. The document describes the use of the IPv6 address prefix 2001:DB8::/32 as a reserved prefix for use in documentation. This memo provides information for the Internet community.</abstract>
        <draft>huston-ipv6-documentation-prefix-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3850</doc-id>
        <title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling</title>
        <author>
            <name>B. Ramsdell</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37446</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>x.509</kw>
            <kw>encryption</kw>
            <kw>certificate</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>secure</kw>
        </keywords>
        <abstract>This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 3280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 3280. [STANDARDS TRACK]</abstract>
        <draft>ietf-smime-rfc2632bis-07</draft>
        <obsoletes>
            <doc-id>RFC2632</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3851</doc-id>
        <title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification</title>
        <author>
            <name>B. Ramsdell</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53328</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
            <kw>secure</kw>
            <kw>multipurpose</kw>
            <kw>internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
            <kw>encryption</kw>
        </keywords>
        <abstract>This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 2633. [STANDARDS TRACK]</abstract>
        <draft>ietf-smime-rfc2633bis-09</draft>
        <obsoletes>
            <doc-id>RFC2633</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3852</doc-id>
        <title>Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>July</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15541</char-count>
            <page-count>56</page-count>
        </format>
        <keywords>
            <kw>digitally sign</kw>
            <kw>authenticate</kw>
            <kw>encrypt</kw>
            <kw>arbitrary message content</kw>
        </keywords>
        <abstract>This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS TRACK]</abstract>
        <draft>ietf-smime-rfc3369bis-04</draft>
        <obsoletes>
            <doc-id>RFC3369</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3853</doc-id>
        <title>S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>July</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10687</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>SIP</kw>
            <kw>application-layer</kw>
            <kw>application</kw>
            <kw>layer</kw>
            <kw>multimedia</kw>
            <kw>multicast</kw>
            <kw>unicast</kw>
        </keywords>
        <abstract>RFC 3261 currently specifies 3DES as the mandatory-to-implement ciphersuite for implementations of S/MIME in the Session Initiation Protocol (SIP). This document updates the normative guidance of RFC 3261 to require the Advanced Encryption Standard (AES) for S/MIME. [STANDARDS TRACK]</abstract>
        <draft>ietf-sip-smime-aes-01</draft>
        <updates>
            <doc-id>RFC3261</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3854</doc-id>
        <title>Securing X.400 Content with Secure/Multipurpose Internet Mail Extensions (S/MIME)</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>C. Bonatti</name>
        </author>
        <author>
            <name>A. Eggen</name>
        </author>
        <date>
            <month>July</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32801</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>encryption</kw>
            <kw>cryptographic signature</kw>
        </keywords>
        <abstract>This document describes a protocol for adding cryptographic signature and encryption services to X.400 content with Secure/Multipurpose Internet Mail Extensions (S/MIME). [STANDARDS TRACK]</abstract>
        <draft>ietf-smime-x400wrap-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3855</doc-id>
        <title>Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400</title>
        <author>
            <name>P. Hoffman</name>
        </author>
        <author>
            <name>C. Bonatti</name>
        </author>
        <date>
            <month>July</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25774</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>cms</kw>
            <kw>cryptographic message syntax message</kw>
        </keywords>
        <abstract>This document describes protocol options for conveying objects that have been protected using the Cryptographic Message Syntax (CMS) and Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1 over an X.400 message transfer system. [STANDARDS TRACK]</abstract>
        <draft>ietf-smime-x400transport-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3856</doc-id>
        <title>A Presence Event Package for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>62956</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>subscription notification</kw>
        </keywords>
        <abstract>This document describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of presence. Presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to "on-line" and "off-line" indicators; the notion of presence here is broader. Subscriptions and notifications of presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence Profile (CPP) framework. [STANDARDS TRACK]</abstract>
        <draft>ietf-simple-presence-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3857</doc-id>
        <title>A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46221</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document defines the watcher information template-package for the Session Initiation Protocol (SIP) event framework. Watcher information refers to the set of users subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A user can subscribe to this information, and therefore learn about changes to it. This event package is a template-package because it can be applied to any event package, including itself. [STANDARDS TRACK]</abstract>
        <draft>ietf-simple-winfo-package-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3858</doc-id>
        <title>An Extensible Markup Language (XML) Based Format for Watcher Information</title>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26416</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>xml</kw>
        </keywords>
        <abstract>Watchers are defined as entities that request (i.e., subscribe to) information about a resource. There is fairly complex state associated with these subscriptions. The union of the state for all subscriptions to a particular resource is called the watcher information for that resource. This state is dynamic, changing as subscribers come and go. As a result, it is possible, and indeed useful, to subscribe to the watcher information for a particular resource. In order to enable this, a format is needed to describe the state of watchers on a resource. This specification describes an Extensible Markup Language (XML) document format for such state. [STANDARDS TRACK]</abstract>
        <draft>ietf-simple-winfo-format-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3859</doc-id>
        <title>Common Profile for Presence (CPP)</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30537</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>data formats</kw>
            <kw>semantics</kw>
            <kw>instant messaging</kw>
        </keywords>
        <abstract>At the time this document was written, numerous presence protocols were in use (largely as components of commercial instant messaging services), and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for presence to facilitate the creation of gateways between presence services. [STANDARDS TRACK]</abstract>
        <draft>ietf-impp-pres-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3860</doc-id>
        <title>Common Profile for Instant Messaging (CPIM)</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26486</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>data formats</kw>
            <kw>semantics</kw>
            <kw>instant messaging</kw>
        </keywords>
        <abstract>At the time this document was written, numerous instant messaging protocols were in use, and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for instant messaging to facilitate the creation of gateways between instant messaging services. [STANDARDS TRACK]</abstract>
        <draft>ietf-impp-im-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3861</doc-id>
        <title>Address Resolution for Instant Messaging and Presence</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15764</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>uri</kw>
            <kw>schemes</kw>
            <kw>universal resource identifier</kw>
            <kw>impp</kw>
            <kw>instant messaging and presence protocol</kw>
            <kw>presentity</kw>
            <kw>instant inbox</kw>
        </keywords>
        <abstract>Presence and instant messaging are defined in RFC 2778. The Common Profiles for Presence and Instant Messaging define two Universal Resource Identifier (URI) schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES. This document provides guidance for locating the resources associated with URIs that employ these schemes. [STANDARDS TRACK]</abstract>
        <draft>ietf-impp-srv-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3862</doc-id>
        <title>Common Presence and Instant Messaging (CPIM): Message Format</title>
        <author>
            <name>G. Klyne</name>
        </author>
        <author>
            <name>D. Atkins</name>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>56133</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>instant messaging and presence protocol</kw>
            <kw>message/cpim</kw>
        </keywords>
        <abstract>This memo defines the MIME content type 'Message/CPIM', a message format for protocols that conform to the Common Profile for Instant Messaging (CPIM) specification. [STANDARDS TRACK]</abstract>
        <draft>ietf-impp-cpim-msgfmt-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3863</doc-id>
        <title>Presence Information Data Format (PIDF)</title>
        <author>
            <name>H. Sugano</name>
        </author>
        <author>
            <name>S. Fujimoto</name>
        </author>
        <author>
            <name>G. Klyne</name>
        </author>
        <author>
            <name>A. Bateman</name>
        </author>
        <author>
            <name>W. Carr</name>
        </author>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>56956</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>instant messaging and presence protocol</kw>
            <kw>cpp</kw>
            <kw>common profile for presence</kw>
            <kw>presence data format</kw>
            <kw>application/pidf+xml</kw>
        </keywords>
        <abstract>This memo specifies the Common Profile for Presence (CPP) Presence Information Data Format (PIDF) as a common presence data format for CPP-compliant Presence protocols, and also defines a new media type "application/pidf+xml" to represent the XML MIME entity for PIDF. [STANDARDS TRACK]</abstract>
        <draft>ietf-impp-cpim-pidf-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3864</doc-id>
        <title>Registration Procedures for Message Header Fields</title>
        <author>
            <name>G. Klyne</name>
        </author>
        <author>
            <name>M. Nottingham</name>
        </author>
        <author>
            <name>J. Mogul</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36231</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>Internet mail</kw>
            <kw>HTTP</kw>
            <kw>Netnews</kw>
        </keywords>
        <abstract>This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>klyne-msghdr-registry-07</draft>
        <is-also>
            <doc-id>BCP0090</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3865</doc-id>
        <title>A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension</title>
        <author>
            <name>C. Malamud</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40717</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>unsolicited bulk email</kw>
            <kw>ube</kw>
            <kw>no soliciting</kw>
            <kw>solicitation class keywords</kw>
            <kw>solicitation mail header</kw>
            <kw>trace fields</kw>
        </keywords>
        <abstract>This document proposes an extension to Soliciting Simple Mail Transfer Protocol (SMTP) for an electronic mail equivalent to the real-world "No Soliciting" sign. In addition to the service extension, a new message header and extensions to the existing "received" message header are described. [STANDARDS TRACK]</abstract>
        <draft>malamud-no-soliciting-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3866</doc-id>
        <title>Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP)</title>
        <author>
            <name>K. Zeilenga</name>
            <title>Editor</title>
        </author>
        <date>
            <month>July</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31501</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>lightweight</kw>
            <kw>directory</kw>
            <kw>access</kw>
            <kw>protocol</kw>
            <kw>servers</kw>
        </keywords>
        <abstract>It is often desirable to be able to indicate the natural language associated with values held in a directory and to be able to query the directory for values which fulfill the user's language needs. This document details the use of Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP). [STANDARDS TRACK]</abstract>
        <draft>zeilenga-ldap-rfc2596-05</draft>
        <obsoletes>
            <doc-id>RFC2596</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3867</doc-id>
        <title>Payment Application Programmers Interface (API) for v1.0 Internet Open Trading Protocol (IOTP)</title>
        <author>
            <name>Y. Kawatsura</name>
        </author>
        <author>
            <name>M. Hiroya</name>
        </author>
        <author>
            <name>H. Beykirch</name>
        </author>
        <date>
            <month>November</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>234572</char-count>
            <page-count>106</page-count>
        </format>
        <keywords>
            <kw>modules</kw>
            <kw>data format exchange</kw>
        </keywords>
        <abstract>The Internet Open Trading Protocol (IOTP) provides a data exchange format for trading purposes while integrating existing pure payment protocols seamlessly. This motivates the multiple layered system architecture which consists of at least some generic IOTP application core and multiple specific payment modules. &lt;br&gt; This document addresses a common interface between the IOTP application core and the payment modules, enabling the interoperability between these kinds of modules. Furthermore, such an interface provides the foundations for a plug-in-mechanism in actual implementations of IOTP application cores. Such interfaces exist at the Consumers', the Merchants' and the Payment Handlers' installations connecting the IOTP application core and the payment software components/legacy systems. This memo provides information for the Internet community.</abstract>
        <draft>ietf-trade-iotp-v1.0-papi-06a</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3868</doc-id>
        <title>Signalling Connection Control Part User Adaptation Layer (SUA)</title>
        <author>
            <name>J. Loughney</name>
            <title>Editor</title>
        </author>
        <author>
            <name>G. Sidebottom</name>
        </author>
        <author>
            <name>L. Coene</name>
        </author>
        <author>
            <name>G. Verwimp</name>
        </author>
        <author>
            <name>J. Keller</name>
        </author>
        <author>
            <name>B. Bidulock</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>294116</char-count>
            <page-count>131</page-count>
        </format>
        <keywords>
            <kw>sctp</kw>
            <kw>stream control transmission protocol</kw>
            <kw>modular</kw>
            <kw>symmetric</kw>
            <kw>signalling gateway</kw>
            <kw>signalling endpoint architecture</kw>
        </keywords>
        <abstract>This document defines a protocol for the transport of any Signalling Connection Control Part-User signalling over IP using the Stream Control Transmission Protocol. The protocol is designed to be modular and symmetric, to allow it to work in diverse architectures, such as a Signalling Gateway to IP Signalling Endpoint architecture as well as a peer-to-peer IP Signalling Endpoint architecture. [STANDARDS TRACK]</abstract>
        <draft>ietf-sigtran-sua-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3869</doc-id>
        <title>IAB Concerns and Recommendations Regarding Internet Research and Evolution</title>
        <author>
            <name>R. Atkinson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>S. Floyd</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Internet Architecture Board</name>
        </author>
        <date>
            <month>August</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>78250</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>internet architecture board</kw>
            <kw>internet infrastructure</kw>
            <kw>non-commercial funding</kw>
        </keywords>
        <abstract>This document discusses IAB concerns that ongoing research is needed to further the evolution of the Internet infrastructure, and that consistent, sufficient non-commercial funding is needed to enable such research. This memo provides information for the Internet community.</abstract>
        <draft>iab-research-funding-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3870</doc-id>
        <title>application/rdf+xml Media Type Registration</title>
        <author>
            <name>A. Swartz</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14195</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>xml</kw>
            <kw>extensible markup language</kw>
            <kw>mime</kw>
            <kw>multipurpose internet mail extensions</kw>
            <kw>rdf</kw>
            <kw>resource description framework</kw>
        </keywords>
        <abstract>This document describes a media type (application/rdf+xml) for use with the Extensible Markup Language (XML) serialization of the Resource Description Framework (RDF). RDF is a language designed to support the Semantic Web, by facilitating resource description and data exchange on the Web. RDF provides common structures that can be used for interoperable data exchange and follows the World Wide Web Consortium (W3C) design principles of interoperability, evolution, and decentralization. This memo provides information for the Internet community.</abstract>
        <draft>swartz-rdfcore-rdfxml-mediatype-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3871</doc-id>
        <title>Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure</title>
        <author>
            <name>G. Jones</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>151101</char-count>
            <page-count>81</page-count>
        </format>
        <abstract>This document defines a list of operational security requirements for the infrastructure of large Internet Service Provider (ISP) IP networks (routers and switches). A framework is defined for specifying "profiles", which are collections of requirements applicable to certain network topology contexts (all, core-only, edge-only...). The goal is to provide network operators a clear, concise way of communicating their security requirements to vendors. This memo provides information for the Internet community.</abstract>
        <draft>jones-opsec-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3872</doc-id>
        <title>Management Information Base for Telephony Routing over IP (TRIP)</title>
        <author>
            <name>D. Zinman</name>
        </author>
        <author>
            <name>D. Walker</name>
        </author>
        <author>
            <name>J. Jiang</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>98614</char-count>
            <page-count>53</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Telephony Routing over IP (TRIP) devices. [STANDARDS TRACK]</abstract>
        <draft>ietf-iptel-trip-mib-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3873</doc-id>
        <title>Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)</title>
        <author>
            <name>J. Pastor</name>
        </author>
        <author>
            <name>M. Belinchon</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>82403</char-count>
            <page-count>46</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a connectionless packet network such as IP. It is designed to transport public switched telephone network (PSTN) signaling messages over the connectionless packet network, but is capable of broader applications. &lt;br&gt; This memo defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage the implementation of the SCTP. [STANDARDS TRACK]</abstract>
        <draft>ietf-sigtran-sctp-mib-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3874</doc-id>
        <title>A 224-bit One-way Hash Function: SHA-224</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11600</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>secure standard</kw>
        </keywords>
        <abstract>This document specifies a 224-bit one-way hash function, called SHA-224. SHA-224 is based on SHA-256, but it uses a different initial value and the result is truncated to 224 bits. This memo provides information for the Internet community.</abstract>
        <draft>ietf-pkix-sha224-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3875</doc-id>
        <title>The Common Gateway Interface (CGI) Version 1.1</title>
        <author>
            <name>D. Robinson</name>
        </author>
        <author>
            <name>K. Coar</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>80728</char-count>
            <page-count>36</page-count>
        </format>
        <format>
            <file-format>PDF</file-format>
            <char-count>121026</char-count>
        </format>
        <keywords>
            <kw>www</kw>
            <kw>world wide web</kw>
        </keywords>
        <abstract>The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. Currently, the supported information servers are HTTP servers. &lt;br&gt; The interface has been in use by the World-Wide Web (WWW) since 1993. This specification defines the 'current practice' parameters of the 'CGI/1.1' interface developed and documented at the U.S. National Centre for Supercomputing Applications. This document also defines the use of the CGI/1.1 interface on UNIX(R) and other, similar systems. This memo provides information for the Internet community.</abstract>
        <draft>coar-cgi-v11-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3876</doc-id>
        <title>Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3)</title>
        <author>
            <name>D. Chadwick</name>
        </author>
        <author>
            <name>S. Mullan</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24233</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
            <kw>attribute</kw>
            <kw>filter</kw>
        </keywords>
        <abstract>This document describes a control for the Lightweight Directory Access Protocol version 3 that is used to return a subset of attribute values from an entry. Specifically, only those values that match a "values return" filter. Without support for this control, a client must retrieve all of an attribute's values and search for specific values locally. [STANDARDS TRACK]</abstract>
        <draft>ietf-ldapext-matchedval-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3877</doc-id>
        <title>Alarm Management Information Base (MIB)</title>
        <author>
            <name>S. Chisholm</name>
        </author>
        <author>
            <name>D. Romascanu</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>149783</char-count>
            <page-count>75</page-count>
        </format>
        <keywords>
            <kw>alarm mib</kw>
            <kw>iana-itu-alarm-tc-mib</kw>
            <kw>itu-alarm-tc-mib</kw>
            <kw>itu-alarm-mib</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes management objects used for modelling and storing alarms. [STANDARDS TRACK]</abstract>
        <draft>ietf-disman-alarm-mib-18</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3878</doc-id>
        <title>Alarm Reporting Control Management Information Base (MIB)</title>
        <author>
            <name>H. Lam</name>
        </author>
        <author>
            <name>A. Huynh</name>
        </author>
        <author>
            <name>D. Perkins</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31093</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>alarm condition</kw>
            <kw>probably cause</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for controlling the reporting of alarm conditions. [STANDARDS TRACK]</abstract>
        <draft>ietf-disman-conditionmib-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3879</doc-id>
        <title>Deprecating Site Local Addresses</title>
        <author>
            <name>C. Huitema</name>
        </author>
        <author>
            <name>B. Carpenter</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24142</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>ipv6</kw>
            <kw>architecture</kw>
        </keywords>
        <abstract>This document describes the issues surrounding the use of IPv6 site-local unicast addresses in their original form, and formally deprecates them. This deprecation does not prevent their continued use until a replacement has been standardized and implemented. [STANDARDS TRACK]</abstract>
        <draft>ietf-ipv6-deprecate-site-local-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3880</doc-id>
        <title>Call Processing Language (CPL): A Language for User Control of Internet Telephony Services</title>
        <author>
            <name>J. Lennox</name>
        </author>
        <author>
            <name>X. Wu</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>154991</char-count>
            <page-count>74</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document defines the Call Processing Language (CPL), a language to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agents. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs. [STANDARDS TRACK]</abstract>
        <draft>ietf-iptel-cpl-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3881</doc-id>
        <title>Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications</title>
        <author>
            <name>G. Marshall</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>86130</char-count>
            <page-count>47</page-count>
        </format>
        <draft>marshall-security-audit-12</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status></publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3882</doc-id>
        <title>Configuring BGP to Block Denial-of-Service Attacks</title>
        <author>
            <name>D. Turk</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19637</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>dos</kw>
            <kw>border gateway protocol</kw>
        </keywords>
        <abstract>This document describes an operational technique that uses BGP communities to remotely trigger black-holing of a particular destination network to block denial-of-service attacks. Black-holing can be applied on a selection of routers rather than all BGP-speaking routers in the network. The document also describes a sinkhole tunnel technique using BGP communities and tunnels to pull traffic into a sinkhole router for analysis. This memo provides information for the Internet community.</abstract>
        <draft>turk-bgp-dos-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3883</doc-id>
        <title>Detecting Inactive Neighbors over OSPF Demand Circuits (DC)</title>
        <author>
            <name>S. Rao</name>
        </author>
        <author>
            <name>A. Zinin</name>
        </author>
        <author>
            <name>A. Roy</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13100</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>OSPF-DC</kw>
            <kw>Open Shortest Path First</kw>
        </keywords>
        <abstract>OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF behavior over demand circuits (DC) is optimized in RFC 1793 to minimize the amount of overhead traffic. A part of the OSPF demand circuit extensions is the Hello suppression mechanism. This technique allows a demand circuit to go down when no interesting traffic is going through the link. However, it also introduces a problem, where it becomes impossible to detect an OSPF-inactive neighbor over such a link. This memo introduces a new mechanism called "neighbor probing" to address the above problem. [STANDARDS TRACK]</abstract>
        <draft>ietf-ospf-dc-07</draft>
        <updates>
            <doc-id>RFC1793</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3884</doc-id>
        <title>Use of IPsec Transport Mode for Dynamic Routing</title>
        <author>
            <name>J. Touch</name>
        </author>
        <author>
            <name>L. Eggert</name>
        </author>
        <author>
            <name>Y. Wang</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59437</char-count>
        </format>
        <abstract>IPsec can secure the links of a multihop network to protect communication between trusted components, e.g., for a secure virtual network (VN), overlay, or virtual private network (VPN). Virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside VNs because IP routing depends on references to interfaces and next-hop IP addresses. The IPsec tunnel mode specification is ambiguous on this issue, so even compliant implementations cannot be trusted to avoid conflicts. An alternative to tunnel mode uses non-IPsec IPIP encapsulation together with IPsec transport mode, which we call IIPtran. IPIP encapsulation occurs as a separate initial step, as the result of a forwarding lookup of the VN packet. IPsec transport mode processes the resulting (tunneled) IP packet with an SA determined through a security association database (SAD) match on the tunnel header. IIPtran supports dynamic routing inside the VN without changes to the current IPsec architecture. IIPtran demonstrates how to configure any compliant IPsec implementation to avoid the aforementioned conflicts. IIPtran is also compared to several alternative mechanisms for VN routing and their respective impact on IPsec, routing, policy enforcement, and interactions with the Internet Key Exchange (IKE). This memo provides information for the Internet community.</abstract>
        <draft>touch-ipsec-vpn-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3885</doc-id>
        <title>SMTP Service Extension for Message Tracking</title>
        <author>
            <name>E. Allman</name>
        </author>
        <author>
            <name>T. Hansen</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17458</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>simple mail transfer protocol</kw>
        </keywords>
        <abstract>This memo defines an extension to the SMTP service whereby a client may mark a message for future tracking. [STANDARDS TRACK]</abstract>
        <draft>ietf-msgtrk-smtpext-05</draft>
        <updates>
            <doc-id>RFC3461</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3886</doc-id>
        <title>An Extensible Message Format for Message Tracking Responses</title>
        <author>
            <name>E. Allman</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>21746</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>Delivery Status Notifications</kw>
            <kw>DSN</kw>
            <kw>Message Disposition Notifications</kw>
            <kw>MDN</kw>
        </keywords>
        <abstract>Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications (DSN) and Message Disposition Notifications (MDN); generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period. &lt;br&gt; This memo defines a MIME content-type for message tracking status in the same spirit as RFC 3464, "An Extensible Message Format for Delivery Status Notifications". It is to be issued upon a request as described in "Message Tracking Query Protocol". This memo defines only the format of the status information. An extension to SMTP to label messages for further tracking and request tracking status is defined in a separate memo. [STANDARDS TRACK]</abstract>
        <draft>ietf-msgtrk-trkstat-05</draft>
        <updates>
            <doc-id>RFC3463</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3887</doc-id>
        <title>Message Tracking Query Protocol</title>
        <author>
            <name>T. Hansen</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42763</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>mtqp</kw>
            <kw>ESMTP</kw>
        </keywords>
        <abstract>Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document describes the Message Tracking Query Protocol that is used in conjunction with extensions to the ESMTP protocol to provide a complete message tracking solution for the Internet. [STANDARDS TRACK]</abstract>
        <draft>ietf-msgtrk-mtqp-12</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3888</doc-id>
        <title>Message Tracking Model and Requirements</title>
        <author>
            <name>T. Hansen</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20950</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document provides a model of message tracking that can be used for understanding the Internet-wide message infrastructure and to further enhance those capabilities to include message tracking, as well as requirements for proposed message tracking solutions. This memo provides information for the Internet community.</abstract>
        <draft>ietf-msgtrk-model-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3890</doc-id>
        <title>A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)</title>
        <author>
            <name>M. Westerlund</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>49894</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>tias</kw>
            <kw>application specific maximum</kw>
        </keywords>
        <draft>ietf-mmusic-sdp-bwparam-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3891</doc-id>
        <title>The Session Initiation Protocol (SIP) "Replaces" Header</title>
        <author>
            <name>R. Mahy</name>
        </author>
        <author>
            <name>B. Biggs</name>
        </author>
        <author>
            <name>R. Dean</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34180</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>multi-party applications</kw>
            <kw>call control</kw>
        </keywords>
        <abstract>This document defines a new header for use with Session Initiation Protocol (SIP) multi-party applications and call control. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Attended Transfer" and "Call Pickup". Note that the definition of these example features is non-normative. [STANDARDS TRACK]</abstract>
        <draft>ietf-sip-replaces-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3892</doc-id>
        <title>The Session Initiation Protocol (SIP) Referred-By Mechanism</title>
        <author>
            <name>R. Sparks</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52441</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>REFER</kw>
        </keywords>
        <abstract>The Session Initiation Protocol (SIP) REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method, allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present. [STANDARDS TRACK]</abstract>
        <draft>ietf-sip-referredby-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3893</doc-id>
        <title>Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28500</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>authenticated identity body</kw>
            <kw>digitally-signed SIP message</kw>
            <kw>message fragment</kw>
            <kw>Authenticated Identity Bodies</kw>
            <kw>AIB</kw>
        </keywords>
        <abstract>RFC 3261 introduces the concept of adding an S/MIME body to a Session Initiation Protocol (SIP) request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an 'authenticated identity body', a digitally-signed SIP message, or message fragment. A standard format for such bodies (known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given. [STANDARDS TRACK]</abstract>
        <draft>ietf-sip-authid-body-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3894</doc-id>
        <title>Sieve Extension: Copying Without Side Effects</title>
        <author>
            <name>J. Degener</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9018</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>client</kw>
            <kw>server</kw>
        </keywords>
        <abstract>The Sieve scripting language allows users to control handling and disposal of their incoming e-mail. By default, an e-mail message that is processed by a Sieve script is saved in the owner's "inbox". Actions such as "fileinto" and "redirect" cancel this default behavior. &lt;br&gt; This document defines a new keyword parameter, ":copy", to be used with the Sieve "fileinto" and "redirect" actions. Adding ":copy" to an action suppresses cancellation of the default "inbox" save. It allows users to add commands to an existing script without changing the meaning of the rest of the script. [STANDARDS TRACK]</abstract>
        <draft>degener-sieve-copy-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3895</doc-id>
        <title>Definitions of Managed Objects for the DS1, E1, DS2, and E2 Interface Types</title>
        <author>
            <name>O. Nicklass</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>163841</char-count>
            <page-count>84</page-count>
        </format>
        <keywords>
            <kw>management information base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS3/E3 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. This document obsoletes RFC 2495. [STANDARDS TRACK]</abstract>
        <draft>ietf-atommib-rfc2495bis-06</draft>
        <obsoletes>
            <doc-id>RFC2495</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3896</doc-id>
        <title>Definitions of Managed Objects for the DS3/E3 Interface Type</title>
        <author>
            <name>O. Nicklass</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>129547</char-count>
            <page-count>63</page-count>
        </format>
        <keywords>
            <kw>DS3-E3-MIB</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS3 and E3 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS1/E1/DS2/E2 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. This document obsoletes RFC 2496. [STANDARDS TRACK]</abstract>
        <draft>ietf-atommib-rfc2496bis-06</draft>
        <obsoletes>
            <doc-id>RFC2496</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3897</doc-id>
        <title>Open Pluggable Edge Services (OPES) Entities and End Points Communication</title>
        <author>
            <name>A. Barbir</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33890</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>tracing</kw>
            <kw>non-blocking</kw>
            <kw>bypass</kw>
        </keywords>
        <abstract>This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES). This memo provides information for the Internet community.</abstract>
        <draft>ietf-opes-end-comm-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3898</doc-id>
        <title>Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
        <author>
            <name>V. Kalusivalingam</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13955</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>NIS Servers</kw>
            <kw>NIS+ Servers</kw>
            <kw>NIS Client Domain Name</kw>
            <kw>NIS+ Client Domain name</kw>
        </keywords>
        <abstract>This document describes four options for Network Information Service (NIS) related configuration information in Dynamic Host Configuration Protocol for IPv6 (DHCPv6): NIS Servers, NIS+ Servers, NIS Client Domain Name, NIS+ Client Domain name. [STANDARDS TRACK]</abstract>
        <draft>ietf-dhc-dhcpv6-opt-nisconfig-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3901</doc-id>
        <title>DNS IPv6 Transport Operational Guidelines</title>
        <author>
            <name>A. Durand</name>
        </author>
        <author>
            <name>J. Ihren</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10025</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>domain name system</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract>This memo provides guidelines and Best Current Practice for operating DNS in a world where queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>ietf-dnsop-ipv6-transport-guidelines-02</draft>
        <is-also>
            <doc-id>BCP0091</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3902</doc-id>
        <title>The "application/soap+xml" media type</title>
        <author>
            <name>M. Baker</name>
        </author>
        <author>
            <name>M. Nottingham</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10575</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>This document defines the "application/soap+xml" media type which can be used to describe SOAP 1.2 messages serialized as XML 1.0. This memo provides information for the Internet community.</abstract>
        <draft>baker-soap-media-reg-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3903</doc-id>
        <title>Session Initiation Protocol (SIP) Extension for Event State Publication</title>
        <author>
            <name>A. Niemi</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>72062</char-count>
            <page-count>32</page-count>
        </format>
        <keywords>
            <kw>presence</kw>
            <kw>information</kw>
            <kw>package</kw>
        </keywords>
        <abstract>This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the SIP Events framework. The first application of this extension is for the publication of presence information. &lt;br&gt; The mechanism described in this document can be extended to support publication of any event state for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose. [STANDARDS TRACK]</abstract>
        <draft>ietf-sip-publish-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3904</doc-id>
        <title>Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks</title>
        <author>
            <name>C. Huitema</name>
        </author>
        <author>
            <name>R. Austein</name>
        </author>
        <author>
            <name>S. Satapati</name>
        </author>
        <author>
            <name>R. van der Pol</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46844</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>home office</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract>This document analyzes issues involved in the transition of "unmanaged networks" from IPv4 to IPv6. Unmanaged networks typically correspond to home networks or small office networks. A companion paper analyzes out the requirements for mechanisms needed in various transition scenarios of these networks to IPv6. Starting from this analysis, we evaluate the suitability of mechanisms that have already been specified, proposed, or deployed. This memo provides information for the Internet community.</abstract>
        <draft>ietf-v6ops-unmaneval-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3905</doc-id>
        <title>A Template for IETF Patent Disclosures and Licensing Declarations</title>
        <author>
            <name>V. See</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16110</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>ipr</kw>
        </keywords>
        <abstract>This document describes a proposal for one form of a template for IETF patent disclosures and licensing declarations. The optional use of this template is meant to simplify the process of such disclosures and licensing declarations and to assist disclosers in providing the necessary information to meet the obligations documented in RFC 3668. This memo provides information for the Internet community.</abstract>
        <draft>ietf-ipr-template-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3906</doc-id>
        <title>Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels</title>
        <author>
            <name>N. Shen</name>
        </author>
        <author>
            <name>H. Smit</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18410</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>hop-by-hop link-state routing protocols</kw>
            <kw>SPF</kw>
            <kw>shortest path first</kw>
        </keywords>
        <abstract>This document describes how conventional hop-by-hop link-state routing protocols interact with new Traffic Engineering capabilities to create Interior Gateway Protocol (IGP) shortcuts. In particular, this document describes how Dijkstra's Shortest Path First (SPF) algorithm can be adapted so that link-state IGPs will calculate IP routes to forward traffic over tunnels that are set up by Traffic Engineering. This memo provides information for the Internet community.</abstract>
        <draft>ietf-rtgwg-igp-shortcut-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3909</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP) Cancel Operation</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13423</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>abandon operation</kw>
            <kw>outstanding operation</kw>
        </keywords>
        <abstract>This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to cancel (or abandon) an outstanding operation. Unlike the LDAP Abandon operation, but like the X.511 Directory Access Protocol (DAP) Abandon operation, this operation has a response which provides an indication of its outcome. [STANDARDS TRACK]</abstract>
        <draft>zeilenga-ldap-cancel-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3910</doc-id>
        <title>The SPIRITS (Services in PSTN requesting Internet Services) Protocol</title>
        <author>
            <name>V. Gurbani</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Brusilovsky</name>
        </author>
        <author>
            <name>I. Faynberg</name>
        </author>
        <author>
            <name>J. Gato</name>
        </author>
        <author>
            <name>H. Lu</name>
        </author>
        <author>
            <name>M. Unmehopa</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>110515</char-count>
            <page-count>50</page-count>
        </format>
        <keywords>
            <kw>pstn</kw>
            <kw>sip</kw>
            <kw>services</kw>
            <kw>event notification</kw>
            <kw>eventpackages</kw>
            <kw>internet call waiting</kw>
            <kw>xml</kw>
            <kw>wireless</kw>
            <kw>intelligent network</kw>
            <kw>in</kw>
            <kw>detection point</kw>
            <kw>dp</kw>
        </keywords>
        <abstract>This document describes the Services in PSTN (Public Switched Telephone Network) requesting Internet Services (SPIRITS) protocol. The purpose of the SPIRITS protocol is to support services that originate in the cellular or wireline PSTN and necessitate interactions between the PSTN and the Internet. On the PSTN side, the SPIRITS services are most often initiated from the Intelligent Network (IN) entities. Internet Call Waiting and Internet Caller-ID Delivery are examples of SPIRITS services, as are location-based services on the cellular network. The protocol defines the building blocks from which many other services can be built. [STANDARDS TRACK]</abstract>
        <draft>ietf-spirits-protocol-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3911</doc-id>
        <title>The Session Initiation Protocol (SIP) "Join" Header</title>
        <author>
            <name>R. Mahy</name>
        </author>
        <author>
            <name>D. Petrie</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35373</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document defines a new header for use with SIP multi-party applications and call control. The Join header is used to logically join an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Barge-In", answering-machine-style "Message Screening" and "Call Center Monitoring". Note that definition of these example features is non-normative. [STANDARDS TRACK]</abstract>
        <draft>ietf-sip-join-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3912</doc-id>
        <title>WHOIS Protocol Specification</title>
        <author>
            <name>L. Daigle</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7770</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>NICNAME</kw>
        </keywords>
        <abstract>This document updates the specification of the WHOIS protocol, thereby obsoleting RFC 954. The update is intended to remove the material from RFC 954 that does not have to do with the on-the-wire protocol, and is no longer applicable in today's Internet. This document does not attempt to change or update the protocol per se, or document other uses of the protocol that have come into existence since the publication of RFC 954. [STANDARDS TRACK]</abstract>
        <draft>daigle-rfc954bis-01</draft>
        <obsoletes>
            <doc-id>RFC0954</doc-id>
            <doc-id>RFC0812</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3913</doc-id>
        <title>Border Gateway Multicast Protocol (BGMP): Protocol Specification</title>
        <author>
            <name>D. Thaler</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>97443</char-count>
            <page-count>41</page-count>
        </format>
        <keywords>
            <kw>enter-domain</kw>
            <kw>source-specific multicast</kw>
            <kw>ssm</kw>
        </keywords>
        <abstract>This document describes the Border Gateway Multicast Protocol (BGMP), a protocol for inter-domain multicast routing. BGMP builds shared trees for active multicast groups, and optionally allows receiver domains to build source-specific, inter-domain, distribution branches where needed. BGMP natively supports "source-specific multicast" (SSM). To also support "any-source multicast" (ASM), BGMP requires that each multicast group be associated with a single root (in BGMP it is referred to as the root domain). It requires that different ranges of the multicast address space are associated (e.g., with Unicast-Prefix-Based Multicast addressing) with different domains. Each of these domains then becomes the root of the shared domain-trees for all groups in its range. Multicast participants will generally receive better multicast service if the session initiator's address allocator selects addresses from its own domain's part of the space, thereby causing the root domain to be local to at least one of the session participants. This memo provides information for the Internet community.</abstract>
        <draft>ietf-bgmp-spec-06</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3914</doc-id>
        <title>Open Pluggable Edge Services (OPES) Treatment of IAB Considerations</title>
        <author>
            <name>A. Barbir</name>
        </author>
        <author>
            <name>A. Rousskov</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>37411</char-count>
            <page-count>16</page-count>
        </format>
        <abstract>IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES addresses those considerations. This memo provides information for the Internet community.</abstract>
        <draft>ietf-opes-iab-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3915</doc-id>
        <title>Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)</title>
        <author>
            <name>S. Hollenbeck</name>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45467</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>dns</kw>
            <kw>name system</kw>
        </keywords>
        <abstract>This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the management of Domain Name System (DNS) domain names subject to "grace period" policies defined by the Internet Corporation for Assigned Names and Numbers (ICANN). Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for grace period processing. [STANDARDS TRACK]</abstract>
        <draft>hollenbeck-epp-rgp-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3916</doc-id>
        <title>Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)</title>
        <author>
            <name>X. Xiao</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. McPherson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Pate</name>
            <title>Editor</title>
        </author>
        <date>
            <month>September</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43856</char-count>
            <page-count>19</page-count>
        </format>
        <abstract>This document describes base requirements for the Pseudo-Wire Emulation Edge to Edge Working Group (PWE3 WG). It provides guidelines for other working group documents that will define mechanisms for providing pseudo-wire emulation of Ethernet, ATM, and Frame Relay. Requirements for pseudo-wire emulation of TDM (i.e., "synchronous bit streams at rates defined by ITU G.702") are defined in another document. It should be noted that the PWE3 WG standardizes mechanisms that can be used to provide PWE3 services, but not the services themselves. This memo provides information for the Internet community.</abstract>
        <draft>ietf-pwe3-requirements-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3917</doc-id>
        <title>Requirements for IP Flow Information Export (IPFIX)</title>
        <author>
            <name>J. Quittek</name>
        </author>
        <author>
            <name>T. Zseby</name>
        </author>
        <author>
            <name>B. Claise</name>
        </author>
        <author>
            <name>S. Zander</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>81615</char-count>
            <page-count>33</page-count>
        </format>
        <keywords>
            <kw>ipfix</kw>
            <kw>routers</kw>
            <kw>measurment</kw>
            <kw>middleboxes</kw>
        </keywords>
        <abstract>This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes, and middleboxes. This memo provides information for the Internet community.</abstract>
        <draft>ietf-ipfix-reqs-16</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3918</doc-id>
        <title>Methodology for IP Multicast Benchmarking</title>
        <author>
            <name>D. Stopp</name>
        </author>
        <author>
            <name>B. Hickman</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>64652</char-count>
            <page-count>31</page-count>
        </format>
        <abstract>The purpose of this document is to describe methodology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 2544, RFC 2432 and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm. &lt;br&gt; The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. This memo provides information for the Internet community.</abstract>
        <draft>ietf-bmwg-mcastm-14</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3919</doc-id>
        <title>Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS)</title>
        <author>
            <name>E. Stephan</name>
        </author>
        <author>
            <name>J. Palet</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14228</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
        </keywords>
        <abstract>This memo defines additional (to those in RFC 2896) protocol identifier examples for IP version 6 and MPLS protocols. These can be used to produce valid protocolDirTable INDEX encodings, as defined by the Remote Network Monitoring MIB (Management Information Base) Version 2 [RFC2021] and the RMON Protocol Identifier Reference [RFC2895]. &lt;br&gt; This document contains additional (to those in RFC 2896) protocol identifier macros for well-known protocols. A conformant implementation of the RMON-2 MIB [RFC2021] can be accomplished without the use of these protocol identifiers, and accordingly, this document does not specify any IETF standard. It is published to encourage better interoperability between RMON-2 agent implementations, by providing RMON related IPv6 and MPLS protocol information. This memo provides information for the Internet community.</abstract>
        <draft>ietf-rmonmib-pi-ipv6-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3920</doc-id>
        <title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
        <author>
            <name>P. Saint-Andre</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>194313</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>instant messaging</kw>
            <kw>im</kw>
            <kw>extensible markup language</kw>
            <kw>xml</kw>
            <kw>jabber</kw>
        </keywords>
        <abstract>This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779. [STANDARDS TRACK]</abstract>
        <draft>ietf-xmpp-core-24</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3921</doc-id>
        <title>Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence</title>
        <author>
            <name>P. Saint-Andre</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>217527</char-count>
            <page-count>107</page-count>
        </format>
        <keywords>
            <kw>instant messaging</kw>
            <kw>im</kw>
            <kw>extensible markup language</kw>
            <kw>xml</kw>
            <kw>jabber</kw>
        </keywords>
        <abstract>This memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779. [STANDARDS TRACK]</abstract>
        <draft>ietf-xmpp-im-22</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3922</doc-id>
        <title>Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>70790</char-count>
            <page-count>34</page-count>
        </format>
        <keywords>
            <kw>xml</kw>
            <kw>extensible markup language</kw>
            <kw>im</kw>
            <kw>instant messaging</kw>
            <kw>jabber</kw>
        </keywords>
        <abstract>This memo describes a mapping between the Extensible Messaging and Presence Protocol (XMPP) and the Common Presence and Instant Messaging (CPIM) specifications. [STANDARDS TRACK]</abstract>
        <draft>ietf-xmpp-cpim-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3923</doc-id>
        <title>End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)</title>
        <author>
            <name>P. Saint-Andre</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51828</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>xml</kw>
            <kw>extensible markup language</kw>
            <kw>im</kw>
            <kw>instant messaging</kw>
            <kw>jabber</kw>
        </keywords>
        <abstract>This memo defines methods of end-to-end signing and object encryption for the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS TRACK]</abstract>
        <draft>ietf-xmpp-e2e-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3924</doc-id>
        <title>Cisco Architecture for Lawful Intercept in IP Networks</title>
        <author>
            <name>F. Baker</name>
        </author>
        <author>
            <name>B. Foster</name>
        </author>
        <author>
            <name>C. Sharp</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40826</char-count>
            <page-count>18</page-count>
        </format>
        <abstract>For the purposes of this document, lawful intercept is the lawfully authorized interception and monitoring of communications. Service providers are being asked to meet legal and regulatory requirements for the interception of voice as well as data communications in IP networks in a variety of countries worldwide. Although requirements vary from country to country, some requirements remain common even though details such as delivery formats may differ. This document describes Cisco's Architecture for supporting lawful intercept in IP networks. It provides a general solution that has a minimum set of common interfaces. This document does not attempt to address any of the specific legal requirements or obligations that may exist in a particular country. This memo provides information for the Internet community.</abstract>
        <draft>baker-slem-architecture-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3925</doc-id>
        <title>Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)</title>
        <author>
            <name>J. Littlefield</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17999</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>dhc</kw>
            <kw>dhcp</kw>
            <kw>class</kw>
            <kw>vendor-specific</kw>
        </keywords>
        <abstract>The Dynamic Host Configuration Protocol (DHCP) options for Vendor Class and Vendor-Specific Information can be limiting or ambiguous when a DHCP client represents multiple vendors. This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, that contain Enterprise Numbers to remove ambiguity. [STANDARDS TRACK]</abstract>
        <draft>ietf-dhc-vendor-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3926</doc-id>
        <title>FLUTE - File Delivery over Unidirectional Transport</title>
        <author>
            <name>T. Paila</name>
        </author>
        <author>
            <name>M. Luby</name>
        </author>
        <author>
            <name>R. Lehtonen</name>
        </author>
        <author>
            <name>V. Roca</name>
        </author>
        <author>
            <name>R. Walsh</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>81224</char-count>
            <page-count>35</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This memo defines an Experimental Protocol for the Internet community.</abstract>
        <draft>ietf-rmt-flute-08</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3928</doc-id>
        <title>Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP)</title>
        <author>
            <name>R. Megginson</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Smith</name>
        </author>
        <author>
            <name>O. Natkovich</name>
        </author>
        <author>
            <name>J. Parham</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36892</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document defines the Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. [STANDARDS TRACK]</abstract>
        <draft>ietf-ldup-lcup-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3929</doc-id>
        <title>Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF</title>
        <author>
            <name>T. Hardie</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>26493</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document proposes an experimental set of alternative decision-making processes for use in IETF working groups. There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot agree on the decision itself. This document describes alternative mechanisms for reaching a decision in those cases. This is not meant to provide an exhaustive list, but to provide a known set of tools that can be used when needed. This memo defines an Experimental Protocol for the Internet community.</abstract>
        <draft>hardie-alt-consensus-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3930</doc-id>
        <title>The Protocol versus Document Points of View in Computer Protocols</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36892</char-count>
            <page-count>15</page-count>
        </format>
        <abstract>This document contrasts two points of view: the "document" point of view, where digital objects of interest are like pieces of paper written and viewed by people, and the "protocol" point of view where objects of interest are composite dynamic network messages. Although each point of view has a place, adherence to a document point of view can be damaging to protocol design. By understanding both points of view, conflicts between them may be clarified and reduced. This memo provides information for the Internet community.</abstract>
        <draft>eastlake-proto-doc-pov-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3931</doc-id>
        <title>Layer Two Tunneling Protocol - Version 3 (L2TPv3)</title>
        <author>
            <name>J. Lau</name>
            <title>Editor</title>
        </author>
        <author>
            <name>M. Townsley</name>
            <title>Editor</title>
        </author>
        <author>
            <name>I. Goyret</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>214407</char-count>
            <page-count>94</page-count>
        </format>
        <keywords>
            <kw>L2TP</kw>
            <kw>ppp</kw>
            <kw>point-to-point</kw>
            <kw>protocol</kw>
            <kw>packets</kw>
        </keywords>
        <abstract>This document describes "version 3" of the Layer Two Tunneling Protocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation for tunneling multiple Layer 2 connections between two IP nodes. Additional documents detail the specifics for each data link type being emulated. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-l2tpext-l2tp-base-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3932</doc-id>
        <title>The IESG and RFC Editor Documents: Procedures</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17093</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>independent submission</kw>
        </keywords>
        <abstract>This document describes the IESG's procedures for handling documents submitted for RFC publication via the RFC Editor, subsequent to the changes proposed by the IESG at the Seoul IETF, March 2004. &lt;br&gt; This document updates procedures described in RFC 2026 and RFC 3710. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>iesg-rfced-documents-03</draft>
        <updates>
            <doc-id>RFC3710</doc-id>
            <doc-id>RFC2026</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0092</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3933</doc-id>
        <title>A Model for IETF Process Experiments</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <author>
            <name>S. Dawkins</name>
        </author>
        <date>
            <month>November</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14409</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>The IETF has designed process changes over the last ten years in one of two ways: announcement by the IESG, sometimes based on informal agreements with limited community involvement and awareness, and formal use of the same mechanism used for protocol specification. The first mechanism has often proven to be too lightweight, the second too heavyweight. &lt;br&gt; This document specifies a middle-ground approach to the system of making changes to IETF process, one that relies heavily on a "propose and carry out an experiment, evaluate the experiment, and then establish permanent procedures based on operational experience" model rather than those previously attempted. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>klensin-process-july14-02</draft>
        <is-also>
            <doc-id>BCP0093</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3934</doc-id>
        <title>Updates to RFC 2418 Regarding the Management of IETF Mailing Lists</title>
        <author>
            <name>M. Wasserman</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>8488</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>BCP</kw>
            <kw>WG</kw>
            <kw>escape</kw>
            <kw>clause</kw>
            <kw>procedures</kw>
        </keywords>
        <abstract>This document is an update to RFC 2418 that gives WG chairs explicit responsibility for managing WG mailing lists. In particular, it gives WG chairs the authority to temporarily suspend the mailing list posting privileges of disruptive individuals. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>wasserman-rfc2418-ml-update-01</draft>
        <updates>
            <doc-id>RFC2418</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0094</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3935</doc-id>
        <title>A Mission Statement for the IETF</title>
        <author>
            <name>H. Alvestrand</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16639</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>alvestrand-ietf-mission-02</draft>
        <is-also>
            <doc-id>BCP0095</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3936</doc-id>
        <title>Procedures for Modifying the Resource reSerVation Protocol (RSVP)</title>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>J. Lang</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15314</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>resource</kw>
            <kw>reservation</kw>
            <kw>protocol</kw>
            <kw>label</kw>
            <kw>switched</kw>
            <kw>paths</kw>
        </keywords>
        <abstract>This memo specifies procedures for modifying the Resource reSerVation Protocol (RSVP). This memo also lays out new assignment guidelines for number spaces for RSVP messages, object classes, class-types, and sub-objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>kompella-rsvp-change-02</draft>
        <updates>
            <doc-id>RFC3209</doc-id>
            <doc-id>RFC2205</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0096</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3937</doc-id>
        <title>A Uniform Resource Name (URN) Namespace for the International Press Telecommunications Council (IPTC)</title>
        <author>
            <name>M. Steidl</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15458</char-count>
            <page-count>9</page-count>
        </format>
        <abstract>This document describes a URN (Uniform Resource Name) namespace for identifying persistent resources published by the International Press Telecommunications Council (IPTC). These resources include XML Data Type Definition files (DTD), XML Schema, Namespaces in XML, XSL stylesheets, other XML based document and documents of other data formats like PDF documents, Microsoft Office documents and others. This memo provides information for the Internet community.</abstract>
        <draft>steidl-iptc-urn-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3938</doc-id>
        <title>Video-Message Message-Context</title>
        <author>
            <name>T. Hansen</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>6224</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>user agent</kw>
            <kw>ua</kw>
        </keywords>
        <abstract>The Message-Context header defined in RFC 3458 describes the context of a message (for example: fax-message or voice-message). This specification extends the Message-Context header with one additional context value: "video-message". &lt;br&gt; A receiving user agent (UA) may use this information as a hint to optimally present the message. [STANDARDS TRACK]</abstract>
        <draft>hansen-lemonade-msgctxt-videomsg-01</draft>
        <updates>
            <doc-id>RFC3458</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3939</doc-id>
        <title>Calling Line Identification for Voice Mail Messages</title>
        <author>
            <name>G. Parsons</name>
        </author>
        <author>
            <name>J. Maruszak</name>
        </author>
        <date>
            <month>December</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22739</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document describes a method for identifying the originating calling party in the headers of a stored voice mail message. Two new header fields are defined for this purpose: Caller_ID and Called_Name. Caller_id is used to store sufficient information for the recipient to callback, or reply to, the sender of the message. Caller-name provides the name of the person sending the message. [STANDARDS TRACK]</abstract>
        <draft>ema-vpim-clid-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3940</doc-id>
        <title>Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol</title>
        <author>
            <name>B. Adamson</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>J. Macker</name>
        </author>
        <date>
            <month>November</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>220549</char-count>
            <page-count>80</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document describes the messages and procedures of the Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal "a priori" coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design. This memo defines an Experimental Protocol for the Internet community.</abstract>
        <draft>ietf-rmt-pi-norm-10</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3941</doc-id>
        <title>Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks</title>
        <author>
            <name>B. Adamson</name>
        </author>
        <author>
            <name>C. Bormann</name>
        </author>
        <author>
            <name>M. Handley</name>
        </author>
        <author>
            <name>J. Macker</name>
        </author>
        <date>
            <month>November</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>92785</char-count>
            <page-count>36</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document discusses the creation of negative-acknowledgment (NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM goals and assumptions are presented. Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of NORM protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This memo defines an Experimental Protocol for the Internet community.</abstract>
        <draft>ietf-rmt-bb-norm-09</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3942</doc-id>
        <title>Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options</title>
        <author>
            <name>B. Volz</name>
        </author>
        <date>
            <month>November</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13996</char-count>
        </format>
        <keywords>
            <kw>DHCP-BOOTP</kw>
            <kw>Bootstrap</kw>
        </keywords>
        <abstract>This document updates RFC 2132 to reclassify Dynamic Host Configuration Protocol version 4 (DHCPv4) option codes 128 to 223 (decimal) as publicly defined options to be managed by IANA in accordance with RFC 2939. This document directs IANA to make these option codes available for assignment as publicly defined DHCP options for future options. [STANDARDS TRACK]</abstract>
        <draft>ietf-dhc-reclassify-options-01</draft>
        <updates>
            <doc-id>RFC2132</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3943</doc-id>
        <title>Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)</title>
        <author>
            <name>R. Friend</name>
        </author>
        <date>
            <month>November</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28942</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>lossless data compression algorithm</kw>
            <kw>TLS Record Protocol</kw>
        </keywords>
        <abstract>The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and then to apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method, which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with the Lempel-Ziv-Stac (LZS) lossless data compression algorithm for use with TLS. This document also defines the application of the LZS algorithm to the TLS Record Protocol. This memo provides information for the Internet community.</abstract>
        <draft>friend-tls-lzs-compression-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3944</doc-id>
        <title>H.350 Directory Services</title>
        <author>
            <name>T. Johnson</name>
        </author>
        <author>
            <name>S. Okubo</name>
        </author>
        <author>
            <name>S. Campos</name>
        </author>
        <date>
            <month>December</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>61160</char-count>
            <page-count>30</page-count>
        </format>
        <keywords>
            <kw>ldap</kw>
            <kw>directory services</kw>
            <kw>h.350</kw>
            <kw>h.323</kw>
            <kw>h.320</kw>
            <kw>h.235</kw>
            <kw>sip</kw>
        </keywords>
        <abstract>The International Telecommunications Union Standardization Sector (ITU-T) has created the H.350 series of Recommendations that specify directory services architectures in support of multimedia conferencing protocols. The goal of the architecture is to 'directory enable' multimedia conferencing so that these services can leverage existing identity management and enterprise directories. A particular goal is to enable an enterprise or service provider to maintain a canonical source of users and their multimedia conferencing systems, so that multiple call servers from multiple vendors, supporting multiple protocols, can all access the same data store. &lt;br&gt; Because SIP is an IETF standard, the contents of H.350 and H.350.4 are made available via this document to the IETF community. This document contains the entire normative text of ITU-T Recommendations H.350 and H.350.4 in sections 4 and 5, respectively. The remaining sections are included only in this document, not in the ITU-T version. This memo provides information for the Internet community.</abstract>
        <draft>johnson-h350-directory-serv-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3945</doc-id>
        <title>Generalized Multi-Protocol Label Switching (GMPLS) Architecture</title>
        <author>
            <name>E. Mannie</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>166700</char-count>
            <page-count>69</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. &lt;br&gt; This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. [STANDARDS TRACK]</abstract>
        <draft>ietf-ccamp-gmpls-architecture-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3946</doc-id>
        <title>Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control</title>
        <author>
            <name>E. Mannie</name>
        </author>
        <author>
            <name>D. Papadimitriou</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52205</char-count>
            <page-count>26</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. [STANDARDS TRACK]</abstract>
        <draft>ietf-ccamp-gmpls-sonet-sdh-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3947</doc-id>
        <title>Negotiation of NAT-Traversal in the IKE</title>
        <author>
            <name>T. Kivinen</name>
        </author>
        <author>
            <name>B. Swander</name>
        </author>
        <author>
            <name>A. Huttunen</name>
        </author>
        <author>
            <name>V. Volpe</name>
        </author>
        <date>
            <month>January</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34759</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document describes how to detect one or more network address translation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of IPsec packets through NAT boxes in Internet Key Exchange (IKE). [STANDARDS TRACK]</abstract>
        <draft>ietf-ipsec-nat-t-ike-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3948</doc-id>
        <title>UDP Encapsulation of IPsec ESP Packets</title>
        <author>
            <name>A. Huttunen</name>
        </author>
        <author>
            <name>B. Swander</name>
        </author>
        <author>
            <name>V. Volpe</name>
        </author>
        <author>
            <name>L. DiBurro</name>
        </author>
        <author>
            <name>M. Stenberg</name>
        </author>
        <date>
            <month>January</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>30366</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for traversing Network Address Translators. ESP encapsulation, as defined in this document, can be used in both IPv4 and IPv6 scenarios. Whenever negotiated, encapsulation is used with Internet Key Exchange (IKE). [STANDARDS TRACK]</abstract>
        <draft>ietf-ipsec-udp-encaps-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3949</doc-id>
        <title>File Format for Internet Fax</title>
        <author>
            <name>R. Buckley</name>
        </author>
        <author>
            <name>D. Venable</name>
        </author>
        <author>
            <name>L. McIntyre</name>
        </author>
        <author>
            <name>G. Parsons</name>
        </author>
        <author>
            <name>J. Rafferty</name>
        </author>
        <date>
            <month>February</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>204903</char-count>
            <page-count>84</page-count>
        </format>
        <keywords>
            <kw>FFIF</kw>
            <kw>TIFF</kw>
            <kw>Tag</kw>
            <kw>Image</kw>
            <kw>facsimile</kw>
            <kw>MIME</kw>
            <kw>multipurpose</kw>
            <kw>Internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document is a revised version of RFC 2301. The revisions, summarized in the list attached as Annex B, are based on discussions and suggestions for improvements that have been made since RFC 2301 was issued in March 1998, and on the results of independent implementations and interoperability testing. &lt;br&gt; This RFC 2301 revision describes the Tag Image File Format (TIFF) representation of image data specified by the International Telecommunication Union (ITU-T) Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF for Fax eXtended (TIFF-FX). It formally defines minimal, extended, and lossless Joint Bi-level Image experts Group (JBIG) profiles (Profiles S, F, J) for black-and-white fax and base JPEG, lossless JBIG, and Mixed Raster Content profiles (Profiles C, L, M) for color and grayscale fax. These profiles correspond to the content of the applicable ITU-T Recommendations. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-fax-tiff-fx-14</draft>
        <obsoletes>
            <doc-id>RFC2301</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3950</doc-id>
        <title>Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration</title>
        <author>
            <name>L. McIntyre</name>
        </author>
        <author>
            <name>G. Parsons</name>
        </author>
        <author>
            <name>J. Rafferty</name>
        </author>
        <date>
            <month>February</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13884</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>FFIF</kw>
            <kw>TIFF</kw>
            <kw>Tag</kw>
            <kw>Image</kw>
            <kw>facsimile</kw>
            <kw>MIME</kw>
            <kw>multipurpose</kw>
            <kw>Internet</kw>
            <kw>mail</kw>
            <kw>extensions</kw>
        </keywords>
        <abstract>This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for Internet Fax and its extensions. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-fax-tiff-fx-reg-v2-01</draft>
        <obsoletes>
            <doc-id>RFC3250</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3951</doc-id>
        <title>Internet Low Bit Rate Codec (iLBC)</title>
        <author>
            <name>S. Andersen</name>
        </author>
        <author>
            <name>A. Duric</name>
        </author>
        <author>
            <name>H. Astrom</name>
        </author>
        <author>
            <name>R. Hagen</name>
        </author>
        <author>
            <name>W. Kleijn</name>
        </author>
        <author>
            <name>J. Linden</name>
        </author>
        <date>
            <month>December</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>373442</char-count>
            <page-count>194</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document specifies a speech codec suitable for robust voice communication over IP. The codec is developed by Global IP Sound (GIPS). It is designed for narrow band speech and results in a payload bit rate of 13.33 kbit/s for 30 ms frames and 15.20 kbit/s for 20 ms frames. The codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets. This memo defines an Experimental Protocol for the Internet community.</abstract>
        <draft>ietf-avt-ilbc-codec-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3952</doc-id>
        <title>Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech</title>
        <author>
            <name>A. Duric</name>
        </author>
        <author>
            <name>S. Andersen</name>
        </author>
        <date>
            <month>December</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28655</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document describes the Real-time Transport Protocol (RTP) payload format for the internet Low Bit Rate Codec (iLBC) Speech developed by Global IP Sound (GIPS). Also, within the document there are included necessary details for the use of iLBC with MIME and Session Description Protocol (SDP). This memo defines an Experimental Protocol for the Internet community.</abstract>
        <draft>ietf-avt-rtp-ilbc-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3953</doc-id>
        <title>Telephone Number Mapping (ENUM) Service Registration for Presence Services</title>
        <author>
            <name>J. Peterson</name>
        </author>
        <date>
            <month>January</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13875</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>uniform resource identifier</kw>
            <kw>uri</kw>
            <kw>provisioning pres</kw>
        </keywords>
        <abstract>This document registers a Telephone Number Mapping (ENUM) service for presence. Specifically, this document focuses on provisioning pres URIs in ENUM. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-enum-pres-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3954</doc-id>
        <title>Cisco Systems NetFlow Services Export Version 9</title>
        <author>
            <name>B. Claise</name>
            <title>Editor</title>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>76360</char-count>
            <page-count>33</page-count>
        </format>
        <abstract>This document specifies the data export format for version 9 of Cisco Systems' NetFlow services, for use by implementations on the network elements and/or matching collector programs. The version 9 export format uses templates to provide access to observations of IP packet flows in a flexible and extensible manner. A template defines a collection of fields, with corresponding descriptions of structure and semantics. This memo provides information for the Internet community.</abstract>
        <draft>claise-netflow-9-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3955</doc-id>
        <title>Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)</title>
        <author>
            <name>S. Leinen</name>
        </author>
        <date>
            <month>October</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>55143</char-count>
            <page-count>23</page-count>
        </format>
        <abstract>This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group. The protocols are characterized and grouped in broad categories, and evaluated against specific requirements. Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification. This memo provides information for the Internet community.</abstract>
        <draft>leinen-ipfix-eval-contrib-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3956</doc-id>
        <title>Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address</title>
        <author>
            <name>P. Savola</name>
        </author>
        <author>
            <name>B. Haberman</name>
        </author>
        <date>
            <month>November</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40136</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>internet protocol</kw>
        </keywords>
        <abstract>This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306. [STANDARDS TRACK]</abstract>
        <draft>ietf-mboned-embeddedrp-07</draft>
        <updates>
            <doc-id>RFC3306</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3957</doc-id>
        <title>Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4</title>
        <author>
            <name>C. Perkins</name>
        </author>
        <author>
            <name>P. Calhoun</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63576</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>Authentication, Authorization, and Accounting (AAA) servers,</abstract>
        <draft>draft-ietf-mip4-aaa-key-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3958</doc-id>
        <title>Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)</title>
        <author>
            <name>L. Daigle</name>
        </author>
        <author>
            <name>A. Newton</name>
        </author>
        <date>
            <month>January</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>54568</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port. [STANDARDS TRACK]</abstract>
        <draft>daigle-snaptr-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3959</doc-id>
        <title>The Early Session Disposition Type for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>December</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22160</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document defines a new disposition type (early-session) for the Content-Disposition header field in the Session Initiation Protocol (SIP). The treatment of "early-session" bodies is similar to the treatment of "session" bodies. That is, they follow the offer/answer model. Their only difference is that session descriptions whose disposition type is "early-session" are used to establish early media sessions within early dialogs, as opposed to regular sessions within regular dialogs. [STANDARDS TRACK]</abstract>
        <draft>ietf-sipping-early-disposition-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3960</doc-id>
        <title>Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>December</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31692</char-count>
            <page-count>13</page-count>
        </format>
        <abstract>This document describes how to manage early media in the Session Initiation Protocol (SIP) using two models: the gateway model and the application server model. It also describes the inputs one needs to consider in defining local policies for ringing tone generation. This memo provides information for the Internet community.</abstract>
        <draft>ietf-sipping-early-media-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3961</doc-id>
        <title>Encryption and Checksum Specifications for Kerberos 5</title>
        <author>
            <name>K. Raeburn</name>
        </author>
        <date>
            <month>February</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>111865</char-count>
            <page-count>50</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document describes a framework for defining encryption and checksum mechanisms for use with the Kerberos protocol, defining an abstraction layer between the Kerberos protocol and related protocols, and the actual mechanisms themselves. The document also defines several mechanisms. Some are taken from RFC 1510, modified in form to fit this new framework and occasionally modified in content when the old specification was incorrect. New mechanisms are presented here as well. This document does NOT indicate which mechanisms may be considered "required to implement". [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-krb-wg-crypto-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3962</doc-id>
        <title>Advanced Encryption Standard (AES) Encryption for Kerberos 5</title>
        <author>
            <name>K. Raeburn</name>
        </author>
        <date>
            <month>February</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32844</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>kerberos cryptosystem suite</kw>
        </keywords>
        <abstract>The United States National Institute of Standards and Technology (NIST) has chosen a new Advanced Encryption Standard (AES), which is significantly faster and (it is believed) more secure than the old Data Encryption Standard (DES) algorithm. This document is a specification for the addition of this algorithm to the Kerberos cryptosystem suite. [STANDARDS TRACK]</abstract>
        <draft>draft-raeburn-krb-rijndael-krb-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3963</doc-id>
        <title>Network Mobility (NEMO) Basic Support Protocol</title>
        <author>
            <name>V. Devarapalli</name>
        </author>
        <author>
            <name>R. Wakikawa</name>
        </author>
        <author>
            <name>A. Petrescu</name>
        </author>
        <author>
            <name>P. Thubert</name>
        </author>
        <date>
            <month>January</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>75955</char-count>
            <page-count>33</page-count>
        </format>
        <keywords>
            <kw>mobile ipv6</kw>
            <kw>session continuity</kw>
        </keywords>
        <abstract>This document describes the Network Mobility (NEMO) Basic Support protocol that enables Mobile Networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. It also allows every node in the Mobile Network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed so that network mobility is transparent to the nodes inside the Mobile Network. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-nemo-basic-support-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3964</doc-id>
        <title>Security Considerations for 6to4</title>
        <author>
            <name>P. Savola</name>
        </author>
        <author>
            <name>C. Patel</name>
        </author>
        <date>
            <month>December</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>83360</char-count>
            <page-count>41</page-count>
        </format>
        <abstract>The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from any node in the IPv4 internet. This characteristic enables a number of security threats, mainly Denial of Service. It also makes it easier for nodes to spoof IPv6 addresses. This document discusses these issues in more detail and suggests enhancements to alleviate the problems. This memo provides information for the Internet community.</abstract>
        <draft>ietf-v6ops-6to4-security-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3965</doc-id>
        <title>A Simple Mode of Facsimile Using Internet Mail</title>
        <author>
            <name>K. Toyoda</name>
        </author>
        <author>
            <name>H. Ohno</name>
        </author>
        <author>
            <name>J. Murai</name>
        </author>
        <author>
            <name>D. Wing</name>
        </author>
        <date>
            <month>December</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>28157</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
            <kw>SMFAX-IM</kw>
            <kw>data</kw>
            <kw>file</kw>
            <kw>format</kw>
            <kw>e-mail</kw>
        </keywords>
        <abstract>This specification provides for "simple mode" carriage of facsimile data using Internet mail. Extensions to this document will follow. The current specification employs standard protocols and file formats such as TCP/IP, Internet mail protocols, Multipurpose Internet Mail Extensions (MIME), and Tagged Image File Format (TIFF) for Facsimile. It can send images not only to other Internet-aware facsimile devices but also to Internet-native systems, such as PCs with common email readers which can handle MIME mail and TIFF for Facsimile data. The specification facilitates communication among existing facsimile devices, Internet mail agents, and the gateways which connect them. &lt;br&gt; This document is a revision of RFC 2305. There have been no technical changes. [DRAFT STANDARD]</abstract>
        <draft>ietf-fax-service-v2-05</draft>
        <obsoletes>
            <doc-id>RFC2305</doc-id>
        </obsoletes>
        <current-status>DRAFT STANDARD</current-status>
        <publication-status>DRAFT STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3966</doc-id>
        <title>The tel URI for Telephone Numbers</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>December</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>40783</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>locator</kw>
            <kw>schemes</kw>
        </keywords>
        <abstract>This document specifies the URI (Uniform Resource Identifier) scheme "tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806. [STANDARDS TRACK]</abstract>
        <draft>ietf-iptel-rfc2806bis-09</draft>
        <obsoletes>
            <doc-id>RFC2806</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3967</doc-id>
        <title>Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level</title>
        <author>
            <name>R. Bush</name>
        </author>
        <author>
            <name>T. Narten</name>
        </author>
        <date>
            <month>December</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12251</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies). For example, a standards track document may not have a normative reference to an informational RFC. Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards or IETF-specific modes of use of such standards. This document clarifies and updates the procedure used in these circumstances. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>ymbk-downref-03</draft>
        <is-also>
            <doc-id>BCP0097</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3968</doc-id>
        <title>The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>December</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20615</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) header field parameters and parameter values. It also lists the already existing parameters and parameter values to be used as the initial entries for this registry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>ietf-sip-parameter-registry-02</draft>
        <updates>
            <doc-id>RFC3427</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0098</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3969</doc-id>
        <title>The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <date>
            <month>December</month>
            <year>2004</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12119</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) and SIPS Uniform Resource Identifier (URI) parameters, and their values. It also lists the already existing parameters to be used as initial values for that registry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>ietf-sip-uri-parameter-reg-02</draft>
        <updates>
            <doc-id>RFC3427</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0099</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3970</doc-id>
        <title>A Traffic Engineering (TE) MIB</title>
        <author>
            <name>K. Kompella</name>
        </author>
        <date>
            <month>January</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>88833</char-count>
            <page-count>44</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Traffic Engineered (TE) Tunnels; for example, Multi-Protocol Label Switched Paths. [STANDARDS TRACK]</abstract>
        <draft>ietf-tewg-mib-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3971</doc-id>
        <title>SEcure Neighbor Discovery (SEND)</title>
        <author>
            <name>J. Arkko</name>
            <title>Editor</title>
        </author>
        <author>
            <name>J. Kempf</name>
        </author>
        <author>
            <name>B. Zill</name>
        </author>
        <author>
            <name>P. Nikander</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>123372</char-count>
            <page-count>56</page-count>
        </format>
        <keywords>
            <kw>Neighbor Discovery Protocol</kw>
            <kw>NDP</kw>
        </keywords>
        <abstract>IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-send-ndopt-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3972</doc-id>
        <title>Cryptographically Generated Addresses (CGA)</title>
        <author>
            <name>T. Aura</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>51473</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>Secure Neighbor Discovery</kw>
            <kw>SEND</kw>
        </keywords>
        <abstract>This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-send-cga-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3973</doc-id>
        <title>Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)</title>
        <author>
            <name>A. Adams</name>
        </author>
        <author>
            <name>J. Nicholas</name>
        </author>
        <author>
            <name>W. Siadak</name>
        </author>
        <date>
            <month>January</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>136708</char-count>
            <page-count>61</page-count>
        </format>
        <keywords>
            <kw>multicast routing protocol</kw>
            <kw>prune messages</kw>
        </keywords>
        <abstract>This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers without group membership information. This memo defines an Experimental Protocol for the Internet community.</abstract>
        <draft>draft-ietf-pim-dm-new-v2-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3974</doc-id>
        <title>SMTP Operational Experience in Mixed IPv4/v6 Environments</title>
        <author>
            <name>M. Nakamura</name>
        </author>
        <author>
            <name>J. Hagino</name>
        </author>
        <date>
            <month>January</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22729</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>simple mail transfer protocol</kw>
            <kw>dual stack</kw>
            <kw>dualstack</kw>
            <kw>ipv4</kw>
            <kw>ipv6</kw>
        </keywords>
        <abstract>This document discusses SMTP operational experiences in IPv4/v6 dual stack environments. As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations of MX records are necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. This document clarifies the existing problems in the transition period between IPv4 SMTP and IPv6 SMTP. It also defines operational requirements for stable IPv4/v6 SMTP operation. &lt;br&gt; This document does not define any new protocol. This memo provides information for the Internet community.</abstract>
        <draft>draft-motonori-dualstack-smtp-requirement-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3975</doc-id>
        <title>OMA-IETF Standardization Collaboration</title>
        <author>
            <name>G. Huston</name>
            <title>Editor</title>
        </author>
        <author>
            <name>I. Leuca</name>
            <title>Editor</title>
        </author>
        <date>
            <month>January</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>16926</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>oopen mobile alliance</kw>
            <kw>ietf</kw>
            <kw>internet engineering task force</kw>
        </keywords>
        <abstract>This document describes the standardization collaboration between the Open Mobile Alliance (OMA) and the Internet Engineering Task Force (IETF). This memo provides information for the Internet community.</abstract>
        <draft>draft-iab-oma-liaison-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3976</doc-id>
        <title>Interworking SIP and Intelligent Network (IN) Applications</title>
        <author>
            <name>V. K. Gurbani</name>
        </author>
        <author>
            <name>F. Haerens</name>
        </author>
        <author>
            <name>V. Rastogi</name>
        </author>
        <date>
            <month>January</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>60191</char-count>
            <page-count>25</page-count>
        </format>
        <keywords>
            <kw>sip</kw>
            <kw>intelligent network</kw>
            <kw>call models</kw>
            <kw>call model mapping</kw>
            <kw>telephony services</kw>
            <kw>public switched telephone network</kw>
            <kw>pstn</kw>
        </keywords>
        <abstract>Public Switched Telephone Network (PSTN) services such as 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network (IN). This document addresses means to support existing IN services from Session Initiation Protocol (SIP) endpoints for an IP-host-to-phone call. The call request is originated on a SIP endpoint, but the services to the call are provided by the data and procedures resident in the PSTN/IN. To provide IN services in a transparent manner to SIP endpoints, this document describes the mechanism for interworking SIP and Intelligent Network Application Part (INAP). This memo provides information for the Internet community.</abstract>
        <draft>draft-gurbani-sin-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3978</doc-id>
        <title>IETF Rights in Contributions</title>
        <author>
            <name>S. Bradner</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>43574</char-count>
            <page-count>18</page-count>
        </format>
        <keywords>
            <kw>intellectual property rights</kw>
            <kw>copyright</kw>
            <kw>ipr</kw>
        </keywords>
        <abstract>The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3979, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>draft-ietf-ipr-subm-rights-fix-00</draft>
        <obsoletes>
            <doc-id>RFC3667</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2026</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0078</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3979</doc-id>
        <title>Intellectual Property Rights in IETF Technology</title>
        <author>
            <name>S. Bradner</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>41366</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>ipr</kw>
            <kw>copyright</kw>
        </keywords>
        <abstract>The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and, with RFC 3978, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <notes>there was no internet-draft for this document; iesg requested a republication of rfc3668 with a few corrections.</notes>
        <obsoletes>
            <doc-id>RFC3668</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC2028</doc-id>
            <doc-id>RFC2026</doc-id>
        </updates>
        <is-also>
            <doc-id>BCP0079</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3980</doc-id>
        <title>T11 Network Address Authority (NAA) Naming Format for iSCSI Node Names</title>
        <author>
            <name>M. Krueger</name>
        </author>
        <author>
            <name>M. Chadalapaka</name>
        </author>
        <author>
            <name>R. Elliott</name>
        </author>
        <date>
            <month>February</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>14056</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>internet small computer systems interface</kw>
            <kw>scsi transport protocol</kw>
        </keywords>
        <abstract>Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. This document defines an additional iSCSI node name type format to enable use of the "Network Address Authority" (NAA) worldwide naming format defined by the InterNational Committee for Information Technology Standards (INCITS) T11 - Fibre Channel (FC) protocols and used by Serial Attached SCSI (SAS). This document updates RFC 3720. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-ips-iscsi-name-ext-05</draft>
        <updates>
            <doc-id>RFC3720</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3981</doc-id>
        <title>IRIS: The Internet Registry Information Service (IRIS) Core Protocol</title>
        <author>
            <name>A. Newton</name>
        </author>
        <author>
            <name>M. Sanz</name>
        </author>
        <date>
            <month>January</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>101359</char-count>
            <page-count>52</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document describes an application layer client-server protocol for a framework to represent the query and result operations of the information services of Internet registries. Specified in the Extensible Markup Language (XML), the protocol defines generic query and result operations and a mechanism for extending these operations for specific registry service needs. [STANDARDS TRACK]</abstract>
        <draft>ietf-crisp-iris-core-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3982</doc-id>
        <title>IRIS:  A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS)</title>
        <author>
            <name>A. Newton</name>
        </author>
        <author>
            <name>M. Sanz</name>
        </author>
        <date>
            <month>January</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>90901</char-count>
            <page-count>50</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document describes an Internet Registry Information Service (IRIS) registry schema for registered DNS information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by domain registries and registrars. [STANDARDS TRACK]</abstract>
        <draft>ietf-crisp-iris-dreg-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3983</doc-id>
        <title>Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)</title>
        <author>
            <name>A. Newton</name>
        </author>
        <author>
            <name>M. Sanz</name>
        </author>
        <date>
            <month>January</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23466</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document specifies how to use the Blocks Extensible Exchange Protocol (BEEP) as the application transport substrate for the Internet Registry Information Service (IRIS). [STANDARDS TRACK]</abstract>
        <draft>ietf-crisp-iris-beep-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3984</doc-id>
        <title>RTP Payload Format for H.264 Video</title>
        <author>
            <name>S. Wenger</name>
        </author>
        <author>
            <name>M.M. Hannuksela</name>
        </author>
        <author>
            <name>T. Stockhammer</name>
        </author>
        <author>
            <name>M. Westerlund</name>
        </author>
        <author>
            <name>D. Singer</name>
        </author>
        <date>
            <month>February</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>205093</char-count>
            <page-count>83</page-count>
        </format>
        <keywords>
            <kw>ITU-T Recommendation H.264</kw>
            <kw>ISO/IEC International Standard 14496-10</kw>
        </keywords>
        <abstract>This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, to Internet video streaming with interleaved transmission, to high bit-rate video-on-demand. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-avt-rtp-h264-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3985</doc-id>
        <title>Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture</title>
        <author>
            <name>S. Bryant</name>
            <title>Editor</title>
        </author>
        <author>
            <name>P. Pate</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>95062</char-count>
            <page-count>42</page-count>
        </format>
        <abstract>This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It discusses the emulation of services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions. This memo provides information for the Internet community.</abstract>
        <draft>draft-ietf-pwe3-arch-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3986</doc-id>
        <title>Uniform Resource Identifier (URI): Generic Syntax</title>
        <author>
            <name>T. Berners-Lee</name>
        </author>
        <author>
            <name>R. Fielding</name>
        </author>
        <author>
            <name>L. Masinter</name>
        </author>
        <date>
            <month>January</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>141811</char-count>
            <page-count>61</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>protocol</kw>
            <kw>uniform</kw>
            <kw>resource</kw>
            <kw>identifier</kw>
            <kw>www</kw>
            <kw>world wide web</kw>
        </keywords>
        <abstract>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS TRACK]</abstract>
        <draft>draft-fielding-uri-rfc2396bis-07</draft>
        <obsoletes>
            <doc-id>RFC2732</doc-id>
            <doc-id>RFC2396</doc-id>
            <doc-id>RFC1808</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC1738</doc-id>
        </updates>
        <is-also>
            <doc-id>STD0066</doc-id>
        </is-also>
        <current-status>STANDARD</current-status>
        <publication-status>STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3987</doc-id>
        <title>Internationalized Resource Identifiers (IRIs)</title>
        <author>
            <name>M. Duerst</name>
        </author>
        <author>
            <name>M. Suignard</name>
        </author>
        <date>
            <month>January</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>111190</char-count>
            <page-count>46</page-count>
        </format>
        <keywords>
            <kw>uri</kw>
            <kw>uniform resource identifier</kw>
            <kw>Universal Character Set</kw>
        </keywords>
        <abstract>This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement to the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources. &lt;br&gt; The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs. [STANDARDS TRACK]</abstract>
        <draft>draft-duerst-iri-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3988</doc-id>
        <title>Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol</title>
        <author>
            <name>B. Black</name>
        </author>
        <author>
            <name>K. Kompella</name>
        </author>
        <date>
            <month>January</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18841</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>mtu</kw>
            <kw>ldp</kw>
            <kw>lsp</kw>
            <kw>label switched path</kw>
            <kw>label switching router</kw>
            <kw>lsr</kw>
        </keywords>
        <abstract>Proper functioning of RFC 1191 path Maximum Transmission Unit (MTU) discovery requires that IP routers have knowledge of the MTU for each link to which they are connected. As currently specified, the Label Distribution Protocol (LDP) does not have the ability to signal the MTU for a Label Switched Path (LSP) to the ingress Label Switching Router (LSR). In the absence of this functionality, the MTU for each LSP must be statically configured by network operators or by equivalent off-line mechanisms. &lt;br&gt; This document specifies experimental extensions to LDP in support of LSP MTU discovery. This memo defines an Experimental Protocol for the Internet community.</abstract>
        <draft>draft-ietf-mpls-ldp-mtu-extensions-03</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3989</doc-id>
        <title>Middlebox Communications (MIDCOM) Protocol Semantics</title>
        <author>
            <name>M. Stiemerling</name>
        </author>
        <author>
            <name>J. Quittek</name>
        </author>
        <author>
            <name>T. Taylor</name>
        </author>
        <date>
            <month>February</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>160606</char-count>
            <page-count>70</page-count>
        </format>
        <keywords>
            <kw>nat</kw>
            <kw>network address translator</kw>
            <kw>firewall</kw>
        </keywords>
        <abstract>This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs). The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. This memo provides information for the Internet community.</abstract>
        <draft>draft-ietf-midcom-semantics-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3990</doc-id>
        <title>Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement</title>
        <author>
            <name>B. O'Hara</name>
        </author>
        <author>
            <name>P. Calhoun</name>
        </author>
        <author>
            <name>J. Kempf</name>
        </author>
        <date>
            <month>February</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11854</char-count>
            <page-count>5</page-count>
        </format>
        <abstract>This document describes the Configuration and Provisioning for Wireless Access Points (CAPWAP) problem statement. This memo provides information for the Internet community.</abstract>
        <draft>draft-ietf-capwap-problem-statement-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3991</doc-id>
        <title>Media Gateway Control Protocol (MGCP) Redirect and Reset Package</title>
        <author>
            <name>B. Foster</name>
        </author>
        <author>
            <name>F. Andreasen</name>
        </author>
        <date>
            <month>February</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22951</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>voice</kw>
            <kw>IP</kw>
            <kw>internet</kw>
            <kw>VoIP</kw>
        </keywords>
        <abstract>The base Media Gateway Control Protocol (MGCP) specification (RFC 3435) allows endpoints to be redirected one endpoint at a time. This document provides extensions in the form of a new MGCP package that provides mechanisms for redirecting and resetting a group of endpoints. It also includes the ability to more accurately redirect endpoints by allowing a list of Call Agents to be specified in a preferred order. This memo provides information for the Internet community.</abstract>
        <draft>draft-foster-mgcp-redirect-05</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3992</doc-id>
        <title>Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism</title>
        <author>
            <name>B. Foster</name>
        </author>
        <author>
            <name>F. Andreasen</name>
        </author>
        <date>
            <month>February</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>9718</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>fault recovery</kw>
        </keywords>
        <abstract>A Media Gateway Control Protocol (MGCP) endpoint that has encountered an adverse failure condition (such as being involved in a transient call when a Call Agent failover occurred) could be left in a lockstep state whereby events are quarantined but not notified. The MGCP package described in this document provides a mechanism for reporting these situations so that the new Call Agent can take the necessary fault recovery procedures. This memo provides information for the Internet community.</abstract>
        <draft>draft-foster-mgcp-lockstep-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3993</doc-id>
        <title>Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option</title>
        <author>
            <name>R. Johnson</name>
        </author>
        <author>
            <name>T. Palaniappan</name>
        </author>
        <author>
            <name>M. Stapp</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13938</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This memo defines a new Subscriber-ID suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to associate a stable "Subscriber-ID" with DHCP client messages in a way that is independent of the client and of the underlying physical network infrastructure. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-dhc-subscriber-id-07</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3994</doc-id>
        <title>Indication of Message Composition for Instant Messaging</title>
        <author>
            <name>H. Schulzrinne</name>
        </author>
        <date>
            <month>January</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>27472</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>im</kw>
            <kw>status message content type</kw>
            <kw>xml</kw>
            <kw>extensible markup language</kw>
        </keywords>
        <abstract>In instant messaging (IM) systems, it is useful to know during an IM conversation whether the other party is composing a message; e.g., typing or recording an audio message. This document defines a new status message content type and XML namespace that conveys information about a message being composed. The status message can indicate the composition of a message of any type, including text, voice, or video. The status messages are delivered to the instant messaging recipient in the same manner as the instant messages themselves. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-simple-iscomposing-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3995</doc-id>
        <title>Internet Printing Protocol (IPP): Event Notifications and Subscriptions</title>
        <author>
            <name>R. Herriot</name>
        </author>
        <author>
            <name>T. Hastings</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>223294</char-count>
            <page-count>95</page-count>
        </format>
        <keywords>
            <kw>optional</kw>
            <kw>subscription events</kw>
            <kw>subscription objects</kw>
            <kw>asynchronous even notification</kw>
        </keywords>
        <abstract>This document describes an OPTIONAL extension to the Internet Printing Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910). This extension allows a client to subscribe to printing related Events. Subscriptions are modeled as Subscription Objects. The Subscription Object specifies that when one of the specified Events occurs, the Printer delivers an asynchronous Event Notification to the specified Notification Recipient via the specified Push or Pull Delivery Method (i.e., protocol). &lt;br&gt; A client associates Subscription Objects with a particular Job by performing the Create-Job-Subscriptions operation or by submitting a Job with subscription information. A client associates Subscription Objects with the Printer by performing a Create-Printer-Subscriptions operation. Four other operations are defined for Subscription Objects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew-Subscription, and Cancel-Subscription. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-ipp-not-spec-12</draft>
        <updates>
            <doc-id>RFC2911</doc-id>
            <doc-id>RFC2910</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3996</doc-id>
        <title>Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications</title>
        <author>
            <name>R. Herriot</name>
        </author>
        <author>
            <name>T. Hastings</name>
        </author>
        <author>
            <name>H. Lewis</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>73638</char-count>
            <page-count>31</page-count>
        </format>
        <keywords>
            <kw>pull delivery method</kw>
            <kw>event notifications</kw>
            <kw>event subscriptions</kw>
        </keywords>
        <abstract>This document describes an extension to the Internet Printing Protocol1.1: Model and Semantics (RFC 2911, RFC 2910). This document specifies the 'ippget' Pull Delivery Method for use with the "Internet Printing Protocol (IPP): Event Notifications and Subscriptions" specification (RFC 3995). This IPPGET Delivery Method is REQUIRED for all clients and Printers that support RFC 3995. The Notification Recipient, acting as a client, fetches (pulls) Event Notifications by using the Get-Notifications operation defined in this document. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-ipp-notify-get-10</draft>
        <updates>
            <doc-id>RFC2911</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3997</doc-id>
        <title>Internet Printing Protocol (IPP): Requirements for IPP Notifications</title>
        <author>
            <name>T. Hastings</name>
            <title>Editor</title>
        </author>
        <author>
            <name>R. K. deBry</name>
        </author>
        <author>
            <name>H. Lewis</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38185</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>model</kw>
            <kw>directory services</kw>
            <kw>notification requirements</kw>
        </keywords>
        <abstract>This document is one of a set of documents that together describe all aspects of the Internet Printing Protocol (IPP). IPP is an application-level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol, and an interface to Directory Services. This document provides a statement of the requirements for notifications as an optional part of an IPP Service. This memo provides information for the Internet community.</abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC3998</doc-id>
        <title>Internet Printing Protocol (IPP): Job and Printer Administrative Operations</title>
        <author>
            <name>C. Kugler</name>
        </author>
        <author>
            <name>H. Lewis</name>
        </author>
        <author>
            <name>T. Hastings</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>109658</char-count>
            <page-count>46</page-count>
        </format>
        <keywords>
            <kw>system administration operations</kw>
            <kw>Enable-Printer and Disable-Printer</kw>
            <kw>Pause-Printer-After-Current-Job</kw>
            <kw>Hold-New-Jobs and Release-Held-New-Jobs</kw>
            <kw>Deactivate-Printer and Activate-Printer</kw>
            <kw>Restart-Printer</kw>
            <kw>Shutdown-Printer and Startup-Printer</kw>
            <kw>Reprocess-Job</kw>
            <kw>Cancel-Current-Job</kw>
            <kw>Suspend-Current-Job</kw>
            <kw>Resume-Job</kw>
            <kw>Promote-Job</kw>
            <kw>Schedule-Job-After</kw>
        </keywords>
        <abstract>This document specifies the following 16 additional OPTIONAL system administration operations for use with the Internet Printing Protocol/1.1 (IPP), plus a few associated attributes, values, and status codes, and using the IPP Printer object to manage printer fan-out and fan-in. (Printer operations: Enable-Printer and Disable-Printer, Pause-Printer-After-Current-Job, Hold-New-Jobs and Release-Held-New-Jobs, Deactivate-Printer and Activate-Printer, Restart-Printer, Shutdown-Printer and Startup-Printer. Job operations: Reprocess-Job, Cancel-Current-Job, Suspend-Current-Job, Resume-Job, Promote-Job, Schedule-Job-After.) [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-ipp-ops-set2-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4001</doc-id>
        <title>Textual Conventions for Internet Network Addresses</title>
        <author>
            <name>M. Daniele</name>
        </author>
        <author>
            <name>B. Haberman</name>
        </author>
        <author>
            <name>S. Routhier</name>
        </author>
        <author>
            <name>J. Schoenwaelder</name>
        </author>
        <date>
            <month>February</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>45836</char-count>
            <page-count>22</page-count>
        </format>
        <keywords>
            <kw>MIB</kw>
            <kw>management information base</kw>
            <kw>internet network layer addressing information</kw>
        </keywords>
        <abstract>This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-ops-rfc3291bis-06</draft>
        <obsoletes>
            <doc-id>RFC3291</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4002</doc-id>
        <title>IANA Registration for Enumservice 'web' and 'ft'</title>
        <author>
            <name>R. Brandner</name>
        </author>
        <author>
            <name>L. Conroy</name>
        </author>
        <author>
            <name>R. Stastny</name>
        </author>
        <date>
            <month>February</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18072</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>URI schemes</kw>
            <kw>uniform resource identifier</kw>
            <kw>enum</kw>
        </keywords>
        <abstract>This document registers the Enumservices 'web' and 'ft' by using the URI schemes 'http:', 'https:' and 'ftp:' as per the IANA registration process defined in the ENUM specification (RFC 3761). [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-enum-webft-01</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4003</doc-id>
        <title>GMPLS Signaling Procedure for Egress Control</title>
        <author>
            <name>L. Berger</name>
        </author>
        <date>
            <month>February</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>10306</char-count>
            <page-count>5</page-count>
        </format>
        <keywords>
            <kw>lsp</kw>
            <kw>label switch path</kw>
            <kw>gmpls signaling</kw>
        </keywords>
        <abstract>This document clarifies the procedures for the control of the label used on an output/downstream interface of the egress node of a Label Switched Path (LSP). This control is also known as "Egress Control". Support for Egress Control is implicit in Generalized Multi-Protocol Label Switching (GMPLS) Signaling. This document clarifies the specification of GMPLS Signaling and does not modify GMPLS signaling mechanisms and procedures. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-enum-webft-01</draft>
        <updates>
            <doc-id>RFC3473</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4007</doc-id>
        <title>IPv6 Scoped Address Architecture</title>
        <author>
            <name>S. Deering</name>
        </author>
        <author>
            <name>B. Haberman</name>
        </author>
        <author>
            <name>T. Jinmei</name>
        </author>
        <author>
            <name>E. Nordmark</name>
        </author>
        <author>
            <name>B. Zill</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53555</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>architectural characteristics</kw>
            <kw>expected behavior</kw>
            <kw>textual representation</kw>
        </keywords>
        <abstract>This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-ipv6-scoping-arch-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4008</doc-id>
        <title>Definitions of Managed Objects for Network Address Translators (NAT)</title>
        <author>
            <name>R. Rohit</name>
        </author>
        <author>
            <name>P. Srisuresh</name>
        </author>
        <author>
            <name>R. Raghunarayan</name>
        </author>
        <author>
            <name>N. Pai</name>
        </author>
        <author>
            <name>C. Wang</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>125696</char-count>
            <page-count>64</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for configuration as well as monitoring of a device capable of NAT function. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-nat-natmib-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4009</doc-id>
        <title>The SEED Encryption Algorithm</title>
        <author>
            <name>J. Park</name>
        </author>
        <author>
            <name>S. Lee</name>
        </author>
        <author>
            <name>J. Kim</name>
        </author>
        <author>
            <name>J. Lee</name>
        </author>
        <date>
            <month>February</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32552</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>encryption algorithm</kw>
            <kw>seed cbc</kw>
            <kw>seed oid</kw>
        </keywords>
        <abstract>This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea. Included are a description of the cipher and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B). This memo provides information for the Internet community.</abstract>
        <draft>draft-park-seed-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4010</doc-id>
        <title>Use of the SEED Encryption Algorithm in Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>J. Park</name>
        </author>
        <author>
            <name>S. Lee</name>
        </author>
        <author>
            <name>J. Kim</name>
        </author>
        <author>
            <name>J. Lee</name>
        </author>
        <date>
            <month>February</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22403</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>smime</kw>
            <kw>secure/multipurpose internet mail extensions</kw>
        </keywords>
        <abstract>This document specifies the conventions for using the SEED encryption algorithm for encryption with the Cryptographic Message Syntax (CMS). &lt;br&gt; SEED is added to the set of optional symmetric encryption algorithms in CMS by providing two classes of unique object identifiers (OIDs). One OID class defines the content encryption algorithms and the other defines the key encryption algorithms. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-smime-cms-seed-02</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4011</doc-id>
        <title>Policy Based Management MIB</title>
        <author>
            <name>S. Waldbusser</name>
        </author>
        <author>
            <name>J. Saperia</name>
        </author>
        <author>
            <name>T. Hongal</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>265942</char-count>
            <page-count>121</page-count>
        </format>
        <keywords>
            <kw>management information base</kw>
            <kw>Simple Network Management Protocol</kw>
            <kw>snmp</kw>
            <kw>infrastructures</kw>
            <kw>scripting language</kw>
            <kw>script execution environment</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this MIB defines objects that enable policy-based monitoring and management of Simple Network Management Protocol (SNMP) infrastructures, a scripting language, and a script execution environment. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-snmpconf-pm-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4012</doc-id>
        <title>Routing Policy Specification Language next generation (RPSLng)</title>
        <author>
            <name>L. Blunk</name>
        </author>
        <author>
            <name>J. Damas</name>
        </author>
        <author>
            <name>F. Parent</name>
        </author>
        <author>
            <name>A. Robachevsky</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35217</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This memo introduces a new set of simple extensions to the Routing Policy Specification Language (RPSL), enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. [STANDARDS TRACK]</abstract>
        <draft>draft-blunk-rpslng-08</draft>
        <updates>
            <doc-id>RFC2725</doc-id>
            <doc-id>RFC2622</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4013</doc-id>
        <title>SASLprep: Stringprep Profile for User Names and Passwords</title>
        <author>
            <name>K. Zeilenga</name>
        </author>
        <date>
            <month>February</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13051</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>unicode strings</kw>
            <kw>saslprep</kw>
            <kw>stringprep</kw>
            <kw>sasl</kw>
            <kw>simple authentication and security layer</kw>
        </keywords>
        <abstract>This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the "SASLprep" profile of the "stringprep" algorithm to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5), as well as other protocols exchanging simple user names and/or passwords. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-sasl-saslprep-10</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4014</doc-id>
        <title>Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option</title>
        <author>
            <name>R. Droms</name>
        </author>
        <author>
            <name>J. Schnizlein</name>
        </author>
        <date>
            <month>February</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15416</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>The RADIUS Attributes suboption enables a network element to pass identification and authorization attributes received during RADIUS authentication to a DHCP server. When the DHCP server receives a message from a relay agent containing a RADIUS Attributes suboption, it extracts the contents of the suboption and uses that information in selecting configuration parameters for the client. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-dhc-agentopt-radius-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4015</doc-id>
        <title>The Eifel Response Algorithm for TCP</title>
        <author>
            <name>R. Ludwig</name>
        </author>
        <author>
            <name>A. Gurtov</name>
        </author>
        <date>
            <month>February</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31512</char-count>
            <page-count>13</page-count>
        </format>
        <keywords>
            <kw>transmision control protocol</kw>
        </keywords>
        <abstract>Based on an appropriate detection algorithm, the Eifel response algorithm provides a way for a TCP sender to respond to a detected spurious timeout. It adapts the retransmission timer to avoid further spurious timeouts and (depending on the detection algorithm) can avoid the often unnecessary go-back-N retransmits that would otherwise be sent. In addition, the Eifel response algorithm restores the congestion control state in such a way that packet bursts are avoided. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-tsvwg-tcp-eifel-response-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4016</doc-id>
        <title>Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements</title>
        <author>
            <name>M. Parthasarathy</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>36104</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
            <kw>authentication</kw>
            <kw>network access</kw>
        </keywords>
        <abstract>This document discusses the threats to protocols used to carry authentication for network access. The security requirements arising from these threats will be used as additional input to the Protocol for Carrying Authentication for Network Access (PANA) Working Group for designing the IP based network access authentication protocol. This memo provides information for the Internet community.</abstract>
        <draft>draft-ietf-pana-threats-eval-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4017</doc-id>
        <title>Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs</title>
        <author>
            <name>D. Stanley</name>
        </author>
        <author>
            <name>J. Walker</name>
        </author>
        <author>
            <name>B. Aboba</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22183</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>IEEE 802.11</kw>
            <kw>wireless lan</kw>
        </keywords>
        <abstract>The IEEE 802.11i MAC Security Enhancements Amendment makes use of IEEE 802.1X, which in turn relies on the Extensible Authentication Protocol (EAP). This document defines requirements for EAP methods used in IEEE 802.11 wireless LAN deployments. The material in this document has been approved by IEEE 802.11 and is being presented as an IETF RFC for informational purposes. This memo provides information for the Internet community.</abstract>
        <draft>draft-walker-ieee802-req-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4018</doc-id>
        <title>Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2)</title>
        <author>
            <name>M. Bakke</name>
        </author>
        <author>
            <name>J. Hufferd</name>
        </author>
        <author>
            <name>K. Voruganti</name>
        </author>
        <author>
            <name>M. Krueger</name>
        </author>
        <author>
            <name>T. Sperry</name>
        </author>
        <date>
            <month>April</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48498</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>scsi</kw>
            <kw>slp</kw>
        </keywords>
        <abstract>The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the Service Location Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide. [PROPOSED STANDARD]</abstract>
        <draft>draft-ietf-ips-iscsi-slp-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4019</doc-id>
        <title>RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite</title>
        <author>
            <name>G. Pelletier</name>
        </author>
        <date>
            <month>April</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>46896</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>rtp</kw>
            <kw>udp-lite</kw>
            <kw>ip</kw>
            <kw>real-time transport protocol</kw>
            <kw>user datagram protocol lite</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract>This document defines Robust Header Compression (ROHC) profiles for compression of Real-Time Transport Protocol, User Datagram Protocol-Lite, and Internet Protocol (RTP/UDP-Lite/IP) packets and UDP-Lite/IP. These profiles are defined based on their differences with the profiles for UDP as specified in RFC 3095. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-rohc-udp-lite-04</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4020</doc-id>
        <title>Early IANA Allocation of Standards Track Code Points</title>
        <author>
            <name>K. Kompella</name>
        </author>
        <author>
            <name>A. Zinin</name>
        </author>
        <date>
            <month>February</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>13706</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This memo discusses earlier allocation of code points by IANA as a remedy to the problem created by the "Standards Action" IANA policy for protocols for which, by the IETF process, implementation and deployment experience is desired or required prior to publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>draft-kompella-zinin-early-allocation-02</draft>
        <is-also>
            <doc-id>BCP0100</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4021</doc-id>
        <title>Registration of Mail and MIME Header Fields</title>
        <author>
            <name>G. Klyne</name>
        </author>
        <author>
            <name>J. Palme</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>75452</char-count>
            <page-count>54</page-count>
        </format>
        <abstract>This document defines the initial IANA registration for permanent mail and MIME message header fields, per RFC 3864. [STANDARDS TRACK]</abstract>
        <draft>draft-klyne-hdrreg-mail-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4022</doc-id>
        <title>Management Information Base for the Transmission Control Protocol (TCP)</title>
        <author>
            <name>R. Raghunarayan</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>47360</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>MIB-TCP</kw>
            <kw>TCP</kw>
            <kw>Simple Network Management Protocol</kw>
            <kw>MIB</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Transmission Control Protocol (TCP) in an IP version independent manner. This memo obsoletes RFCs 2452 and 2012. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-ipv6-rfc2012-update-06</draft>
        <obsoletes>
            <doc-id>RFC2452</doc-id>
            <doc-id>RFC2012</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4023</doc-id>
        <title>Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)</title>
        <author>
            <name>T. Worster</name>
        </author>
        <author>
            <name>Y. Rekhter</name>
        </author>
        <author>
            <name>E. Rosen</name>
            <title>Editor</title>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>31696</char-count>
            <page-count>14</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>Various applications of MPLS make use of label stacks with multiple entries. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks that do not have MPLS enabled in their core routers. This document specifies two IP-based encapsulations: MPLS-in-IP and MPLS-in-GRE (Generic Routing Encapsulation). Each of these is applicable in some circumstances. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-mpls-in-ip-or-gre-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4025</doc-id>
        <title>A Method for Storing IPsec Keying Material in DNS</title>
        <author>
            <name>M. Richardson</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>25408</char-count>
            <page-count>12</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document describes a new resource record for the Domain Name System (DNS). This record may be used to store public keys for use in IP security (IPsec) systems. The record also includes provisions for indicating what system should be contacted when an IPsec tunnel is established with the entity in question. &lt;br&gt; This record replaces the functionality of the sub-type #4 of the KEY Resource Record, which has been obsoleted by RFC 3445. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-ipseckey-rr-11</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4026</doc-id>
        <title>Provider Provisioned Virtual Private Network (VPN) Terminology</title>
        <author>
            <name>L. Andersson</name>
        </author>
        <author>
            <name>T. Madsen</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>42124</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>l3vpn</kw>
            <kw>l2vpn</kw>
        </keywords>
        <abstract>The widespread interest in provider-provisioned Virtual Private Network (VPN) solutions lead to memos proposing different and overlapping solutions. The IETF working groups (first Provider Provisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have discussed these proposals and documented specifications. This has lead to the development of a partially new set of concepts used to describe the set of VPN services. &lt;br&gt; To a certain extent, more than one term covers the same concept, and sometimes the same term covers more than one concept. This document seeks to make the terminology in the area clearer and more intuitive. This memo provides information for the Internet community.</abstract>
        <draft>draft-ietf-l3vpn-ppvpn-terminology-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4027</doc-id>
        <title>Domain Name System Media Types</title>
        <author>
            <name>S. Josefsson</name>
        </author>
        <date>
            <month>April</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>11676</char-count>
            <page-count>6</page-count>
        </format>
        <keywords>
            <kw>media type</kw>
            <kw>application/dns</kw>
            <kw>text/dns</kw>
        </keywords>
        <abstract>This document registers the media types application/dns and text/dns in accordance with RFC 2048. The application/dns media type is used to identify data on the detached Domain Name System (DNS) format described in RFC 2540. The text/dns media type is used to identify master files as described in RFC 1035. This memo provides information for the Internet community.</abstract>
        <draft>draft-josefsson-mime-dns-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4028</doc-id>
        <title>Session Timers in the Session Initiation Protocol (SIP)</title>
        <author>
            <name>S. Donovan</name>
        </author>
        <author>
            <name>J. Rosenberg</name>
        </author>
        <date>
            <month>April</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>65363</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>re-invite request</kw>
            <kw>update request</kw>
            <kw>session-expires</kw>
            <kw>min-se</kw>
        </keywords>
        <abstract>This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a \%re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine whether the SIP session is still active. The extension defines two new header fields: \%Session-Expires, which conveys the lifetime of the session, and \%Min-SE, which conveys the minimum allowed value for the session timer. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-sip-session-timer-15</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4029</doc-id>
        <title>Scenarios and Analysis for Introducing IPv6 into ISP Networks</title>
        <author>
            <name>M. Lind</name>
        </author>
        <author>
            <name>V. Ksinant</name>
        </author>
        <author>
            <name>S. Park</name>
        </author>
        <author>
            <name>A. Baudot</name>
        </author>
        <author>
            <name>P. Savola</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>64388</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>internet service provider</kw>
            <kw>internet protocol</kw>
        </keywords>
        <abstract>This document describes different scenarios for the introduction of IPv6 into an ISP's existing IPv4 network without disrupting the IPv4 service. The scenarios for introducing IPv6 are analyzed, and the relevance of already defined transition mechanisms are evaluated. Known challenges are also identified. This memo provides information for the Internet community.</abstract>
        <draft>draft-ietf-v6ops-isp-scenarios-analysis-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4030</doc-id>
        <title>The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option</title>
        <author>
            <name>M. Stapp</name>
        </author>
        <author>
            <name>T. Lemon</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>34332</char-count>
            <page-count>15</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>The Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option (RFC 3046) conveys information between a DHCP Relay Agent and a DHCP server. This specification defines an authentication suboption for that option, containing a keyed hash in its payload. The suboption supports data integrity and replay protection for relayed DHCP messages. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-dhc-auth-suboption-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4031</doc-id>
        <title>Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)</title>
        <author>
            <name>M. Carugi</name>
            <title>Editor</title>
        </author>
        <author>
            <name>D. McDysan</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>118568</char-count>
            <page-count>50</page-count>
        </format>
        <keywords>
            <kw>l3vpn</kw>
            <kw>service provider</kw>
            <kw>vpn</kw>
        </keywords>
        <abstract>This document provides requirements for Layer 3 Virtual Private Networks (L3VPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use to provision a Virtual Private Network (VPN) service. This document expresses a service provider perspective, based upon past experience with IP-based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it first defines terminology and states general requirements. Detailed requirements are expressed from a customer perspective as well as that of a service provider. This memo provides information for the Internet community.</abstract>
        <draft>ietf-l3vpn-requirements-02</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4032</doc-id>
        <title>Update to the Session Initiation Protocol (SIP) Preconditions Framework</title>
        <author>
            <name>G. Camarillo</name>
        </author>
        <author>
            <name>P. Kyzivat</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>20492</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
            <kw>qos</kw>
            <kw>quality of service</kw>
            <kw>precondition</kw>
        </keywords>
        <abstract>This document updates RFC 3312, which defines the framework for preconditions in SIP. We provide guidelines for authors of new precondition types and describe how to use SIP preconditions in situations that involve session mobility. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-sip-rfc3312-update-03</draft>
        <updates>
            <doc-id>RFC3312</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4033</doc-id>
        <title>DNS Security Introduction and Requirements</title>
        <author>
            <name>R. Arends</name>
        </author>
        <author>
            <name>R. Austein</name>
        </author>
        <author>
            <name>M. Larson</name>
        </author>
        <author>
            <name>D. Massey</name>
        </author>
        <author>
            <name>S. Rose</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>52445</char-count>
            <page-count>21</page-count>
        </format>
        <keywords>
            <kw>domain name system</kw>
            <kw>authentication</kw>
            <kw>origin integrity</kw>
            <kw>dnssec</kw>
            <kw>domain name system security extensions</kw>
        </keywords>
        <abstract>The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-dnsext-dnssec-intro-13</draft>
        <obsoletes>
            <doc-id>RFC2535</doc-id>
            <doc-id>RFC3008</doc-id>
            <doc-id>RFC3090</doc-id>
            <doc-id>RFC3445</doc-id>
            <doc-id>RFC3655</doc-id>
            <doc-id>RFC3658</doc-id>
            <doc-id>RFC3755</doc-id>
            <doc-id>RFC3757</doc-id>
            <doc-id>RFC3845</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
            <doc-id>RFC2136</doc-id>
            <doc-id>RFC2181</doc-id>
            <doc-id>RFC2308</doc-id>
            <doc-id>RFC3225</doc-id>
            <doc-id>RFC3007</doc-id>
            <doc-id>RFC3597</doc-id>
            <doc-id>RFC3226</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4034</doc-id>
        <title>Resource Records for the DNS Security Extensions</title>
        <author>
            <name>R. Arends</name>
        </author>
        <author>
            <name>R. Austein</name>
        </author>
        <author>
            <name>M. Larson</name>
        </author>
        <author>
            <name>D. Massey</name>
        </author>
        <author>
            <name>S. Rose</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>63879</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>domain name system</kw>
            <kw>authentication</kw>
            <kw>origin integrity</kw>
            <kw>dnssec</kw>
            <kw>domain name system security extensions</kw>
        </keywords>
        <abstract>This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. &lt;br&gt; This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-dnsext-dnssec-records-11</draft>
        <obsoletes>
            <doc-id>RFC2535</doc-id>
            <doc-id>RFC3008</doc-id>
            <doc-id>RFC3090</doc-id>
            <doc-id>RFC3445</doc-id>
            <doc-id>RFC3655</doc-id>
            <doc-id>RFC3658</doc-id>
            <doc-id>RFC3755</doc-id>
            <doc-id>RFC3757</doc-id>
            <doc-id>RFC3845</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
            <doc-id>RFC2136</doc-id>
            <doc-id>RFC2181</doc-id>
            <doc-id>RFC2308</doc-id>
            <doc-id>RFC3225</doc-id>
            <doc-id>RFC3007</doc-id>
            <doc-id>RFC3597</doc-id>
            <doc-id>RFC3226</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4035</doc-id>
        <title>Protocol Modifications for the DNS Security Extensions</title>
        <author>
            <name>R. Arends</name>
        </author>
        <author>
            <name>R. Austein</name>
        </author>
        <author>
            <name>M. Larson</name>
        </author>
        <author>
            <name>D. Massey</name>
        </author>
        <author>
            <name>S. Rose</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>130589</char-count>
            <page-count>53</page-count>
        </format>
        <keywords>
            <kw>domain name system</kw>
            <kw>authentication</kw>
            <kw>origin integrity</kw>
            <kw>dnssec</kw>
            <kw>domain name system security extensions</kw>
        </keywords>
        <abstract>This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. &lt;br&gt; This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-dnsext-dnssec-protocol-09</draft>
        <obsoletes>
            <doc-id>RFC2535</doc-id>
            <doc-id>RFC3008</doc-id>
            <doc-id>RFC3090</doc-id>
            <doc-id>RFC3445</doc-id>
            <doc-id>RFC3655</doc-id>
            <doc-id>RFC3658</doc-id>
            <doc-id>RFC3755</doc-id>
            <doc-id>RFC3757</doc-id>
            <doc-id>RFC3845</doc-id>
        </obsoletes>
        <updates>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
            <doc-id>RFC2136</doc-id>
            <doc-id>RFC2181</doc-id>
            <doc-id>RFC2308</doc-id>
            <doc-id>RFC3225</doc-id>
            <doc-id>RFC3007</doc-id>
            <doc-id>RFC3597</doc-id>
            <doc-id>RFC3226</doc-id>
        </updates>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4036</doc-id>
        <title>Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management</title>
        <author>
            <name>W. Sawyer</name>
        </author>
        <date>
            <month>April</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>57946</char-count>
            <page-count>27</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>snmp</kw>
            <kw>simple network management protocol</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP)-based management of Data-over-Cable Service Interface Specification (DOCSIS)-compliant Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. The Differentiated Services MIB (RFC 3289) provides the filtering functions needed here, making use of classification items defined in this specification. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-ipcdn-subscriber-mib-16</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4037</doc-id>
        <title>Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core</title>
        <author>
            <name>A. Rousskov</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>131487</char-count>
            <page-count>56</page-count>
        </format>
        <keywords>
            <kw>callout server</kw>
        </keywords>
        <abstract>This document specifies the core of the Open Pluggable Edge Services (OPES) Callout Protocol (OCP). OCP marshals application messages from other communication protocols: An OPES intermediary sends original application messages to a callout server; the callout server sends adapted application messages back to the processor. OCP is designed with typical adaptation tasks in mind (e.g., virus and spam management, language and format translation, message anonymization, or advertisement manipulation). As defined in this document, the OCP Core consists of application-agnostic mechanisms essential for efficient support of typical adaptations. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-opes-ocp-core-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4038</doc-id>
        <title>Application Aspects of IPv6 Transition</title>
        <author>
            <name>M-K. Shin</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Y-G. Hong</name>
        </author>
        <author>
            <name>J. Hagino</name>
        </author>
        <author>
            <name>P. Savola</name>
        </author>
        <author>
            <name>E. M. Castro</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>69727</char-count>
            <page-count>33</page-count>
        </format>
        <abstract>As IPv6 networks are deployed and the network transition is discussed, one should also consider how to enable IPv6 support in applications running on IPv6 hosts, and the best strategy to develop IP protocol support in applications. This document specifies scenarios and aspects of application transition. It also proposes guidelines on how to develop IP version-independent applications during the transition period. This memo provides information for the Internet community.</abstract>
        <draft>draft-ietf-v6ops-application-transition-03</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4039</doc-id>
        <title>Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)</title>
        <author>
            <name>S. Park</name>
        </author>
        <author>
            <name>P. Kim</name>
        </author>
        <author>
            <name>B. Volz</name>
        </author>
        <date>
            <month>March</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>22297</char-count>
            <page-count>10</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>This document defines a new Dynamic Host Configuration Protocol version 4 (DHCPv4) option, modeled on the DHCPv6 Rapid Commit option, for obtaining IP address and configuration information using a 2-message exchange rather than the usual 4-message exchange, expediting client configuration. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-dhc-rapid-commit-opt-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4040</doc-id>
        <title>RTP Payload Format for a 64 kbit/s Transparent Call</title>
        <author>
            <name>R. Kreuter</name>
        </author>
        <date>
            <month>April</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15363</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>realtime transport protocol</kw>
        </keywords>
        <abstract>This document describes how to carry 64 kbit/s channel data transparently in RTP packets, using a pseudo-codec called "Clearmode". It also serves as registration for a related MIME type called "audio/clearmode". &lt;br&gt; "Clearmode" is a basic feature of VoIP Media Gateways. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-avt-rtp-clearmode-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4041</doc-id>
        <title>Requirements for Morality Sections in Routing Area Drafts</title>
        <author>
            <name>A. Farrel</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15249</char-count>
            <page-count>8</page-count>
        </format>
        <keywords>
            <kw>moral values</kw>
            <kw>moral code</kw>
        </keywords>
        <abstract>It has often been the case that morality has not been given proper consideration in the design and specification of protocols produced within the Routing Area. This has led to a decline in the moral values within the Internet and attempts to retrofit a suitable moral code to implemented and deployed protocols has been shown to be sub-optimal. &lt;br&gt; This document specifies a requirement for all new Routing Area Internet-Drafts to include a "Morality Considerations" section, and gives guidance on what that section should contain. This memo provides information for the Internet community.</abstract>
        <draft>draft-farrel-rtg-morality-requirements-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4042</doc-id>
        <title>UTF-9 and UTF-18 Efficient Transformation Formats of Unicode</title>
        <author>
            <name>M. Crispin</name>
        </author>
        <date>
            <month>April</month>
            <day>01</day>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>19123</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>universal character set</kw>
            <kw>ucs</kw>
            <kw>codeopints</kw>
            <kw>unicode</kw>
            <kw>utf-7</kw>
            <kw>utf-8</kw>
            <kw>utf-16</kw>
        </keywords>
        <abstract>ISO-10646 defines a large character set called the Universal Character Set (UCS), which encompasses most of the world's writing systems. The same set of codepoints is defined by Unicode, which further defines additional character properties and other implementation details. By policy of the relevant standardization committees, changes to Unicode and amendments and additions to ISO/IEC 10646 track each other, so that the character repertoires and code point assignments remain in synchronization. &lt;br&gt; The current representation formats for Unicode (UTF-7, UTF-8, UTF-16) are not storage and computation efficient on platforms that utilize the 9 bit nonet as a natural storage unit instead of the 8 bit octet. This document describes a transformation format of Unicode that takes advantage of the nonet so that the format will be storage and computation efficient. This memo provides information for the Internet community.</abstract>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4044</doc-id>
        <title>Fibre Channel Management MIB</title>
        <author>
            <name>K. McCloghrie</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>127148</char-count>
            <page-count>69</page-count>
        </format>
        <keywords>
            <kw>management information base</kw>
            <kw>fc-mgmt-mib</kw>
        </keywords>
        <abstract>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-ips-fcmgmt-mib-06</draft>
        <obsoletes>
            <doc-id>RFC2837</doc-id>
        </obsoletes>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4045</doc-id>
        <title>Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP)</title>
        <author>
            <name>G. Bourdon</name>
        </author>
        <date>
            <month>April</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>59140</char-count>
            <page-count>28</page-count>
        </format>
        <keywords>
            <kw>ppp</kw>
            <kw>point-to-point protocol</kw>
        </keywords>
        <abstract>The Layer Two Tunneling Protocol (L2TP) provides a method for tunneling PPP packets. This document describes an extension to L2TP, to make efficient use of L2TP tunnels within the context of deploying multicast services whose data will have to be conveyed by these tunnels. This memo defines an Experimental Protocol for the Internet community.</abstract>
        <draft>draft-ietf-l2tpext-mcast-05</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4046</doc-id>
        <title>Multicast Security (MSEC) Group Key Management Architecture</title>
        <author>
            <name>M. Baugher</name>
        </author>
        <author>
            <name>R. Canetti</name>
        </author>
        <author>
            <name>L. Dondeti</name>
        </author>
        <author>
            <name>F. Lindholm</name>
        </author>
        <date>
            <month>April</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>97885</char-count>
            <page-count>38</page-count>
        </format>
        <keywords>
            <kw>group security association</kw>
            <kw>gsa</kw>
        </keywords>
        <abstract>This document defines the common architecture for Multicast Security (MSEC) key management protocols to support a variety of application, transport, and network layer security protocols. It also defines the group security association (GSA), and describes the key management protocols that help establish a GSA. The framework and guidelines described in this document permit a modular and flexible design of group key management protocols for a variety of different settings that are specialized to applications needs. MSEC key management protocols may be used to facilitate secure one-to-many, many-to-many, or one-to-one communication. This memo provides information for the Internet community.</abstract>
        <draft>draft-ietf-msec-gkmarch-08</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4047</doc-id>
        <title>MIME Sub-type Registrations for Flexible Image Transport System (FITS)</title>
        <author>
            <name>S. Allen</name>
        </author>
        <author>
            <name>D. Wells</name>
        </author>
        <date>
            <month>April</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>53737</char-count>
            <page-count>23</page-count>
        </format>
        <keywords>
            <kw>multipurpose internet mail extensions</kw>
            <kw>astronomical observations</kw>
        </keywords>
        <abstract>This document describes the registration of the Multipurpose Internet Mail Extensions (MIME) sub-types to be used by the international astronomical community for the interchange of Flexible Image Transport System (FITS) files. The encoding is defined by the published FITS standard documents. The FITS format has been in use since 1979, and almost all data from astronomical observations are interchanged by using FITS. This memo provides information for the Internet community.</abstract>
        <draft>draft-allen-fitsmime-00</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4048</doc-id>
        <title>RFC 1888 Is Obsolete</title>
        <author>
            <name>B. Carpenter</name>
        </author>
        <date>
            <month>April</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>7394</char-count>
            <page-count>4</page-count>
        </format>
        <keywords>
            <kw>Internet</kw>
            <kw>Protocol</kw>
            <kw>Open</kw>
            <kw>Systems</kw>
            <kw>Interconnection</kw>
        </keywords>
        <abstract>This document recommends that RFC 1888, on Open Systems Interconnection (OSI) Network Service Access Points (NSAPs) and IPv6, be reclassified as Historic, as most of it has no further value, apart from one section, which is faulty. This memo provides information for the Internet community.</abstract>
        <draft>draft-carpenter-obsolete-1888-01</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4049</doc-id>
        <title>BinaryTime: An Alternate Format for Representing Date and Time in ASN.1</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>April</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>12302</char-count>
            <page-count>7</page-count>
        </format>
        <keywords>
            <kw>signing-time attribute</kw>
            <kw>cryptographic message syntax</kw>
            <kw>cms</kw>
            <kw>SignedData</kw>
            <kw>AuthenticatedData</kw>
        </keywords>
        <abstract>This document specifies a new ASN.1 type for representing time: BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax (CMS) SignedData and AuthenticatedData content types; the binary-signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 3852. This memo defines an Experimental Protocol for the Internet community.</abstract>
        <draft>draft-housley-binarytime-02</draft>
        <current-status>EXPERIMENTAL</current-status>
        <publication-status>EXPERIMENTAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4050</doc-id>
        <title>Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures</title>
        <author>
            <name>S. Blake-Wilson</name>
        </author>
        <author>
            <name>G. Karlinger</name>
        </author>
        <author>
            <name>T. Kobayashi</name>
        </author>
        <author>
            <name>Y. Wang</name>
        </author>
        <date>
            <month>April</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35327</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>elliptic curve digital signature algorithm</kw>
            <kw>ecdsa</kw>
            <kw>elliptic curve cryptography</kw>
            <kw>ecc</kw>
            <kw>xml</kw>
            <kw>digital signatures</kw>
            <kw>xml dsig</kw>
            <kw>xml</kw>
        </keywords>
        <abstract>This document specifies how to use Elliptic Curve Digital Signature Algorithm (ECDSA) with XML Signatures. The mechanism specified provides integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or included by reference. This memo provides information for the Internet community.</abstract>
        <draft>draft-blake-wilson-xmldsig-ecdsa-09</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4051</doc-id>
        <title>Additional XML Security Uniform Resource Identifiers (URIs)</title>
        <author>
            <name>D. Eastlake 3rd</name>
        </author>
        <date>
            <month>April</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>33368</char-count>
            <page-count>17</page-count>
        </format>
        <keywords>
            <kw>digital signatures</kw>
            <kw>encryption</kw>
            <kw>canonicalization</kw>
        </keywords>
        <abstract>A number of Uniform Resource Identifiers (URIs) intended for use with XML Digital Signatures, Encryption, and Canonicalization are defined. These URIs identify algorithms and types of keying information. [STANDARDS TRACK]</abstract>
        <draft>draft-eastlake-xmldsig-uri-09</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4052</doc-id>
        <title>IAB Processes for Management of IETF Liaison Relationships</title>
        <author>
            <name>L. Daigle</name>
            <title>Editor</title>
        </author>
        <author>
            <name>Internet Architecture Board</name>
        </author>
        <date>
            <month>April</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>18360</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>internet architecture board</kw>
            <kw>sdo</kw>
            <kw>standards development organization</kw>
        </keywords>
        <abstract>This document discusses the procedures used by the IAB to establish and maintain liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora. This document also discusses the appointment and responsibilities of IETF liaison managers and representatives, and the expectations of the IAB for organizations with whom liaison relationships are established. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>draft-iab-liaison-mgt-03</draft>
        <is-also>
            <doc-id>BCP0102</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4053</doc-id>
        <title>Procedures for Handling Liaison Statements to and from the IETF</title>
        <author>
            <name>S. Trowbridge</name>
        </author>
        <author>
            <name>S. Bradner</name>
        </author>
        <author>
            <name>F. Baker</name>
        </author>
        <date>
            <month>April</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>38816</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>sdo</kw>
            <kw>standards develoopment organization</kw>
        </keywords>
        <abstract>This document describes the procedure for proper handling of incoming liaison statements from other standards development organizations (SDOs), consortia, and industry fora, and for generating liaison statements to be transmitted from IETF to other SDOs, consortia and industry fora. This procedure allows IETF to effectively collaborate with other organizations in the international standards community. &lt;br&gt; The IETF expects that liaison statements might come from a variety of organizations, and it may choose to respond to many of those. The IETF is only obligated to respond if there is an agreed liaison relationship, however. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>draft-baker-liaison-statements-04</draft>
        <is-also>
            <doc-id>BCP0103</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4054</doc-id>
        <title>Impairments and Other Constraints on Optical Layer Routing</title>
        <author>
            <name>J. Strand</name>
            <title>Editor</title>
        </author>
        <author>
            <name>A. Chiu</name>
            <title>Editor</title>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>73327</char-count>
            <page-count>29</page-count>
        </format>
        <keywords>
            <kw>diversity</kw>
            <kw>routing</kw>
            <kw>path selection</kw>
            <kw>impariment</kw>
            <kw>ase</kw>
            <kw>pmd</kw>
            <kw>optical control plane</kw>
            <kw>gmpls</kw>
        </keywords>
        <abstract>Optical networking poses a number challenges for Generalized Multi-Protocol Label Switching (GMPLS). Fundamentally, optical technology is an analog rather than digital technology whereby the optical layer is lowest in the transport hierarchy and hence has an intimate relationship with the physical geography of the network. This contribution surveys some of the aspects of optical networks that impact routing and identifies possible GMPLS responses for each: (1) Constraints arising from the design of new software controllable network elements, (2) Constraints in a single all-optical domain without wavelength conversion, (3) Complications arising in more complex networks incorporating both all-optical and opaque architectures, and (4) Impacts of diversity constraints. This memo provides information for the Internet community.</abstract>
        <draft>draft-ietf-ipo-impairments-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4059</doc-id>
        <title>Internet X.509 Public Key Infrastructure Warranty Certificate Extension</title>
        <author>
            <name>D. Linsenbardt</name>
        </author>
        <author>
            <name>S. Pontius</name>
        </author>
        <author>
            <name>A. Sturgeon</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17904</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>certificate authority</kw>
            <kw>ca</kw>
            <kw>insurance policy</kw>
        </keywords>
        <abstract>This document describes a certificate extension to explicitly state the warranty offered by a Certificate Authority (CA) for the certificate containing the extension. This memo provides information for the Internet community.</abstract>
        <draft>draft-ietf-pkix-warranty-extn-04</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4060</doc-id>
        <title>RTP Payload Formats for European Telecommunications Standards Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding</title>
        <author>
            <name>Q. Xie</name>
        </author>
        <author>
            <name>D. Pearce</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>39654</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>real-time transport protocol</kw>
            <kw>dsr</kw>
            <kw>distributed speeech recognition</kw>
            <kw>xfe</kw>
            <kw>extended front-end</kw>
            <kw>xafe</kw>
            <kw>extended advanced front-end</kw>
        </keywords>
        <abstract>This document specifies RTP payload formats for encapsulating European Telecommunications Standards Institute (ETSI) European Standard ES 202 050 DSR Advanced Front-end (AFE), ES 202 211 DSR Extended Front-end (XFE), and ES 202 212 DSR Extended Advanced Front-end (XAFE) signal processing feature streams for distributed speech recognition (DSR) systems. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-avt-rtp-dsr-codecs-03</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4061</doc-id>
        <title>Benchmarking Basic OSPF Single Router Control Plane Convergence</title>
        <author>
            <name>V. Manral</name>
        </author>
        <author>
            <name>R. White</name>
        </author>
        <author>
            <name>A. Shaikh</name>
        </author>
        <date>
            <month>April</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>32706</char-count>
            <page-count>16</page-count>
        </format>
        <keywords>
            <kw>spf time</kw>
            <kw>adjacency formation time</kw>
        </keywords>
        <abstract>This document provides suggestions for measuring OSPF single router control plane convergence. Its initial emphasis is on the control plane of a single OSPF router. We do not address forwarding plane performance. &lt;br&gt; NOTE: In this document, the word "convergence" relates to single router control plane convergence only. This memo provides information for the Internet community.</abstract>
        <draft>draft-ietf-bmwg-ospfconv-intraarea-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4062</doc-id>
        <title>OSPF Benchmarking Terminology and Concepts</title>
        <author>
            <name>V. Manral</name>
        </author>
        <author>
            <name>R. White</name>
        </author>
        <author>
            <name>A. Shaikh</name>
        </author>
        <date>
            <month>April</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>15784</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>spf time</kw>
            <kw>adjacency formation time</kw>
        </keywords>
        <abstract>This document explains the terminology and concepts used in OSPF benchmarking. Although some of these terms may be defined elsewhere (and we will refer the reader to those definitions in some cases) we include discussions concerning these terms, as they relate specifically to the tasks involved in benchmarking the OSPF protocol. This memo provides information for the Internet community.</abstract>
        <draft>draft-ietf-bmwg-ospfconv-term-10</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4063</doc-id>
        <title>Considerations When Using Basic OSPF Convergence Benchmarks</title>
        <author>
            <name>V. Manral</name>
        </author>
        <author>
            <name>R. White</name>
        </author>
        <author>
            <name>A. Shaikh</name>
        </author>
        <date>
            <month>April</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>23401</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
            <kw>spf time</kw>
            <kw>adjacency formation time</kw>
        </keywords>
        <abstract>This document discusses the applicability of various tests for measuring single router control plane convergence, specifically in regard to the Open Shortest First (OSPF) protocol. There are two general sections in this document, the first discusses advantages and limitations of specific OSPF convergence tests, and the second discusses more general pitfalls to be considered when routing protocol convergence is tested. This memo provides information for the Internet community.</abstract>
        <draft>draft-ietf-bmwg-ospfconv-applicability-07</draft>
        <current-status>INFORMATIONAL</current-status>
        <publication-status>INFORMATIONAL</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4069</doc-id>
        <title>Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding</title>
        <author>
            <name>M. Dodge</name>
        </author>
        <author>
            <name>B. Ray</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>35712</char-count>
            <page-count>19</page-count>
        </format>
        <keywords>
            <kw>mib</kw>
            <kw>management information base</kw>
            <kw>VDSL-LINE-MIB</kw>
            <kw>VDSL-LINE-EXT-SCM-MIB</kw>
        </keywords>
        <abstract>This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Single Carrier Modulation (SCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB, RFC 3728, which handles line code independent objects. [STANDARDS TRACK]</abstract>
        <draft>draft-ietf-adslmib-vdsl-ext-scm-08</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4070</doc-id>
        <title>Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding</title>
        <author>
            <name>M. Dodge</name>
        </author>
        <author>
            <name>B. Ray</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48561</char-count>
            <page-count>24</page-count>
        </format>
        <keywords>
            <kw>management information base</kw>
            <kw>mib</kw>
            <kw>VDSL-LINE-MIB</kw>
            <kw>VDSL-LINE-EXT-MCM-MIB</kw>
        </keywords>
        <abstract>This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Multiple Carrier Modulation (MCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB, RFC 3728, which handles line code independent objects. [PROPOSED STANDARD]</abstract>
        <draft>draft-ietf-adslmib-vdsl-ext-mcm-06</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4071</doc-id>
        <title>Structure of the IETF Administrative Support Activity (IASA)</title>
        <author>
            <name>R. Austein</name>
            <title>Editor</title>
        </author>
        <author>
            <name>B. Wijnen</name>
            <title>Editor</title>
        </author>
        <date>
            <month>April</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>48614</char-count>
            <page-count>20</page-count>
        </format>
        <keywords>
            <kw>isoc</kw>
            <kw>ietf administrative oversight committee</kw>
            <kw>IAOC</kw>
            <kw>ietf administrative director</kw>
            <kw>iad</kw>
        </keywords>
        <abstract>This document describes the structure of the IETF Administrative Support Activity (IASA) as an activity housed within the Internet Society (ISOC). It defines the roles and responsibilities of the IETF Administrative Oversight Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IAOC. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>draft-ietf-iasa-bcp-07</draft>
        <is-also>
            <doc-id>BCP0101</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4073</doc-id>
        <title>Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)</title>
        <author>
            <name>R. Housley</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>17103</char-count>
            <page-count>9</page-count>
        </format>
        <keywords>
            <kw>content collection</kw>
        </keywords>
        <abstract>This document describes a convention for using the Cryptographic Message Syntax (CMS) to protect a content collection. If desired, attributes can be associated with the content. [STANDARDS TRACK]</abstract>
        <draft>draft-housley-contentcollection-05</draft>
        <current-status>PROPOSED STANDARD</current-status>
        <publication-status>PROPOSED STANDARD</publication-status>
    </rfc-entry>
    <rfc-entry>
        <doc-id>RFC4084</doc-id>
        <title>Terminology for Describing Internet Connectivity</title>
        <author>
            <name>J. Klensin</name>
        </author>
        <date>
            <month>May</month>
            <year>2005</year>
        </date>
        <format>
            <file-format>ASCII</file-format>
            <char-count>24522</char-count>
            <page-count>11</page-count>
        </format>
        <keywords>
        </keywords>
        <abstract>As the Internet has evolved, many types of arrangements have been advertised and sold as "Internet connectivity". Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, the effort to distinguish between these services has caused considerable consumer confusion. This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</abstract>
        <draft>draft-klensin-ip-service-terms-04</draft>
        <is-also>
            <doc-id>BCP0104</doc-id>
        </is-also>
        <current-status>BEST CURRENT PRACTICE</current-status>
        <publication-status>BEST CURRENT PRACTICE</publication-status>
    </rfc-entry>
    <std-entry>
        <doc-id>STD0001</doc-id>
        <title>Internet Official Protocol Standards</title>
        <is-also>
            <doc-id>RFC3700</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0002</doc-id>
        <title>[Reserved for Assigned Numbers.  See RFC 1700 and RFC 3232.]</title>
        <is-also>
            <doc-id>RFC1700</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0003</doc-id>
        <title>Requirements for Internet Hosts</title>
        <is-also>
            <doc-id>RFC1122</doc-id>
            <doc-id>RFC1123</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0004</doc-id>
        <title>[Reserved for Router Requirements.  See RFC 1812.]</title>
    </std-entry>
    <std-entry>
        <doc-id>STD0005</doc-id>
        <title>Internet Protocol</title>
        <is-also>
            <doc-id>RFC0791</doc-id>
            <doc-id>RFC0792</doc-id>
            <doc-id>RFC0919</doc-id>
            <doc-id>RFC0922</doc-id>
            <doc-id>RFC0950</doc-id>
            <doc-id>RFC1112</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0006</doc-id>
        <title>User Datagram Protocol</title>
        <is-also>
            <doc-id>RFC0768</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0007</doc-id>
        <title>Transmission Control Protocol</title>
        <is-also>
            <doc-id>RFC0793</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0008</doc-id>
        <title>Telnet Protocol</title>
        <is-also>
            <doc-id>RFC0854</doc-id>
            <doc-id>RFC0855</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0009</doc-id>
        <title>File Transfer Protocol</title>
        <is-also>
            <doc-id>RFC0959</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0010</doc-id>
        <title>Simple Mail Transfer Protocol</title>
        <is-also>
            <doc-id>RFC0821</doc-id>
            <doc-id>RFC1869</doc-id>
            <doc-id>RFC974</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0011</doc-id>
        <title>STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES</title>
        <is-also>
            <doc-id>RFC0822</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0012</doc-id>
        <title>[Reserved for Network Time Protocol (NTP).  See RFC 1305.]</title>
    </std-entry>
    <std-entry>
        <doc-id>STD0013</doc-id>
        <title>Domain Name System</title>
        <is-also>
            <doc-id>RFC1034</doc-id>
            <doc-id>RFC1035</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0014</doc-id>
        <title>[Was Mail Routing and the Domain System.  Now Historic.]</title>
    </std-entry>
    <std-entry>
        <doc-id>STD0015</doc-id>
        <title>[Was Simple Network Management Protocol.  Now Historic.]</title>
    </std-entry>
    <std-entry>
        <doc-id>STD0016</doc-id>
        <title>Structure of Management Information</title>
        <is-also>
            <doc-id>RFC1155</doc-id>
            <doc-id>RFC1212</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0017</doc-id>
        <title>Management Information Base</title>
        <is-also>
            <doc-id>RFC1213</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0018</doc-id>
        <title>[Was Exterior Gateway Protocol (RFC 904).  Now Historic.]</title>
    </std-entry>
    <std-entry>
        <doc-id>STD0019</doc-id>
        <title>NetBIOS Service Protocols</title>
        <is-also>
            <doc-id>RFC1001</doc-id>
            <doc-id>RFC1002</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0020</doc-id>
        <title>Echo Protocol</title>
        <is-also>
            <doc-id>RFC0862</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0021</doc-id>
        <title>Discard Protocol</title>
        <is-also>
            <doc-id>RFC0863</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0022</doc-id>
        <title>Character Generator Protocol</title>
        <is-also>
            <doc-id>RFC0864</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0023</doc-id>
        <title>Quote of the Day Protocol</title>
        <is-also>
            <doc-id>RFC0865</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0024</doc-id>
        <title>Active Users Protocol</title>
        <is-also>
            <doc-id>RFC0866</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0025</doc-id>
        <title>Daytime Protocol</title>
        <is-also>
            <doc-id>RFC0867</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0026</doc-id>
        <title>Time Server Protocol</title>
        <is-also>
            <doc-id>RFC0868</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0027</doc-id>
        <title>Binary Transmission Telnet Option</title>
        <is-also>
            <doc-id>RFC0856</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0028</doc-id>
        <title>Echo Telnet Option</title>
        <is-also>
            <doc-id>RFC0857</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0029</doc-id>
        <title>Suppress Go Ahead Telnet Option</title>
        <is-also>
            <doc-id>RFC0858</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0030</doc-id>
        <title>Status Telnet Option</title>
        <is-also>
            <doc-id>RFC0859</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0031</doc-id>
        <title>Timing Mark Telnet Option</title>
        <is-also>
            <doc-id>RFC0860</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0032</doc-id>
        <title>Extended Options List Telnet Option</title>
        <is-also>
            <doc-id>RFC0861</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0033</doc-id>
        <title>Trivial File Transfer Protocol</title>
        <is-also>
            <doc-id>RFC1350</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0034</doc-id>
        <title>[Was Routing Information Protocol (RIP).  Replaced by STD 56.]</title>
    </std-entry>
    <std-entry>
        <doc-id>STD0035</doc-id>
        <title>ISO Transport Service on top of the TCP (Version: 3)</title>
        <is-also>
            <doc-id>RFC1006</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0036</doc-id>
        <title>Transmission of IP and ARP over FDDI Networks</title>
        <is-also>
            <doc-id>RFC1390</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0037</doc-id>
        <title>An Ethernet Address Resolution Protocol</title>
        <is-also>
            <doc-id>RFC0826</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0038</doc-id>
        <title>A Reverse Address Resolution Protocol</title>
        <is-also>
            <doc-id>RFC0903</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0039</doc-id>
        <title>[Was BBN Report 1822 (IMP/Host Interface).  Now Historic.]</title>
    </std-entry>
    <std-entry>
        <doc-id>STD0040</doc-id>
        <title>Host Access Protocol specification</title>
        <is-also>
            <doc-id>RFC0907</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0041</doc-id>
        <title>Standard for the transmission of IP datagrams over Ethernet networks</title>
        <is-also>
            <doc-id>RFC0894</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0042</doc-id>
        <title>Standard for the transmission of IP datagrams over experimental Ethernetnetworks</title>
        <is-also>
            <doc-id>RFC0895</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0043</doc-id>
        <title>Standard for the transmission of IP datagrams over IEEE 802 networks</title>
        <is-also>
            <doc-id>RFC1042</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0044</doc-id>
        <title>DCN Local-Network Protocols</title>
        <is-also>
            <doc-id>RFC0891</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0045</doc-id>
        <title>Internet Protocol on Network System's HYPERchannel: Protocol Specification</title>
        <is-also>
            <doc-id>RFC1044</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0046</doc-id>
        <title>Transmitting IP traffic over ARCNET networks</title>
        <is-also>
            <doc-id>RFC1201</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0047</doc-id>
        <title>Nonstandard for transmission of IP datagrams over serial lines: SLIP</title>
        <is-also>
            <doc-id>RFC1055</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0048</doc-id>
        <title>Standard for the transmission of IP datagrams over NetBIOS networks</title>
        <is-also>
            <doc-id>RFC1088</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0049</doc-id>
        <title>Standard for the transmission of 802.2 packets over IPX networks</title>
        <is-also>
            <doc-id>RFC1132</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0050</doc-id>
        <title>[Reserved for Definitions of Managed Objects for the Ethernet-like Interface Types.  See RFC 3638.]</title>
    </std-entry>
    <std-entry>
        <doc-id>STD0051</doc-id>
        <title>The Point-to-Point Protocol (PPP)</title>
        <is-also>
            <doc-id>RFC1661</doc-id>
            <doc-id>RFC1662</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0052</doc-id>
        <title>The Transmission of IP Datagrams over the SMDS Service</title>
        <is-also>
            <doc-id>RFC1209</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0053</doc-id>
        <title>Post Office Protocol - Version 3</title>
        <is-also>
            <doc-id>RFC1939</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0054</doc-id>
        <title>OSPF Version 2</title>
        <is-also>
            <doc-id>RFC2328</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0055</doc-id>
        <title>Multiprotocol Interconnect over Frame Relay</title>
        <is-also>
            <doc-id>RFC2427</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0056</doc-id>
        <title>RIP Version 2</title>
        <is-also>
            <doc-id>RFC2453</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0057</doc-id>
        <title>RIP Version 2 Protocol Applicability Statement</title>
        <is-also>
            <doc-id>RFC1722</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0058</doc-id>
        <title>Structure of Management Information Version 2 (SMIv2)</title>
        <is-also>
            <doc-id>RFC2578</doc-id>
            <doc-id>RFC2579</doc-id>
            <doc-id>RFC2580</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0059</doc-id>
        <title>Remote Network Monitoring Management Information Base</title>
        <is-also>
            <doc-id>RFC2819</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0060</doc-id>
        <title>SMTP Service Extension for Command Pipelining</title>
        <is-also>
            <doc-id>RFC2920</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0061</doc-id>
        <title>A One-Time Password System</title>
        <is-also>
            <doc-id>RFC2289</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0062</doc-id>
        <title>Simple Network Management Protocol Version 3 (SNMPv3)</title>
        <is-also>
            <doc-id>RFC3411</doc-id>
            <doc-id>RFC3412</doc-id>
            <doc-id>RFC3413</doc-id>
            <doc-id>RFC3414</doc-id>
            <doc-id>RFC3415</doc-id>
            <doc-id>RFC3416</doc-id>
            <doc-id>RFC3417</doc-id>
            <doc-id>RFC3418</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0063</doc-id>
        <title>UTF-8, a transformation format of ISO 10646</title>
        <is-also>
            <doc-id>RFC3629</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0064</doc-id>
        <title>RTP: A Transport Protocol for Real-Time Applications</title>
        <is-also>
            <doc-id>RFC3550</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0065</doc-id>
        <title>RTP Profile for Audio and Video Conferences with Minimal Control</title>
        <is-also>
            <doc-id>RFC3551</doc-id>
        </is-also>
    </std-entry>
    <std-entry>
        <doc-id>STD0066</doc-id>
        <title>Uniform Resource Identifier (URI): Generic Syntax</title>
        <is-also>
            <doc-id>RFC3986</doc-id>
        </is-also>
    </std-entry>
</rfc-index>
